この 2 日間、NoSQL、MongoDB、CouchDB などについて読んで学んでいますが、これが自分にとって適切な種類のストレージであるかどうかはまだわかりません。
私が心配しているのは、結果整合性の問題です。そのような一貫性は、クラスターを使用する場合にのみ機能しますか? (私は単一の専用サーバーでサイトをホストしているので、NoSQL の恩恵を受けることができるかどうかはわかりません) (ACID の代わりに) 結果整合性を持つことができるアプリケーションの種類と、そうでないアプリケーションの種類？いくつか例を挙げていただけますか？結果整合性が問題ないアプリケーションで起こりうる最悪の事態は何ですか?
私が読んだもう 1 つのことは、MongoDB が多くのことをメモリに保持しているということです。ドキュメントでは、2 GB のデータ制限を持つ 32 ビット システムについて何か述べています。これは、32 ビット システムの RAM の制限によるものですか?
私は CouchDB についてのみ話すことができますが、結果整合性と ACID のどちらかを選択する必要はありません。それらは同じカテゴリにはありません。
CouchDB は完全に ACID です。ドキュメントの更新は、アトミックで、一貫性があり、分離されており、耐久性があります (CouchDB の推奨される本稼働設定のdelayed_commits=false を使用すると、更新は 201 成功コードが返される前にディスクにフラッシュされます)。CouchDB が提供しないのは、マルチアイテム トランザクションです (アイテムが別々のサーバーに格納されている場合、これらはスケーリングが非常に難しいため)。「トランザクション」と「ACID」の混同は残念ですが、典型的な RDBMS が通常両方をサポートしていることを考えると許されます。
結果整合性は、データベースのレプリカが同じデータ セットに収束する方法に関するものです。従来の RDBMS でのマスター/スレーブ設定を考えてみましょう。その関係の一部の構成では、マスターとスレーブの両方が常にロックステップにあるように、分散トランザクション メカニズムが使用されます。ただし、パフォーマンス上の理由からこれを緩和するのが一般的です。マスターはローカルでトランザクションを作成し、トランザクション ジャーナルを介してスレーブに遅延転送できます。これは「結果整合性」でもあり、ジャーナルが完全に空になると、2 つのサーバーは同じデータ セットに収束します。CouchDB はさらに進んで、マスターとスレーブの区別を取り除きます。つまり、CouchDB サーバーは同等のピアとして扱うことができ、任意のホストで行われた変更が他のホストに正しくレプリケートされます。
結果整合性の秘訣は、異なるホストでの同じアイテムへの更新の処理方法にあります。CouchDB では、これらの個別の更新は同じアイテムの「競合」として検出され、レプリケーションにより、競合するすべての更新がすべてのホストに存在することが保証されます。次に、CouchDB はこれらのいずれかを選択して、現在のリビジョンとして表示します。この選択は、保持したくない競合を削除することで修正できます。
NoSQL データベースは、従来の RDMS では解決が難しい一連の問題を解決します。NoSQL はthe right storage for you、問題がそのセットに含まれている場合に発生する可能性があります。
永続化されたばかりのデータとは異なる/以前のバージョンのデータを読み戻す可能性がある場合、結果整合性が「開始」されます。例えば：
同じデータを複数の場所、たとえば A と B に永続化します。構成によっては、A にのみ永続化した後に永続化操作が返される場合があります (まだ B には永続化されていません)。その直後に、まだ存在しない B からそのデータを読み取ります。最終的にはそこにあるでしょうが、残念ながら読み返すとそうではありません
NOT OK=> あなたは家族の銀行口座を持っていて、100 ドルが利用可能です。今、あなたとあなたの配偶者は、同時に (別の店で) 100 ドルで何かを買おうとしています。銀行がこれを「結果整合性」モデルで実装した場合、たとえば複数のノードで、配偶者は、あなたがすべてを費やした後、数ミリ秒で 100 ドルを費やした可能性があります。銀行にとって良い日とは言えません。
OK=> Twitter で 10000 人のフォロワーがいます。あなたは「今夜、ハッキングをしたい人はいますか?」とツイートしました。100% の一貫性とは、10000 人全員が同時に招待を受け取ることを意味します。しかし、ジョンがあなたのツイートをメアリーが見た 2 秒後に見たとしても、悪いことは何も起こりません。
たとえば、ノード A がデータを取得するときと、ノード B が同じデータを取得するとき (それらは同期している) の間の巨大な遅延。NoSQL ソリューションがしっかりしている場合、それは最悪の事態になる可能性があります。
MongoDB ドキュメントから:
" MongoDB は、Linux、Windows、および OS X で実行されるサーバー プロセスです。32 ビットまたは 64 ビットの両方のアプリケーションとして実行できます。Mongo は合計データ サイズが約32 ビット モードのすべてのデータベースで 2GB。 "
Brewers CAP定理は、利用可能なオプションが何であるかを理解するための最良の情報源です. それはすべて依存していると言えますが、Mongo について話すと、すぐに使用できる水平方向のスケーラビリティが提供され、状況によっては常に優れています。
次に一貫性について。実際には、データを最新の状態に保つための 3 つのオプションがあります。
1）最初に考慮すべきことは、アンドレアスが示す「セーフ」モードまたは「getLastError（）」です。「安全な」書き込みを発行すると、データベースが挿入を受け取り、書き込みを適用したことがわかります。ただし、MongoDB は 60 秒ごとにディスクにフラッシュするだけなので、サーバーはディスクにデータがないと失敗する可能性があります。
2) 次に考慮すべきことは、「ジャーナリング」(v1.8+) です。ジャーナリングをオンにすると、データは 100 ミリ秒ごとにジャーナルにフラッシュされます。したがって、失敗するまでの時間枠が短くなります。ドライバーには、「安全」よりも一歩進んだ「fsync」オプション (名前を確認してください) があり、データがディスク (つまり、ジャーナル ファイル) にフラッシュされたという確認を待ちます。ただし、これは 1 つのサーバーのみを対象としています。サーバーのハード ドライブが故障した場合はどうなりますか? さて、あなたは2番目のコピーが必要です。
3) 考慮すべき 3 番目のことは、レプリケーションです。ドライバーは、戻る前に「このデータを N ノードに複製する」という「W」パラメーターをサポートします。特定のタイムアウトまでに書き込みが「N」ノードに到達しない場合、書き込みは失敗します (例外がスローされます)。ただし、レプリカ セット内のノード数に基づいて "W" を正しく構成する必要があります。繰り返しになりますが、ジャーナリングを使用してもハード ドライブに障害が発生する可能性があるため、レプリケーションを検討する必要があります。次に、ここに入るには長すぎるデータ センター間のレプリケーションがあります。考慮すべき最後のことは、「ロールバック」する必要があることです。私の理解では、MongoDB にはこの「ロールバック」機能がありません。バッチ挿入を行っている場合、どの要素が失敗したかを示すのが最善です。
とにかく、データの一貫性が開発者の責任になるシナリオはたくさんあります。Mongo には、私たちのような「これが正しい方法です」というものがないため、注意してすべてのシナリオを含め、DB スキーマを調整するのはあなた次第です。 RDB-s で使用されます。
メモリについて - これは完全にパフォーマンスの問題です。MongoDB はインデックスと「ワーキング セット」を RAM に保持します。RAM を制限することで、ワーキング セットを制限します。実際には、大量の RAM と HDD ではなく、SSD と少量の RAM を使用できます。少なくとも、これらは公式の推奨事項です。とにかく、この質問は個人的なものです。特定のユース ケースのパフォーマンス テストを行う必要があります。