データはどのようにして削除されるか

Cassandraはどのようにデータを削除するのか、また削除されたデータがなぜ復活する可能性があるのか。

Cassandraは、リレーショナル・データベースとは異なる方法でデータを削除します。リレーショナル・データベースの場合は、期限切れのデータがないかデータをスキャンしてそれを捨てる時間を費やしたり、管理者が期限切れのデータを月単位に分割しなければならないことがあります。Cassandraカラムのデータには、TTL(Time to live)という有効期限日を任意で持たせることができます。CQLを使用することで、データのTTLを秒単位で設定することができます。Cassandraは、要求された時間が経過すると、TTLデータにトゥームストーンのマークを付けます。トゥームストーンは、gc_grace_secondsの期間中存在します。データにトゥームストーンのマークが付くと、このデータは通常のコンパクション中に自動的に除去されます。

削除されるデータについての注意事項
  • Cassandraは、削除対象のマークが付いたデータをすぐにディスクから除去することはしません。削除が行われるのは、コンパクションのときです。
  • SizeTieredCompactionStrategyまたはDateTieredCompactionStrategyを使用している場合は、コンパクション・プロセスを手動で開始することで、すぐにデータを削除できます。その手順を実行する前に、このプロセスの欠点を理解してください。コンパクションを強制的に実行すると、すべてのデータから1つの非常に大きいSSTableが作成される可能性があります。次回のコンパクションは長時間発動されません。強制コンパクション中に作成されたSSTable内のデータは、この長期間コンパクションされない間に非常に古くなる可能性があります。
  • リペアを定期的に実行しないと、削除されたデータが復活することがあります。

    データにトゥームストーンのマークが付けられると、Cassandraは、削除時にダウンしていたレプリカに削除要求を再送信するように合図されます。猶予期間中にレプリカが稼働を再開した場合、削除要求は最終的に受け取られます。しかし、猶予期間を過ぎてもノードがダウンしていた場合は、gc_grace_secondsの経過後にトゥームストーンが消えてしまうため、ノードがその削除を取りこぼしてしまう場合があります。Cassandraは必ず、ノードが稼働を開始すると、取りこぼした更新を再実行しようと試みます。障害が発生した後でノードをクラスターに戻す場合は、ノード・リペアを実行して、すべてのレプリカの間の不整合のリペアを行うのがベスト・プラクティスです。ノードがgc_grace_seconds内に復帰しない場合は、そのノードを除去し、そのノードのデータを削除して、再度ブートストラップを行ってください。