DBまとめ1:分散Key-Valueストア

クラウド時代のデータベース「分散Key-Valueストア」

グーグルがインターネットの世界をここまで席けんできた最大の理由
検索技術ではなく、同社が生み出した巨大な分散データストア、「Bigtable」にあります。

Bigtableは、Google検索をはじめ、YouTubeやGoogle Map、Google Earth、Google Analytics、Google App Engineなど、グーグルの70以上のプロジェクトの基盤として利用されています。合計で数PB（ペタバイト）に達する天文学的規模のデータを、全世界 36カ所以上のデータセンターに配置された数万〜数十万台のサーバに分散して格納し、これらグーグルの各種サービスの圧倒的なスケーラビリティと高可用性 を低コストで実現しています。

Bigtableは、リレーショナルデータベース（以下、RDB）ではなく、いわゆる「分散Key-Value Store（以下、KVS）」の1つです。KVSは、プログラミング言語の連想配列やMapと同様に「Key（キー）」と「Value（値）」のペアからなる、ごくシンプルなデータモデルに基づくデータストアです。KVSは「キー・バリュー型データストア」「Key/Valueストア」などと呼ばれることもあります。

分散KVSが苦手なトランザクションの「ACID特性」

RDBのように、テーブルとテーブルを結合（SQLでいうJOIN文）して複雑な条件検索や集計処理を一発でこなすような芸当はできません。また、トランザクションによる「ACID特性」の確保も分散KVSが苦手な分野です。

RDBが不得意な分散／拡張

そのため、これらの不足をアプリケーション側で補うためのさまざまな工夫やフォローが必要となります。その一方で、分散KVSはデータストア全体をいくらでも多くのサーバに分散（スケールアウト）できるのが最大の特徴です。
　一方でこれは、RDBが最も不得意とするところです。RDBでは、その長所であるテーブル結合やACIDの確保がボトルネックとなり、複数のサー バにスケールアウトさせることが「原理的」に容易ではありません。そのため、負荷分散や高可用性を低コストで実現することが困難です。

RDBで負荷分散させようとすると……

例えばMySQLを使う場合、1テーブルのレコード件数が数百万〜数千万件を超えるような規模になると、1台のDBサーバだけでは実用的なパ フォーマンスが達成しにくくなります。そこで一般には、以下のような対策によってRDBのスケーラビリティを引き上げる努力が必要となります。

• RDBサーバのスケールアップ（大型サーバへの載せ替え）
• DBのレプリケーションやシャード（パーティション）分割によるクラスタ構築
• 分散キャッシュ（Oracle RACやmemcachedなど）によるクラスタ構築

経験者ならばお分かりいただけるとおり、このどれもが結果的に「高コスト」となるソリューションです。



■利点その【1】負荷分散や可用性に悩まないでいい！負荷分散や可用性に悩まないでいい！
　まず、実用上は制限のないスケーラビリティのおかげで、「負荷分散や可用性のことで悩んだりコストを掛けたりする必要があまりなくなる」ということです。
■利点その【2】データを効率よく集約できる！データを効率よく集約できる！
　そしてもう1つの、かつ最も重要な利点は、「アプリケーションの分散化対応によって、クラウドによる全体最適のメリットを享受できる」ことです。

例えるなら、「一戸建て」と「タコ部屋」である

これは例えるなら、独立した仮想マシンやOS、DBインスタンスを占有していた「一戸建て」の環境を捨て、100人くらいで1つの部屋を共有する「タコ部屋」に入居するようなものです。このタコ部屋では、分散KVSという使いにくい収納しかありません。


http://www.atmarkit.co.jp/ait/articles/0907/02/news101.html