分散データベースでの削除について

ここまで削除処理を見てきました。比較的簡単に実行できるのでAPIレベルで難しいところはないと思います。ところが，Cassandraが分散データベースである点を考慮すると，実はこの削除という処理は厄介なことになってきます。

Cassandraは複数ノードを立てて運用する場合，レプリケーション数を3かそれ以上にするのが一般的です。つまり複数ノード間でデータのレプリケーションを行うようになっています。

また，Cassandraは一貫性モデルをイベンチュアルコンシステンシに沿って設計されているので，内部的には以下の処理が行われています。

• ユーザの検索処理が終わった後に各ノード間の整合性をとる（read repair)
• 一時的に死んでいたサーバに後からデータの同期を行う（hinted handoff)
• 非同期に定期的に各ノードが保持しているデータを同期する（antientropy）

このため，本当にただデータを削除するだけだと，ノード間の整合性でデータが復旧されてしまったり，システムとしてのデータ一貫性のレベルが低下してしまう危険性があります。これは避けねばなりません。そこでCassandraでは，データを単純に物理削除するのではなく，データ削除の特別な値におきかえる処理（いわゆる論理削除）を最初に行っています。

この削除用の特別な値のことをトゥームストーン（墓標とか墓石という意味です）と呼んでいます。この仕組みのおかげで，レプリカ間でもトゥームストーンが伝播するので，削除された値であることがすぐにわかります。

ただし，これだけだと，削除されたデータが物理的には削除されないため，ディスクを圧迫していくばかりです。そこで，トゥームストーンがついたデータはある一定のタイミングで物理的に削除される仕組みになっています。このタイミングはCassandraのstorage-conf.xmlのGCGraceSecondsで変更することができます。デフォルトは10日です。また，運用管理者の操作によって，永続化されたデータをコンパクトにする処理を行った際にトゥームストーンも削除します。

以上，今回は更新と削除についてまとめました。次回は検索をしてみます。お楽しみに。