私はcsv-filesのバージョンを格納するCassandraのテーブルを持っています。バージョン(パーティションキー)と行番号(クラスタリングキー)の一意のIDを持つ主キーが使用されます。私が新しいバージョンを挿入すると、挿入しようとしているパーティションキーにdeleteステートメントが実行され、不完全なデータがすべて消去されます。次に、データが挿入されます。パーティションCassandraのDELETE/INSERT同時実行の問題
ここに問題があります。アプリケーション内で削除と後続の挿入が同期して実行されても、Cassandraにはまだ並行性のレベルが存在するようです。後で読み込むと、挿入された行が時々見つからなくなるためです。ここではいくつかの事実です:
- カサンドラ3.0
- 一貫ALL(R + W)は
- 火花カサンドラコネクタ ノードの
- 数使用して
- 挿入するJavaドライバーを使用して削除します。2 を
- レプリケーションファクタ:2
私が実行するdelete文は次のようになります。
私はそれを省略した場合、問題が消える
"バージョン= 'ID' mytableはFROM DELETE"。削除と挿入の間に遅延を挿入すると、問題が少なくなります(欠落行が少なくなります)。当初は、より限定的ではない一貫性レベルを使用しましたが、これが問題だと確信していましたが、問題には影響しませんでした。私の仮説は何らかの理由でdeleteステートメントがALLの整合性レベルにもかかわらずレプリカに非同期的に送信されていることですが、なぜこれがどうなるのか、それを避ける方法はわかりません。
一般に、C *は最終的に一貫性のあるデータベースです。これは、さまざまなことを意味しますが、操作順序に頼ることはできません。従属操作を決して行なわないでください。スキーマを再設計し、アプローチを変更する方がよいでしょう。データモデルを投稿し、達成したいことを説明した場合は、それを手助けすることがあります。あなたの状況で理解できる限り、たとえばクライアント側でデータを取得した後に古いバージョンをフィルタリングするほうがよいでしょう。 –
最終的な一貫性の程度は、自分の選択した一貫性レベルによって制限されると私は予想しています。現在はボトルネックではないため、単純化のためにプロトタイプでALLを使用しています。最も守秘的な整合性レベルで順番に完了する操作のシーケンスに依存できない場合は、整合性レベルをどのように使用できますか? –
ALLは、すべてのノードが照会に関してコンセンサスを持つことを保証します(したがって、その単一の照会の後、すべてのノードは影響を受けた行と同じバージョンを持ちます)が、照会の順序に関しては何も保証しません。私は、あなたのアプローチを再設計し、C *をリレーショナルデータベースとして考えるのをやめてください。それは動作しません。 –