ドキュメント データベース、特に MongoDB のアイデアが気に入っています。データベース スキーマを調整する必要がないため、開発を高速化できます。ただし、MongoDB はマルチドキュメント トランザクションをサポートしておらず、通常のデータベースのように変更がすぐにディスクに書き込まれることを保証しません (フラッシュ間の時間を非常に短くできることはわかっていますが、それでも保証はされません)。
私たちのプロジェクトのほとんどは、マルチサーバー環境などを必要とするほど大きくはありません。それを念頭に置いてください。複数ドキュメントのトランザクションと信頼性の高いディスクへのフラッシュをサポートする単一サーバーの MongoDB のようなドキュメント データベースはありますか?
ArangoDBを見る価値があるかもしれません。これは、ドキュメント、グラフ、およびキー値の柔軟なデータ モデルを備えたマルチ モデル データベースです。特定の要件に関して、ArangoDB データベースには完全な ACID トランザクションがあり、同じコレクション内の複数のドキュメントと複数のコレクションにまたがることができます ( ArangoDB のトランザクションを参照)。つまり、ドキュメントに対する一連の操作をトランザクションでまとめて実行でき、アトミック性と分離性が保証されます。追加で設定するwaitForSync: true
と (前述のページのさらに下で説明されているように)、トランザクションが完了を報告する前に、ディスクへの同期が保証されます。トランザクションが複数のコレクションにまたがる場合、これは自動的に行われることに注意してください。
特定の（ただし簡単な）要件に対する非常に短い答え：
複数ドキュメントのトランザクションと信頼性の高いディスクへのフラッシュをサポートする単一サーバーの MongoDB のようなドキュメント データベースはありますか?
RavenDB [ 1 ] は、マルチドキュメント トランザクション [ 2 ] のサポートを提供します。残念ながら、耐久性についてはわかりません。
CouchDB [ 3 ] は永続的な書き込みを提供しますが、マルチドキュメント トランザクションは提供しません
RethinkDB [ 4 ] は永続的な書き込みを提供しますが、マルチドキュメント トランザクションは提供しません。
では、これら 3 つのソリューションの違いについて疑問に思われるかもしれません。ほとんどの場合、クエリのサポート (RethinkDB には、ほとんどすべての種類のクエリ (サブクエリ、JOIN、集計など) をカバーする最も高度なサポートがあると思います)、その履歴 (読み取り: 本番環境への対応 -- ここで私はおそらく CouchDB がリードしていると思います)、その配布モデル (それはあなたにとって興味深いことではないとおっしゃいました)、そのライセンス (RavenDB: 商用、CouchDB: Apache ライセンス、Rethinkdb: AGPL) です。
次のステップは、それらの機能セットを簡単に見て、ニーズに近いものを見つけて試してみることです.
Couchbase を参照することをお勧めします。
Couchbase は単一サーバーで実行でき、必要に応じて後でノードを追加できます。
Couchbase には memcached が統合されているため、更新をディスクに書き込む信頼性の高い方法で、共通データを高速にキャッシュできます。
また、NQL (「ニッケル」) と呼ばれる新しいクエリ言語 (開発中ですが、現在使用できます) もあり、重要な場合は SQL のようなアクセスを提供します。
クロス データセンター レプリケーションを使用すると、異なるマシンまたはデータ センターにある 2 つの DB の同期を維持できます。これは、オフサイト バックアップに適しています。これにより、これらのタイプのクエリ用の全文検索エンジンが必要な場合は、エラスティック検索を追加することもできます.
要するに、Couchbase は非常に完全なソリューションであり、すべてがオープン ソースであり、分散データベースの典型的な問題に対処するためのインテリジェントな (私の意見では) アーキテクチャを備えています (たとえば、すべてのドキュメントは特定のノードによって「所有」されているため、すべての変更はそのノードに移動します)。これは、Riak のように 2 つのノードに更新を行ってから調整するよりも優れていると思います。)
プロジェクトを異なるバケットに分けることで、1 つのノードで Couchbase を使用して多くのプロジェクトのデータベースを実行できます。
非常に多くのnosqlデータベースがあり、1つを選択するのは間違いなく困難です. 適切な要件を考え出し、何が欲しいかを正確に知る必要があります。次のリンクは、ほとんどすべての一般的な nosql データベースを比較しました http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
これが役立つことを願っています。
Berkeley DB は、私たちが使用したものです。ACIDをサポートしています。トランザクションはありますが、「マルチドキュメント」という用語が適用されるかどうかは完全にはわかりません。各データベース (つまり、個々のドキュメント) が同じ BDB 環境 (つまり、トランザクションが保存される場所) を共有している限り、おそらくそれで目的が達成されると思います。ただし、BDB には他のトレードオフがあります。完全な耐久性と高い同時実行性により、コミットはかなり遅くなります。
試してみてください: http://www.orientdb.org/
「OrientDB には、ドキュメント データベースの柔軟性と、関係を管理するためのグラフ データベースの機能があります。スキーマレス モード、スキーマフル、またはその両方のモードで動作できます。ACID トランザクション、高速インデックス、ネイティブなどの高度な機能をサポートします。および SQL クエリ。JSON でドキュメントをインポートおよびエクスポートします。OrientDB は、高速挿入と超高速ルックアップの両方の利点を備えた Red-Black Tree および B+Tree から派生した MVRB-Tree と呼ばれる新しいインデックス作成アルゴリズムを使用します。
私があなただったら、Solr を詳しく調べます。基礎となるデータ層 (Lucene) は、NoSQL データベースの中で群を抜いて最も成熟しており、Solr を使用すると、単一ホストの lucene ストアのインストール、構成、および統合が簡単になります。
あなたの質問への回答として、ユーザーが記述したトランザクションをサポートしています。Lucene は読み取りに最適化されているため、多くのアプリケーションには適さない可能性がありますが、要件によっては、それらのほとんどが Solr/Lucene+[SQL、Cassandra、CouchDB、RDF] に適しています。
個人的には、Solr+SQL または Solr+RDF から始める傾向がありますが、NodeJS+CouchDB スタイル全体を愛する人を何人か知っており、提供される柔軟性の価値を確信しています。
肝心なのは、あなたやあなたのユーザーのデータを危険にさらすことなく、あらゆる要件を満たすデータの整合性を考慮した NoSQL と SQL 拡張機能が十分に存在するということです。
ドキュメント データ ストアのスキーマを調整する必要はありません。ACID データベースが必要なようです。リレーショナル データがあり、そのデータとのトランザクションが必要な場合は、リレーショナル データベースが必要なように思えます。
Mongo のような「NoSQL」データベースでは、多くの書き込み可能なレプリカ、シャーディング、ドキュメント データへの迅速なアクセスなどの機能のために ACID をあきらめています。あなたはそれから恩恵を受けていないように聞こえますが、なぜトレードオフを取るのですか? 最近、多くの人が PostgreSQL でハイブリッド アプローチを行っており、ドキュメントをリレーショナル テーブルに JSON の blob として格納しています。これにより、必要のない厳密に構造化されていない列としてデータを格納できるという利点があります。
したがって、更新時にトランザクションを行う必要があるドキュメントが複数ある場合は、キーを列に並べて、列「ドキュメント」または単にシリアル化および逆シリアル化する JSON のブロブである何かを作成できます。これは、データベースとしての Mongo やその他のドキュメント ストアを批判しているわけではありませんが、トランザクショナル マルチドキュメント データにはあまり適していません。MarkLogic は、複数のドキュメントに対しても ACID を実行すると思います。
多くの人が、スキーマのない mongodb に魅力を感じていると思いますが、最終的にはリレーショナル モデルを mongodb に押し込もうとして苦しむことになると思います。したがって、DB の選択は常にデータの状態によって異なります。
個人的には、要件が何であるかを本当に確認する必要があると思います。
サーバーの OS がどのように動作するかのダイナミクスにより、たとえ指示されたとしても、すべてが「すぐに」ディスクに移動するとは言い難いです。確かに、SQL などの ACID 技術は、単一のサーバーがダウンしたときに未完成のビジネスや特定のウィンドウ内での操作を失うことによる部分的な破損に対して脆弱であることを知っています。残念ながら、これは単一のサーバーを使用する際の問題の 1 つです。あなたはそれを受け入れるしかありません。
トランザクションは、サーバーが失敗する前にデータ全体を受信することを保証しないことに注意してください ( http://en.wikipedia.org/wiki/Database_transaction )。サーバーがトランザクションの途中で停止した場合はどうなりますか?
トランザクションの制約に基づいて安全なロールバックを実行できますが、トランザクションに必要なすべてのデータを既に受け取っていない限り (通常はそうではありません)、トランザクションの再生を継続する機能を提供するデータベースはほとんどありません。とにかく古くなる。
実際、一部のトランザクションの重みと、トランザクション内で実行されるクエリの量により、トランザクションを使用すると、MongoDB の 60 ミリ秒のディスクへの書き込みウィンドウよりも大きな運用上の損失ウィンドウが発生する可能性があると考えられます。もちろん、これは乱用に依存しますが、ストアド プロシージャと同様に、この乱用はよくあることです。
トランザクションは、カスケード削除や、銀行口座への送金などの典型的なシナリオに役立ちますが、通常、カスケード可能な削除は、(ほとんどのサイトが行うように) 行を削除済みとしてマークするアプリケーションを使用して cronjob によって実行する方が適切です (トランザクションのロールバックが表示されないようにするため)。削除されたデータは再びユーザーに返されます); このようにして、ユーザーがアプリケーションを使用している間はリアルタイムでは実行できない多くのことを実行して一貫性を確保できます。
したがって、なぜ技術が必要なのか、それが何をするのに成功するのかを本当に質問する必要があります。質問の簡潔さは、要件について完全に確信が持てないことを示しています。