15facebook0twittertはてぶ1グラフデータベースNeo4jの実践的な利用方法の1例を紹介するために始めたトライアルプロジェクトがいよいよ最終回を迎えました。今回は、トライアルプロジェクトを進めているなかで発生した問題点などの改善策を盛り込んだデータモデルを利用して理想の相手を探してみたいと思います。第3回目:どのように改善したらいいのか第4回目:改善したデータモデルによるデータ処理(今回)追加のサブドメイン作成及びデータロードデータモデル最終的に完成したデータモデルは以下のようなものです。波線のようにリクエスト用のサブドメイン(RE_CATEGORY)と必須要素のフィルター条件用のサブドメイン(FI_CATEGORY)を追加し、居住地域のフィルター条件は人(:Person)の属性(filter_location)として持たせています。FI:Filterこれから、改善したデータモデルに基づいてノードを追加していFきます。この作業を行いたくない方は、完成したグラフデータベースをダウンロードして利用してください。konkatu-4.gdb.zip完成したグラフデータベースを利用する方は、『M04さんのデータ処理をやってみる』に進んでください。次のCypherクエリーをすべてWebインターフェースに入力して実行してください。list[i]}))結果を確認してみましょう。次のCypherクエリーをWebインターフェースに入力して実行し、ラベル、要素の集合、要素数を確認してください。次のCypherクエリーをすべてWebインターフェースに入力して実行してください。list[i]}))結果を確認してみましょう。次のCypherクエリーをWebインターフェースに入力して実行し、ラベル、要素の集合、要素数を確認してください。次のCypherクエリーをすべてWebインターフェースに入力して実行してください。*CREATEman-[:RE_ALCOHOL]->a1,man-[:RE_BORN]->a2,man-[:RE_BORN]->b2,man-[:RE_BORN]->c2,man-[:RE_BORN]->d2,man-[:RE_BORN]->e2,man-[:RE_BORN]->f2,man-[:RE_BORN]->g2,man-[:RE_BORN]->h2,man-[:RE_BORN]->i2,man-[:RE_EDUCATION]->a3,man-[:RE_EDUCATION]->b3,man-[:RE_EDUCATION]->c3,man-[:RE_FORTUNETELLING]->a4,man-[:RE_HEALTHCARE]->a5,man-[:RE_HEIGHT]->a6,man-[:RE_HEIGHT]->b6,man-[:RE_HEIGHT]->c6,man-[:RE_HOLIDAY]->a7,man-[:RE_INCOME]->a8,man-[:RE_INCOME]->b8,man-[:RE_INCOME]->c8,man-[:RE_INCOME]->d8,man-[:RE_INCOME]->e8,man-[:RE_INCOME]->f8,man-[:RE_INCOME]->g8,man-[:RE_INCOME]->h8,man-[:RE_INCOME]->i8,man-[:RE_INDOOR]->a9,man-[:RE_INDOOR]->b9,man-[:RE_JOB]->a10,man-[:RE_JOB]->b10,man-[:RE_JOB]->c10,man-[:RE_JOB]->d10,man-[:RE_JOB]->e10,man-[:RE_JOB]->f10,man-[:RE_JOB]->g10,man-[:RE_JOB]->h10,man-[:RE_JOB]->i10,man-[:RE_JOB]->j10,man-[:RE_JOB]->k10,man-[:RE_KARAOKE]->a11,man-[:RE_LOCATION]->a12,man-[:RE_LOCATION]->b12,man-[:RE_LOCATION]->c12,man-[:RE_LOCATION]->d12,man-[:RE_MARITALHISTORY]->a13,man-[:RE_MEET]->a14,man-[:RE_OUTDOOR]->a15,man-[:RE_OUTDOOR]->b15,man-[:RE_PERSONALITY]->a16,man-[:RE_PERSONALITY]->b16,man-[:RE_PET]->a17,man-[:RE_SMOKING]->a18,man-[:RE_SPORT]->a19,man-[:RE_SPORT]->b19,man-[:RE_SPORT]->c19,man-[:RE_SPORT]->d19,man-[:RE_SPORT]->e19,man-[:RE_SPORT]->f19,man-[:RE_SPORT]->g19,man-[:RE_SPORT]->h19,man-[:RE_SPORT]->i19,man-[:RE_TALK]->a20グラフをサンプリングして実行結果を確認してみましょう。以下は教育水準のグラフです。rしかし大量のグラフを作成した場合、都度目視で確認することは困難です。次のようにタイプや要素、数を確認するCypherクエリーを利用しましょう。次のCypherクエリーをすべてWebインターフェースに入力して実行してください。*CREATEman-[:FI_BORN]->a1,man-[:FI_BORN]->b1,man-[:FI_BORN]->c1,man-[:FI_BORN]->d1,man-[:FI_BORN]->e1,man-[:FI_BORN]->f1,man-[:FI_BORN]->g1,man-[:FI_BORN]->h1,man-[:FI_BORN]->i1,man-[:FI_BORN]->j1,man-[:FI_BORN]->k1,man-[:FI_BORN]->l1,man-[:FI_BORN]->m1,man-[:FI_BORN]->n1,man-[:FI_BORN]->o1,man-[:FI_BORN]->p1,man-[:FI_BORN]->q1,man-[:FI_EDUCATION]->a3,man-[:FI_EDUCATION]->b3,man-[:FI_EDUCATION]->c3,man-[:FI_HEIGHT]->a4,man-[:FI_HEIGHT]->b4,man-[:FI_HEIGHT]->c4,man-[:FI_HEIGHT]->d4,man-[:FI_JOB]->a5,man-[:FI_JOB]->b5居住地域も忘れないでください。man.filter_location="北海道|青森県|岩手県|宮城県|秋田県|山形県|福島県|茨城県|栃木県|群馬県|新潟県|富山県|石川県|福井県|山梨県|長野県|岐阜県|静岡県|愛知県|三重県|滋賀県|京都府|大阪府|兵庫県|奈良県|和歌山県|鳥取県|島根県|岡山県|広島県|山口県|徳島県|香川県|愛媛県|高知県|福岡県|佐賀県|長崎県|熊本県|大分県|宮崎県|鹿児島県|沖縄県"グラフをサンプリングして実行結果を確認してみましょう。以下は、教育水準のグラフです。r次のCypherクエリーを利用してタイプや要素、数を確認しましょう。2最後に、居住地域のフィルター条件を確認してみましょう。沖縄県]M04さんのデータ処理をやってみるここで、この連載を愛読している皆様にご了承を得たいことがあります。第2回目のデータ処理時のCypherクエリーのフィルター条件の設定に間違いがあることが分かりました。第2回目のCypherクエリーの間違いを直して実行してみてから、今回のデータ処理をさせて頂きます。以下のCypherクエリーが第2回目の間違いを訂正したクエリー文です。今回の分析で候補者26人のなかでM04さんのリクエストに合っている人は5人しか存在しないことが分かりました。10以下は出力される結果の例です。0.55第2回目のデータ処理時のCypherクエリーの間違いは次の通りです。・必須条件のフィルター要素を年齢のみにしていました。・必須条件のフィルターを実行するクエリーブロックの箇所をリクエスト要素とのパターンマッチを実行してから行っていました。これは、データ処理量を減らすためにも、不正確なパターンを見逃さないためにも、その前のクエリーブロックで実行すべきことでした。今回のCypherクエリーでは、すべてのパターンの取得をCypherクエリーのなかで自己完結しています。第2回目のデータ処理時のCypherクエリーと比較してみてください。各種リストの要素が剥き出しになっている箇所がすべてなくなっています。10以下のような結果が出力されます。0.55しかしながらM04さんのリクエストに合っている人は5人しか存在しないことは変わりません。今回のトライアルプロジェクトで登録している女性の人数が少ないためですが、それでも26人のなかでの5人という結果は少し寂しいかもしれませんね。M04さん、頑張ってください!M04さんの候補者でリクエストと異なる要素をみる前項の5人の候補者の情報からM04さんのリクエストと一致しない要素を出してみます。必須条件としては出してないですが、内心、これだけはM04さんの気持ちでは勘弁してほしいと思うことがあるかもしれません。以下のような結果が出力されます。犬派]まとめこれで「婚活プロジェクト」の連載は終了させて頂きます。今回のトライアルプロジェクトは、現実の世界に有り得ることを素材にしてはいますが、様々なことを単純化しています。今回のデータモデルや処理方法が、このようなケースにおけるベストプラクティスとは思っておりません。お気づきのところがありましたら是非コメントを頂けると幸いです。ここまで愛読して頂いた方達に何か役に立つことが1つでもあったとすれば幸いです。Twitterなど、世界をリードするIT企業では、既に10年以上前から「情報と情報の繋がりは価値である」いう思想を持っていたようです。これらの企業達は、繋がりを起業や新しいサービス展開のための中核に据えていたと言われています。繋がりを利用するための手段(グラフデータベース)の開発や利用にも熱心に取り組んできました。汎用型グラフデータベースとも言えるNeo4jも、これらの企業の思想や技術に影響を受けているといわれています。従来のリレーショナルデータベースの考え方から言うと、繋がりはER図やジョインなどのための紐付と表現し、情報を検索するための手段という位置づけでした。情報を検索するための手段というのも重要なことですが、「情報と情報の繋がりは価値である」という思想とは、大きな隔たりがあるような気がします。グラフデータベースを利用するに当たっては、この思想の違いを理解して頂きたいです。存在する繋がりから新しい価値を発掘する、繋がりが存在しなかった箇所に繋がりを作ることで、さらに新しい価値連鎖を引き起こすことが、これからグラフデータベースがもたらす未来なのかも知れません。AuthorleefacebookTwitterデータベースが大好きなサーバサイドのエンジニア。Neo4j、MongoDBのテクニカルサポート、IoTビックデータ処理基盤のアーキテクトとして活動しています。LABの情報を逃さずチェックしよう!メールアドレスを登録すると記事が投稿されるとメールで通知します。※登録後メールに記載しているリンクをクリックして認証してください。#21)に、弊社エンジニア李が登壇します。LABの情報を逃さずチェックしよう!メールアドレスを登録すると記事が投稿されるとメールで通知します。※登録後メールに記載しているリンクをクリックして認証してください。