Agile Cat — in the cloud

Cassandra 分散データベースでの削除とは?

Posted in NoSQL by Agile Cat on February 10, 2010

Distributed deletes in the Cassandra database
Monday, February 08, 2010

http://spyced.blogspot.com/2010/02/distributed-deletes-in-cassandra.html

image

Handling deletes in a distributed, eventually consistent system is a little tricky, as demonstrated by the fairly frequent recurrence of the question, "Why doesn’t disk usage immediately decrease when I remove data in Cassandra?"

Cassandra にデータを削除するとき、なぜ直ぐに、ディスクの使用量が減らないのか?」という質問が頻繁に繰り返されるように、Eventually Consistent システムにおける、分散データの Delete 処理は、少々トリッキーである。

As background, recall that a Cassandra cluster defines a ReplicationFactor that determines how many nodes each key and associated columns are written to. In Cassandra (as in Dynamo), the client controls how many replicas to block for on writes, which includes deletions. In particular, the client may (and typically will) specify a ConsistencyLevel of less than the cluster’s ReplicationFactor, that is, the coordinating server node should report the write successful even if some replicas are down or otherwise not responsive to the write.

それぞれのキーごとのノード数と、それに関連する記述されたカラム数を決定する ReplicationFactor を、 バック・グラウンドとしての Cassandra クラスタが定義することを思い出してほしい。 Cassandra においては(Dynamo のように)、クライアントは書き込み時にレプリカのためのブロック数を制御するが、そこには削除も含まれる。 とりわけ、クライアントでは、クラスタの ReplicationFactor より少ない値を、ConsistencyLevel に指定することになるだろう(一般的にはそうなる)。つまり、いくつかのレプリカがダウンしていようが、また、書き込みに反応しなくても、サーバーノードの調整では、書き込みが成功していると報告されるはずだ。

(Thus, the "eventual" in eventual consistency: if a client reads from a replica that did not get the update with a low enough ConsistencyLevel, it will potentially see old data. Cassandra uses Hinted Handoff, Read Repair, and Anti Entropy to reduce the inconsistency window, as well as offering higher consistency levels such as ConstencyLevel.QUORUM, but it’s still something we have to be aware of.)

(したがって、eventual consistency における ”eventual” となる。つまり、適切な ConsistencyLevel で更新されていないレプリカから、クライアントが読み込みを行う場合には、古いデータだと見なされる。 Cassandra は、inconsistency window を低減するために、 Hinted Handoff と、Read RepairAnti Entropy を使用する。それだけではなく、ConstencyLevel.QUORUM などの higher consistency level なども提供するが、今後の課題となる)

Thus, a delete operation can’t just wipe out all traces of the data being removed immediately: if we did, and a replica did not receive the delete operation, when it becomes available again it will treat the replicas that did receive the delete as having missed a write update, and repair them! So, instead of wiping out data on delete, Cassandra replaces it with a special value called a tombstone. The tombstone can then be propagated to replicas that missed the initial remove request.

それ故に、Delete 操作により、削除されたデータに対する全トレースを、直ちに消し去ることはできない。仮に削除したとしても、レプリカが削除オペレーションを受けない場合も想定される、そのレプリカが再び利用可能になるとき、削除を受け取った書き込みの更新をミスしたと勘違いして、自身で復元してしまう!そのため、Cassandra では、削除されたデータを取り除く代わりに、tombstone(墓石)と呼ばれる特殊値で、そのデータを置き換える。 続いて、この tombstone を、最初の削除リクエストを見逃したレプリカに対して、プロパゲートすることができる。

There’s one more piece to the problem: how do we know when it’s safe to remove tombstones? In a fully distributed system, we can’t. We could add a coordinator like ZooKeeper, but that would pollute the simplicity of the design, as well as complicating ops — then you’d essentially have two systems to monitor, instead of one. (This is not to say ZK is bad software — I believe it is best in class at what it does — only that it solves a problem that we do not wish to add to our system.)

この問題に関しては、もうひとつの視点がある。 つまり、tombstone を安全に取り除くタイミングのことである。 ただし、完全に分散されたシステムでは、それを行うことができない。 ZooKeeper のようなコーディネーターを加えることができるが、操作を複雑にすることに加えて、デザインの単純さが損なわれる。 そして、本質的には、モニターのためのシステムを加えた、2つのシステムを持つことになる。 (これは、ZooKeeper を批判しているのではない。それは、すばらしいソフトウェアだと信じるが、私たちが解決を望む問題に合っていない)

So, Cassandra does what distributed systems designers frequently do when confronted with a problem we don’t know how to solve: define some additional constraints that turn it into one that we do. Here, we defined a constant, GCGraceSeconds, and had each node track tombstone age locally. Once it has aged past the constant, it can be GC’d. This means that if you have a node down for longer than GCGraceSeconds, you should treat it as a failed node and replace it as described in Cassandra Operations. The default setting is very conservative, at 10 days; you can reduce that once you have Anti Entropy configured to your satisfaction. And of course if you are only running a single Cassandra node, you can reduce it to zero, and tombstones will be GC’d at the first compaction.

したがって、解決する方法を知らない問題に直面するときに、分散システムのデザイナーが頻繁に行うことを、 Cassandra は行う。つまり、いくつかの制約を定義して、それを取り除いいていくという方法である。 私たちは、GCGraceSeconds という定数を定義し、また、それぞれノードトラックの tombstone におけるローカルな年齢を持つことにした。 この定数を、tombstone の年齢が上回ると、それは GC になる。 つまり、GCGraceSeconds より長生きなノードがダウンした場合には、それを失敗したノードとして取り扱い、 Cassandra Operations に記述されるように置き換えるべきだ。 デフォルト設定は、10日という、きわめて保守的な値である。そして、Anti Entropy をコンフィグレーションすれば、短くすることができる。 もちろん、シングル Cassandra ノードを走らすなら、その値をゼロにすることが可能であり、最初の compaction において tombstone を GC にできる。

<関連>
イベンチュアル・コンシステンシーはお好き? by James Hamilton
Twitter が Cassandra を選んだ理由 — MyNoSQL
Digg が Cassandra を採用する理由 by John Quinn
Cassandra プロジェクトと Rackspace
NoSQL Ecosystem とは? _1
NoSQL Ecosystem とは? _2
NoSQL Ecosystem とは? _3

Comments Off on Cassandra 分散データベースでの削除とは?

%d bloggers like this: