会話をサポートするためだけに回答として投稿します- Tim Mahy 、 nawroth 、および CraigTP は実行可能なデータベースを提案しています。 CouchDB は Erlang を使用しているため、好まれますが、他にもあります。
ACIDは、NoSQL ...の概念と矛盾も否定もしません。 dove 、私は概念が異なると主張します。
NoSQLは、基本的に、単純なキー値（Redisなど）またはドキュメントスタイルのスキーマ（MongoDBなどの "ドキュメント"モデルで収集されたキー値ペア）について、古典的な明示的なスキーマの直接の代替手段としてRDBMS。開発者はthingsを非対称的に扱うことができますが、従来のエンジンはデータモデル全体で剛体same-nessを適用していました。これが非常に興味深い理由は、変更に対処する別の方法を提供するためです。また、より大きなデータセットに対しては、ボリュームとパフォーマンスに対処する興味深い機会を提供するためです。
ACIDは、データベースへの変更の適用方法を管理する原則を提供します。非常に単純化された方法で、それは（私自身のバージョン）と述べています：
- （A）データベースを変更するために何かをするとき、変更は全体として機能するか失敗するはずです
- （C）データベースは一貫性を保つ必要があります（これはかなり広範なトピックです）
- （I）他のことが同時に進行している場合、更新の途中でそれらを見ることができないはずです
- （D）システムが破裂した場合（ハードウェアまたはソフトウェア）、データベースは自身をバックアップできる必要があります。更新プログラムの適用が終了したと表示された場合は、確実にする必要があります
伝播と制約 の概念になると、会話は少し興奮します。一部のRDBMSエンジンは、伝播要素（acascade）を含む可能性のある制約（外部キーなど）を強制する機能を提供します。簡単に言えば、ある「もの」はデータベース内の別の「もの」と関係がある場合があり、一方の属性を変更する場合、他方の変更（更新、削除、...多数のオプション）が必要になる場合があります。 NoSQLデータベースは、主に（現時点では）大量のデータとトラフィックに重点を置いており、（消費者の観点から）任意の時間枠内で行われる分散更新のアイデアに取り組んでいるようです。これは基本的に replicationtransaction で管理される特殊な形式です。したがって、従来の分散データベースがACIDをサポートできれば、NoSQLデータベースもサポートできます。
さらに読むためのリソース：
UPDATE（2012年7月27日）：ウィキペディアの記事へのリンクは、この回答が投稿されたときに最新であった記事のバージョンを反映するように更新されました。 現在のウィキペディアの記事 は大幅に改訂されていることに注意してください！
さて、 Wikipedia NoSQLの記事 の古いバージョンによると：
NoSQLは、リレーショナルデータベースの長い歴史とACIDの保証で壊れる、緩やかに定義された非リレーショナルデータストアのクラスを推進する動きです。
また：
この名前は、ACIDの保証を提供しないことが多い非リレーショナルの分散データストアの増加を説明する試みでした。
そして
NoSQLシステムは、補助ミドルウェアレイヤーを追加することで完全なACID保証を課すことができますが、結果整合性や単一のデータ項目に制限されたトランザクションなどの弱い一貫性保証を提供します。
簡単に言うと、「NoSQL」データストアの主な利点の1つは、 ACID プロパティの明確な欠如です。さらに、私見では、 ACID プロパティを実装および適用しようとすればするほど、「NoSQL」データストアの「精神」から離れ、「true」に近づきます RDBMS を取得します（もちろん、比較的言えます）。
ただし、「NoSQL」は非常に曖昧な用語であり、個々の解釈に対して開かれており、純粋主義的な視点の程度に大きく依存しています。たとえば、ほとんどの現代のRDBMSシステムは、実際に Edgar F. Codd の 12ルール の 関係モデル のallに準拠していません_！
実用的なアプローチをとると、Apacheの CouchDB が、疎結合の非リレーショナル「NoSQL」メンタリティを維持しながら、ACID準拠の両方を具体化することに最も近いように見えます。
FoundationDBはACIDに準拠しています。
適切なトランザクションがあるため、複数の異なるデータ項目をACID方式で更新できます。これは、上位層でインデックスを維持するための基盤として使用されます。
この質問では、誰かが言及する必要があります OrientDB ：OrientDBはNoSQLデータベースであり、ACIDトランザクションを完全にサポートする数少ないデータベースの1つです。 ACIDは、リレーショナル代数の一部ではないため、RDBMS専用ではありません。したがって、ISは、ACIDをサポートするNoSQLデータベースを持つことができます。
この機能は、MongoDBで最も見逃している機能です
NoSQLデータベースに関するMartin Fowlerの紹介を読んでください を確認してください。そして、対応するビデオ。
まず、2種類のNoSQLデータベースを区別できます。
- 集約指向のデータベース。
- グラフ指向データベース（Neo4Jなど）。
設計上、ほとんどのグラフ指向データベースはACIDです！
それでは、他のタイプはどうですか？
集約指向のデータベースでは、3つのサブタイプを配置できます。
- ドキュメントベースのNoSQLデータベース（MongoDB、CouchDBなど）;
- キー/値NoSQLデータベース（Redisなど）;
- 列ファミリNoSQLデータベース（例：Hibase、Cassandra）。
ここでAggregateと呼ぶものは、Eric Evansが Domain-Driven Design でエンティティの自給自足として定義したものです指定された境界コンテキスト内の値オブジェクト。
結果として、集合体は、ユニットとして対話するデータのコレクションです。集計は、データベースとのACID操作の境界を形成します。 （マーティン・ファウラー）
したがって、集計レベルでは、ほとんどのNoSQLデータベースは適切な設定でACID RDBMSと同じくらい安全であると言えます。ソースのうち、サーバーを最適な速度に調整すると、ACID以外の何かが発生する可能性があります。しかし、複製は役立ちます。
私の主なポイントは、RDBMSの（安価な）代替としてではなく、NoSQLデータベースをそのまま使用する必要があるということです。私はドキュメント間の関係を乱用するプロジェクトを見すぎました。これはACIDにはできません。ドキュメントレベル、つまり集計境界にとどまる場合、トランザクションは必要ありません。そして、あなたのデータはACIDデータベースと同じくらい安全です。たとえそれが本当にACIDでなくても、それらのトランザクションは必要ないからです！トランザクションが必要で、複数の「ドキュメント」を一度に更新する場合は、NoSQLの世界にはもういません。代わりにRDBMSエンジンを使用してください。
2019更新：バージョン4.0以降、複数のドキュメントの更新または複数のドキュメントの読み取りの一貫性に原子性が必要な状況のために、MongoDBは レプリカセットのマルチドキュメントトランザクション を提供します。
ACIDとNoSQLは完全に直交しています。一方は他方を意味しません。
私は机の上にノートブックを持っています。私はそれを使ってまだしなければならないことのメモを取ります。このノートブックはNoSQLデータベースです。 「ページキャッシュ」を使用した線形検索を使用してクエリを実行するため、常にすべてのページを検索する必要はありません。また、ACIDに準拠しています。これは、一度に1つのことだけを記述し、読んでいる間は決して書かないようにするためです。
NoSQLは、単にSQLではないことを意味します。多くの人々は混乱し、それは非常にスケーラブルな野生の西の超高速ストレージを意味すると思います。そうではありません。キーと値のストア、または最終的な一貫性を意味するものではありません。 「SQLではない」ということだけです。この惑星には多くのデータベースがあり、それらのほとんどはSQLではありません[引用が必要]。
他の回答で多くの例を見つけることができるので、ここにそれらをリストする必要はありませんが、さまざまな操作でACID準拠の非SQLデータベースがあり、一部は単一オブジェクト書き込み用のACIDであり、一部ははるかに保証されています。各データベースは異なります。
「NoSQL」は明確に定義された用語ではありません。これは非常に曖昧な概念です。そのため、「NoSQL」製品とは何か、何でないかを言うことすらできません。通常、このラベルでブランド化されている製品のほとんどがキーバリューストアではありません。
はい、MarkLogicサーバーは、ACIDトランザクションで動作するNoSQLソリューション（ドキュメントデータベースと呼んでいます）です。
NoSQLの祖父：ZODBはACIDに準拠しています。 http://www.zodb.org/
ただし、Pythonのみです。
ACID準拠のキー/値ストアを探している場合は、 Berkeley DB があります。 グラフデータベース 少なくとも Neo4j および HyperGraphDB ACIDトランザクションを提供します（HyperGraphDBは現在、低レベルストレージにBerkeley DBを使用しています）。
NoSQLの創始者の1人として（私はApache CouchDBの初期の貢献者であり、2009年にCBS Interactive/CNETで開催された 最初のNoSQLイベント の講演者でした）これまで存在しなかった可能性。 The Calvin protocol は、CAPや PACELC などの物理的制約を考える新しい方法を提供します。
アクティブ/パッシブ非同期レプリケーションまたはアクティブ/アクティブ同期レプリケーションの代わりに、Calvinは RAFTのようなプロトコル を使用してトランザクションログを維持することにより、レプリカの停止中に正確さと可用性を維持します。さらに、各レプリカで トランザクションは確定的に処理されます により、デッドロックの可能性が排除されるため、合意は1回のコンセンサスのみで達成されます。これにより、世界中のマルチクラウド展開でも高速になります。
FaunaDB は、Calvinプロトコルを使用する唯一のデータベース実装であり、NoSQLの拡張性と柔軟性を備えたメインフレームのようなデータ整合性を必要とするワークロードに特に適しています。
MongoDBは、4.0バージョンがマルチドキュメントトランザクションに対してACIDに準拠することを発表しました。
バージョン4.2。シャード設定でそれをサポートすることになっています。
https://www.mongodb.com/blog/post/multi-document-transactions-in-mongodb
NewSQL
この概念 ウィキペディアの貢献者 定義：
[…]従来のデータベースシステムのACID保証を維持しながら、オンライントランザクション処理（OLTP）の読み取り/書き込みワークロードに対してNoSQLシステムと同じスケーラブルなパフォーマンスを提供しようとする最新のリレーショナルデータベース管理システムのクラス。
[1][2][3]
参照資料
[1]ナンシーリンチとセスギルバート、 「ブリューワーの推測と一貫性のある、利用可能なパーティショントレラントWebサービスの実現可能性」 、ACM SIGACT News、Vol。33 Issue 2（2002）、pg。 51-59。
[2]"Brewer's CAP Theorem" 、julianbrowne.com、Retrieved 02-Mar-2010
[3]"分散システムでのブリューワーズCAP定理" 、royans.net
FoundationDBが言及されましたが、当時はオープンソースではありませんでした。 Appleによって2日前にオープンソース化されました： https://www.foundationdb.org/blog/foundationdb-is-open-source/
ACIDに準拠していると思います。
代替のリストに追加するには、ACIDに完全に準拠した別のNoSQLデータベースが GT.M です。
Hyperdex Warp http://hyperdex.org/warp/ Warp（ACID機能）は独自仕様ですが、Hyperdexは無料です。
cAP定理を見てみましょう
編集：RavenDBはACIDに準拠しているようです
db4o
Roll-your-ownパーシステンスまたはシリアル化とは異なり、db4oはACIDトランザクションセーフであり、実行中のクエリ、レプリケーション、およびスキーマの変更を可能にします
Tarantoolは完全にACID NoSQLデータベースです。 CRUD操作またはストアドプロシージャを発行できます。すべてがACIDプロパティに厳密に従って実行されます。これについては、こちらでも読むことができます。 http://stable.tarantool.org/doc/mpage/data-and-persistence.html
MarkLogicもACIDに準拠しています。私は今、最大のプレーヤーの一人だと思います。
YugaByte DB は、 ACID準拠の分散txns をサポートし、クエリレイヤーでのRedisおよびCQL APIの互換性もサポートします。
最新のNoSQLソリューションの多くは、ACIDトランザクション（独立した複数キーの更新）をサポートしていませんが、それらのほとんどは、アプリケーションレベルでトランザクションを実装できるプリミティブをサポートしています。
データストアがキーごとの線形化と比較と設定（ドキュメントレベルの原子性）をサポートしている場合は、クライアント側のトランザクションを実装するだけで十分です。さらに、いくつかのオプションから選択できます。
Serializable分離レベルが必要な場合は、Googleが Percolator システムに使用するのと同じアルゴリズム、または CockroachDB にCockroach Labsを使用できます。私はそれについてブログに書いて、 ステップバイステップの視覚化 を作成しました。アルゴリズムの背後にある主要なアイデアを理解するのに役立つことを願っています。
高い競合が予想されるものの、Read Committed分離レベルを設定して問題ない場合は、Peter Bailisによる RAMPトランザクション をご覧ください。
3番目のアプローチは、サガパターンとも呼ばれる補正トランザクションを使用することです。それは Sagas の論文で80年代後半に記述されましたが、分散システムの登場によってより現実的になりました。 佐賀パターンの適用 インスピレーションについての話を参照してください。
クライアント側のトランザクションに適したデータストアのリストには、軽量トランザクションのCassandra、一貫性のあるバケットのRiak、RethinkDB、ZooKeeper、Etdc、HBase、DynamoDB、MongoDBなどが含まれます。
待ちました。
ACID準拠のNoSQL DBがリリースされました-----------をご覧ください citrusleaf
BergDB は、ACIDトランザクションを実行するために最初から設計された、軽量でオープンソースのNoSQLデータベースです。実際、BergDBは、データベースの状態を変更する唯一の方法がACIDトランザクションを実行するという意味で、ほとんどのSQLデータベースよりも「より多く」のACIDです。最高の分離レベル（SQL用語：「シリアライズ可能」）。ダーティリード、繰り返し不可のリード、ファントムリードの問題はありません。
私の意見では、データベースは依然として非常に高性能です。しかし、私を信じないで、私はソフトウェアを作成しました。代わりに自分で試してください。
onlyサーバーではなく組み込みエンジンですが、 leveldb にはWriteBatchがあり、同期書き込みを有効にしてACIDを提供します動作。
ノードlevelUPはトランザクションであり、leveldb上に構築されます https://github.com/rvagg/node-levelup#batch
VoltDB はACID準拠を主張する参加者であり、SQLを使用している間、その目標はスケーラビリティの点で同じです。
DynamoDBはNoSQLデータベースであり、 ACIDトランザクション があります。