cassandraは、データを削除すると墓石を生成します。 いくつかの状況では、過剰な墓石は、長いGCの一時停止、レイテンシ、読み取りエラー、またはヒープ外エラーを引き起こす可能性があります。 この記事では、墓石を管理するためのアドバイスを提供します。

目次

墓石とは何ですか？Cassandraでは、削除されたデータはすぐにディスクからパージされません。 代わりに、Cassandraは、データが削除されたことを示すために、墓石と呼ばれる特別な値を書き込みます。 墓石は、読み取り中に削除されたデータが返されないようにし、最終的には圧縮を介してデータをドロップできるようにします。

墓石は書き込みです–通常の書き込みパスを通過し、ディスク上のスペースを占有し、Cassandraの一貫性メカニズムを利用します。 墓石は、ヒントと修理を介してクラスタ全体に伝播することができます。 クラスターが適切に管理されている場合、これにより、削除が発行されたときにノードがダウンしていても、データが削除されたままになります。

墓石は次のように生成されます。

:

• DELETEステートメント
• TTLsの設定
• null値の挿入
• コレクションの一部にデータを挿入します。

墓石の通常のライフサイクルは何ですか？

墓石はタイムスタンプで書かれています。 理想的な状況下では、一定の時間が経過した後、圧縮中に墓石（およびそれに関連するデータ）が削除されます。

墓石を削除するには、次の三つの基準を満たす必要があります。

• 墓石はgc_grace_secondsよりも前に作成されました。
  • 墓石はgc_grace_secondsよりも前に作成されました。
    • 墓石を含むテーブルは圧縮に関与しています。
    • 関連するデータを含む可能性のあるすべてのsstableが圧縮に関与しています。

    各テーブルにはgc_grace_seconds設定があります。 デフォルトでは、これは864000に設定されており、これは10日に相当します。 その目的は、クラスターが修復によって一貫性を達成するための時間を提供することです（したがって、削除されたデータの復活を防ぐことです）。

    墓石は、関連するデータを含む可能性のあるすべてのsstableが圧縮に関与している場合にのみ、圧縮を介してドロップされます。 元のデータの書き込みから削除の発行までに多くの時間が経過した場合、これは可能性が低くなります。

    • Size-Tiered Compaction戦略は、同様のサイズのsstableを一緒にコン データは年を取るにつれて大きなsstableに移動する傾向があるため、墓石（新しい小さなsstable）がデータ（古い大きなsstable）で圧縮されることはまずありません。
    • 水平圧縮戦略は、別々に圧縮されている多くのレベルに分割されます。 墓石はレベル0に書き込まれ、レベルを介してデータを効果的に”追跡”します–最終的に追いつくはずです。
    • タイムウィンドウ圧縮戦略(または日付階層圧縮戦略)は、異なるタイムウィンドウに書き込まれた場合、墓石をデータで圧縮することはありません。

    墓石に問題が発生するのはいつですか？

    ディスク使用量

    データが削除されると、少なくともテーブル設定で設定されたgc_grace期間は、実際には領域が解放されません。 これは、クラスターが急速にいっぱいになっている場合に問題を引き起こす可能性があります。

    状況によっては、手動の介入なしにスペースが解放されることはありません。

    読み取りパフォーマンス

    読み取りで大量の墓石が発生すると、深刻なパフォーマンスの問題が発生する可能性があります。

    パフォーマンスの問題は、次のタイプのクエリで発生する可能性が最も高いです。

    • テーブル内のすべてのパーティションを実行するクエリ(“select*from keyspace.テーブル”)
    • 範囲クエリ(“select*from keyspace.table WHERE value>x”、または”WHERE value IN(value1,value2,…)”
    • “ALLOW FILTERING”句でのみ実行できる任意のクエリ。

    これらのパフォーマンスの問題は、読み取り中の墓石の動作が原因で発生します。 範囲クエリでは、Cassandraドライバは通常、ノードが一度に限られた数の応答を返すことを可能にするページングを使用します。 Cassandraの墓石が関係している場合、ノードは、関連するデータが削除されたことを他のレプリカのいずれかが認識していない場合に備えて、遭遇した墓石をメ すべてを返すことが不可欠であるため、墓石をページングすることはできないため、レイテンシとメモリ使用量は、遭遇する墓石の数に比例して増加し

    墓石が検出されるかどうかは、データが格納され、取得される方法によって異なります。 たとえば、Cassandraを使用してキューにデータを格納する場合（これは推奨されません）、クエリで数万の墓石が発生し、数行のデータが返される可能性があります。墓石に関連する問題を診断するにはどうすればよいですか？

    墓石関連の問題を診断するにはどうすればよいですか？

    大量の墓石に遭遇するクエリは、ログに表示されます。 デフォルトでは、千以上の墓石に遭遇した読み取りは警告を生成します：

    WARN org。アパッチカサンドラdb。ReadCommandクエリSELECT*FROMの例では、0のライブ行と87051の墓碑セルを読み取ります。table

    デフォルトでは、100,000以上の墓石が検出されると、T O M B S T Oneoverwhelmingexceptionでクエリが失敗します。

    墓碑読み取りがパフォーマンスの問題を引き起こしているかどうかを確認するには、読み取りが読み取り待ち時間とGC一時停止期間の増加と相関しているかどうかを確認します。

    墓石が問題であることが明らかな場合は、次の手法を使用して、問題の範囲を絞り込むことができます。

    • 特定のクエリで返される墓石の数は、トレーシングを有効にした状態でcqlshでクエリを実行することで見つけることができます。
    • 各テーブルで最近遭遇した墓石の数の統計は、nodetool cfstatsの出力で利用できます。
    • マネージドサービスのクラスターの場合、最近発生した墓石の統計は、メトリックリストのクラスターページで利用できます>テーブル情報。 これには、読み取りごとのライブセルと、読み取りごとの平均および最大墓石が含まれ、特定の期間のノードまたはテーブルごとに分類されます。
    • 保存された墓石に関するより詳細な情報は、ic-toolsを使用して見つけることができます。

    墓石の問題を回避するにはどうすればよいですか？

    次のオプションが役立ちます。

    • テーブル内のすべてのパーティションで実行されるクエリを回避します(WHERE句のないクエリや、ALLOW FILTERINGを必要とする
    • 削除されたデータを照会しないようにするには、範囲クエリを変更するか、より狭い範囲のデータを操作します。 パフォーマンスの問題は、墓石が読み取られ、読み取られた墓石の数に合わせてスケーリングされた場合にのみ発生します。
    • 大量のデータを削除しないようにデータモデルを設計します。
    • テーブル内のすべてのデータを削除する場合は、テーブルを切り捨てたり削除して、墓石を生成せずにすべてのデータを削除します。
    • デフォルトの有効期間の値を使用します。 これは、データの主キーが時間ベースであり、データが時系列で書き込まれ、データが既知の日付に削除される場合にのみ効率的に機能します。 これを行うには、テーブルレベルのオプションで既定のTTLを設定し、時間ベースの圧縮戦略を設定します(使用可能な場合はT I M E Windowcompactionstrategy、それ以外の場合はDateTieredCompactionStrategy)。 これはまだ墓石を作成しますが、すべての内容のTTLが経過すると、sstable全体が効率的に削除されます。

    既存の墓石を取り除くにはどうすればよいですか？

    ほとんどの状況では、墓石が正常にコンパクトになるのを待つのが最善の方法です。 緊急のパフォーマンスまたはディスク使用の問題がより即時のアクションを必要とする場合は、圧縮を強制するために使用できるnodetoolコマンドが2つあり、これは墓石の削除を支援することができます。 適切に設計されたデータモデルを持つ正常なクラスターでは、手動で圧縮を実行する必要はありません。

    実行中nodetool compactすべてのsstableの圧縮を強制します。 これには大量の空きディスク領域が必要です。 Keyspace引数とtable引数は、圧縮をtombstonesが問題になるテーブルに制限するために使用する必要があります。 サイズ階層型圧縮戦略が使用されているテーブルでは、このコマンドは、圧縮するピアを持たない巨大なsstableを作成する可能性があります; –split-outputフラグが使用可能な場合は、それを使用する必要があります。

    nodetool garbagecollectコマンドはCassandra3.10以降で使用できます。 このコマンドは、重複するsstableもチェックする一連の小さな圧縮を実行します。 これは、nodetool compactよりもCPUを集中的に消費し、時間がかかりますが、ディスクの空き容量は少なくて済みます。墓碑が作成されてからgc_grace_secondsが経過した場合にのみ墓碑が削除されます。

    墓碑が作成されてからgc_grace_secondsが経過した場合にのみ墓碑が削除され Gc_grace_secondsの意図された目的は、クラスターの整合性を復元するための修復のための時間を提供することであるため、変更するときは注意してください。 また、gc_grace_seconds設定は、ヒントハンドオフ用に生成されたヒントの有効期限に影響するため、gc_grace_secondsをヒントハンドオフウィンドウの期間(デフォルトでは3時間)を下回るようにすることは危険です。

    修理

    修理は、墓石の落下を遅らせたり防止したりする可能性があります。 完全修復または増分修復が実行されると、影響を受けたsstableは修復済みとしてマークされます。 墓石がペアリングされていないsstableにあり、シャドウされたデータが修復されたsstableにある場合(またはその逆)、sstableを一緒に圧縮することができないため、データ
    クラスターで定期的にフルまたは増分の修復を実行する場合、墓石やデータは最終的に修復されるため、これはあまり問題にならないはずです。 ただし、修復されたデータと修復されていないデータが混在していて、定期的に修復を実行していない場合、これが問題になる可能性があります。 sstablemetadataは、sstableの修復された状態を検査して、これが発生しているかどうかを調べるのに役立ちます。 そうであれば、すべてのsstableをsstablerepairedsetでペアリングされていないものとして設定して、それらを一緒に圧縮できるようにすることをお勧めします。
    サブレンジリペアはデータを修復したものとしてマークしないことに注意してください。