プロパティ グラフを HBase に保存したいと考えています。プロパティ グラフはグラフ ノードであり、エッジにはプロパティがあり、エッジが異なるタイプに属している限り、複数のエッジがノードの同じタプルをリンクできます。
私のクエリ パターンは、プロパティと近傍を要求するか、グラフをトラバースします。例: Vertex[name=claudio]=>OutgoingEdge[knows]=>Vertex[gender=female] で、claudio が好きなすべての女性が表示されます。
グラフデータベースがこれを行うことは知っていますが、通常、巨大なデータセットの場合、複数のノードにスケーリングしません。したがって、これを NoSQL 列ストア (HBase、Cassandra など) に実装したいと考えています。
私のデータモデルは次のとおりです。
Vertices Table :
key: vertexid (uuid)
Family "Properties:": <property name>=><property value>, ...
Family "OutgoingEdges:": <edge key>=><other vertexid>, ...
Family "IncomingEdges:": 発信エッジと同じ...
このテーブルを使用すると、頂点とその隣接リストのプロパティをすばやく取得できます。複数のエッジ (異なるタイプ) が同じ 2 つの頂点を接続できるため、頂点 ID を他のエンドポイントとして使用できません。
Edges Table :
key: edge key (composite(<source vertexid>, <destination vertexid>, <edge typename>)) (ie vertexid1_vertexid2_knows)
Family "Properties:": <property name>=><property value>, ...
このテーブルを使用すると、エッジのプロパティをすばやく取得できます。
エッジ タイプ:
キー: コンポジット(<ソース頂点 ID>, "out|in", <エッジ タイプ名>) (つまり、頂点 ID1_OUT_KNOWS)
ファミリ "ネイバー:": <宛先頂点 ID>=>null,...
このテーブルを使用すると、頂点からの着信または発信のいずれかで、特定のタイプに属し、API のトラバース機能のコアとなるエッジを検索/スキャンできます (したがって、両方の点で可能な限り高速にしたいのネットワーク I/O (RPC)、ディスク I/O (シーク))。また、グラフのサイズに「スケーリング」する必要があります。つまり、グラフの成長に伴い、このタイプの操作のコストは、頂点とエッジの合計数ではなく、頂点から出力されるエッジの数に依存する必要があります。上記の例では、プロパティ name:claudio を持つソース頂点である vertexid1 を考慮し、 vertexid1_out_knows をスキャンして、接続されている頂点のリストを受け取ります。その後、これらの頂点の「Properties:gender」列をスキャンして、「female」値を持つものを探すことができます。
質問:
1) 全般: 運用に適したデータ モデルはありますか?
2) 特定のキーに対して一部のファミリが空になる (つまり、"OutgoingEdges:" ファミリはエッジに対して意味をなさない) 1 つのテーブルにすべてを収めることはできますか? ご覧のとおり、すべてのキーが vertexid uuid プレフィックスで構成されているため、それらは非常にコンパクトで、ほとんどが同じリージョンサーバーに収まります。
3) スキャンにはフィルターを多用すると思います。regexp Filter は私の友達になると思います。このデータ モデルに適用されるフィルターのパフォーマンスについて懸念がありますか?