トゥームストーン
トゥームストーンとは？
Cassandraのデータ削除プロセスは、パフォーマンスを向上させ、Cassandraの組み込みのデータ分散とフォールトトレランスの特性と連携するように設計されています。
Cassandraは削除を挿入として扱い、トゥームストーンと呼ばれるタイムスタンプ付きの削除マーカーを挿入します。トゥームストーンはCassandraの書き込みパスを通過し、1つ以上のノードのSSTableに書き込まれます。トゥームストーンの主な機能の違いは、組み込みの有効期限/時刻を持っていることです。有効期限（猶予期間）が終了すると、トゥームストーンはCassandraの通常のコンパクションプロセスの一部として削除されます。
|
Cassandraの行または列に有効期限（TTL）値をマークすることもできます。この時間が経過すると、Cassandraはオブジェクトにトゥームストーンをマークし、他のトゥームストーンオブジェクトと同様に処理します。 |
なぜトゥームストーンなのか？
トゥームストーンは、行または列の値のいずれかのオブジェクトの削除を表します。このアプローチは、Cassandraの分散型の性質のため、値を削除する代わりに使用されます。オブジェクトがトゥームストーンとしてマークされると、クエリはトゥームストーンの挿入前にタイムスタンプが付けられたすべての値を無視します。
ゾンビ
複数ノードクラスターでは、Cassandraは同じデータのレプリカを2つ以上のノードに格納する場合があります。これはデータの損失を防ぐのに役立ちますが、削除プロセスが複雑になります。ノードがローカルに格納されているデータの削除コマンドを受信すると、ノードはそのオブジェクトにトゥームストーンを付け、そのオブジェクトのレプリカを含む他のノードにトゥームストーンを渡そうとします。ただし、その時点で1つのレプリカノードが応答しない場合、トゥームストーンをすぐに受信しないため、削除前のバージョンのオブジェクトがまだ含まれています。そのノードが回復する前に、トゥームストーンオブジェクトがクラスターの残りの部分からすでに削除されている場合、Cassandraは回復したノードのオブジェクトを新しいデータとして扱い、クラスターの残りの部分に伝播します。この種の削除されたが永続的なオブジェクトは、ゾンビと呼ばれます。
猶予期間
ゾンビの再出現を防ぐため、Cassandraは各トゥームストーンに猶予期間を与えます。トゥームストーンの猶予期間は、テーブルプロパティ `WITH gc_grace_seconds` で設定されます。デフォルト値は864000秒（10日）で、その後トゥームストーンは期限切れになり、コンパクション中に削除できます。猶予期間が満了する前は、Cassandraはコンパクションイベントを通じてトゥームストーンを保持します。各テーブルはこのプロパティに独自の値を設定できます。
猶予期間の目的は、応答しないノードが回復し、トゥームストーンを正常に処理する時間を与えることです。クライアントが猶予期間中にトゥームストーンオブジェクトに新しい更新を書き込むと、Cassandraはトゥームストーンを上書きします。クライアントが猶予期間中にそのオブジェクトの読み取りを送信すると、Cassandraはトゥームストーンを無視し、可能であれば他のレプリカからオブジェクトを取得します。
応答しないノードが回復すると、Cassandraはヒント付きハンドオフを使用して、ノードがダウンしている間に見逃したデータベースの変更を再生します。Cassandraは、猶予期間中にトゥームストーンオブジェクトの変更を再生しません。ただし、猶予期間が終了するまでノードが回復しない場合、Cassandraは削除を見逃す可能性があります。
トゥームストーンの猶予期間が終了すると、Cassandraはコンパクション中にトゥームストーンを削除します。
削除
`gc_grace_seconds` が経過すると、トゥームストーンが削除される場合があります（つまり、特定のデータが削除されたことを示すオブジェクトがなくなることを意味します）。ただし、削除の1つの複雑な点は、トゥームストーンが1つのSSTableに存在し、削除対象のデータが別のSSTableに存在する可能性があるため、コンパクションでは両方のSSTableも削除する必要があることです。より正確には、実際のトゥームストーンを削除するには、
-
トゥームストーンは `gc_grace_seconds` より古い必要があります。 `gc_grace_seconds` が経過しても、コンパクションイベントが発生するまでトゥームストーンは削除されないことに注意してください。
-
パーティションXにトゥームストーンが含まれている場合、パーティションを含むSSTableと、Xを含むトゥームストーンよりも古いデータを含むすべてのSSTableを同じコンパクションに含める必要があります。パーティションXを含むSSTableのすべてのデータがトゥームストーンよりも新しい場合、無視できます。
-
オプション `only_purge_repaired_tombstones` が有効になっている場合、データも修復されている場合にのみトゥームストーンが削除されます。このプロセスは、「トゥームストーンを使用した削除」セクションで説明されています。
ノードが `gc_grace_seconds` より長くダウンまたは切断されたままの場合、削除されたデータは他のノードに修復され、クラスターに再び表示されます。これは基本的に、「トゥームストーンなしの削除」セクションと同じです。
トゥームストーンなしの削除
値[A]がすべてのノードにレプリケートされている3ノードクラスターを想像してください。
[A], [A], [A]ノードの1つに障害が発生し、削除操作で既存の値のみが削除された場合、次のようになる可能性があります。
[], [], [A]次に、修復操作により、値[A]が値のない2つのノードに置き換えられます。
[A], [A], [A]これは、データが削除されていてもゾンビとして復活する原因となります.
トゥームストーンを使用した削除
値[A]がすべてのノードにレプリケートされている3ノードクラスターから 다시 시작합니다.
[A], [A], [A]データを削除する代わりにトゥームストーンオブジェクトを追加すると、単一ノード障害の状況は次のようになります。
[A, Tombstone[A]], [A, Tombstone[A]], [A]これで、修復を発行すると、削除されたデータが復活するのではなく、トゥームストーンがレプリカにコピーされます。
[A, Tombstone[A]], [A, Tombstone[A]], [A, Tombstone[A]]修復操作により、オブジェクト[A]がすべてのノードで削除済みとしてマークされた状態で、システムの状態が期待どおりに正しく設定されます。これは、ディスク容量を永続的に累積するトゥームストーンが最終的に発生することを意味します。トゥームストーンを永久に保持しないようにするために、Cassandraのすべてのテーブルに `gc_grace_seconds` を設定します。
完全に期限切れのSSTable
SSTableにトゥームストーンのみが含まれており、そのSSTableが他のSSTableのデータをシャドウイングしていないことが保証されている場合、コンパクションはそのSSTableを削除できます。トゥームストーンのみを含むSSTableが表示された場合（TTLデータは有効期限が切れるとトゥームストーンと見なされます）、コンパクションによって削除されていない場合は、他のSSTableに古いデータが含まれている可能性があります。削除可能なSSTableと、削除をブロックしているSSTableをリストする `sstableexpiredblockers` というツールがあります。 `TimeWindowCompactionStrategy` を使用すると、 `unsafe_aggressive_sstable_expiration` を有効にすることで、保証を削除できます（シャドウイングデータをチェックしない）。
