イベントストアにイベントを保存する場合、特にイベントを後で投影してエンティティの現在の状態を復元する場合は、イベントが保存される順序が非常に重要です。
MongoDBは、その速度とflexibelスキーマを考えると、イベントストアを永続化するのに適しているようですが（多くの場合、そのように推奨されます）、MongoDBにはトランザクションなどがないため、正しいイベントの順序を保証できません。
その事実を考えると、一貫性のあるイベントストアを探している場合は、MongoDBを使用するのではなく、従来のRDMSを使用する必要がありますか、それともこの問題を回避する方法がありますか？
「イベント ストア」という用語を使用しているため、私はよく知りませんが、質問のいくつかの問題に対処できます。少し注意して、MongoDB を必要に応じて使用することはおそらく合理的だと思います。
MongoDB では、各ドキュメントには_id、デフォルトでObjectIdフォーマットされているフィールドがあり、サーバー識別子、タイムスタンプ、シーケンス カウンターで構成されます。ObjectIdしたがって、そのフィールドで並べ替えると、オブジェクトがすべて同じマシンで作成されている場合、オブジェクトを作成順に取得できます。
ほとんどの MongoDB クライアント ドライバーは_id、挿入コマンドをデータベースに送信する前にフィールドをローカルに作成します。したがって、複数のクライアントがデータベースに接続している_id場合、最初にサーバーハッシュでソートされるため、ソートは希望どおりにはなりませんが、これは望んでいるものではありません。
ただし、MongoDB クライアント ドライバーに挿入コマンドに を含めないように説得できれば_id、サーバーは各ドキュメントの ObjectId を生成し、必要なプロパティを取得します。各言語には独自のクライアント ドライバーがあるため、これを行う方法は作業している言語によって異なります。ドライバーのドキュメントを注意深く読むか、ソース コードに飛び込んでください。これらはすべてオープン ソースです。ほとんどのドライバーには、生のコマンドをサーバーに送信する方法も含まれています。したがって、insert手動でコマンドを作成すると、これにより、必要なことを確実に行うことができます。
システムが非常に大規模で、単一のデータベース サーバーがすべての書き込みトラフィックを処理できない場合、これは機能しなくなります。毎秒数千のレコードを書き込む必要がある場合の MongoDB ソリューションは、シャード データベースをセットアップすることです。この場合、ObjectIds は別のマシンによって再び作成され、必要な優れた並べ替えプロパティがありません。書き込み用に 1 台のサーバーを拡張することを懸念している場合は、分散シーケンス番号を提供する別のテクノロジを検討する必要があります。