MongoDBがWiredTigerとそのリレーショナルデータベースストレージエンジンを買収したので、技術者はMongoDBがマルチドキュメントトランザクションをサポートする時を推測してきた。今週の発表で、MongoDB 4.0の一部として、この夏に準備が完了する予定である。
MongoDBのGrigori Melnik氏は、「アプリケーションの80%～90%はマルチドキュメントトランザクションを全く必要としない」と主張している（しかし、この主張には疑問の余地があり、階層的なデータベースには多くの非正規化データを含む傾向があり、一貫性を確保するために複数の場所で同時に更新がされる必要がある）。彼は続けて次のように言っている。
また、開発者やDBAの中には、40年にわたるリレーショナルデータのモデリングによって、構築するデータ・モデルに関係なく、マルチテーブル/マルチドキュメント・トランザクションが、どのデータベースに対しても要件であるとするのが習慣となっている人もいます。別の人たちは、現状、アプリケーションではマルチドキュメントトランザクションは不要であるが、将来的には必要となる可能性があり、データベースを扱えきれない状況となってしまわないか懸念しています。
ACIDの基礎となるマルチドキュメントトランザクションのサポートは、MongoDB 3.0から始まった。このバージョンでは、MongoDBは、PostgreSQLやOracleリレーショナルデータベースによく連想されるスナップショット分離のための手法であるマルチバージョン・コンカレンシー・コントロール(MVCC)が取り入れられた。最近のバージョンのSQL Serverでは、MVCCを「メモリ最適化」テーブルにも使用している。
MongoDB 3.2では「リード・コンサーン」のサポートが追加された。これまで、クライアントは、通信しているノードのいずれかが知っているデータを与えられていた。リード・コンサーンオプションによって、クライアントは大多数のノードが知っているデータを要求できる。ドキュメントによれば、「リード・コンサーンのレベルに関係なく、ノード上の最新のデータは、システム内の最新のデータを反映していない可能性がある」。
MongoDB 3.6では「因果一貫性」と呼ばれるものを提供した。以前のバージョンのMongoDBでは、操作が特定の順序で行われるという保証はなかった。たとえば、一連のレコードを削除し、次に削除したばかりのレコードを返す読み取りを実行できる。因果一貫性によって、読み取り操作が書き込み操作の結果に依存することを示すことができ、読み取りが実行される前に削除が完了したことを確認できる。
最後に、MongoDB 4.0は読み取りの一貫性を実行する機能を提供する。つまり、読み取り操作が開始された瞬間に知られていたデータだけを返す。A Quick Primer on Isolation Levels and Dirty Readsという記事で説明されている通り、MongoDBの以前のバージョンでは、いずれかの時点とは、必ずしも一貫性がない結果が返される可能性がある。1つのクエリでドキュメントをスキップしたり、同じドキュメントの複数のバージョンを返すこともできる。
マルチドキュメントトランザクションを試してみたい開発者には、MongoDB 4.0ベータプログラムに登録することが勧められている。
Rate this Article
- Editor Review
- Chief Editor Action