グーグルのクラウドを支えるテクノロジー > 第6回 大規模構造化データに最適化された分散キーバリューストアBigtable(パート2)

※この記事は読者によって投稿されたユーザー投稿です:
  • 編集部の見解や意向と異なる内容の場合があります
  • 編集部は内容について正確性を保証できません
  • 画像が表示されない場合、編集部では対応できません
  • 内容の追加・修正も編集部では対応できません

CTC教育サービスはコラム「 グーグルのクラウドを支えるテクノロジー > 第6回 大規模構造化データに最適化された分散キーバリューストアBigtable(パート2)」を公開しました。

はじめに
 前回に続いて、2006年に公開された論文「Bigtable: A Distributed Storage System for Structured Data」をもとに、分散キーバリューストア「Bigtable」の構造を解説します。前回、Bigtableを構成するサーバーの全体像を紹介した際に、次のような疑問点を指摘しました。

(1) クライアントは、アクセス対象の行を含むTablet、および、該当のTabletを担当するTabletサーバーをどのようにして発見するのか?
(2) マスターサーバーは、Tabletサーバーの障害をどのように検知して、Tabletの再割り当てを行うのか?
(3) Tabletの実体は、「memtable」と「SSTable」によってどのように構成されているのか?

 今回は、これらの点について解説を進めていきましょう。

Tabletサーバーの検索
 Bigtableで作成したテーブルに含まれる行は、Row Keyの文字列に対して辞書順にソートされており、1つのテーブルを複数のTabletに分割する際は、この順序が保持されます。つまり、1つのTabletは、一定範囲のRow Keyに対応する行を含みます。そして、1つのテーブルに含まれるTabletの位置情報は、Root tablet、および、METADATA tabletと呼ばれる、特別なTabletに記録されます。
 これは、図1のようなツリー型の階層構造になっており、Row Keyの範囲ごとに次のTablet(および、それを担当するTabletサーバー)が指定されており、このツリーをたどっていくことで、該当のRow Keyを含むTabletを検索することができます。また、Root tableを担当するTabletサーバーの情報は、分散ロックサービスを提供するChubbyに保存されています。クライアントは、ChubbyからRoot tableの情報を取得した後、自分自身でツリーをたどってTabletの検索を行います。

この続きは以下をご覧ください
http://www.school.ctc-g.co.jp/columns/nakai2/nakai206.html

この記事が役に立ったらシェア!
メルマガの登録はこちら Web担当者に役立つ情報をサクッとゲット!

人気記事トップ10(過去7日間)

今日の用語

UX
ユーザーの体験や経験を表す言葉。ある製品サービスを利用する前の期待値、実際に利用 ...→用語集へ

連載/特集コーナーから探す

インフォメーション

RSSフィード


Web担を応援して支えてくださっている企業さま [各サービス/製品の紹介はこちらから]