は、ユーザが最初にDB /グラフが空である、動的にノードとエッジを追加することができ、</p> <p>を我々は重み付き有向グラフを断片たい（キー/値のデータベース上）加重有向グラフ

Question

のパーティション。

ノードとエッジをキー/値データベース（おそらくRedis）に保持します。ノードごとに、nodeIdをキーとし、参照されるノードのソートセットをsortedSet内の各nodeIdのスコアとしますエッジの重さ

（ここではということに関する質問を参照してください：Redis: Implement Weighted Directed Graph）我々はバランスの制約を持っていない

、グラフで最も一般的なアクションはダイクストラある、と私たちは私たちの中にI/O（ネットワークを最小限に抑えるようにしていましたケース）

考えられる解決策：各DBサーバがIPを持つ他のサーバーのリストが含まれています

キー：SERVER1、値：.... 250.1

キー：SERVER2、値：.... 250.2

キー：server3の、値：.... 250.3

とそれぞれのnodeIdがどこに行くかをノード決定アルゴリズムがどうなるか

をserverX.originalNodeIdされるのですか？ノードの再配置をサポートする必要がありますか？

Iがので

Answer 1

..単純なアプローチがあれば、サーバXが完全に占有されないように、ARGMAX（サーバX内のノードの＃ノードAとエッジを有する）サーバXにノードAを追加するであろうことが推測処理はクライアント側で行われますが、この種のグラフデータは断片化するのが難しくありません。各ステップで必要なのは、単一のソートされたセットなので、ロードされているノードは問題ではありません。実際のデータをノードと一緒に取得することは最終ステップとして行われます。ノードが1つだけの場合は単純なMGETになり、いくつかのノードに分割するのは簡単です。

鍵を保存するノードを決定するには、手動で追跡するのではなく、ハッシュを使用する必要があります。特定のノードに対してある範囲のハッシュをマッピングするテーブルを使用します。それは長期間の永続性のためにredisに格納されますが、実際にはクライアントの一部です。特定のキーにアクセスするには、キーのハッシュを取得し、テーブルでそれを探し、そのノードに接続します。数千のスロットを持つテーブルを使用すると、データを別のノードに簡単に移動できます。テーブルを更新すると、特定のスロットの要求が別のノードに送信されます。これは、Redisクラスタで使用されているアプローチとまったく同じではありませんが、かなり類似しています。

つまり、シャーディングを設定する理由はグラフデータではありませんでした。 IDだけを含む小さな並べ替えセットは、メモリをあまり使わないため、1つのノードで1億個のエッジを処理することができます。