googleの裏側では、日々せっせと世界中のWebページの情報を取得して、
検索エンジンへの照会に即答できるためのインデックス生成処理が動いている。インデックス構造・分散ストレージ・分散コンピューティング・データセンタなど、
googleを支える種々の技術要素を、公表されている論文から読み解いて解説した本。
DBについては、
Oracleや
mySQLの管理可能なオーダーを超えたデータを保持する仕組みが
Bigtableであり、これが興味深い。
【Bigtable】
- 概要
- Bigtableとは、googleの大規模サービスのデータを格納するための分散DBMS。(最大容量は2,000,000,000GB/テーブル)
- クローラが収集したWebページを、検索エンジン用インデックス生成のために格納する等に利用
- GFS(Google File System)というファイルシステム上のファイルに対して、更新や削除をオンラインでは行わず、追記型の更新でまかなう
- 特徴
- テーブルやインデックスの再編成は、運用の中でデータが偏っていこうとも、自律的に安定した性能を維持できる仕組みであり、例えばパーティショニング・キーの選定如何には左右されない
- シーケンシャルリード・ライト、ランダムライトはクラスタのマシン数増で性能向上するが、(メモリキャッシュを利用できないような)ランダムリードは性能はマシン数比例で向上しない
- 実装
- 物理構成
- 論理構成
- テーブルは、行キーとコラムファミリーを事前定義
- 行は、任意の数のコラムキーを保有でき、コラムキーはコラムファミリーに属する
- 行キーとコラムキーに加えて、タイムスタンプを指定することで、セルが特定される(キー:={行キー＋コラムキー＋タイムスタンプ}、値:={構造データ}という考え方)
- 運用
- 1つのテーブルは、行キーに応じて複数のタブレットに分割格納される(1つのタブレットの容量は、100MB〜200MB程度)
- 1つのタブレットでは、GFS上の複数のSStableと、タブレットサーバ上のmemtableを組み合わせて最新データが保持・格納される
- レコードの更新・削除が行われた場合、SStableを直接Update，Deleteせず、更新・削除した旨をmemtableに記録
- 再編成
- memtableが容量増大すると、新しいSSTableを生成(マイナーコンパクション)
- SSTableの数が増えすぎると、SSTableを統合(メジャーコンパクション)
- SSTableを統合しても容量が偏る場合、タブレットを分割・統合
- タブレットが分割・統合されると、メタデータも更新される
