問題タブ [tombstone]

Cassandra の更新とクラスター キーの処理はどのように相互作用しますか?

• Cassandra は、一度書き込まれたレコードを実際に更新することはありません。古いバージョンがハウスキーピング プロセス (ガベージ コレクションの形式) によって最終的に削除されるまで、 tombstoneを使用して古いバージョンを削除済みとしてマークし、古いバージョンと新しいバージョンの両方を記録します。
• クラスター キーは、パーティション キーのみを持つ "実際の" レコードにデータを記録する魔法を使用して実装されます。

これらの 2 つの機能が相互に作用し、過剰なゴミが生成される可能性があると思います。

次のスキーマを検討してください。

次の挿入の実行後:

データを保持する廃棄マークの付いたレコードと、とデータ(1, 1, "text-1")の両方を保持する新しいレコードはありますか? つまり、2 番目の挿入は、パーティション キー ( ) が 1 の "実際の" レコードの更新として実装されていますか?(1, 1, "text-1")(1, 2, "text-2")p

既存の Android プロセスが強制終了され、その結果、tombstone ファイルがすぐに生成される状況をシミュレートする必要があります。

それを達成するために、次のコマンドシーケンスを使用します。

残念ながら、"-6" シグナル (およびその他の可能なシグナル) は、トゥームストーンが生成されるという事実を保証しません。

アプリケーションを変更せずに保証付きで生成された墓石を取得する方法についてのアイデアはありますか?

ありがとう！

titan db (v0.5.4) を使用してアプリケーションを実行している 3 ノードの cassandra (2.1.8) クラスターがあります。データの量は非常に少ない (20 MB 未満) ですが、私のユース ケースでは時々削除が必要になるため、既にトゥームストーンに問題があります。すでに作成された墓石を取り除くことはできません。私が試した解決策は次のとおりです。

• 指定されたグラフインデックス テーブルのgc_graceを 60 秒に下げる
• nodetool フラッシュを実行する
• ノードツールの修復を実行する
• titan.graphindex テーブルでは、圧縮オプションを {'class': 'SizeTieredCompactionStrategy', 'unchecked_tombstone_compaction': 'true', 'tombstone_compaction_interval': '0', 'tombstone_threshold': '0.1'} として設定します。
• jmx から forceUserDefinedCompaction を実行しています。

その結果、統計は少し低下しましたが、スライスあたりの平均廃棄数とスライスあたりの最大廃棄数はまだ満足のいくものではありません。

すべての墓石を削除するオプションはありますか? ご提案いただきありがとうございます。

Tombstone に関する質問のとおり、アップサートで tombstone が作成されないのはなぜですか? datastax のドキュメントによると、データはどのように更新されますか? アップサートごとに、挿入の新しいタイムスタンプが古いタイムスタンプを上書きするため、cassandra は削除の後に挿入を行うと見なします。古いタイムスタンプ データは、廃棄に関連する削除としてマークする必要があります。

なぜ私たちは矛盾した声明を持っているのですか？または、ここで何か不足していますか？

ユースケース: データは Cassandra に一意のキー (uuid) で挿入され、このデータの一部の列は頻繁に更新され続けます。どのアプローチをお勧めしますか?

1. 挿入クエリで新しい列の値を持つ同じデータを挿入します。
2. 更新クエリの新しい列値で、指定された uuid に基づいて既存のレコードを更新します。

墓石を作成するアプローチと作成しないアプローチはどれですか? また、Cassandra は両方のクエリをどのように処理するのでしょうか?

Memtables とコミット ログには、削除されたデータをマークするためのトゥームストーンがありますか? Memtables で削除されたデータは、データをフラッシュする前にどのようにマークされますか?

Cassandra をデータベース システムとして使用する CMS のコードを書いています。

CMS の強みの 1 つは、CMS で変更されるデータに対して永続的に実行されるバックエンド コンピューターを使用して、あらゆる種類のものを事前に計算できることです。

たとえば、CMS は、ページが作成または変更されたことをリスト システムに通知します。リスト システムは、その情報を というテーブルに保存しますlist。その情報は、どのページを処理する必要があるかを示す 1 つのライナーにすぎません。

ときどき (ほとんどの場合、単純なページ編集後 1 秒以内)、そのリスト バックエンド システムが起動し、特定のページが変更されたことを確認し、含まれている (または含まれていない) すべてのリストを更新することによって、そのページで作業を開始します。そのページを要素として。これにより、フロントエンドはリスト内の要素の数を即座に認識し、リストが必要なときに複雑なクエリを実行することなくリストを非常に迅速に読み取ることができます (多くの CMS が SQL を使用して行うこととは対照的です...)

実際には、listテーブルを TODO リストとして使用しています。私が取り組まなければならない一連のページ。そのため、フロントエンドはそのリストにページ参照を追加し、バックエンドはそれらの処理が完了するとそれらを削除します。その結果、テーブル内に非常に多くのトゥームストーンが作成される可能性がありlistます。現実世界の影響: トゥームストーン障害が発生し、システムがランダムな場所で障害を起こし始めました。リストが機能しなくなると、システム内の他の多くの機能が停止し、Web サイトが使用できなくなります。

Cassandra がその特定のテーブル (および他のいくつかのテーブル) の墓石を処理するのにかかる時間を短縮しましたが、期待どおりに Cassandra を使用しているかどうか疑問に思っています。この環境でこの種の TODO リストを処理するためのより良い方法はありますか?

補足として: TODO リストは、さまざまなバックエンド コンピューターから処理される可能性があります。小規模なシステムでは、リスト データに対して実行するバックエンドが 1 つしかない可能性が高く、数千人のユーザーがいる大規模なシステムでは、リストを処理するためだけに 2 つまたは 3 つのバックエンドを使用する可能性は低くありません。そのため、Cassandra にデータを保持することは、コンピューター間でデータをすばやく共有するのに非常に実用的です。

テーブルの修復を行うと、次のような多くの警告が表示されます。

しかし、私は何も削除せず、TTL も設定していないため、何も削除されていません。墓石が多いのはなぜ？データサイズは約200Gですが、NULLでいくつかのセルを挿入しています。

これを試してデバッグするための手順を教えていただければ幸いです。このバグは Android 6.0.0 と Android 6.0.1 でランダムにのみ発生するため、アプリのデバッグを試みるしかありません。私のコードはすべてネイティブ Android Java で書かれています。

05-10 10:31:15.471 15933-15933/com.ragemods A/libc: 致命的な信号 11 (SIGSEGV)、コード 1、tid 15933 の障害 addr 0x0 (com.ragemods)

そして、これに付随する墓石は次のとおりです。

https://www.dropbox.com/s/svwhdzub70klgpb/tombstone_00?dl=0

ご協力いただきありがとうございます。

また、これが役立つ場合は、エントリのスタック トレースを以下に示します。

私の会社では、debian サーバーで実行されている Cassandra (2.1.8) を使用しています。

クエリ/準備済みステートメントに一貫性を設定しないと、"SELECT * FROM table_name WHERE key = ?". 追加後:

毎回返事が来ます。ただし、以下の記事から： 一貫性レベルの読み取り/書き込み戦略

一貫性を気にしないのであれば、この議論は意味がありません。一貫性レベルに関係なく読み取り/書き込みが可能で、Cassandra の非同期レプリケーションと反エントロピー機能が機能します。とはいえ、目標はネットワーク トラフィック/コストを最小限に抑えることですが、ワークロードのほとんどが読み取りである場合、CL QUORUM または ALL で書き込みを行う追加コストは、実際にはそれほど大きくない可能性があります。

一貫性を気にしなければ、私の一貫性レベルは問題にならないと言われています。そして、私はしません。データが何時間も何日も前のものであるかどうかは、私にはあまり問題ではありません。しかし、私は毎回データを取得することに気を配っています。

私が知る必要があるのは、書き込みにも一貫性レベルを設定して、それらが実際に書き込まれることを確認し、以前に何かを書いた場合、読み取りが常に値を取得する必要があるかどうかです。

そして、上記の基準を考えると、その一貫性レベルはどのくらいになるでしょうか?