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 shot6
Date Tue, 06 Apr 2010 04:54:18 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 shot6.
http://wiki.apache.org/cassandra/DistributedDeletes_JP?action=diff&rev1=4&rev2=5

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

  ## page was copied from DistributedDeletes
  予備知識として、Cassandraは!ReplicationFactorを定義することを思い出してください。それはキーと関連するカラムがいくつのノードに書き込まれるかを定義します。(Dynamoと同じように)Cassandraでは、書き込み時(削除時も含む)にいくつのレプリカをブロックするかを制御できます。具体的には、クラスタの!ReplicationFactorよりも!ConsistencyLevelを低く設定したりします。その場合、クライアントがアクセスしているサーバーノードは、いくつかのレプリカがダウンしていたり書き込みに応答しなかった場合でも、書き込みが成功した、と結果を返します。
  
- (イベンチュアルコンシステンシー(結果整合性)の"イベンチュアル"のこと。もしも更新を受け取っていないレプリカを低い!ConsistencyLevelで読み込んだ場合、古いデータを読み込む可能性が有ります。CassandraはHintedHandoff、ReadRepair、AntiEntropyを用いて、データが一貫していない時間を短くします。!ConsistencyLevel.QUORUMのような高いレベルの一貫性も提供しますが、依然注意が必要です。)
+ (イベンチュアルコンシステンシー(結果整合性)の"イベンチュアル"のこと。もしも更新を受け取っていないレプリカを低い!ConsistencyLevelで読み込んだ場合、古いデータを読み込む可能性が有ります。Cassandraは[[HintedHandoff_JP|HintedHandoff]]、[[ReadRepair_JP|ReadRepair]]、AntiEntropyを用いて、データが一貫していない時間を短くします。!ConsistencyLevel.QUORUMのような高いレベルの一貫性も提供しますが、依然注意が必要です。)
  
  したがって削除操作では、削除されようとしているデータのすべての痕跡をすぐに取り除くことができません。それが可能であるとすると、あるレプリカが削除操作を受け取らなかった場合、そのデータがもう一度利用可能になった際に、削除操作を受け取ったレプリカを更新ミスとして扱ってしまい、データを修復してしまいます!
したがってCassandraでは削除時にデータを消去する代わりにTombstone(廃棄)と呼ばれる特別な値で置き換えます。Tombstoneは削除要求を受け取れなかったレプリカにも伝播されます。
  

Mime
View raw message