NoSQL（MongoDB）でのコミットとディスクの永続性

このミームはどこから来たのだろうか。まず、何も すべてのキャッシングレイヤーがあるため、実際のHDDに何かが書き込まれることが実際に保証されます。従来のRDBMSでさえ、常にファイルに書き込もうとはしません。そうしないと、それほど高速ではありませんが、詳細は大きく異なります（を参照してください）。例InnoDBでのアダプティブフラッシング 。

データベースがディスクに書き込もうとするときの本質的な問題である最初の層だけに関心を持つ必要があります。これで、最初のキャッシュレイヤーができました。実際のテーブル/コレクションに書き込む代わりに、多くのDB（MongoDBを含む）はジャーナリングを使用します。実際のデータファイルに定期的にマージされる追加専用ファイルに書き込みます。何が落ちてもジャーナルに載っていれば大丈夫です。

ここで問題となるのは、ジャーナルに書き込みたいかどうか、そしてそれをどのように行うかです。 MongoDBでは、書き込みの懸念 を使用してこれを制御できます。 つまり、MongoDBが特定の書き込み（またはすべての書き込み）のためにジャーナルに書き込むまで、アプリケーションコードを待機させることができます。 MongoDBでは、ジャーナルとデータファイルが異なるブロックデバイス上にある場合、デフォルト構成でジャーナルコミットの待機に最大10ミリ秒かかり、同じブロックデバイス上にある場合は33ミリ秒かかります。 journalCommitInternval 必要に応じて変更することもできます。

別の回答で、MongoDBのジャーナリングに関する詳細を収集しました 。

ちなみに、耐久性はトランザクションとはあまり関係がありません。トランザクションは、分離と一貫性を提供します。一度に複数のものを変更することができ、読者は新しい状態または古い状態のいずれかを取得することが保証されますが、中間の状態は取得できません。つまり、トランザクションセーフデータベースは、ディスクにまったく書き込みを行わないインメモリデータベースである可能性があります。