問題タブ [tombstone]

最近gc_grace_seconds、CQL テーブルを下げました。私は走っていLeveledCompactionStrategyます。SSTableから古いトゥームストーンを強制的に削除することはできますか?

データ モデルを単純化しすぎると、次のテーブルがあります。

最初のテーブルには数億のレコードを含めることができ、インデックス テーブルを使用して、クエリ可能なパラメーターに基づいてデータを簡単に検索します。

問題は、foo、bar、またはbazのいずれかに基づいてデータをパージする必要がある場合に発生します。ストレージテーブルとすべてのインデックス テーブルからエントリを削除する必要があります。したがって、たとえばfooで削除すると仮定すると、実行される手順は次のとおりです。

1. 適切なインデックス テーブルに基づいて ID を見つけます (この場合はstorage_idx_by_foo ) 。
2. barとbazを取得し、ストレージテーブルからレコードを削除します
3. 残りの 2 つのインデックス テーブルからレコードを削除します ( bar / bazとidがあります) 。

ステップ 3 は、トゥームストーンが原因で問題になります。残りの 2 つのインデックス テーブルから何百万ものレコードを削除すると (つまり、パーティションによってではなく)、Cassandra は何百万ものトゥームストーンを作成し、圧縮が発生する前にデータを読み取るときに多くの頭痛の種となります。

簡単なブレインストーミングでは、次のことができることが示唆されています。

1. パージ プロセス後に圧縮を強制する
2. これらの 2 つのテーブルから削除せず、コード内の存在しないものを指すインデックス エントリを処理します
3. ????

推奨されるアプローチは何ですか? 他の Cassandra ユーザーもこの問題に遭遇したと思いますが、「Cassandra のやり方が間違っている」以外のアドバイスをオンラインで見つけることができませんでした。この問題を回避するためにデータを別の方法でモデル化することはできなかったと思います (もし可能であれば、それについてのフィードバックもいただければ幸いです)。

現在、私たちはオプション 2 に傾いていますが、データベースにゴミが残るという考えは好きではありません。

そのため、テーブルからデータをクエリすると、この例外が発生します。私はオンラインでたくさん読んでいますが、私が理解していることから、これはnull行がたくさんあるために起こります。しかし、これを解決する方法は何ですか？これらのヌルをすべて簡単に取り除くことはできますか?

更新：私は走っnodetool compactて、スクラブも試しました。どちらの場合も、これを取得します。

そして、これらはからの最後の行です system.log

最後の行の意味がわかりません。非常に大きな行はないようです (存在するかどうかを見つける方法がわかりません)。注意として、まだ圧縮が 60.33% でスタックしており、 でスタックしていokcoin_order_book_btc_usdます。Cassandra 2.0.11 を実行しています

Cassandra (バージョン 2) はどのタイプのトゥームストーンをサポートしていますか? この記事によると、それは（CQL用語で）サポートしています：

• 行の特定の列。
• 静的列。
• パーティション キーのすべての行。

他の種類の墓石を見逃していませんか? 特定の (CQL) 行を削除しますか? クラスタ キーなどの範囲の削除をサポートする特別なトゥームストーンはありますか? この情報は、トゥームストーンが多くなりすぎないようにスキーマを計画するときに知っておくと役立ちます。

Cassandra に支えられた Titan Graph DB サーバーを永続ストアとして実行していますが、Cassandra トゥームストーンのしきい値の制限に達するという問題が発生しており、データが蓄積されるとクエリが定期的に失敗/タイムアウトします。追加された墓石の数に圧縮が追いついていないようです。

私たちのユースケースは以下をサポートしています：

1. 高い読み取り/書き込みスループット。
2. 読み取り感度が高い。
3. Titan のノード値の頻繁な更新。Cassandra で行が更新されます。

上記の使用例を考慮して、以下を積極的に行うために Cassandra をすでに最適化しています。

1. レベル化された圧縮戦略を使用した積極的な圧縮
2. tombstone_compaction_interval を 60 秒として使用します。
3. tombstone_threshold を 0.01 に使用する
4. gc_grace_seconds を 1800 に設定する

次の最適化にもかかわらず、Cassandra ログに次のような警告が引き続き表示されます 。 ）。8001 列が要求されました。スライス = [00-ff]、delInfo = {deletedAt = -9223372036854775808、localDeletion = 2147483647}

時折、時間の経過とともに、障害のしきい値を超えてエラーが発生することもあります。

cassandra.yaml ファイルの tombstone_warn_threshold は 10000 に設定されており、tombstone_failure_threshold は推奨値の 250000 よりもはるかに高く設定されていますが、特に目立ったメリットはありません。

さらに最適化する余地がある場合は、正しい構成を示すことができるヘルプがあれば大歓迎です。お時間とご協力いただきありがとうございます。

Cassandra 2.1.3 で時系列アプリケーションのデータモデルを作成しています。システムのユーザーごとに X 量のデータを保存する予定ですが、この要件に合わせて設計するための最良のアプローチは何か疑問に思っています。

オプション1：

パーティション キーで「バケット」を使用して、X 期間のデータが同じ行に入るようにします。このようなもの：

このバケットの概念を維持することを犠牲にして、一度に 1 つの行を削除できます。また、クエリできる範囲も制限さtimestampれるため、複数のクエリが発生する可能性があります。

オプション 2:

すべてのデータを同じ行に格納します。N 個の削除は列ごとです。

範囲クエリも簡単です。しかし、多くの列を削除した後のパフォーマンスはどうでしょうか?

TTL を使用してデータを期限切れにすることを計画している場合、2 つのモデルのどちらが最高のパフォーマンスを発揮しますか? Option1 << Option2 の墓石のオーバーヘッドですか、それとも両方のモデルで列ごとに墓石がありますか?

墓石墓地に埋葬されるのを避けようとしている。

Cassandra から行を削除しても、データがまだ memtable に残っている場合 (SSTable はまだ作成されていません)、削除された行は memtable でクリーンアップされないように見えます。なぜなら、削除された行は memtable でクリーンアップされていないように見えます。 SSTable。SSTableにフラッシュする前に、memtable自体から削除された行を完全にクリーンアップできる方法はありますか? 更新は行われていますが、削除は行われていないようです。

Cassandra 2.0.8 を使用しています。

ありがとう

100k のトゥームストーンをスキャンした後、cassandra はクエリでエラーを出します。テーブルでメジャー コンパクションを実行しようとしましたが、セカンダリ インデックスのトゥームストーンは削除されません。クエリはまだ完了できません。

しばらく検索しましたが、rebuild_index が 1 つの提案ですが、再構築中に多くのクエリが失敗する可能性があると思います。また、インデックスの再構築にかかる時間の見積もりもありません。

なにか提案を？