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 Sun, 25 Apr 2010 13:13:34 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=5&rev2=6

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

  
  もう一つ問題が有ります。Tombstoneとなったデータを削除するのに安全なタイミングをどのように知ることができるでしょうか?
完全に分散化された環境ではそれを知ることは不可能です。!ZooKeeperのようなコーディネータを導入することはできますが、シンプルに保たれたデザインという原則からはずれてしまいます。複雑な運用
-- モニターするのは1つのシステムだけで良いはずなのに、結局2つのシステムをモニターすること
-- になります。(これはZKが悪いソフトウェアだと言っているのではありません。
-- 同じような機能を提供するものの中では最上でしょう。 -- そもそも我々のシステムに含めたくない問題を解決するだけなのです。)
  
- したがってCassandraでは、解決方法が不明な問題に直面した分散システム設計者がよく行う方法をとっています。つまり解決できる問題に変換するために、さらなる制約を定義することです。CassandraではGCGraceSecondsという定数を定義し、各ノードにそれぞれのローカルのTombstoneの年齢を追跡させます。そして定数値を超える時間が経過するとGC可能だと判断します。ということはGCGraceSecondsよりも長い間ノードがダウンした場合、そのノードを故障したものとみなして[[Operations]]にある手順でノードを置き換えるべきです。デフォルトの設定はとても控えめで、10日間に設定してあります。ニーズに合ったAntiEntropyを設定すると、この値を短くすることができます。もちろんCassandraを1ノードで動かしている場合は0に設定することもできます。その場合、Tombstoneは最初のコンパクション時にGCされます。([[MemtableSSTable_JP|MemtableSSTable]]を参照。)
+ したがってCassandraでは、解決方法が不明な問題に直面した分散システム設計者がよく行う方法をとっています。つまり解決できる問題に変換するために、さらなる制約を定義することです。CassandraではGCGraceSecondsという定数を定義し、各ノードにそれぞれのローカルのTombstoneの年齢を追跡させます。そして定数値を超える時間が経過するとコンパクション時にGC可能だと判断します([[MemtableSSTable_JP|MemtableSSTable]]を参照。)。ということはGCGraceSecondsよりも長い間ノードがダウンした場合、そのノードを故障したものとみなして[[Operations]]にある手順でノードを置き換えるべきです。デフォルトの設定はとても控えめで、10日間に設定してあります。ニーズに合ったAntiEntropyを設定すると、この値を短くすることができます。もちろんCassandraを1ノードで動かしている場合は0に設定することもできます。その場合、Tombstoneは最初のメジャーコンパクション時にGCされます。
  

Mime
View raw message