最近 Graph database が盛り上がってるように感じる。
さて ArangoDB という DB を知っているだろうか。
MySQL とか MongoDB とかと比べると知名度は低いものの、NoSQL、とりわけ Graph database 界隈では名が知られている。Graph database 界隈と書いたが、さしずめこの領域では Neo4j が幅を利かせている。Neo4j なら聞いたことあるって人はたくさんいると思う。
Graph databases
・Neo4j
Neo4j の強みとしては、そのクエリ言語である Cypher の読みやすさが一つ挙げられる。Cypher の紹介ページ に書かれている最初のサンプルを引用すると、こうだ。
MATCH(:Person{ name:"Ann"})-[:MARRIED_TO]->(spouse)
このクエリは「name が "Ann" である Person と MARRIED_TO で結ばれている相手を探して変数 spouse にセットする」のだが、それを SQL で表現しようとするとおおよそ直感的とは言えない join に苛立たせられるだろうと思う*1。
Neo4j は先行者であり、現在は後続の Graph databases からパフォーマンステストで叩かれまくっている。僕も試したんだけど正直、ある程度のレコード数になると遅さが目立つようになる。
・Dgraph
勢いだけで言うなら、最近いちばん盛り上がりを見せたのは Dgraph じゃないかな。
『オープンソースの分散グラフデータベースDgraphが$3Mを調達しv.1.0にやっと到達』Tech Crunch
Dgraph のクエリ言語は GraphQL+- という、昨今話題の GraphQL を Graph database 用に進化させた言語である。Dgraph の紹介としてはこのスライド 『Dgraph - A high performance graph database written in pure Go』 Speaker Deck の 14 ページ目 〜 24 ページ目が分かりやすい*2。
・その他
他にも Graph database はたくさんあるけど紹介していたらキリが無い（OrientDB, Amazon の Neptune, GraphDB, ...）。ArangoDB の話をしよう。
ArangoDB
ArangoDB は Graph database であることが主ではなく、あくまで Multi-Model NoSQL database という触れ込みになっている。簡単に言ってしまうと、JSON で表されるような構造化されたドキュメントを value とする kvs でありつつ、そのレコードを使って Directed graph を形成したりできる database である。
データを操作するには 2 つの方法がある。ひとつは AQL というクエリ言語を使うこと、もう一つはシェルから JavaScript を叩くことである。
なお最新のパフォーマンス比較は↓こちら。LGTM。
『NoSQL Performance Benchmark 2018 – MongoDB, PostgreSQL, OrientDB, Neo4j and ArangoDB』
Dgraph と ArangoDB とのパフォーマンス比較をした良い記事が見つからなかったので良かったら教えて欲しいのだけど、その比較を待つまでもなく ArangoDB を推したくなる理由を次に書こうと思う。
ArangoDB を選択する理由
データというのはプロダクトにとってライフタイムの長い性質のリソースであって、それをどういう形で持つのかというのはとても重要である。おいそれとアクの強い、信頼の薄いデータストアに置くわけにはいかない。「では ArangoDB がきな臭いか？」というとそれは判断が割れるところであろうが、少なくとも知名度を一つの尺度とするなら MySQL や MongoDB には敵わないだろう。しかしそれを踏まえてもなお検討を続ける価値はあると思う。
1. Multi-Model であること
データの保存先として、何も考えずに RDB を選ぶ時代は終わった。とはいえ、他の選択肢として何があるかと言ったとき MongoDB しか無いというのも面白く無い。改めて「データは、それを利用するアプリケーションからどう見えるべきか？」という問いに真っ正面から向き合ってみると、それに応える有力な選択肢として Graph があると思う。アプリケーションが使う全てのデータを Graph として見るというのは無理があるが、Graph 的なデータを部分的に持つアプリケーションというのはたくさんあると思うのだ。Document は保存したいし Document 同士の Relationship も保存したい、当然 Collection を横断する SQL 的な join もやりたい。Middle size のプロジェクトに対して ArangoDB が妥当性を持つ余地がここにある。*3
2. foxx
ArangoDB には、foxx という、microservice を作る機能が乗っている。データベース内で動く JavaScript を書くことが出来、またそれは DB のインメモリデータへアクセス出来る。DB が Microservice になるのだ。
通常 Web アプリケーションは少なくとも 2 つの大仕事をしている。ひとつはフロントエンドに返すデータの構築*4、もう一つは何らか「形式立ったロジック」に沿ったデータアクセスである。DB が Microservice になるということは、後者の「形式立ったロジック」を DB 側に配置できるようになるということである。またネットワークオーバーヘッド削減にも寄与する。
その他 foxx の面白さを最も的確に語っているのは公式のページだと思う。
3. 決定的な欠点が無い
Transaction もある*5、クエリ言語もある、クラスタリングもある、プラットフォームに合わせたインストール手段、コミュニティ*6もある、開発も継続されている。だから、（我々の）プロジェクトと ArangoDB 双方の将来を考えたとき、どうしてもココが真っ暗だというポイントが無い。そう言えるものって一握りですよ。
以上、そんなわけで
日本でユーザーさん増えてほしいなぁと思うわけです。
