ロックなしで同時更新を実行できます。
スライド46の質問「誤検知を取得できませんか?」PlayOrmの場合と同じです。
1つの注意点は、読み取り時に解決する必要がある場合があることです。したがって、例は次のとおりです。データベースにアドレス123のFredがあるとします。
現在、2台のサーバーがFredを更新しています
- サーバー1:フレッドの新しいアドレスは456です(インデックス123.fredを削除し、456.fredを追加します)
- サーバー2:フレッドの新しいアドレスは789です(結果としてインデックス123.fredが削除され、789.fredが追加されます)
これは、インデックスに456.fredと789.fredの重複がある可能性があることを意味します。次に、読み取り時にこれを解決できます。アドレス456のユーザーを要求すると、クエリはフレッドを返します。読み取り時にこれを解決するための別のチケットがあります;)そしてエントリを削除します。
カサンドラに変更を加えることについて質問しましたが(列456.fred IF列123.fredが存在するか失敗するかを追加)、そのようなものを実装するかどうかはわかりません。これにより、失敗が敗者に戻されます(つまり、最後のライターが例外を取得します)。それは素晴らしいことですが、彼らがこのような機能を実行するかどうかはわかりません。
大きな注意:CQLとは異なり、クエリはすべてのノードに送信されるわけではありません。100台すべてのコンピューターではなく、インデックスを含むノードにのみ負荷がかかります。すなわち。この方法でより適切にスケーリングできます。
詳細:あなたのリンクが持っているそのプレゼンテーションのスライド27で、それは私たちのインデックスのそれとほとんど同じです。ただし、この形式には1、2、3は含まれていません。インデックス形式は
Indexes=
{"User_Keys_By_Last_Name":{
{"adams","e5d…"}: null,
{"alden","e80…"}: null,
{"anderson","e5f…"}: null,
{"anderson","e71…"}: null,
{"doe","e78…"}: null,
{"franks","e66…"}: null,
…:…,
}
}
このようにして、名前の後半に1、2、3、4、5を使用する必要があるかどうかを確認するために、読み取りを回避できます。代わりに、一意であることがわかっているFKを使用し、書き込みを行う必要があります。Cassandraは、とにかく読み取りの競合を解決することを目的としているため、修復プロセスが存在します。これは、競合が非常に低い割合で発生し、その低い割合でヒットするという事実に基づいています。
最後に、コマンドラインツールを使用してインデックスを表示できます!!!! ストリーミングごとに約200列にバッチ処理されるため、100万のエントリを作成でき、コマンドラインツールはctrl-cするまでそれらを印刷し続けます。
後で、ディーン