私は大規模な分散グラフデータベースの候補としてTitan(HBase上)を研究しています。 OLTPアクセス(グラフ上の高速マルチホップクエリ)とOLAPアクセス(グラフの全部または少なくとも大部分を解析用にSparkにロード)の両方が必要です。タイタンからHBaseの大きなグラフをSparkに読み込む
私が理解しているように、Gremlinサーバーを使用して、OLTPスタイルのクエリを処理して、結果セットを小さくすることができます。私のクエリはUIによって生成されるので、APIを使ってGremlinサーバとインターフェースすることができます。ここまでは順調ですね。
この問題は、OLAPの使用例に関係しています。 HBaseのデータはSparkエグゼキュータと同じ場所に配置されるため、HDFSInputFormat
を使用してデータをSparkに読み込むと効率的です。ドライバからGremlinクエリを実行し、そのデータをエグゼキュータに戻すのは非効率的です(実際には、投影されたグラフのサイズでは不可能です)。
私が見つけた最高のガイダンスは標準TitanCassandraInputFormat
は、タイタンのテーブルを読み取るための作業がすべき(少なくともカサンドラバックエンド用)ことを示唆しているタイタンGitHubのレポ(https://github.com/thinkaurelius/titan/issues/1045)からの未締結の議論です。 HBaseバックエンドについては何も主張されていません。
しかし、基本的なタイタンデータモデル(http://s3.thinkaurelius.com/docs/titan/current/data-model.html)について読むと、内容からプロパティグラフを再構築する方法についての説明がなく、「生の」グラフデータがシリアル化されているように見えます。
だから、私は2つの質問があります。
1)は、私が正しいの上に述べてきたすべてのものか、それとも私が見逃している/誤解何か?
2)HBaseの「生の」タイタングラフを読んで、Spark(GraphXまたはDataFrames、RDDなど)で再構築できた人はいますか?もしそうなら、あなたは私に何か指針を与えることができますか?
こんにちは、Titan(cassandra)の類似ソリューションはありますか? – Parag
私は気づいていませんが、あなたは作ることができます:) – imriqwe