Introducing Gizzard, a framework for creating distributed datastores (1)
TwitterエンジニアブログでGizzardというミドルウェアの話が紹介されていて非常に興味深かったのでメモ取りながら読んでいます。以下メモ。
sharding入門
現代のWebサイトは一台の計算機では効率的に情報を保存できないような量の情報に高速にアクセスする必要がある。
この問題に対する良い方法は情報を"shard"することである。つまり、情報を複数のコンピュータに分けて保存する。
シャーディング戦略はパーティショニングとレプリケーションの二つの技術を使う。
パーティショニングによってデータは細かい単位に分けて複数の計算機に保存する。それぞれの
塊はそれぞれのコンピュータで効率的に保管して操作やクエリできるように十分細かくしておく。
レプリケーションによって複数のデータのコピーをいくつかのマシンに跨って保存する。
それぞれのコピーは多くのクエリに答えられるようにそれぞれのマシンで稼働する。
レプリケーションはどこかのデータのコピーが壊れたり汚れたりしても他のコピーが
同じタスクをうまくこなせるようにも働く。
問題はシャーディングが難しいことである。ある種のデータを賢くパーティショニングするには
よく考える必要がある。さらに難しいのは信頼できないコミュニケーションや
予測できないコンピュータの障害に関わらずデータの一貫性を保つことである。
最近ｎオープンソースのDBはこの問題を解く助けになる。残念ながら
これを書いている時点では、ほとんどのオープンソースのプロジェクトは未発達で
現実の問題を解くには限られている。これらの新しいデータベースは将来の見込みは大きいが
現在はもっと経験的なカスタマイズが必要である。
シャーディングフレームワークとは
Twitterはいくつか分散データストアをカスタマイズした。多くは一般的によく知られているもので
我々で拡張することができ、簡単にメンテナンスできて再利用可能である。我々は
ScalaフレームワークのGizzardを拡張した。耐障害性を持った分散データベースを簡単に作る
ことができる。
Gizzardはあるクラスの問題をとくための標準的なテンプレートを提供するフレームワーク
である。このテンプレートは万人に完璧ではないがデータストレージ問題に関しては広く
活用できる。高いレベルでは、Gizzardは任意のバックエンドのデータストア(SQL Database,
Lucene,...)によるパーティショニングをマネージするネットワークサービスとも言える。
パーティショニングルールはフォワーディングテーブルに置かれ、それはパーティションする
キーのレンジをマッピングする。それぞれのパーティションは宣言されたレプリケーションツリーを
通じて自分のレプリケーションを管理する。Gizzardは「マイグレーション」(たとえばクラスタへの
弾力的なマシンの追加など)をサポートし、優雅に障害を処理する。システムは
すべての書き込み操作が操作が失敗して(例えばネットワーク障害などで)後で
やり直せば冪等であるような要求の元、Eventually consistetになる。
Gizzardの非常にシンプルな例がRowzという分散key-valueストアである。Gizzardを素早く
動かしてみたいならRowzをクローンしてカスタマイズするといいだろう。
しかし、最初にGizzardがどのように動いているか、詳細を見てみる。
Gizzardはミドルうウェアのようにネットワーキングサービスを操作する。それは
クライアント(標準的にはPHPやRoRのようなWebのフロントエンド)と多くのパーティションニングされ
レプリケーションされたデータの間に入る。中間に立ち、すべてのクエリと操作の流れが
Gizzardを通る。Gizzardインスタンスはステートレスでスループットを持続させることとTCP接続の
期限を管理する事だけが必要である、なぜならこれはJVM上で動作し極めて効率的だからだ。
TwitterのGizzardアプリケーション(FlockDB 分散グラフDB)はコモディティマシンを使って
10000のクエリを一秒間でさばくことができる。あなたのがたの受ける利益はもっと違ったものになるだろう。
Gizzardはどんなデータストレージでもバックエンドに持ってくることができる。
Gizzardはネットワークで扱えるデータストレージサービスをどんなものでもレプリケーションするように
設計されている。これはレリーショナルデータベースでもいいし、Lucene,Redis,何でも想像するもの
すべてよい。一般的なルールとしてGizzardは書き込み操作がすべての冪等であることを要求する、この
ことによりバックエンドのデータストアを使うためにいくつかの制約が設けられるだろう。特に
Gizzardは操作の順序を保証しない。それゆえに書き込み操作の順序がシステムの一貫性に影響を
与えないような設計が必須である。
続く（多分）
TwitterエンジニアブログでGizzardというミドルウェアの話が紹介されていて非常に興味深かったのでメモ取りながら読んでいます。以下メモ。
sharding入門
現代のWebサイトは一台の計算機では効率的に情報を保存できないような量の情報に高速にアクセスする必要がある。
この問題に対する良い方法は情報を"shard"することである。つまり、情報を複数のコンピュータに分けて保存する。
シャーディング戦略はパーティショニングとレプリケーションの二つの技術を使う。
パーティショニングによってデータは細かい単位に分けて複数の計算機に保存する。それぞれの
塊はそれぞれのコンピュータで効率的に保管して操作やクエリできるように十分細かくしておく。
レプリケーションによって複数のデータのコピーをいくつかのマシンに跨って保存する。
それぞれのコピーは多くのクエリに答えられるようにそれぞれのマシンで稼働する。
レプリケーションはどこかのデータのコピーが壊れたり汚れたりしても他のコピーが
同じタスクをうまくこなせるようにも働く。
問題はシャーディングが難しいことである。ある種のデータを賢くパーティショニングするには
よく考える必要がある。さらに難しいのは信頼できないコミュニケーションや
予測できないコンピュータの障害に関わらずデータの一貫性を保つことである。
最近ｎオープンソースのDBはこの問題を解く助けになる。残念ながら
これを書いている時点では、ほとんどのオープンソースのプロジェクトは未発達で
現実の問題を解くには限られている。これらの新しいデータベースは将来の見込みは大きいが
現在はもっと経験的なカスタマイズが必要である。
シャーディングフレームワークとは
Twitterはいくつか分散データストアをカスタマイズした。多くは一般的によく知られているもので
我々で拡張することができ、簡単にメンテナンスできて再利用可能である。我々は
ScalaフレームワークのGizzardを拡張した。耐障害性を持った分散データベースを簡単に作る
ことができる。
Gizzardはあるクラスの問題をとくための標準的なテンプレートを提供するフレームワーク
である。このテンプレートは万人に完璧ではないがデータストレージ問題に関しては広く
活用できる。高いレベルでは、Gizzardは任意のバックエンドのデータストア(SQL Database,
Lucene,...)によるパーティショニングをマネージするネットワークサービスとも言える。
パーティショニングルールはフォワーディングテーブルに置かれ、それはパーティションする
キーのレンジをマッピングする。それぞれのパーティションは宣言されたレプリケーションツリーを
通じて自分のレプリケーションを管理する。Gizzardは「マイグレーション」(たとえばクラスタへの
弾力的なマシンの追加など)をサポートし、優雅に障害を処理する。システムは
すべての書き込み操作が操作が失敗して(例えばネットワーク障害などで)後で
やり直せば冪等であるような要求の元、Eventually consistetになる。
Gizzardの非常にシンプルな例がRowzという分散key-valueストアである。Gizzardを素早く
動かしてみたいならRowzをクローンしてカスタマイズするといいだろう。
しかし、最初にGizzardがどのように動いているか、詳細を見てみる。
Gizzardはミドルうウェアのようにネットワーキングサービスを操作する。それは
クライアント(標準的にはPHPやRoRのようなWebのフロントエンド)と多くのパーティションニングされ
レプリケーションされたデータの間に入る。中間に立ち、すべてのクエリと操作の流れが
Gizzardを通る。Gizzardインスタンスはステートレスでスループットを持続させることとTCP接続の
期限を管理する事だけが必要である、なぜならこれはJVM上で動作し極めて効率的だからだ。
TwitterのGizzardアプリケーション(FlockDB 分散グラフDB)はコモディティマシンを使って
10000のクエリを一秒間でさばくことができる。あなたのがたの受ける利益はもっと違ったものになるだろう。
Gizzardはどんなデータストレージでもバックエンドに持ってくることができる。
Gizzardはネットワークで扱えるデータストレージサービスをどんなものでもレプリケーションするように
設計されている。これはレリーショナルデータベースでもいいし、Lucene,Redis,何でも想像するもの
すべてよい。一般的なルールとしてGizzardは書き込み操作がすべての冪等であることを要求する、この
ことによりバックエンドのデータストアを使うためにいくつかの制約が設けられるだろう。特に
Gizzardは操作の順序を保証しない。それゆえに書き込み操作の順序がシステムの一貫性に影響を
与えないような設計が必須である。
続く（多分）