全くクラウド流行である*1。クラウドの技術的な課題を実感するには、クラウドを構成する技術を学ぶしかない。グーグルの技術は、一部発表されているが肝心の部分をうまく隠していてもどかしい。幸いにもオープンソースプロジェクトがいくつかあるので、それらを探ることが近道のように感じる。
そこで、グーグルのBigTableにあたるHyperTableのアーキテクチャ紹介の文章を読んだ。せっかくなので和訳を公開する。原文は以下。
http://code.google.com/p/hypertable/wiki/ArchitecturalOverview
イントロダクション
このドキュメントはHpyertableのアーキテクチャオーバービューを記す。Hpyertableは、Hadoop DFSのようなサードパーティの分散ファイルシステムの上で走るよう設計されている。しかしながら、Hpyertableをローカルファイルシステムの上で走らせることも可能である。君が最初に動作させる際にはまずローカルファイルシステムで行うことを勧める。
データモデル
Hpyertableのデータモデルは、一つのプライマリキーでのみ検索できる多次元テーブルからなる。テーブルの最初の次元は row keyである。 Row keyはプライマリキーであり、物理的に格納されたテーブルデータ上の順序を決める。2番目の次元は column familyである。この次元は通常のデータベースの列といくぶん似ている。3番目の次元はcolumn qualifierである。各column familyの中で理論的には無限の数のqualified instanceを持ちうる。例えば、ＵＲＬタギングサービスを考えよう。Column familiesの中身を urlとtagで定義できる。Tag column familyの中に無限のqualified instance例えば tag:sicience, tag:teacher, tag:good, などを持ちうる。4番目の次元は時間軸である。この次元はタイムスタンプからなる。概念的にはHpyertableのテーブルは3次元のエクセルシートで、各々のセルにタイムスタンプが付いているとみなすことが出来る。
原文には図あり。
この多次元テーブルはkey/valueペアのフラットリストとして表現される。Keyは4つの次元のキーのコンカチネーションである(row, column family, column qualifier, and timestamp) 以下の図が、フラットリストの例である。タイムスタンプはビッグエンディアンで記述されているので、古いセルほど前に並んでいる。
原文には図あり
Physical Data Layout
全てのテーブルデータはHpyertableの下で走っている分散ファイルシステムに格納される。主にHadoop DFSを使っているがどんなファイルシステムの上でも動作可能である。分散ファイルシステムとのインタフェースは抽象化されており、別のファイルシステムで動作させるためのコネクターを記述するのも簡単だ。
Key/valueペアデータはCellStoresと呼ばれるファイルに格納されている。もっとも抽象化されたレベルでは、CellStoreはKey/Valueペアのリストを含む。物理的にはKey/Valueペアは一連のブロック（圧縮され６５ＫＢとなっている）に格納されている。最後のブロックはLast keyのリストとブロックオフセットを格納する。ファイル内の各ブロックには、ブロックのオフセットと一緒にlast keyを含むインデックスが存在する。このインデックスは、CellStoreファイルがシステムにロードされたとき、メモリにロードされる。以下の図はCellStoreのフォーマットを示す。
原文に図あり
通常のデータベースは列指向あるいは行指向（これらは物理的なデータ配置に依存する）で考えられる。行指向データベースの場合全てのデータは与えられた行に対して連続的にディスに格納される。Hyptertableのアクセスグループはgroup columnsにともに格納する方法を与える。アクセスグループ内の全ての行は、同じCellSotreに物理的に一緒に格納される。これはハイブリッドアプローチである。行指向データベースは列の全てを一つのアクセスグループにすることでシミュレートできる。
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
残りはまた後で
