cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Cassandra Wiki] Update of "DistributedDeletes_JP" by yukim
Date Mon, 05 Apr 2010 15:13:53 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification.

The "DistributedDeletes_JP" page has been changed by yukim.
http://wiki.apache.org/cassandra/DistributedDeletes_JP?action=diff&rev1=3&rev2=4

--------------------------------------------------

  ## page was copied from DistributedDeletes
- 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.
+ 予備知識として、Cassandraは!ReplicationFactorを定義することを思い出してください。それはキーと関連するカラムがいくつのノードに書き込まれるかを定義します。(Dynamoと同じように)Cassandraでは、書き込み時(削除時も含む)にいくつのレプリカをブロックするかを制御できます。具体的には、クラスタの!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 HintedHandoff, ReadRepair, and AntiEntropy 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.)
+ (イベンチュアルコンシステンシー(結果整合性)の"イベンチュアル"のこと。もしも更新を受け取っていないレプリカを低い!ConsistencyLevelで読み込んだ場合、古いデータを読み込む可能性が有ります。CassandraはHintedHandoff、ReadRepair、AntiEntropyを用いて、データが一貫していない時間を短くします。!ConsistencyLevel.QUORUMのような高いレベルの一貫性も提供しますが、依然注意が必要です。)
  
- 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.
+ したがって削除操作では、削除されようとしているデータのすべての痕跡をすぐに取り除くことができません。それが可能であるとすると、あるレプリカが削除操作を受け取らなかった場合、そのデータがもう一度利用可能になった際に、削除操作を受け取ったレプリカを更新ミスとして扱ってしまい、データを修復してしまいます!
したがって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のようなコーディネータを導入することはできますが、シンプルに保たれたデザインという原則からはずれてしまいます。複雑な運用
-- モニターするのは1つのシステムだけで良いはずなのに、結局2つのシステムをモニターすること
-- になります。(これはZKが悪いソフトウェアだと言っているのではありません。
-- 同じような機能を提供するものの中では最上でしょう。 -- そもそも我々のシステムに含めたくない問題を解決するだけなのです。)
  
- 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 [[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 (see MemtableSStables).
+ したがってCassandraでは、解決方法が不明な問題に直面した分散システム設計者がよく行う方法をとっています。つまり解決できる問題に変換するために、さらなる制約を定義することです。CassandraではGCGraceSecondsという定数を定義し、各ノードにそれぞれのローカルのTombstoneの年齢を追跡させます。そして定数値を超える時間が経過するとGC可能だと判断します。ということはGCGraceSecondsよりも長い間ノードがダウンした場合、そのノードを故障したものとみなして[[Operations]]にある手順でノードを置き換えるべきです。デフォルトの設定はとても控えめで、10日間に設定してあります。ニーズに合ったAntiEntropyを設定すると、この値を短くすることができます。もちろんCassandraを1ノードで動かしている場合は0に設定することもできます。その場合、Tombstoneは最初のコンパクション時にGCされます。([[MemtableSSTable_JP|MemtableSSTable]]を参照。)
  

Mime
View raw message