分散型で無制限の拡張性をもち、高信頼性をもつデータストアは、業界の次の聖杯となっている。Googleは2年前にGoogle App Engine Datastoreを立ち上げた際に、初めてこの問題に取り組んだ。このマスター/スレーブ型のレプリケーションアーキテクチャは、すぐに利用可能となる高速な書き込みを実現しつつ、素早く、強い一貫性をもった読み取りをサポートするように設計されていた。しかし、Googleはこの方式を再考しなければならなかった。
過去6ヶ月間の間、皆さんおそらくご存じのように、私たちは、App Engine Datastoreに関する信頼性の問題に取り組んできました。過去数ヶ月の取り組みで、これらの問題の解決に向けて大きく前進しました。しかしながら、これらの問題を経験して、私たちは設計の前提のいくつか改めて考え直す必要がでてきました。
Googleは、先週、読み込みと書き込みの双方で高いレベルの可用性を提供する「High Replication Datastore」を導入した。これは、書き込み時の遅延の増加とAPIでの一貫性保障の変更によって実現された。
High Replication Datastoreは、Paxosアルゴリズムを利用してデータセンター間のデータの同期を行うことにより、データのレプリカを管理するデータセンターの数を増加させます。このことによるもっとも大きな利点の一つは、計画停止中や、予期せぬ基盤の問題発生時にも、アプリケーションの全機能が利用可能だという点です。
Googleは、開発者に次のような警告を行っている。
分散データベースであるため、CAP定理が示すことを考慮にいれた上で、開発者はアプリケーションのアーキテクチャをどのようなものにするかを注意深く考えなければなりません。なぜならコストが増大し、信頼性が増大するにつれ、複雑度は増し、パフォーマンスは劣化するからです。
既存のアプリケーションをHigh Replication Datastoreに移行するために、Googleは移行ツールを用意しようとしている。レプリケーションの量が増加するので、Googleは価格を3倍に設定した。
Todd Hoff氏は、これを「完全な分散機能への大きな一歩」と呼んだ。
HRDは、少なくとも3カ所のデータセンターにデータがレプリケーションされることを必要とし、エンティティグループ内では完全なACIDが保障され、エンティティグループをまたぐとより低い一貫性の保障でよいミッションクリティカルなアプリケーションを対象としています。
Googleの新しいデータストアは、RDBMSの抽象的なタプルとNoSQLの具体的な行-列ストレージの中間のデータモデルを定義している。RDBMSでは、データモデルはスキーマで宣言されており、強く型付けされている。それぞれのスキーマは一連のテーブルをもち、それぞれのテーブルは一連のエンティティをもち、それが一連のプロパティを持っている。プロパティは名前を持っており、型付けされた値を持つ。
Bigtableは、同じ列/行のペアに異なるタイムスタンプを持つ複数の値を保持することができる機能を提供している。この機能によって、multiversion concurrency control (MVCC)が実装されている。トランザクションの中で変更が適用されると、値はトランザクションのタイムスタンプと共に書き込まれる。読み取り側は、最後に完全に適用されたトランザクションを利用することで部分的な更新を読み取ることを避けることができる。
データの量にもよるが、平均的な読み取りの遅延は数十ミリ秒程度であり、多くの読み取りがローカルで行われていることを示している。多くのユーザにとって、平均的な書き込みの遅延は、100から400ミリ秒である。これはデータセンター間の距離や、書き込まれるデータの大きさ、完全なレプリカの数に依存する。
かつては、巨大企業のミッションクリティカルアプリケーションだけのためのものであった「巨大なインフラストラクチャ」のコストが急落しており、数年前には考えもつかなかったような革新的なロングテールのアプリケーションを作成することが可能となってきている。Google App Engineを利用する予定はあるだろうか？このようなデータストアをあなたのソリューションでは必要としているだろうか？この種のインフラストラクチャはどのような業界にとって、もっとも価値があるだろうか？