NoSQLは「一貫性あるトランザクションを実現できない」という誤解:NoSQLベストプラクティス(7)(3/3 ページ)
本連載では、「NoSQLデータベースの今」を正しく理解し、ビジネス躍進の実現に向けた対策としての「ベストプラクティス」を掲示していきます。今回は、「NoSQLデータベースでは、トランザクションの一貫性を保証できない」という誤解について解説します。
トランザクションのコミット
コミットはトランザクションの最後に行われます。これによりトランザクションの「原子性」(ACIDの「A」)が実現されます。これが終わると、トランザクションによるあらゆる変更が公開されます。トランザクション中、何らかの部分がうまくいかなかった場合には、このトランザクションが中止され、そこまでの変更はロールバックされます(以前の状態に戻されます)。つまりこのトランザクションはなかったことになります。
トランザクションをコミットすると、新しいバージョンには現在の時間に基づく開始タイムスタンプが付けられ、これまでのバージョンには終了タイムスタンプが付けられます。これらは全て同時に行われます(タイムスタンプ情報は、独立したTimestampsファイルに格納され、コミットは1つの操作として実行されます)。トランザクションにおいてファイル変更時ではなく、コミット時にタイムスタンプを更新することにより、トランザクションの「原子性」が実現されます。全ての変更が一度に行われるのです。
分散コミット
それでは、分散されたデータベースにおいて、複数ホスト上にある複数ドキュメントをトランザクションとして更新する場合はどうでしょうか。この場合、コミットのプロセスは複雑になります。ここでデータベースは2相コミット(Two-Phase Commit)を行います。これは、全ての変更がコミットされたこと(あるいは失敗した場合にはどのホストでもコミットされていないこと)を確認するために、トランザクションに関わっているホスト同士がやりとりをするというものです。
2相コミットの際には、トランザクションに関わるホストのうち1つがコーディネーターの役割を担い、自分のオンディスクジャーナルに「distributed begin」というエントリーを記述します。これが終わると、他のホストにコミットの準備を要求するメッセージを送ります。これが2相コミットの1つ目の相(フェーズ)です。
この準備段階で、各ホストは各自のジャーナルに準備用エントリーを記述し、これをディスクと同期させ、参加の準備ができたことをコーディネーターに伝えます。ホスト(コーディネーターを含む)のうち1つでも参加できない場合、このトランザクションは中止されます。問題がない場合には、次のステップに進みます。
全てのホストから準備できていることを伝えられると、コーディネーターはコミットをジャーナルに記述し、これをディスクと同期させます。次にコーディネーターは、他の参加ホストに対してコミットするように伝えます。これにより各参加ホストもコミットを実行します。これが2相コミットの2つ目の相です。タイムスタンプは、分散されていない1つのホストの場合と同様に、全てのホストで更新されます。
コミットを2つのフェーズで行うことで、分散されたホスト全てがOKの場合にのみコミットされます。この準備フェーズがなければ、参加ホストの一部においてのみコミットが発生する可能性があります。こうなるとトランザクションの原子性が損なわれ、データの一部が矛盾してしまいます。
複数の機能を通じてACIDトランザクションを実現
こういった複数の機能により、NoSQLデータベースでも原子性、一貫性、独立性、永続性のある、つまりACIDなトランザクションを実現できます。ACID準拠のNoSQLデータベースに基づくアプリケーションでは、データの読み取りと書き込みを同時に行うことができます(ロックの解除を待たなくてはならない場合もありますが)。システムが異常終了した場合も、オンディスクジャーナルをリプレイすることでインメモリのデータを復旧できます。また2相コミットにより、アプリケーションによる多くのホストに分散したドキュメントへのアクセスも信頼できるものとなります。
筆者紹介
三浦デニース(Denise Miura)
マークロジック株式会社日本法人代表。ソフトウェア開発ならびにwebテクノロジーに関して25年以上の経験を持ち、さまざまなエンジニアリング、コンサルティング、管理職などの要職を歴任。前職はSilicon Graphics、E*TRADE Financial、Blue Martini Software(日本法人代表取締役)など。カーネギーメロン大学卒(コンピュータサイエンス専攻)
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- NoSQLはRDBMSに取って代わるものなのか?
「memcached」や「Apache Cassandra」、「Apache CouchDB」など、RDBMSとは異なる考えで設計してあるデータベース管理システムが普及しつつあります。この連載では、これら新しいデータベース管理システムの特徴と、RDBMSとの使い分け方について解説します。(編集部) - KVS系NoSQLのまとめ(Hibari、Dynamo、Voldemort、Riak編)
エンジニアとして「知らない」とは言えない空気が漂うNoSQL界隈……。いろいろあるけども何がどう違うのか、主要プロダクトの特徴をコッソリ自習しよう。第1回はKVS系NoSQLの中から、マスタ型、P2P型に分類されるものを紹介していく。 - 「演算子のインジェクション」と「SSJI」
ここ数年、大量データ処理時の高速性やデータ構造の柔軟性などから、「NoSQL」が注目を集めています。それと同時に、NoSQLを使うアプリケーションに対する攻撃手法も研究されるようになりました。この記事では、NoSQLを使ったアプリケーションの脆弱性と対策について解説します。 - マークロジック、NoSQLデータベース「MarkLogic 9」正式版をリリース
マークロジックが、NoSQLデータベースプラットフォームの最新版「MarkLogic 9」をリリース。開発者向けの「無償エディション」も用意する。