Introducing Gizzard, a framework for creating distributed datastores.
TwitterエンジニアブログでGizzardというミドルウェアの話が紹介されていて非常に興味深かったのでメモ取りながら読んでいます。続きです。GizzardはConsistent Hashingではないのですね。
Gizzardはフォワーディングテーブルを通して、パーティショニング処理する。
GIzzardはデータの範囲を各々のシャードにマッピングすることによって
パーティショニングする(つまり排他的な範囲で複数のホストに分割される)。
このマッピングは下記のテーブルのように、数値のレンジの下限と所属する
シャードの情報がフォワーディングテーブルに保管される。
正確にはあなた方はGizzardに次のようなカスタムハッシング関数を供給する：
データにキーを与え（このキーはアプリケーションに特別なキーであるべき）、
フォワーディングテーブル中のある範囲にいくつキーが属すのか決める。
この関数は必要に応じて自分でデータの所在やバランスに最適化するよう
プログラミングできる。
このようなテーブル形式のアプローチは様々の他のデータストアで使われている
いわゆる「コンシステントハッシング」とは異なる。この形式は一様でない
サイズのパーティションを許すため、非常に人気のあるデータのセグメントである
ホットスポットを簡単に管理することができる。実はGizzardはコンシステントハッシング
に似せてフォワーディング戦略を完全にカスタマイズすることもできるが、
これは推奨しないアプローチである。
Gizzardはレプリケーションツリーを通じてレプリケーションを取り扱う
フォワーディングテーブルから参照されるShardは物理Shardでも論理Shard
でも構わない。物理ShardはバックエンドにSQL Databaseのような
個別のデータストレージを参照している。対照的に論理shardはただの
別のshardのツリーであり、それぞれのツリー中のブランチはそれぞれ
バックエンドがデータストレージになっているノードの論理的なデータ変換と
なっている。これらのブランチにおける論理変換は普通、どのように読み・書き
の操作がブランチの子要素に伝わるかを規定する。例えばここに2階層の
レプリケーションツリーがあったとする。これが(フォワーディングテーブルから参照される)
「ひとつの」パーティションを表していることに注意。
図中の"Replicate"は単純な戦略でブランチは書き込みはすべての子要素に繰り返し、
読み込みは子要素の健康状態や重み付け関数によってバランスさせる。特定の
データストレージの要求により、自由にカスタムブランチや論理shardを作る
ことができる、例えば原始的なトランザクション/調停やクオーラム戦略を追加
することができる。しかしGizzardは多くの効果を得る少ない標準的な戦略のみを
採用している、それはWrite-Only, Read-Only, そしてBloacked(書き込みも読み込み
も許さない?)である。もっと無名なshardタイプの効用はMigrationセクションで
議論する。
レプリケーショントポロジーの厳密な性質はパーティションによって様々になる。
つまり高いレプリケーションレベルを「熱い」パーティションに、低いレプリケーション
レベルを「冷えた」ものにすることが出来る。これはシステムを高度に設定可能にする。
例えばバックエンドミラーをプライマリ、二次、三次、その他と定義することができる。
他にはより良い耐障害性のために(高度に複雑になるが)マシンにわたって「ストライプ」
パーティションを作りそれぞれがミラーにはなっていないようなものを作ることもできる。
・・・どんどん訳が酷くなってきたが・・・続く(たぶん)
TwitterエンジニアブログでGizzardというミドルウェアの話が紹介されていて非常に興味深かったのでメモ取りながら読んでいます。続きです。GizzardはConsistent Hashingではないのですね。
Gizzardはフォワーディングテーブルを通して、パーティショニング処理する。
GIzzardはデータの範囲を各々のシャードにマッピングすることによって
パーティショニングする(つまり排他的な範囲で複数のホストに分割される)。
このマッピングは下記のテーブルのように、数値のレンジの下限と所属する
シャードの情報がフォワーディングテーブルに保管される。
正確にはあなた方はGizzardに次のようなカスタムハッシング関数を供給する：
データにキーを与え（このキーはアプリケーションに特別なキーであるべき）、
フォワーディングテーブル中のある範囲にいくつキーが属すのか決める。
この関数は必要に応じて自分でデータの所在やバランスに最適化するよう
プログラミングできる。
このようなテーブル形式のアプローチは様々の他のデータストアで使われている
いわゆる「コンシステントハッシング」とは異なる。この形式は一様でない
サイズのパーティションを許すため、非常に人気のあるデータのセグメントである
ホットスポットを簡単に管理することができる。実はGizzardはコンシステントハッシング
に似せてフォワーディング戦略を完全にカスタマイズすることもできるが、
これは推奨しないアプローチである。
Gizzardはレプリケーションツリーを通じてレプリケーションを取り扱う
フォワーディングテーブルから参照されるShardは物理Shardでも論理Shard
でも構わない。物理ShardはバックエンドにSQL Databaseのような
個別のデータストレージを参照している。対照的に論理shardはただの
別のshardのツリーであり、それぞれのツリー中のブランチはそれぞれ
バックエンドがデータストレージになっているノードの論理的なデータ変換と
なっている。これらのブランチにおける論理変換は普通、どのように読み・書き
の操作がブランチの子要素に伝わるかを規定する。例えばここに2階層の
レプリケーションツリーがあったとする。これが(フォワーディングテーブルから参照される)
「ひとつの」パーティションを表していることに注意。
図中の"Replicate"は単純な戦略でブランチは書き込みはすべての子要素に繰り返し、
読み込みは子要素の健康状態や重み付け関数によってバランスさせる。特定の
データストレージの要求により、自由にカスタムブランチや論理shardを作る
ことができる、例えば原始的なトランザクション/調停やクオーラム戦略を追加
することができる。しかしGizzardは多くの効果を得る少ない標準的な戦略のみを
採用している、それはWrite-Only, Read-Only, そしてBloacked(書き込みも読み込み
も許さない?)である。もっと無名なshardタイプの効用はMigrationセクションで
議論する。
レプリケーショントポロジーの厳密な性質はパーティションによって様々になる。
つまり高いレプリケーションレベルを「熱い」パーティションに、低いレプリケーション
レベルを「冷えた」ものにすることが出来る。これはシステムを高度に設定可能にする。
例えばバックエンドミラーをプライマリ、二次、三次、その他と定義することができる。
他にはより良い耐障害性のために(高度に複雑になるが)マシンにわたって「ストライプ」
パーティションを作りそれぞれがミラーにはなっていないようなものを作ることもできる。
・・・どんどん訳が酷くなってきたが・・・続く(たぶん)