[Cassandra Wiki] Update of "HintedHandoff_JP" by MakiWatanabe

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

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

The "HintedHandoff_JP" page has been changed by MakiWatanabe.
http://wiki.apache.org/cassandra/HintedHandoff_JP?action=diff&rev1=6&rev2=7

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

  ## page was copied from HintedHandoff
- Hinted handoff(ヒントハンドオフ)とは、あるノードが書き込み失敗の通知を受けたときに、
- Cassandraが"失敗したノードが復旧したら書き込んだ内容をフォワードしてください"というヒントと共に別のノードに書き込む機能の事をいいます．
  
+ If a write is made and a replica node for the key is down, Cassandra will write a hint to a live replica node indicating that the write needs to be replayed to the unavailable node. If no replica nodes are alive for this key and ConsistencyLevel.ANY was specified, the coordinating node will write the hint locally. Cassandra uses hinted handoff as a way to (1) reduce the time required for a temporarily failed node to become consistent again with live ones and (2) provide extreme write availability when consistency is not required.
- CassandraはHinted handoffを、
-   1. 一時的にダウンしているノードの復旧までの時間を短縮する
-   1. 一貫性が必須でないところでの可用性を極限まで向上する
  
- ことを目的として使っています．
+ Writeの際にそのキーを担当するレプリカノードの一つが停止していた場合、Cassandraはヒント情報を稼働しているレプリカノードに保存します。ヒント情報は障害中のノードに対して当該の書き込みを再実行する必要があることを示します。そのキーに対して稼働中のレプリカノードが一つも存在せず、かつConsitencyLevel.ANYが指定されている場合、コーディネーティングノードはヒントをローカルに保存します。この機構をHinted Handoffと呼びます。
+ CassandraはHinted Handoffを次の目的で使用しています。
  
+  1．一時的障害により他のレプリカとの一貫性を失ったノードが稼働中のレプリカと再同期するのに必要な時間を短縮する
+  2．一貫性の要求が低いシステムにおいて、極めて高い書き込み可用性を提供する
  
+ A hinted write does NOT count towards ConsistencyLevel requirements of ONE, QUORUM, or ALL. Take the simple example of a cluster of two nodes, A and B, and a replication factor of 1 (each key is stored on one node). Suppose node A is down while we write key K to it with ConsistencyLevel.ONE. Then we must fail the write: recall from the API page that "if W + R >ReplicationFactor, where W is the number of nodes to block for on write, and R the number to block for on reads, you will have strongly consistent behavior; that is, readers will always see the most recent write."
  
- ヒントつき書き込みは、!ConsistencyLevelがONE、QUORUM、ALLのときには有効ではありません．
+ ヒントそのものはConsistencyLevel ONE、QUORUM、ALL条件判定の際にカウントされません。簡単な例として、2つのノード、AとBから構成されるクラスタを考えます。レプリケーションファクタは1とします（それぞれのキーは一つのノードのみに格納されます）。ノードAが停止している間に、ノードAに格納されるべきキーKをConsistencyLevel.ONEで書き込むとします。この場合、書き込みは失敗します。APIページで次のように書かれていたことを思い出して下さい。
+ ”Wを書き込み時にブロックするノード数、Rを読み出し時にブロックするノード数とすると、W＋R＞ReplicationFactorが満たされていれば強い一貫性を保証できます。言い換えると、Read操作は常に最新のWriteデータを返します。”
  
- 2つのCassandraノード(A, B)を持ち、レプリケーション要素数が1(各キーが1つのノードにしか保存されない)のシンプルな例を考えてみましょう.
+ Thus if we write a hint to B and call the write good because it is written "somewhere," there is no way to read the data at any ConsistencyLevel until A comes back up and B forwards the data to him. Historically, only the lowest ConsistencyLevel of ZERO would accept writes in this situation; for 0.6, we added ConsistencyLevel.ANY, meaning, "wait for a write to succeed anywhere, even a hinted write that isn't immediately readable."
  
- ノードAがキーK(!ConsistencyLevel.ONE)を書き込みの途中にダウンしたとします．
+ もしヒントをノードBに書いたことをもってそのWrite操作を完了と見なすと、どのようなConsistencyLevelを使用してもそのデータを読み出す方法はありません：ノードAが復帰し、ノードBがデータをAに転送するまでは。従来は最も低いConsistencyLevel、ZEROのみがこのようなWriteを許容できました。Cassandra 0.6ではConsistencyLevel.ANYが追加されています。ConsistencyLevel.ANYのWriteは次のようなことを意味します。
+ 　”例え直ちに読み出せないヒント情報であっても、とにかく「どこかに」書き込めたらWriteを完了する”
  
- この書き込みは、Wは書き込みのためにブロックしているノード数、Rは読み込みのためにブロックしているノード数としたとき、
- `W` + `R` > `ReplicationFactor`を満たさないため、失敗になります([[API]]より抜粋)．
- 
- それゆえ、この場合Bにヒントを書き込みを行うのは成功するはずです．
- 
- 何故かというと、Aが復旧するまで如何なる!ConsistencyLevelでもBがデータをフォワードする事はないからです．
- 
- 昔は!ConsistencyLevelがZEROの場合のみこのような書き込みを許容していましたが、
- 
- 0.6ではこのようなケースも考慮して新しく!ConsistencyLevel.ANYを作りました．
- 
- !ConsistencyLevel.ANYの意味は、"ヒント付き書き込みがすぐに読み込み可能にならなくても、どこかで成功した書き込みを待ちますよ"、ということになります.
-