MongoDBがv4以前にACIDに準拠していないとはどういう意味ですか？
私はデータベースの専門家ではなく、正式なコンピュータサイエンスの経歴もありません。ACIDに準拠していなかったv4より前の古いMongoDBバージョンを使用した場合に発生する可能性のある現実の否定的なことを知りたいのですが。これは、ACIDに準拠していないデータベースに適用されます。 MongoDBはアトミック操作を実行できますが、主にパフォーマンス上の理由により、「従来のロックと複雑なトランザクションをサポート」しないことを理解しています。また、データベーストランザクションの重要性と、データベースが銀行向けであり、すべてを同期する必要のある複数のレコードを更新する場合の例を理解しています。停電により、クレジットは購入と同等になります。 しかし、MongoDBについての会話に入ると、データベースが実際にどのように実装されているかについての技術的な詳細を知らない私たちは、次のようなステートメントを投げかけ始めます。 MongoDBはMySQLやPostgresよりもはるかに高速ですが、100万分の1のように、「正しく保存されない」可能性はわずかです。 「正しく保存されない」という部分は、この理解に言及しています。MongoDBに書き込んでいる瞬間に停電があった場合、特定のレコードが存在する可能性があります（たとえば、10の属性を持つドキュメントのページビューを追跡しているとします）それぞれ）、1つのドキュメントは5つの属性しか保存しませんでした...つまり、時間の経過とともにページビューカウンターが「少し」オフになります。どれだけ正確かは決してわかりません。99.999％正しいことはわかりますが、100％は正しくありません。これは、具体的にこれをmongodbのアトミック操作にしない限り、操作がアトミックであることが保証されないためです。 ですから、私の質問は、MongoDBが「正しく保存」されない場合とその理由の正しい解釈は何ですか？ACIDのどの部分が満足できませんか。また、どのような状況で、0.001％のデータがオフであるかをどのようにして知ることができますか？これはどういうわけか修正できませんか？そうでない場合users、レコードが保存されない可能性があるため、MongoDBにテーブルのようなものを格納してはならないことを意味しているようです。しかし、その場合も、その1 / 1,000,000ユーザーは「もう一度サインアップしてみる」必要があるかもしれません。 MongoDBのようなACID非準拠データベースでネガティブなことが発生するタイミング/理由のリストを探しているだけです。理想的には、標準の回避策（バックグラウンドジョブを実行してデータをクリーンアップするか、SQLだけを使用するなど）がある場合に理想的です。 。