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

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

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

###
はじめに
 今回から2回に分けて、2006年に公開された論文「Bigtable: A Distributed Storage System for Structured Data」をもとに、分散キーバリューストア「Bigtable」の構造を解説します。ご存知の方も多いかも知れませんが、オープンソースのNoSQLデータベースであるHBaseは、Bigtableをモデルに設計されており、ユーザーから見た利用方法には高い類似性があります。(実際、Google Cloud Platformで提供されるCloud Bigtableでは、HBase互換APIが提供されています。)
 それでは、内部の実装については、どのような類似性、あるいは、違いがあるのでしょうか? HBaseのアーキテクチャーについては、さまざまな解説記事が公開されていますので、そちらを参照していただくことにして、ここでは、Bigtableの内部構造をじっくりと紹介したいと思います。

Bigtableのデータモデル
 はじめに、Bigtableのデータモデル、すなわち、ユーザーから見た際のデータの格納・検索方法について簡単に説明します。Bigtableでは、1つのテーブルに対して、行単位でデータの読み書きを行います。1つの行の中には、複数の「カラムファミリー」があり、それぞれのカラムファミリーの中には、複数の「カラム」があります。したがって、行を特定する「Row Key」に加えて、カラムファミリー名、および、カラム名を指定すると、1つのデータにたどり着きます。Row Key、カラムファミリー名、カラム名、そして、保存データはすべて文字列として取り扱われます。数値やバイナリデータを保存する場合は、クライアント側で事前に文字列にエンコードしておきます。
 図1は、論文で紹介されているテーブル構造の例です。これは、検索エンジンのクローラーが、インターネット上の各種Webサイトから取得したHTMLファイルをBigtableに保存する例です。Row Keyは、WebサイトのURLで、カラムファミリー「contents」には、HTMLファイルが保存されています。一般には、1つのカラムファミリー内に複数のカラムが用意されますが、ここでは、無名のカラムを1つだけ使用しています。また、カラムファミリー「anchor」には、このURLに対してリンクを貼っている他のWebサイトの情報が保存されます。カラム名は、リンクを貼っている他のWebサイトのURLで、カラム内のデータは、リンク部分の文字列です。

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

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

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

今日の用語

NDA
Non-Disclosure Agreementの略。一般には「秘密保持契約」と ...→用語集へ

インフォメーション

RSSフィード


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