はじめに
結果整合性(eventually consistent) [1] は、多くの大規模分散データベースで使われる一貫性モデルの1つである。このようなデータベースでは、複製されたデータ片に対する全ての変更は 結果的に全ての関連するレプリカに反映される必要がある。
さらに、コンフリクトの解消はこれらのデータベースでは扱われず、更新のコンフリクトが発生した場合、アプリケーションで対処の責任を負う必要がある。 結果整合性は、弱い一貫性の1つの特異形態で、オブジェクトに新規の更新がない場合、ストレージシステムが全てのアクセスが結果的には、最後にアップデートした値を返すことを保証するものである [1]。 失敗が何も起こらなければ、整合がとれていない部分の最大幅は、通信の遅延、システムの負荷、そしてレプリケーションに関わるレプリカの数などを元に決めることが出来る。前に、 https://blog.mariadb.org/mariadb-eventually-consistent/ で記載した通り、MariaDBはとりうるほとんどのコンフィグで結果整合性がある。
定義 結果整合性
- 結果的展開(Eventual Delivery) ある1ノードで実行された更新は、結果的に全ノードで実行される
- 終了(Termination) 全ての更新は終了すること
- 収束(Convergence) 同じ更新を実行したノードは、結果的に同じ状態となる(そして、その状態のままでいる)
例: 3ノードでR=0のデータがあるケースを考えてみよう。仮に次のような順序の書込みとコミットがノード0であったとする。W(R=3) C W(R=5) C W(R=7) C。現在のところは、ノード1では、R=5F、ノード2ではR=7を示すかもしれない。最終的に全てのノードからの読取り結果が同一になる限りにおいて、これを結果整合であるという。結果整合は、書込順序については何ら制限しない。
このブログエントリでは、結果整合性を使ったDBMSについて簡単に紹介し、評判、成熟度、一貫性、ユースケースの観点でレビューしたデータベースを評価する。これに基づいて結果整合性の利点欠点を示す。詳細な調査結果については [13] に記載した。
結果整合性を使ったデータベース
MongoDB [2] はクロスプラットフォームのドキュメント指向NoSQLデータベースで、データの格納にBSONを利用している。MongoDBはフリーのOSSであり、様々なポピュラーな言語や、開発環境に対応する公式のドライバを持つ。Webプログラミング言語のOpaもビルトインでMongoDBをサポートしているし、DB上で型セーフなレイヤを提供している。 他の言語やフレームワークへの非公式、またはコミュニティーサポートのドライバもたくさんある。
Couch DB [3] は、オープンソースのNoSQLデータベースの1つで、データモデルにJSONを利用し、JavaScriptをクエリ言語に、HTTPをAPIに利用している。2005年に初期リリースされ、2008年にApacheプロジェクトとなる。マルチマスタレプリケーションはCouchDBの特筆すべき特徴の1つである。
Amazon Simple DB [4] は、Amazon.comによって開発されたErlang言語ベースの分散DBである。Amazon EC2とAmazon S3と並んで、Webサービスとして利用でき、Amazon Web Serviceの1つである。2007年12月13日に公開された。
Amazon DynamoDB [5, 6]は、Amazon Web Serviceのポートフォリオの一部として、Amazon.comによって提供される、 商標登録されたフルマネージドなNoSQLのデータベースサービスである。Dynamoに似たデータモデルを利用し、名前の由来はDynamoから来ている。しかしながらDynamo DBは単一DBデザインであり、実装が異なる。Amazon CTOのWerner Vogelsによって2012年1月18日に公開された。
Riak [7] はオープンソースのフォールトトーレラントなキーバリューNoSQLデータベースである。AmazonのDynamoに基づいて実装されている。ノードやデータを格納するバケット間でデータを伝播させるためにコンシステントハッシングを利用している。
DeeDS [8] は、分散アクティブリアルタイムデータベースのプロトタイプである。リアルタイムアプリケーションで利用するデータストレージとして開発され、非常に厳しかったり厳格なリアルタイム性が要求されるアプリ向けである。データベースとしては、OBST(STONEのオブジェクトマネージメントシステム)とOBSTのストレージマネージャにとってかわるTDBM(DBM with transaction)を利用している。TDBMを導入した主な理由は、ネステッドトランザクションをサポートするためである。TDBMはトランザクションを処理できる階層型アーキテクチャのデータストアで、DeeDSとして下記機能を提供している。
- ネステッドトランザクション
- 揮発性/永続性データベース
- 大規模データのサポート
ZATALAデータベース [9] は、分散データベースエンジンで、抽象的なクエリインターフェースとプラグイン化可能な内部データ構造を持つのが特徴である。どんなアプリケーションにでも使える柔軟性を持つようにデザインされ、データの完全性を保証し、ハイパフォーマンスおよびスケーラビリティーをもつ。
DeeDSとZATARAは両方とも研究プロジェクトの成果として生まれたもので、プロダクションで利用するまでには成熟していない。
ここでは、結果整合性をサポートするデータベースシステムを下記の基準で評価した。
- 評判
- 成熟度
- 一貫性
- ユースケース
評判
DB Engines rankinghttp://db-engines.com/en/rankingに基づき、評判を評価した。DB Engines RankingはDBMSを評判に基づいて評価している。2014年の初めには、MongoDBはスコア96.2で7位だったが、6月にはスコア231.44で5位となっている。Couch DBは16位から21位(スコア22.78)に、Riakは27位から、30位(スコア10.82)に、DynamoDBは35位スコア7.20から32位スコア9.58に、SimpleDBは46位から52位スコア2.94となっている。
このランキングによると、MongoDBは明らかに一番ポピュラーで、広く知られている結果整合性をサポートするデータベースシステムである。また、リファレンスによると、MySQLは2位でMariaDBは28位である。
成熟度
筆者の研究によると、MongoDBは最も成熟した結果整合性を利用したデータベースシステムである。大規模なユーザーおよび顧客基盤をもち、開発がさかんである。MongoDBにはいくつかのポピュラーなプログラミング言語と開発環境に対する公式ドライバがある。他の言語やフレームワークへの非公式、またはコミュニティーサポートのドライバもたくさんある。
RiakはApache 2ライセンスの元で無償で利用できる。それに加え、Bashoテクノロジー社が、商用ライセンスを提供しており、サブスクリプションサポートと、複数データセンタ間レプリケーション機能が利用できる。RiakにはRuby, Java, Erlang, Python, PHPそしてC/C++の公式ドライバがあり、他のプログラミング言語やフレームワークについても多数のコミュニティサポートのドライバがある。
CouchDBはNoSQLデータベースで、データ格納にJSONを利用し、JavaScriptとErlangで利用できるMapReduceクエリ関数をサポートする。2005年にリリースされ、2008年にApacheプロジェクトとなった。CoucnDBのレプリケーションと同期の特徴は、ネットワークの接続性が保証されないが、アプリケーションはオフラインで動作継続する必要があるという、モバイルデバイスには理想的である。また、データを蓄積し、ときどき変更があるアプリケーションに向いている。事前に定義されたクエリが実行され、バージョン管理が重要となるようなものである(例えば、CRMやCMSシステム)。マルチマスタレプリケーションは特にCouchDBで興味深い特徴的で、これを利用すると複数ロケーションへの配備が簡単にできる。CouchDBは明らかに成熟したシステムでプロダクション環境でも利用されている。
DynamoDBは有償のマネージドNoSQLデータベースサービスで、Amazon.comによって提供されるAmazon Web Serviceの1つのサービスである。DynamoDBのローカル開発バージョンもあり、開発者はDynamoDBをバックエンドにしたアプリケーションをローカル環境でテストすることが出来る。DynamoDBと利用できるプログラミング言語は、Java, Node.js, .NET, Perl, PHP, Python, Ruby, Erlangがある。このようにDynamoDBは成熟した、プロダクションクオリティーのサービスである。
Amazon SimpleDBはベータ段階なので、プロダクションへの利用はお勧めしない。 ZATARAとDeeDSは研究段階であり、公開されているテスト用に利用できるシステムがない。つまりせいぜいアルファ段階なので、プロダクションへの利用はお勧めしない。
一貫性
以前の調査で、Amazon SimpleDBの結果整合性の読取りに対する、inconsistency windowは500ms以内であった [10]。Amazon S3のinconsistency windowは12秒も継続していたという別の調査結果があるにもかかわらず、である。筆者の知るところによると、結果整合性を使ったデータベースに対する周知の負荷がないため、一貫性または非一貫性に対する比較は単にシステムの特徴に基づいたものとなってしまう。一貫性の観点からは、Riakが最も一貫性レベルを選択できるコンフィグ性が高い。
MongoDB, SimpleDB, そしてDynamoDBは最新のデータをリードする、強い一貫性を結果整合性とともに提供している。その他のシステムは、結果整合性のみを提供しており、読取り一貫性が担保されず古いバージョンを読み取ってしまう可能性がある。
ユースケース
MongoDBはオペレーショナルインテリジェンス、とりわけログデータを格納し、事前集計されたレポートしたり、階層的集約をおこなうケースで成功裡に利用されてきた。その上、MongoDBは製品カタログを格納したり、商品やカテゴリ階層を管理するプロダクトマネジメントシステムに利用されてきた。CMSでは、MongoDBはメタデータ、資材管理、ブログ投稿やブログ媒体のようなコンテンツに対するユーザーコメントの格納に利用されている。
Riakはシンプルな、高レートのRead-Writeアプリエーションのセッションストレージや、広告配信、ログデータとセンサデータの格納に成功裡に利用されてきた。また、Rコンテンツマネジメントおよび、ソーシャルアプリケーションでの、ユーザーアカウントやユーザの設定およびプリファレンス、ユーザーのイベントとタイムライン、記事、ブログの投稿の格納に利用されてきた。
CouchDBのレプリケーションと同期の機能は、ネットワーク接続が保証されないがアプリケーションがオフラインで動きつづけなければいけないモバイル環境によく適している。また、データを蓄積し、ときどき変更があるアプリケーションに向いている。事前に定義されたクエリが実行され、バージョン管理が重要となるようなものである。CRMやCMSシステムがそのようなアプリケーションの例としてあげられる。また、興味深い特徴として、複数ロケーションへの配備が簡単に出来るマルチマスタレプリケーション機能を提供する。
SimpleDBはロギングや、オンラインゲーム、メタデータのインデクシングに向いている。しかしながらSimpleDBでレポートの集約では使えない。SUM, AVERAGE, MINなどの集約関数がない為である。メタデータのインデクシングは、SimpleDBには非常に良いユースケースで、データをS3に格納し、SimpleDBをS3オブジェクトへのポインタ、および付加情報の格納に利用するといった使い方が出来る。SimpleDBを理想的な状態で使える別のタイプの適用例としては、アプリケーションの隔離されたコンポーネント間の情報の共有がある。SimpleDBは索引された情報、つまり検索される情報の格納を提供している。SimpleDBのアイテムはサイズが限定されているが、S3を画像やビデオといったより大きなオブジェクトの格納に利用し、SimpleDBでポインタを格納する。これをメタデータのインデクシングと呼ぶことができる。
利点と欠点
利点
結果整合性は、クライアントに一定の一貫性を提供するには容易である [11]。結果整合性を持つデータベースを構築するにあたって、強い一貫性があるデータベースを構築するのに比べ２つの利点がある。(1) 保証レベルを下げることにより、システムの構築が容易となり、 (2) より大きなデータベースクラスタからネットワーク隔離されたデータベースサーバが、アプリケーションの書込みを受け付けられる。当然、２点目の正しさは、第一世代の結果整合性を採用したNoSQLの作者によって示されている。
結果整合性は、強い一貫性をもつことがしばしばある。 最近のいくつかのプロジェクトは、現実世界の結果一貫ストアの一貫性を立証している。
欠点
結果整合は実現が簡単であるが、現在の定義が正確ではない [11]。 第1に、現在の定義によると、結果整合データベースの現在の状態が明確でない。42を常に返すデータベースは、仮に42が決して書き込まれなくても結果整合を保っている。また、結果的に全てのアクセスは最後にアップデートした値になるという1つの定義が考えられ、 この結果データベースは気まぐれな値には収束しない [1]。この新たな定義でさえも別の問題がある。データベースが最終状態になるまでにどのような値をとるだろうか？レプリカが収束していない場合、データの返り値になにが保証されうるだろうか？このケースでは、1つの解として、最後に取得した一貫性のある値を返すというがあるだろう。問題は、データのどのバージョンのアイテムが全てのレプリカで同じ状態に収束したかをどのように知るかである [1]。
結果整合性は、1ノードに書き込むと、他のレプリカに結果的に現れることを求めているため、全てのレプリカが同じ書込みのセットを受け取り、全てのデータが同じデータになる。この弱い一貫性は異なるキーのデータの操作順序を制約しない。プログラマに対して全ての考えうる順序、およびユーザに一貫性のないデータが見える可能性があることを考慮することを強いる。例えば、結果整合性の元では、アリスがプロファイルをアップデートした後、リフレッシュしたとしてもアップデートした内容を確認できるとは限らない。また、アリスとボブが前後してブログの投稿をした場合、キャロルには、ランダムで連続性のない会話の一部がみえるかもしれない。結果整合性をもつデータベースを利用してアプリケーションを構築する場合は、データベースがアクセスされるどの瞬間においても、いくつかの難しい疑問に答える必要がある。
- データベースが古いデータを読み取った場合、アプリケーションに何が起こるか？
- 更新順序の問題でデータベースが更新中の値を読み取った場合、アプリケーションに何が起こるか？
- クライアントがデータを更新している一方で、データの読取りを行っている場合、アプリケーションに何が起こるか？
- 別クライアントで更新されていた場合、何が読み取られるか？
非常に難しいリストであり、開発者はこれらの疑問に答える為に、ハードに働かなければならない。必然的にエンジニアは、複数のクライアントが複数ノード間で非一貫にならないようにしなければならない。
この問題に答える1つの解は、結果整合性の強いバージョンを利用することである。
定義 強い一貫性(Strong Eventual Consistency)
- 結果的展開(Eventual Delivery) ある1ノードで実行された更新は、結果的に全ノードで実行される
- 終了(Termination) 全ての更新は終了すること
- 強い収束(Strong Convergence) 同じ更新を実行したノードは、同じ状態である
筆者の知る限りでは、強い結果的一貫性をもちいたデータベースシステムは存在しない。これは実装がもっと困難である為である。 結果整合性は、従来のデータベースが提供する保証という点で、明らかな弱点があり、要件をソフトウェア開発者にゆだねている。データベースの正確性が信頼できなかったとしても正しい挙動をするアプリケーションを設計するのは難しい。
実際のところ、Google社は結果整合性の痛点について、F1データベースの最近の論文 [12] で述べている。 「Googleでは結果整合性のシステムでも、たくさんの経験がある。全てのこの種のシステムで、開発者は大変複雑でエラーの起こしやすいメカニズムである、結果整合性とうまくやっていき、最新でない可能性があるデータをうまく扱う為のシステム構築に大きな時間の割合を割いていることを発見した。これは開発者に対して受け入れられない重荷で、データベースレベルで一貫性の問題は解決されるべきである。」
結論
明らかに、結果整合性を使ったとても成熟して一般的なデータベースシステムがいくつか存在する。これらは活発に開発されており、強力なコミュニティーがその背後にある。結果整合性や強い結果的一貫性を利用したデータベースが将来増えることを願う。
参考
[1] Vogels, W.: Scalable Web services: Eventually Consistent, ACM Queue, vol. 6, no. 6, pp. 14-16, October 2009.
[2] MongoDB: Agile and Scalable. http://www.mongodb.org/
[3] Anderson, C. J., Lehnardt, J., and Slater, N.: CouchDB: The Definitive Guide. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. January 2010, First Edition
[4] Amazon SimpleDB, http://aws.amazon.com/simpledb/
[5] DynamoDB, http://aws.amazon.com/dynamodb/
[6] Sivasubramanian, S.: Amazon DynamoDB: a seamlessly scalable non-relational database service. In proceeding SIGMOD International Conference on Management of Data, ACM New York, NY, USA, 2012, pp. 729-730.
[7] Riak, http://basho.com/riak/
[8] F. Andler, J. Hansson, J. Mellin, J. Eriksson, and B. Eftring: An overview of the DeeDS real-time database architecture. In Proc. of 6th International Workshop on Parallel and Distributed Real-Time Systems, 1998
[9] Bogdan Carstoiu and Dorin Carstoiu: Zatara, the Plug-in-able Eventually Consistent Distributed Database. AISS, 2(3), 2010.
[10] Bermbach, D. and Tai S: Eventual Consistency: How soon is eventual? Proceedings of the 6th Workshop on Middleware for Service Oriented Computing, pp1-5, 2011.
[11] Bailis, P., and Ghodsi, A: Eventual consistency today: limitations, extensions, and beyond. In communications of the ACM vol. 56, no. 5, pp.55-63, May 2013.
[12] Shute Jeff, Vingralek Radek, Samwel Bart, Handhy Ben, Whipkey Chad, Rollins Eric, Oancea Mircea, Littlefield Kyle, Menestina David, Ellner Stephqan, Cieslewicz John, Rae Ian, Stancescu Traian, Apte Himani: F1: A Distributed SQL Database That Scales, VLDB, 2013.
