Cassandraは、「墓石」を書き込むことによって、削除するデータをマークします。マークされたデータのデフォルトは10日（構成ファイルのgc_grace_seconds）であり、対応するSSTableへの圧縮またはクリーンアップによって実行されると、実際にはディスクから削除されます。実行が成功した場合、トゥームストーンのある2つのノードがデータを削除すると、トゥームストーンのないノードのみがクラスターに残ります。次にキーが読み取られると、対応するデータが返され、削除されたデータが復活します。修復操作は、すべてのノードのデータを同期して、3つのノードすべてにトゥームストーンが存在することを確認できます。したがって、削除が100％成功したことを確認したい場合は、復元されません。定期的にgc_grace_seconds未満の周期で修復操作を実行する必要があります（したがって、公式の推奨は「毎週」です）
ただし、データを選択する場合、各SSTableファイルで検出されたクエリ条件を満たすすべてのトゥームストーンをメモリに配置して、各SSTableファイルのデータがマージされたときに、どの列データが削除されなかったかを最終的に返すことができるようにするには、トゥームストーンが多すぎるとヒープは非常に占有されており、パフォーマンスに影響を与えるためにさまざまなGCが必要となるため、cassandraはデフォルトで100,000（設定可能）の墓石を読み取り、この読み取りを強制的にキャンセルします。この場合、「間違っている」必要があるためです。したがって、行キーの下の列キーを頻繁に削除し、一度に行キーの下の複数の列キーを選択する必要がある場合、この状況が発生しやすくなります。トゥームストーンは、10w未満であっても正常に読み取られることがよくあります。今回は読み取りが非常に遅く、すぐに若い世代のGCがトリガーされ、ノード全体の応答速度が低下します。
最善の解決策は、設計時にそれを回避することです。ただし、テーブル構造を変更する必要がない場合は、2つの解決策があります。列キーを削除して復活させることができない場合は、最初にgc_grace_secondsを0に変更してから、削除するときに、1つのノードがタイムアウトする限り、ALLモードを使用します。 /削除に失敗した場合は失敗します。削除したデータの復活を受け入れることができる場合、削除はディスク領域の使用を削減するためだけであり、gc_grace_secondsを直接0に設定して、データを復活させます。
