それは Oracle ですか、MySQL ですか、それとも独自に構築したものですか?
ベストアンサー1
ビッグテーブル
Bigtable は、構造化データを管理するための分散ストレージ システム (Google によって構築) であり、数千の汎用サーバーにわたるペタバイト単位のデータという非常に大きなサイズに拡張できるように設計されています。
Google の多くのプロジェクトでは、ウェブ インデックス、Google Earth、Google Finance など、Bigtable にデータを保存しています。これらのアプリケーションは、データ サイズ (URL からウェブ ページ、衛星画像まで) とレイテンシ要件 (バックエンドの一括処理からリアルタイムのデータ提供まで) の両方の点で、Bigtable に非常に異なる要求を課します。
こうした多様な要求にもかかわらず、Bigtable はこれらすべての Google 製品に対して柔軟で高性能なソリューションを提供することに成功しました。
いくつかの機能
- 高速かつ極めて大規模なDBMS
- 行指向データベースと列指向データベースの両方の特性を共有する、疎な分散型多次元ソート マップ。
- ペタバイト規模まで拡張できるように設計
- 数百、数千のマシンで動作する
- システムにマシンを追加し、再構成することなくそれらのリソースを自動的に利用し始めるのは簡単です。
- 各テーブルには複数のディメンションがあります（そのうちの 1 つは時間フィールドで、バージョン管理が可能です）
- テーブルは複数のタブレットに分割され、GFS (Google ファイル システム) 用に最適化されます。テーブルのセグメントは、タブレットのサイズが約 200 MB になるように選択された行に沿って分割されます。
建築
BigTable はリレーショナル データベースではありません。結合も、SQL のような高度なクエリもサポートしていません。各テーブルは多次元のスパース マップです。テーブルは行と列で構成され、各セルにはタイム スタンプがあります。タイム スタンプが異なる複数のバージョンのセルが存在する場合があります。タイム スタンプにより、「この Web ページの n バージョンを選択する」や「特定の日付/時刻より古いセルを削除する」などの操作が可能になります。
巨大なテーブルを管理するために、Bigtable は行の境界でテーブルを分割し、タブレットとして保存します。タブレットは約 200 MB で、各マシンは約 100 個のタブレットを保存します。この設定により、1 つのテーブルのタブレットを多数のサーバーに分散できます。また、きめ細かな負荷分散も可能になります。1 つのテーブルが多数のクエリを受信している場合は、他のタブレットを解放するか、ビジー状態のテーブルをそれほどビジー状態ではない別のマシンに移動できます。また、マシンがダウンした場合、タブレットを他の多数のサーバーに分散して、特定のマシンへのパフォーマンスの影響を最小限に抑えることができます。
テーブルは不変の SSTable とログの末尾 (マシンごとに 1 つのログ) として保存されます。マシンのシステム メモリが不足すると、Google 独自の圧縮技術 (BMDiff および Zippy) を使用して一部のタブレットが圧縮されます。マイナーな圧縮では少数のタブレットのみが対象となりますが、メジャーな圧縮ではテーブル システム全体が対象となり、ハード ディスク領域が回復されます。
Bigtable タブレットの場所はセルに保存されます。特定のタブレットの検索は 3 層システムによって処理されます。クライアントは META0 テーブル (1 つだけ) へのポイントを取得します。META0 テーブルは、検索対象のタブレットの場所を含む多数の META1 タブレットを追跡します。META0 と META1 はどちらも、システムのボトルネックを最小限に抑えるために、プリフェッチとキャッシュを多用します。
実装
BigTable は、ログ ファイルとデータ ファイルのバックアップ ストアとして使用されるGoogle ファイル システム(GFS)上に構築されています。GFS は、テーブル データを永続化するために使用される Google 独自のファイル形式である SSTables に信頼性の高いストレージを提供します。
BigTable が頻繁に使用するもう 1 つのサービスは、可用性と信頼性に優れた分散ロック サービスであるChubbyです。Chubby を使用すると、クライアントはロックを取得して、そのロックを何らかのメタデータに関連付けることができます。このメタデータは、Chubby にキープ アライブ メッセージを送信することで更新できます。ロックは、ファイル システムのような階層的な命名構造で保存されます。
Bigtable システムには、主に3 つのサーバー タイプがあります。
- マスター サーバー: タブレットをタブレット サーバーに割り当て、タブレットの場所を追跡し、必要に応じてタスクを再配布します。
- タブレット サーバー: タブレットの読み取り/書き込み要求を処理し、サイズ制限 (通常 100 MB - 200 MB) を超えた場合にタブレットを分割します。タブレット サーバーに障害が発生した場合、100 台のタブレット サーバーがそれぞれ 1 台の新しいタブレットを取得し、システムが回復します。
- ロック サーバー: Chubby 分散ロック サービスのインスタンス。BigTable 内の多くのアクションでは、書き込み用にタブレットを開く、一度にアクティブなマスターが 1 つだけであることの確認、アクセス制御のチェックなど、ロックの取得が必要です。
Google の研究論文からの例:
Web ページを保存するサンプル テーブルの一部です。行名は逆 URLです。コンテンツ列ファミリにはページ コンテンツが含まれ、アンカー列ファミリにはページを参照するアンカーのテキストが含まれます。CNN のホームページは Sports Illustrated と MY-look の両方のホームページから参照されるため、行には および という名前の列が含まれます
anchor:cnnsi.com。anchor:my.look.ca各アンカー セルには1 つのバージョンがあり、コンテンツ列には、タイムスタンプ、、および の3 つのバージョンがあります。t3t5t6
API
BigTable の一般的な操作は、テーブルと列ファミリの作成と削除、データの書き込み、行からの列の削除です。BigTable は、アプリケーション開発者に API でこの機能を提供します。トランザクションは行レベルでサポートされていますが、複数の行キーにまたがってはサポートされていません。
こちらは研究論文のPDFへのリンク。
そしてここにはワシントン大学でグーグルのジェフ・ディーン氏が講義するビデオGoogle のバックエンドで使用されている Bigtable コンテンツ ストレージ システムについて説明します。