MongoDB と CouchDB に関する投稿を読んでいて、MongoDB がデータを失う可能性があることを確認しましたが、CouchDB は何らかの形で安定しており、データを失うことはありません。
Redis と mongodb のユーザーは、既定では、プロセスがクラッシュまたはシャットダウンした場合にデータが失われる可能性があることを知って、少し驚くかもしれません。
http://java.dzone.com/articles/should-i-use-mongodb-couchdb
この問題を MongoDB で解決する方法がありますが、正しく理解できましたか? したがって、CouchDB システムの更新プロセス中に CouchDB がクラッシュしたり、爆弾が爆発したりする場合 => データが失われることはありませんか?
理由を知りたいだけです。CouchDBがErlangで書かれているからでしょうか? それとも、CouchDB が MVCC を使用しているためですか? 何か案は？ありがとうございました
この問題を MongoDB で解決する方法がありますが、正しく理解できましたか? したがって、CouchDB システムの更新プロセス中に CouchDB がクラッシュしたり、爆弾が爆発したりする場合 => データが失われることはありませんか?
CouchDB の仕様についてはよくわかりませんが、Google で簡単に検索すると、デフォルトで CouchDB は実際には結果整合性があることがわかります ( http://guide.couchdb.org/draft/consistency.html、http://en.wikipedia.org/wiki /Eventual_consistency ) ここで、MongoDB は強い一貫性を持っていると説明されています。非 ACID テクノロジ (MongoDB を含む) には、データの完全な耐久性を保証するほとんどのプロパティがありません。つまり、ディスクへの直接書き込みと即時レプリケーションです。
ただし、MongoDB はディスクに直接書き込まないため、データを失う可能性があることを覚えておく必要があります (これが MySQL のような技術者を「遅く」させますが、技術的には SQL 技術者もディスク書き込みの実行方法によってデータを失う可能性があります。電力が供給されていないディスクに書き込むことはできません) しかし、ウィンドウは 60 ミリ秒程度であり、完全に失敗したシナリオでの潜在的な損失のために、コマンドを複数のノードに送信すると、その 60 ミリ秒のウィンドウが発生する可能性があります。データセンターはかなりリモートになるため、MongoDB は への書き込みに似ていません/dev/null。
では、CouchDB はデータを失うことはありませんか? いいえ、できます。
基本的に、あなたが述べたリンクは私には少し偏っているように見え、実際の結果整合性が考慮されていません。おそらく、このビデオで同じ人によって書かれたものです: http://www.youtube.com/watch?v =b2F-DItXtZs
これをテストしたい場合は、サーバーを爆破できます。
MongoDB は、少なくとも 2 つのノードのレプリカ セットでセットアップされるように設計されています。単一ノードの実行は、開発環境でのみ行う必要があります。
レプリカ セットがあり、ノードの 1 つがクラッシュした場合、他のノードはすべてのデータ変更を記録し続けます。クラッシュしたノードが復旧すると、ノードは自動的に同期されます。クラッシュしたノードは、クラッシュする前にディスクに書き込むことができなかったものを含め、他のノードから失われたすべての変更を受け取ります。
異なる物理サーバーで実行される複数のノードのレプリカ セットをセットアップすると、MongoDB は非常に耐久性が高くなります。