30 に答える
純粋に会話をサポートするための回答としてこれを投稿します-TimMahy、nawroth、およびCraigTPは実行可能なデータベースを提案しました。Erlangを使用しているため、 CouchDBが私の好みですが、他にもあります。
ACIDはNoSQLの概念と矛盾したり否定したりすることはないと思います...鳩が表明した意見に続く傾向があるようですが、概念は明確であると私は主張します。
NoSQLは基本的に、従来のRDBMSの明示的なスキーマの直接的な代替手段として、単純なキー値(Redisなど)またはドキュメントスタイルのスキーマ(「ドキュメント」モデルで収集されたキーと値のペア、MongoDBなど)に関するものです。これにより、開発者は物事を非対称的に扱うことができますが、従来のエンジンはデータモデル全体で厳密な同一性を強制していました。これが非常に興味深い理由は、変更に対処するための異なる方法を提供し、より大きなデータセットの場合、ボリュームとパフォーマンスに対処するための興味深い機会を提供するためです。
ACIDは、変更がデータベースにどのように適用されるかを管理する原則を提供します。非常に単純化された方法で、それは次のように述べています(私自身のバージョン):
- (A)データベースを変更するために何かをするとき、変更は全体として機能するか失敗するはずです
- (C)データベースは一貫性を保つ必要があります(これはかなり幅広いトピックです)
- (I)他のことが同時に起こっている場合、更新の途中で物事を見ることができないはずです
- (D)システムが爆発した場合(ハードウェアまたはソフトウェア)、データベースはそれ自体を回復できる必要があります。更新の適用が終了したと表示されている場合は、確実である必要があります
伝播と制約のアイデアに関しては、会話がもう少し興奮します。一部のRDBMSエンジンは、伝播要素(カスケード)を持つ可能性のある制約(外部キーなど)を適用する機能を提供します。簡単に言うと、ある「モノ」はデータベース内の別の「モノ」と関係がある場合があり、一方の属性を変更すると、もう一方の属性を変更する必要がある場合があります(更新、削除、...多くのオプション)。NoSQLデータベースは、主に(現時点では)大量のデータと大量のトラフィックに重点を置いており、(消費者の観点から)任意の時間枠内で行われる分散更新のアイデアに取り組んでいるようです。これは基本的に、を介して管理される特殊な形式のレプリケーションです。トランザクション-つまり、従来の分散データベースがACIDをサポートできるのであれば、NoSQLデータベースもサポートできると言えます。
さらに読むためのいくつかのリソース:
更新 (2012 年 7 月 27 日): ウィキペディアの記事へのリンクが更新され、この回答が投稿された時点で最新の記事のバージョンが反映されました。現在のウィキペディアの記事は大幅に改訂されていることに注意してください。
まあ、 NoSQLに関するウィキペディアの記事の古いバージョンによると:
NoSQL は、リレーショナル データベースの長い歴史と ACID 保証を破る、大まかに定義された非リレーショナル データ ストアのクラスを推進する動きです。
また:
この名前は、多くの場合、ACID 保証を提供しようとしない非リレーショナル分散データ ストアの出現を説明する試みでした。
と
NoSQL システムは、補助的なミドルウェア レイヤーを追加することで完全な ACID 保証を課すことができますが、最終的な整合性や単一のデータ項目に制限されたトランザクションなどの弱い整合性の保証を提供することがよくあります。
つまり、一言で言えば、「NoSQL」データ ストアの主な利点の 1 つは、ACID プロパティが明確に欠如していることです。さらに、私見ですが、ACIDプロパティを実装および適用しようとすればするほど、「NoSQL」データ ストアの「精神」から遠ざかり、「真の」RDBMSに近づきます (もちろん、比較的言えば、 )。
ただし、「NoSQL」は非常にあいまいな用語であり、個々の解釈に開かれており、どれだけ純粋な視点を持っているかに大きく依存します. たとえば、最新の RDBMS システムのほとんどは、実際には Edgar F. Codd のリレーション モデルの 12 のルールすべてに準拠しているわけではありません。
実用的なアプローチを取ると、Apache のCouchDBは、疎結合で非リレーショナルな「NoSQL」の考え方を保持しながら、ACID 準拠の両方を具現化するのに最も近いように見えます。
この質問では、誰かがOrientDBに言及する必要があります: OrientDB は NoSQL データベースであり、ACID トランザクションを完全にサポートする数少ないデータベースの 1 つです。ACID はリレーショナル代数の一部ではないため、RDBMS だけのものではありません。したがって、ACID をサポートする NoSQL データベースを持つことは可能です。
この機能は、MongoDB で最も欠けている機能です
FoundationDB は ACID に準拠しています。
適切なトランザクションがあるため、複数の異なるデータ項目を ACID 方式で更新できます。これは、上位層でインデックスを維持するための基盤として使用されます。
「NoSQL」は明確に定義された用語ではありません。とても漠然とした概念です。そのため、何が「NoSQL」製品で何がそうでないかを言うことさえできません。通常、このラベルでブランド化された製品のほとんどすべてがキーバリュー ストアであるとは限りません。
NoSQL の祖父: ZODB は ACID に準拠しています。http://www.zodb.org/
ただし、Python のみです。
はい、MarkLogic サーバーは、ACID トランザクションで動作する NoSQL ソリューションです (ドキュメント データベースと呼びたいと思います)。
ACID準拠のキー/値ストアをお探しの場合は、BerkeleyDBがあります。グラフデータベースの中で、少なくともNeo4jとHyperGraphDBはACIDトランザクションを提供します(HyperGraphDBは、現時点では実際には低レベルのストレージにBerkeley DBを使用しています)。
FoundationDB が言及されましたが、当時はオープン ソースではありませんでした。2 日前に Apple によってオープンソース化されました: https://www.foundationdb.org/blog/foundationdb-is-open-source/
ACIDに準拠していると思います。
MongoDB は、その 4.0 バージョンがマルチドキュメント トランザクションに対して ACID に準拠することを発表しました。
バージョン 4.2。シャードされたセットアップでそれをサポートすることになっています。
https://www.mongodb.com/blog/post/multi-document-transactions-in-mongodb
代替のリストに追加するために、もう 1 つの完全に ACID に準拠した NoSQL データベースはGT.Mです。
CAP定理を見てください
編集: RavenDB は ACID に準拠しているようです
db4o
独自の永続性やシリアライゼーションとは異なり、db4o は ACID トランザクションに対して安全であり、実行時にクエリ、レプリケーション、およびスキーマの変更が可能です。
Tarantool は完全な ACID NoSQL データベースです。CRUD 操作またはストアド プロシージャを発行できます。すべてが ACID プロパティに厳密に従って実行されます。ここでもそれについて読むことができます: http://stable.tarantool.org/doc/mpage/data-and-persistence.html
BergDBは、最初から ACID トランザクションを実行するように設計された、軽量でオープンソースの NoSQL データベースです。実際、データベースの状態を変更する唯一の方法は、最高の分離レベル (SQL 用語: 「シリアライズ可能」) で ACID トランザクションを実行することであるという意味で、BergDB はほとんどの SQL データベースよりも「多くの」ACID です。ダーティ リード、繰り返し不可のリード、ファントム リードの問題は発生しません。
私の意見では、データベースは依然として高性能です。しかし、私を信用しないでください。私はソフトウェアを作成しました。代わりに自分で試してください。
待ちは終わりました。
ACID準拠のNoSQLDBがリリースされました----------- citrusleafをご覧ください
最新の NoSQL ソリューションの多くは、ACID トランザクション (アトミックに分離されたマルチキー更新) をサポートしていませんが、それらのほとんどは、アプリケーション レベルでトランザクションを実装できるようにするプリミティブをサポートしています。
データ ストアがキーごとの線形化可能性と比較と設定 (ドキュメント レベルの原子性) をサポートしている場合は、クライアント側のトランザクションを実装するだけで十分です。さらに、いくつかのオプションから選択できます。
Serializable 分離レベルが必要な場合は、Google がPercolatorシステムに使用するアルゴリズムや、Cockroach Labs がCockroachDBに使用するものと同じアルゴリズムに従うことができます。私はそれについてブログを書き、ステップバイステップの視覚化を作成しました。アルゴリズムの背後にある主なアイデアを理解するのに役立つことを願っています.
高い競合が予想されるが、Read Committed 分離レベルで問題ない場合は、Peter Bailis によるRAMP トランザクションを参照してください。
3 番目のアプローチは、saga パターンとも呼ばれる補償トランザクションを使用することです。80 年代後半にSagasの論文で説明されましたが、分散システムの台頭により、より現実的なものになりました。インスピレーションについては、Saga パターンの適用に関する講演をご覧ください。
クライアント側のトランザクションに適したデータ ストアのリストには、軽量トランザクションを備えた Cassandra、一貫性のあるバケットを備えた Riak、RethinkDB、ZooKeeper、Etdc、HBase、DynamoDB、MongoDB などが含まれます。
VoltDBは ACID 準拠を主張する参入者であり、SQL を使用していますが、その目標はスケーラビリティの点で同じです
ノード levelUP はトランザクション対応であり、leveldb で構築されています https://github.com/rvagg/node-levelup#batch
leveldbは単なる組み込みエンジンであり、サーバーではありませんが、leveldbには WriteBatch があり、同期書き込みをオンにして ACID 動作を提供する機能があります。
NoSQLは設計上ACIDに準拠していないだけではありません。NoSQLの動きは、ACIDの反対であると主張されているBASE(基本的に利用可能、ソフト状態、結果整合性)を採用しています。NoSQLデータベースは、最終的に構成されたデータベースと呼ばれることがよくあります。違いを理解するには、CAP定理(別名ブリューワーの定理)にドリルダウンする必要があります
http://www.julianbrowne.com/article/viewer/brewers-cap-theoremにアクセスします