クエリーを開発してみようという企画です。したい方のため、構想段階から進行過程、収束に至るまでのすべて経過を、順を追って連載で詳しく紹介していきます。冒頭で唐突に「予測」という言葉を使っているのでこれについて説明します。本領」ではないかと考えています。Neo4jには様々なユースケースがありますがその間には一見あまり共通性はありません。オペレーションなどの最終結果は、まるで何の関係もないように見えます。それは該当のシステムが提供するサービスのことであり、機能ではありません。実際にデータモデルやデータ処理のアルゴリズムを組み立てるレベルではどうでしょうか。どのデータもカオスをぎりぎりの線で脱出したグラフ形式のデータを入力とします。求められる結果(あるべき姿、又は期待する形)に対して一致するパターンか、あるいはどれほど類似しているパターンなのかを出力しています。これは明らかに一種の予測のプロセスではないでしょうか。Neo4jの活用を検討している方は、「これをどこに利用すればいいのかではなく、何か予測とかをしてもらう必要があることはないか」とアプローチしてみては如何でしょうか。婚活をテーマにしたのか「婚活」と言うテーマを選んだ理由は、この時代の社会問題を扱って見たかったという志があったからではありません。様々な情報が入手しやすいだろうということや、疑似情報を作るにしてもリアルに作れるだろうということ。曖昧さや意外性だらけの男女の関係だから、ちょっと変な結果が出ても大抵の場合、面白がるだろうし、それなりに複雑性も存在しているだろうという。殆ど身勝手な理由ばかりです。婚活に関わりそうな情報収集をしてみましたいずれにせよ、関係ありそうな情報収集を始めました。いくつかの婚活サイトを参照し、周りの同僚の話しを聞き、自分の経験も振り返ってみました。種のドメインと、それぞれの属性を決めました。種にしていますが、深い意味はありません。深く考えるとさらに増えそうだったので、この線で切っています。香川県,愛媛県,高知県,福岡県,佐賀県,長崎県,熊本県,大分県,宮崎県,鹿児島県,沖縄県この段階では、ドメインや属性の妥当性よりも期待する条件の相手を見つけることができる最低限の「データモデル作成」に集中することにしました。スキーマフリーのデータベースですから、データ構造を変更してデータベースを再構成することは比較的に簡単です。クエリーを実行しながら、「トライ&エラー」で最適化を図っていく方法を選んだわけです。データモデルの妥当性は長く議論したからと言って理想的なアイディアに繋がるとは限りません。そもそもデータモデルの段階では判断するだけの十分な情報が入手できない問題があります。実際に有用な情報が得られるのは、データを投入し、狙いのデータパターンが得られるかどうかやってみた時だからです。婚活支援データモデルにおける特殊性いずれにせよ軽い気持ちで始めましたが、婚活の対象になる人のプロファイルには様々な特徴があることが分かりました。男性と女性で明確に分かれ、候補者間で特に関係性は持っていない。関係性を持っているのはカップル成立の関係か、どちらかに断わられた関係である。オリジナルプロファイルと理想の相手を予測するためのリクエストプロファイルの内容は一致しない。種類のプロファイルが存在する。ある条件は重み付けをし、優先度を高くしたい場合がある。ある条件は必須となることがある。身長や収入、住んでる場所などを限定した場合である。考えてみましたが、かなり複雑なデータモデルになりそうですね。希望の相手を予測する方法には大きく3つのパターンがありました。諸条件を利用する方法この方法は候補者のリクエストプロファイルと対象になる人のオリジナルプロファイルを突き合わせて、最適な候補者を予測してもらう方法を利用しています。自分のリクエストが反映されるという安心感があり、相手のプロファイルを見た時に直観的で理解しやすいというメリットがあります。適正検査による方法この方法は候補者から数十から百数十の項目のアンケートに答えてもらって、その結果分析から、相性のよい相手をレコメンドしてもらうタイプです。これは理想の相手を予測する過程がブラックボックスであるため、システム自体を信頼できる人とできない人に分かれるというデメリットがあります。諸条件を利用する方法と適正検査による方法をミックスして利用する方法です。適正検査による方法が参考になるメリットがあります。1回目のデータモデリング開始フェーズ1のデータモデル今回は既に上記の『婚活支援モデルにおける特殊性』で述べているような要件をすべて取り入れたデータモデルを一気に作り上げることは無理だと判断し、いくつかの要件を省略したデータモデルを作ることにしました。男女は人を親ドメインとして階層化する。Person:Womanオリジナルプロファイルのみを対象にする。プライマリドメインとサブドメイングラフデータベースの利用を検討する上で問題点の一つは、データモデリングの方法論が確立してないことでしょう。殆どのケースにおいて経験や試行錯誤に頼っていると言っても過言ではありません。ここでは筆者の独断でドメインの種類を、次の2種類に分類しています。プライマリドメイン分析の上で最も中心的な役割を果たす必須のドメインのこと。今回の人(Person)のようなものであり、一般的にノード数が最も多く、トランザクション処理も頻繁に行われる。サブドメイン分析の切り口として使われ、プライマリードメインを補助する役割を果たすドメインのこと。人に紐づくスポーツのようなものであり、プライマリドメインに比べて相対的にノードの数も少なく、一度作られた後は参照だけのケースも多い。コンセプトデータモデルここまでの調査結果や私自身が決めた方針に従って、概念レベルのデータモデルを作成してみました。人(Person)がプライマリドメインであり、スポーツや休日などは、サブドメイン(:Category)の位置づけです。ディテールデータモデルコンセプトデータモデルのサブドメインを5つサンプリングし、詳細レベルのデータモデルを作成してみました。今回のケースではサブドメインのパターンが同じなので、すべて書いても意味がないことから省略しています。今回のデータモデルのラベル及び関係性を定義し、すべてのドメインモデルを網羅すると、次のようになります。Man-[:SUCCESS]->Person:WomanPerson:Woman-[:DISAGREE]->Person:ManPerson:Man-[:DISAGREE]->Person:WomanWoman-[:MY_SPORT]->sportWoman-[:MY_HOLIDAY]->holidayWoman-[:MY_TALK]->talkWoman-[:MY_HEIGHT]->heightWoman-[:MY_PERSONALITY]->personalityWoman-[:MY_INDOOR]->indoorWoman-[:MY_SMOKING]->smokingWoman-[:MY_ALCOHOL]->alcoholWoman-[:MY_KARAOKE]->karaokeWoman-[:MY_FORTUNETELLING]->FortunetellingWoman-[:MY_OUTDOOR]->OutdoorWoman-[:MY_INCOME]->IncomeWoman-[:MY_BORN]->BornWoman-[:MY_LOCATION]->LocationWoman-[:MY_PET]->PetWoman-[:MY_EDUCATION]->EducationWoman-[:MY_JOB]->JobWoman-[:MY_MEET]->MeetWoman-[:MY_MARRIAGE]->MarriageWoman-[:MY_HEALTHCARE]->HealthcareMan-[:MY_SPORT]->SportMan-[:MY_HOLIDAY]->HolidayMan-[:MY_TALK]->TalkMan-[:MY_HEIGHT]->HeightMan-[:MY_PERSONALITY]->PersonalityMan-[:MY_INDOOR]->IndoorMan-[:MY_SMOKING]->SmokingMan-[:MY_ALCOHOL]->AlcoholMan-[:MY_KARAOKE]->KaraokeMan-[:MY_FORTUNETELLING]->FortunetellingMan-[:MY_OUTDOOR]->OutdoorMan-[:MY_INCOME]->IncomeMan-[:MY_BORN]->BornMan-[:MY_LOCATION]->LocationMan-[:MY_PET]->PetMan-[:MY_EDUCATION]->EducationMan-[:MY_JOB]->JobMan-[:MY_MEET]->MeetMan-[:MY_MARRIAGE]->MarriageMan-[:MY_HEALTHCARE]->Healthcareプライマリドメインを軸としてみたサブグラフのイメージこのサブグラフはプライマリドメインのノードから、サブドメインのノードへ放射型に広がっているシンプルグラフです。このパターンでは人のプロファイルを取捨選択しながら低コストで取得することを狙いとしています。関係性の方向はどのように決めるのでしょうか。これは、美的な要素よりパフォーマンスの面の考慮が最も必要だと思います。今回のグラフは人のノードの数が圧倒的に多いなかで、アクセスパースの観点から人を決めてからサブドメインにアクセスして行きます。なっているためアクセスコストも最低になるはずです。仮にアクセスパースの開始ノードがもっぱら「年収」だとすると、おそらく別のデータモデルへと変更が必要になるかもしれません。サブドメインを軸としてみたサブグラフのイメージ次のグラフはスポーツサブドメインの野球ノードを軸にして人が集中型に集まっているシンプルグラフにしています。グラフの方向は分析におけるアクセスパースとパフォーマンスを意識した構成にしています。まとめここまでで、とりあえず婚活支援プロジェクトの「データモデル設計」が終了しました。クエリーで理想の相手を予測してみたいと思います。AuthorleefacebookTwitterデータベースが大好きなサーバサイドのエンジニア。Neo4j、MongoDBのテクニカルサポート、IoTビックデータ処理基盤のアーキテクトとして活動しています。LABの情報を逃さずチェックしよう!メールアドレスを登録すると記事が投稿されるとメールで通知します。※登録後メールに記載しているリンクをクリックして認証してください。#28に、弊社エンジニア細見・李が登壇します。#21)に、弊社エンジニア李が登壇します。LABの情報を逃さずチェックしよう!メールアドレスを登録すると記事が投稿されるとメールで通知します。※登録後メールに記載しているリンクをクリックして認証してください。