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