Gizzardというミドルウェアの話が紹介をメモ取りながら読んでいます。元記事は以下、
Introducing Gizzard, a framework for creating distributed datastores.
前半と中盤のメモ：
Introducing Gizzard メモ(1)
Introducing Gizzard メモ(2)
今回で最後まで読みました。
Gizard はフォールトトレラント
障害許容性は分散システムの最大の関心事である。なぜならそのような系では多くの計算機と
関係しているので、どんな時でもある確率で一つ（または多く）の機能不全が
起こっているからである。Gizzardは単一障害点をどのような形でも避けている。
もし、パーティション中のあるレプリカがクラッシュしたら、重み付け関数にしたがって、
Gizzardは残りの健康なレプリカにリクエストを案内する。もしパーティション中のすべての
レプリカが動作しない場合、Gizzardはそのshardに対する読みリクエストを実行することができないが、
ほかのshardには影響を及ぼさない。動作しないshardへの書き込みは再び書き込み可能になるまで
バッファされる。
実はいくつのレプリカが応答しなくても、Gizzardは応答するレプリカに可能な限り書き込みかつ
応答しないレプリカへの書き込みをバッファリングし、応答しないshardが生き返ったら後で
書き込む。標準的な戦略としてはすべての書き込みを二重化し、トランザクションの記録をとる。
書き込みはshard中のレプリカに対し非同期に（しかし可能な限り低い遅延で）処理される。
もしshardが応答しない場合は、書き込み操作はエラーキューに入れ、後で再実行する。
Eventual Consistency を実現するために、「後でリトライ」する戦略はあなたに書き込み
操作を冪等かつ可換であることを要求する。これは「後でリトライ」戦略は操作を順序に
関係なく適用する（一例として、失敗したジョブのリトライより先に新しいジョブを適用したりする）。
多くの場合はこの要求は難しくはない。GizzardのデモアプリRowzでは可換で冪等な書き込みが
実践されている。
素早いマイグレーション
時にshardからある計算機から別の計算機にデータをコピーしたり移動したりすることは手軽である。
あなたは負荷分散のために多くまたは少ないマシンへそれを行ったり、ハードの故障をとり扱うために
行うだろう。マイグレーションがどのように働くかのある側面を説明するのは興味深い、
ちょうど下に示すようなより不明瞭な論理shardタイプにおいて。データストアAからデータストアA'
いマイグレーションする時に、複製shardは両者の間に置かれ、さらにデータストアA'の前には
WriteOnly shardが配置される。そして古いshardから新しいshardへデータがコピーされる。
WriteOnly shardは新しいshardが立ち上がるのを守る、データはそこからは読まれない(なぜなら
そこには大きな全体の一部の絵しかないから)。
書き込みが順序関係なく起こるため(新しい書き込みが古いものより先に行われたり、ある
書き込み動作は二回行われたりする。)、すべての書き込みはデータの一貫性を保つために冪等である
必要がある。
以上。まあ、Rowzみてみろと、いうことでしょうか。
Introducing Gizzard, a framework for creating distributed datastores.
前半と中盤のメモ：
Introducing Gizzard メモ(1)
Introducing Gizzard メモ(2)
今回で最後まで読みました。
Gizard はフォールトトレラント
障害許容性は分散システムの最大の関心事である。なぜならそのような系では多くの計算機と
関係しているので、どんな時でもある確率で一つ（または多く）の機能不全が
起こっているからである。Gizzardは単一障害点をどのような形でも避けている。
もし、パーティション中のあるレプリカがクラッシュしたら、重み付け関数にしたがって、
Gizzardは残りの健康なレプリカにリクエストを案内する。もしパーティション中のすべての
レプリカが動作しない場合、Gizzardはそのshardに対する読みリクエストを実行することができないが、
ほかのshardには影響を及ぼさない。動作しないshardへの書き込みは再び書き込み可能になるまで
バッファされる。
実はいくつのレプリカが応答しなくても、Gizzardは応答するレプリカに可能な限り書き込みかつ
応答しないレプリカへの書き込みをバッファリングし、応答しないshardが生き返ったら後で
書き込む。標準的な戦略としてはすべての書き込みを二重化し、トランザクションの記録をとる。
書き込みはshard中のレプリカに対し非同期に（しかし可能な限り低い遅延で）処理される。
もしshardが応答しない場合は、書き込み操作はエラーキューに入れ、後で再実行する。
Eventual Consistency を実現するために、「後でリトライ」する戦略はあなたに書き込み
操作を冪等かつ可換であることを要求する。これは「後でリトライ」戦略は操作を順序に
関係なく適用する（一例として、失敗したジョブのリトライより先に新しいジョブを適用したりする）。
多くの場合はこの要求は難しくはない。GizzardのデモアプリRowzでは可換で冪等な書き込みが
実践されている。
素早いマイグレーション
時にshardからある計算機から別の計算機にデータをコピーしたり移動したりすることは手軽である。
あなたは負荷分散のために多くまたは少ないマシンへそれを行ったり、ハードの故障をとり扱うために
行うだろう。マイグレーションがどのように働くかのある側面を説明するのは興味深い、
ちょうど下に示すようなより不明瞭な論理shardタイプにおいて。データストアAからデータストアA'
いマイグレーションする時に、複製shardは両者の間に置かれ、さらにデータストアA'の前には
WriteOnly shardが配置される。そして古いshardから新しいshardへデータがコピーされる。
WriteOnly shardは新しいshardが立ち上がるのを守る、データはそこからは読まれない(なぜなら
そこには大きな全体の一部の絵しかないから)。
書き込みが順序関係なく起こるため(新しい書き込みが古いものより先に行われたり、ある
書き込み動作は二回行われたりする。)、すべての書き込みはデータの一貫性を保つために冪等である
必要がある。
以上。まあ、Rowzみてみろと、いうことでしょうか。