OracleなのかMySQLなのか、それとも彼らが自分たちで構築したものなのか。
Bigtableは、非常に大きなサイズ、つまり何千ものコモディティサーバーにわたるペタバイト規模のデータに拡張するように設計された、構造化データを管理するための(Googleによって構築された)分散ストレージシステムです。
Googleの多くのプロジェクトでは、Webインデックス、Google Earth、Google FinanceなどのデータをBigtableに格納しています。これらのアプリケーションは、データサイズ(URLからWebページ、衛星画像まで)と待ち時間要件(バックエンドの一括処理からリアルタイムのデータ提供まで)の両方に関して、Bigtableに非常に異なる要求を課します。
これらの多様な要求にもかかわらず、BigtableはこれらのGoogle製品すべてに柔軟で高性能なソリューションを提供することに成功しました。
いくつかの機能
アーキテクチャ
BigTableはリレーショナルデータベースではありません。結合もサポートされておらず、SQLのような豊富なクエリもサポートされていません。各テーブルは多次元スパースマップです。テーブルは行と列で構成され、各セルにはタイムスタンプがあります。タイムスタンプが異なる複数のバージョンのセルが存在する可能性があります。タイムスタンプにより、「このWebページのバージョンを選択する」や「特定の日付/時刻より古いセルを削除する」などの操作が可能になります。
巨大なテーブルを管理するために、Bigtableはテーブルを行の境界で分割し、それらをタブレットとして保存します。タブレットは約200 MBで、各マシンは約100タブレットを節約できます。この設定により、単一のテーブルからのタブレットを多数のサーバーに分散させることができます。きめ細かい負荷分散も可能です。あるテーブルが多数のクエリを受信している場合は、他のタブレットを削除したり、ビジー状態のテーブルをそれほどビジーではない別のマシンに移動したりできます。また、マシンがダウンした場合でも、タブレットは他の多くのサーバーに分散されるため、特定のマシンに対するパフォーマンスへの影響は最小限に抑えられます。
テーブルは不変のSSTableとログの末尾(マシンごとに1つのログ)として格納されます。マシンのシステムメモリが不足すると、Google独自の圧縮技術(BMDiffとZippy)を使用してタブレットを圧縮します。マイナーコンパクションにはほんの数タブレットが含まれますが、メジャーコンパクションにはテーブルシステム全体が含まれ、ハードディスクの空き容量が回復します。
Bigtableタブレットの場所はセルに格納されています。特定のタブレットの検索は、3層システムによって処理されます。クライアントはMETA0テーブルへのポイントを取得します。テーブルは1つだけです。 META0テーブルは、検索されているタブレットの位置を含む多くのMETA1タブレットを追跡します。 META0とMETA1はどちらもシステム内のボトルネックを最小限に抑えるためにプリフェッチとキャッシングを多用しています。
実装
BigTableは、ログファイルやデータファイルのバッキングストアとして使用されるGoogle File System(GFS)に基づいています。 GFSは、SSTable(テーブルデータの永続化に使用されるGoogle独自のファイル形式)用の信頼できるストレージを提供します。
BigTableが多用しているもう1つのサービスは、Chubbyです。これは、高可用性で信頼性の高い分散ロックサービスです。 Chubbyはクライアントがロックをかけることを可能にし、おそらくそれを何らかのメタデータに関連付けます。それはキープアライブメッセージをChubbyに送り返すことによって更新できます。ロックはファイルシステムのような階層的な命名構造に格納されています。
Bigtableシステムには、主に3つのサーバータイプがあります。
グーグルの研究論文の例:
Webページを格納するサンプルテーブルのスライス。行名は反転URLです。 contents列ファミリーはpage contentsを含み、アンカー列ファミリーはページを参照するanyアンカーのテキストを含みます。 CNNのホームページはSports IllustratedホームページとMY-lookホームページの両方で参照されているため、行には
anchor:cnnsi.com
およびanchor:my.look.ca
という名前の列が含まれています。各アンカーセルはone version; contents列にはつのバージョンがあり、タイムスタンプはt3
、t5
、およびt6
です。
API
BigTableに対する一般的な操作は、テーブルおよび列ファミリの作成と削除、データの書き込み、および行からの列の削除です。 BigTableは、APIでこの機能をアプリケーション開発者に提供します。トランザクションは行レベルでサポートされていますが、複数の行キーにまたがってはサポートされていません。
これは 研究論文のPDFへのリンク です。
そして、ここであなたは ワシントン大学での講演でグーグルのジェフディーンを示すビデオ を見つけることができます、グーグルのバックエンドで使われているBigtableコンテンツストレージシステムについて議論します。
それは彼らが自分たちで作ったものです - それはBigtableと呼ばれています。
http://en.wikipedia.org/wiki/BigTable
データベースに関するGoogleの論文があります。
Spanner は、Googleの世界規模で配布されているリレーショナルデータベース管理システム(RDBMS)で、 BigTable の後継です。グーグルは、各テーブルは主キーを持たなければならないので、純粋なリレーショナルシステムではないと主張している。
ここ は論文のリンクです。
Spannerは、Googleのスケーラブル、マルチバージョン、グローバルに分散された、そして同期的に複製されたデータベースです。世界規模でデータを配布し、外部から一貫性のある分散トランザクションをサポートする最初のシステムです。このホワイトペーパーでは、Spannerの構造、その機能、さまざまな設計上の決定の根拠、およびクロックの不確実性を明らかにする新しいtime APIについて説明します。このAPIとその実装は、外部の一貫性とさまざまな強力な機能(過去のノンブロッキング読み取り、ロックフリーの読み取り専用トランザクション、およびすべてのSpannerにわたるアトミックスキーマ変更)をサポートするために重要です。
グーグルによって発明された別のデータベースは Megastore です。これが要約です:
Megastoreは、今日の対話型オンラインサービスの要件を満たすために開発されたストレージシステムです。 Megastoreは、NoSQLデータストアのスケーラビリティと従来のRDBMSの利便性を斬新な方法で組み合わせ、強力な一貫性保証と高可用性の両方を提供します。きめ細かいデータパーティション内で、完全に直列化可能なACIDセマンティクスを提供します。このパーティション化により、妥当な待ち時間でワイドエリアネットワーク全体で各書き込みを同期的に複製し、データセンター間のシームレスなフェールオーバーをサポートできます。本稿では、Megastoreのセマンティクスと複製アルゴリズムについて説明します。また、Megastoreを使用して構築されたさまざまなGoogle制作サービスをサポートしてきた経験についても説明します。
他の人が言ったように、グーグルはBigTableと呼ばれる自家製の解決策を使います、そして彼らはそれを現実の世界に説明しているいくつかの論文を発表しました。
Apacheの人々は HBase と呼ばれるこれらの論文で提示されたアイデアの実装を持っています。 HBaseは彼らのサイトによれば「膨大な量のデータを処理するアプリケーションを簡単に書いて実行することができるソフトウェアプラットフォームです」 - )ベンチマークのいくつかは非常に印象的です。彼らのサイトは http://hadoop.Apache.org です。
Googleはすべての主要なアプリケーションにBigTableを使用していますが、他の(おそらくマイナーな)アプリケーションには MySQLも使用 です。
BigTableはリレーショナルデータベース(MySQLのような)ではなく、非常に異なる特性を持つ巨大な(分散型) ハッシュテーブル であることを知っておくと便利です。 BigTableの(限定版)を Google AppEngine プラットフォームで自分で試してみることができます。
上記のHadoopの隣には、BigTableと同じ問題(スケーラビリティ、可用性)を解決しようとする他の多くの実装があります。昨日、ニースのブログ記事にそれらの大部分がリストされていました ここ 。
Googleは主にBigtableを使用しています。
Bigtableは、非常に大きなサイズに拡張するように設計された構造化データを管理するための分散ストレージシステムです。
詳しくは、 ここ から文書をダウンロードしてください。
Googleは、一部のアプリケーションにOracleとMySQLのデータベースも使用しています。
あなたが追加できる情報はこれ以上ありません。