セカンダリインデックスを持つ分散データにルーティングを使用できないのはなぜですか？私は次の記事を読んでいる

Question

：Elements of Scale: Composing and Scaling Data platforms

私は、次の文章を理解する上でこだわっている：

セカンダリインデックスは、主キーにない指標です。つまり、データはインデックス内の値で区切られません。ハッシュ関数による直接ルーティングはもはやオプションではありません。すべてのマシンにリクエストをブロードキャストする必要があります。

これはどのような理由で説明できますか？私はデータプラットフォームの初心者ですが、これまでに得た記事を理解しています。

具体的には、プライマリキーのセカンダリインデックスの値を検索し、プライマリキーのハッシュ関数を使用してその場所を検索できないのはなぜですか？要求をすべてのマシンにブロードキャストする理由

はあなたの時間、彼らはデータが4つのノード上に分散されている与えている例について

Answer 1

いただきありがとうございます。各ノードにはセカンダリインデックスがありますが、そのノードの値のみです。セカンダリインデックスにすべてのノードのすべてのレコードが含まれているわけではありません。したがって、検索したい発信者はすべてのノードに送信する必要があります。

わずか2ノード

ノード1は（2、A）（3、B）

ノード2は（100、A）（105、C）

を有する（A、1）を有していると例：

ノード1には、プライマリインデックス1,2,3があります。二次インデックスa、a、b

ノード2にはプライマリインデックス100,105があります。そして二次索引a、c

「c」を検索したい呼び出し者は、2つの2次索引を検索するために両方のノードにブロードキャストする必要があります。

しかし、セカンダリインデックスa、a、b、cの完全なコピーを保持していれば、そのインデックスを照会してターゲットノードに直接行くことができます。しかし、実際にはこれが予想以上に多くの合併症を伴います。

編集日：6月22日。 3番目のノードでセカンダリインデックスを維持しようとすると、次のような問題が発生します。

1. 2つまたは3つのノードが含まれるようになりました。したがって、ある種の2フェーズコミットプロトコルまたは代替スキームを実装する必要があります。

2. ノードが多いほど、MTBFが低いほど全体的な信頼性が低下することがあります。

3. ネットワークパーティショニングで何が起こるかを検討する必要があります。

4. メンテナンス操作がより困難になることがあります。たとえば、あまりにも多くのネットワークトラフィックを生成せずに、インデックスを効果的に検証する方法は正しいですか。

5. 更新プログラムはどのようにインデックスノードを編集しますか？クライアントはこれに責任がありますか、またはメインストレージノードはインデックスノードを更新しますか？

の詳細を学ぶのに適した場所は、2相に見て、CAP定理を確認スキームをコミットし、潜在的に分散システムのジャーナルに掲載されたIEEE論文の一部を見ることです。

Answer 2

例として、データは、パーティションキーのハッシュ（表スキーマで定義されている、主キーの最初の部分です）によって決定されるノードのレプリカに書き込まれます。

セカンダリインデックスは、そのパーティションキーにないデータです。インデックスが元のデータを保持する同じノードに書き込まれていると仮定すると、セカンダリインデックスを照会するとき、特定の値のデータを含むノードそのインデックスでは、元のパーティションキー（プライマリデータ）のノード上に存在するため、新しい 'キー'の値をハッシングします。