進化するNoSQLデータベース、SimpleDBやBigTableで一貫性やトランザクションを実現

2010年3月1日

クラウドの登場によって新たな種類のデータベース、NoSQL（Not Only SQLの略）と呼ばれる非リレーショナル型のデータベースが注目を浴びています。アマゾンのAmazon Web Servicesで利用可能なSimpleDB、グーグルのGoogle App Engineで利用可能なBigTable、Apacheで開発が進められているCouchDB、MemcachedやBerkeley DBなどよく知られたものもありますし、商用製品としてはOracle Coherence、IBM WebSphere eXtreme Scaleなどもあります（参考：NoSQLデータベースを40種類以上リストアップ、キーバリュー型にもいろいろある）。

NoSQLデータベースはリレーショナルデータベースとは異なり、スケーラビリティやアベイラビリティをトランザクションやデータ一貫性よりも優先させた実装が多いのが特徴です。しかし、ビジネスアプリケーションのバックエンドとしてNoSQLデータベースを見た場合、トランザクションやデータ一貫性の機能がないことはNoSQLの採用が進まない1つの大きな理由でした。

こうしたNoSQLの課題を解決しようとする動きがこのところ2つありました。

SimpleDBに一貫性保証の機能

Choosing Consistency - All Things Distributed

米Amazon Web ServicesがSimpleDBに一貫性を保証するオプションを付加したと、同社CTOのWerner Vogels氏が自身のブログのエントリ「Choosing Consistency」で紹介しています。＠ITの記事「Amazon SimpleDBに一貫性保証の新オプション」では、その内容を詳しく報じています。

SimpleDBではEventual Consistentと呼ばれる方式が採用されています。これはデータベースのスケーラビリティやアベイラビリティを高めるなどの目的で複数のノードにデータをレプリカとして保存しているため、データをアップデートした直後にリードしたときには、アップデートされたデータが必ず読み出されることを保証していません（まだアップデート情報が伝わっていない別のノードのデータが読み出される可能性がある）。ただしいずれは（Eventualには）すべてのノードのデータが最新になり一貫性が保たれる（Consistentになる）ということは保証されています。

今回SimpleDBには、このデータ一貫性をコントロールする2つの機能が追加されました。

1つは読み出し時の一貫性を保証するオプション「Consistent Read」です。Consistent Readでは、最新データの読み出しが保証されます。ただし、Consistent Readの利用は通常のEventual ConsistentなReadよりもレイテンシが大きくなるため（恐らく強制的にノードの同期が行われるため）、最小限の利用にする方がいいとWerner Vogels氏は書いています。

もう1つの機能追加は「Conditional Put and Delete」です。この2つは、操作対象の値が特定の値のときのみ操作を実行するという機能。用途として、ある操作対象の値をConsistent Readによって読み込んで保持しておき、PutやDeleteのときにはその値と同値であることを条件に設定することで、ある時点から操作時までそのデータがほかのプロセスによってアップデートもデリートもされていないことを保証できます。これはOCC（Optimistic Concurrency Control：楽観的並行性制御）によるトランザクションの実現となります。

App Engineには複数EntityGroupにわたるトランザクション

Google App EngineでGlobal Transaction - ひがやすを blog

Google App Engineでも進化がありました。App Engineに対応したJavaフレームワーク「Slim3」の開発者ひがやすを氏のブログ「ひがやすをblog」のエントリ「Google App EngineでGlobal Transaction」で、表題の通りSlim3による複数のEntityGroup（リレーショナルデータベースでいう複数行）にわたるトランザクションを実現したと報告されています。

Google App EngineはAPI経由でBigTableをデータベースとして利用しますが、トランザクションは1つのEntity Group内でしか利用できないという制限がありました。

そうするとある口座から別の口座にお金を振込むような送金のパターンで、Transactionを利用することができません(すべての口座を1Entity Groupに押し込むと更新がぶつかって現実的ではないから)。
（Google App EngineでGlobal Transactionから引用）

しかし、ひが氏はSlim3でこの制限を乗り越える実装を行い、複数のEntityGroupにまたがるトランザクションを実現したと報告。

そこで、Slim3で複数のEntityGroupにまたがるTransactionをサポートするGlobalTransactionの機能を実装しました。

どのように複数EntityGroupにまたがるトランザクションを実現したかは、ブログに解説があるので読んでいただくとして、これによってひが氏は次のように書いています。

App Engineの最大に懸念点であったTransaction問題はこれで解決されました。もうこれで、バリバリ開発できますね。
（略）
ほら、Bigtableは制限が多すぎて使い辛いというのは、過去の話だということが理解できましたよね。時代は進化しているのです。

NoSQLの課題は取り除かれつつあるが

NoSQLデータベースには2つの大きな課題があると思います。1つはここで取り上げたようにトランザクションや一貫性の制御ができなかったという課題。そしてもう1つは、リレーショナルデータベースにおけるSQLのような、特定の実装に依存せず、一般化された操作方法が存在しないため実装ごとに技術を覚えなければならない、という課題です。

この記事で紹介したように、前者の課題はさまざまな方法で解決されつつあるように見えます。実際、NoSQLはまだ表舞台に登場するようになってまだ数年しか経っていません。今後さらに進化が繰り返されることは疑いようがありません。

しかしNoSQLが本格的に普及するには、もう1つの課題、つまり実装ごとに操作方法や仕組みを覚えなければならないという状況を解決する必要があると思います。

リレーショナルデータベースではSQLという共通の操作言語があるため、SQLを覚えることで複数の実装に対応したスキルを身につけられるという利点がありました（本格的に使いこなすには実装個々について詳しくならなければならないことは当然ですが）。

NoSQLでは個々の実装がかなり違っているため、実装ごとに技術を覚えなければならず、学習する時間やコストの対投資効果はリレーショナルに比べて低いと言わざるをえません。しかしいまはNoSQLが登場したばかりで、実装ごとにさまざまな実験を繰り返しながら進化している途中であるため、ここでそれぞれの実装に共通したなにかを求めることは現実的でないことも明らかです。

しかし、いずれにせよどちらの課題も時間が経てば解決されるでしょう。そして「だからNoSQLにチャレンジするのはもう少し待つべきだ」という結論にするつもりもありません。

以前ひがやすを氏とお会いしたときに、こんな話をしてくれました「（キーバリュー型データストアでは）リレーショナルでの経験があまり役に立たない世界。だからこそ若い人たちにも、だれにでもチャンスがある」と。そして、ひが氏自身もSlim3に複数EntityGroupのトランザクション機能を実装したことは、Slim3をメジャーなフレームワークにするための大きなチャレンジだと言っていました。

NoSQLの課題は誰にとっても共通のものですが、それをどう理解し行動に結びつけていくかは、それぞれの人にゆだねられています。