2015年6月27日土曜日

セミナー「Neo4j ユーザー勉強会 #4」

6/24、Neo4jユーザーズグループ勉強会#4＠代々木、に参加した。

【（1） Neo4jユーザグループからのお知らせ】

案浦氏からの話。名古屋、北海道のオープンソースカンファレンスに出展したとか。東京10/24、25＠明星大学も参加予定とか。



【（2） 販売履歴2億5千万ノードでのCypherパフォーマンス検証】

クリエーションライン株式会社 李氏からの説明。
サンプルは、http://www.creationline.com/lab/10192、http://qiita.com/awk256/items/58f0c6cd905b03718717　 にあり。
  • 販売履歴２億４千万件をNeo4jに。架空のECサイト一年分の販売履歴。ユーザ1200万。商品12000。
  • 最初は12億件つくったが、一億ロードするのに六時間、仮想マシンでは二億四千万で止まってしまった。
  • データ数の制限：ノード340億、関係340億、属性2740億、関係性32000入れられる。
  • データモデル：販売履歴に、ユーザ、販売履歴（過去）、商品、時間がつながり、時間は日、月、年と階層化されているモデル。
  • サーバはCPU１２コア。32GBRAM。SSDは200GB×6．RAID0。Write1.3GB/s、Read2.8GB/s。（/dev/zeroで計算。）
  • パラメータはwrapper.java.initmemory、maxmemory、xxxを設定。
  • インデックス：ユーザ、商品、注文、日付。ロードはインデックスなしで実行しないと大幅な遅延が発生する。（宣言なしで260、インデックス作成69．最初から宣言していると700くらいの差が出る。）
  • ロードは月ごとにcsvを分けて実施。
  • 販売履歴も入れて、そのあとユーザと販売履歴の関係を入れる。（一秒あたり4981件。）2000万件ではcreateのほうがmergeより1.3倍速かった。販売履歴と商品の関係も入れる。match(g:Goods{gid:line.gid}) match(o:order(oid:line.oid}) create (o)-[c....
  • 当初の設計では年、月、日、時、販売履歴、の順で関係作っていたが、「年月日」を販売履歴に関係させることに。（時間がかかりすぎた。データストアの損傷？　階層が深いものは要注意だとか。）　when y.year%4<>0 then range(1,28)
  • 13階層とかあるとパフォーマンス要注意になってくる（一万件くらいでも危険なことも。）match(y:year{year:2014})-->(m:Month{month:9})-->(d)--(h)--　……
  • ページキャッシュで、一度目は132かかったのが2回目30、3回目19まで落ちる。（二回目で大幅短縮。その後は誤差の範囲。）
  • SQLで書くと、テンポラリテーブル、論理的な崩壊が発生等で問題になる。CypherQueryだと一筆書きが可能。リストの作成、操作などスクリプトのような書き方が可能。
  • このような範囲で、商用版、Community版の違いは見られなかった。深い階層で繰り返しのMatch、create/mergeには注意が必要。



【（3） Neo4j.rbを利用したOGM（Object Graph Mapper）】

テクノロジックアート　高部真一郎氏

資料：

www.slideshare.net

Neo4jで、人探し、ある一定の制限を持たせたパターン分析、株トレーニング、グラフ理論を使った知的ゲーム、人間系いろいろ、をやってみたいとか。
Neo4j.rb：2014にBest Community ContributionでGraphDB接続カンファレンス？で賞獲得したrubyライブラリ。公式サイトもあり。
Neo4jをアプリから呼ぶためにOGM（Object-Graph-Mapper）がある。O/Rマッパー（Object-relational mapping。オブジェクトとRDBのミスマッチをマッピングする。コネクション管理、自動マッピング、DTO、DAO自動生成、接続情報管理、キャッシュなどの機能がある）の一つであるActiveRecordと同様に使える。

例：投稿（post）にコメント（comment）を追加していく簡単なWebアプリ。

rails new whisper -m http://neo4jrb.io/neo4j/neo4j.rb
cd whisper
rake neo4j:install[community-2.1.4.development]
rake neo4j:config[development,7000]
rake neo4j.start
....
rubyやrakeはインストールしておく。rails new whisper -m ....でWebアプリ全体、Neo4j準備。
自動でNeo4jはインストールされ、neo4j.startでNeo4jが起動する。
config/environments/development.rb
config neo4j.session_type:server_db
config.neo4j.session_path="http://localhost:7000"
でデータベース定義。development.rbはデータベースに接続するための情報。
rails g scaffold post title body
rails g scaffold comment body
で画面、モデル、ビュー作成。
app/model/comment.rb

class Comment
    include Neo4j::ActiveNode
    property:title,type:String
    has_one:out,:post,type:comments_on
end
....

新しいノードの作成：@comment=Comment.new(comment_params)　保存：@comment.save など、ActiveRecordと同じ記載ができる。
blog/vendor/bundler/ruby/2.1.0/gems内にライブラリが保管されている。（neo4j-ではじまるもの。）
使ってみた感想としては、RDBと同じ記述で行けそう。（JavaのAPI使ってNeo4jからデータとってきてActiveSupportで使いやすくする。）ソースはGitHubに公開されている。


【（4） Neo4j導入事例】

某OSで有名な会社のソリューションアーキテクト、上野智史氏。コンサルティングチームの人。ユーザ目線でシステムデザインの仕事をしているらしい。個人的な見解を含む。
事例：商社向けソリューション
OnlineのSNSでは本当に大事な情報は流れない。人脈とノウハウが重要。限られた相手に、信頼関係のもとに、のみ大事な情報を共有する。人脈はビジネスチャンス。誰かに会いたいと思ってもなかなかつながらないが、誰かを通すと誰かにつながることができる場合がある。そこをどうつないでいくか。（Six Degrees。スモールワールドネットワーク。）ビジネスだと２，３Degreesで会えるのでは？と検討。
自分と、相手までのパスをつなげてVisualに見せるようなソリューションを検討。自分と、自分の会社と、関連会社も使って人脈を探索。データソースは、企業内のメールを交わしたこと、打ち合わせをしたことや、企業外のFacebookなどSNS（ビックデータを解析して情報を小さくしてNeo4jに突っ込む）。UIは乗換案内（最短ルート表示）をイメージ。あまりグラフ型UIは意識せず、フローでつながるような感じ。
実現プロセスとしては、漠然とした題をもらい、モックアップ（仮説）で先にデザインし、実現手段を検討し、プロトタイプ作成。できるかわからないが先にモックアップ準備。実現手段検討時にグラフDBがマッチするのではないかと考えた。（RDB、GraphDB、BigDataなど検討。）Azure上に実装。3人で二か月で動くものが作れた。RDBでスキーマ、クエリ書くより簡単にモデリングができた。
情報のつながりを求めるニーズはいくらでも転がっている。たとえば不動産だと買主・売主・物件、不動産担当営業、上司、物件に近い物件など。ペルソナやシナリオによって入口は異なるが、グラフ型だとどこから入ってもつながれる。どこから入っても簡単に追いかけられ、追いかけなくても存在に気が付けるとなおよい。（思いつきもしなかった情報が広がっている世界。つながり＋コンテクスト（タグ情報））


【ユーザグループの今後の活動について】

Neo4jコミュニティで本を出版予定。


【今後の予定とか】

未定。Connpass上で募集。登壇者も募集。
0 件のコメント:
ラベル: , , ,
登録: 投稿 (Atom)