最新のデータベースには、データがリアルタイムで流れるときにデータをキャプチャして反応する能力が必要です。これは、MongoDBがリアルタイムでデータをキャプチャして応答するMongoDBChangeStreamsと呼ばれる機能を備えている理由を説明しています。ストリームの変更は、アプリケーションからデータベースにリアルタイムで情報をストリーミングするために導入された機能です。これは、コレクションを監視し、データベースおよびデータベースコレクションで変更が発生することを可能にする集約フレームワークに基づいています。さらに、MongoDB Change Streamは、IOTセンサーからデータをキャプチャし、企業の運用データの変更などのレポートを更新できます。このブログでは、MongoDB Change Streamに関するディスカッションを開き、本番環境での推奨事項を変更します。
MongoDBのストリームの変更とコレクションの削除
データベースまたはコレクションの名前を変更または削除すると、削除されたコレクションに対して機能する開いている変更ストリームがあった場合、カーソルが閉じます。コレクションの名前を変更または削除すると、FullDocument：updateLookupでカーソルが作成され、任意のルックアップドキュメントでnullが返されます。変更ストリームが実行されているデータベースを削除した後に再開しようとすると、エラーが発生します。
さらに、変更ストリームが実行されているコレクションの名前を変更する前に行われたデータの変更はすべて失われます。変更ストリームのドキュメント制限は16MBBSONのままです。したがって、16MBを超えるドキュメントは受け付けられません。 16MBを超えるドキュメントを処理しようとすると、通知は失敗し、ドキュメントは設定された制限を満たす別のドキュメントに置き換えられます。
変更ストリームが開かれているコレクションまたはデータベースが削除または名前変更されると、変更ストリームカーソルは、oplogのそのポイントに進むときに閉じる傾向があります。ドキュメント全体でストリームカーソルを変更すると、updateLookupオプションが検索ドキュメントにnullを返す場合があります。
したがって、削除されたコレクションに対して変更ストリームを再開しようとすると、エラーが発生します。キャプチャされた変更ストリームの最後のイベントとコレクションドロップイベントの間のコレクションでのデータ変更の発生はすべて失われます。
ストリーム応答ドキュメントの変更は、16MBのBSONドキュメントの制限に準拠する必要があります。変更ストリームを開いているコレクション内のドキュメントのサイズによっては、結果の通知ドキュメントが16 MBを超えると、通知が失敗する場合があります。良い例は、完全に更新されたドキュメントを返すように設定された変更ストリームの更新操作、または制限内または制限をわずかに下回るドキュメントでプロセスを置換/挿入することです。
MongoDB変更ストリームとレプリカセット
MongoDBレプリカセットは、データセットが変更されないMongoDB内のプロセスのコレクションです。つまり、データセットは同じままです。アービターメンバーを持つレプリカセットの場合、データを保持する十分なメンバーが利用できず、大多数が操作をコミットできない場合、変更ストリームはアイドル状態のままになる可能性があります。たとえば、アービターの横に2つのデータ保持ノードを持つ3つのメンバーを持つレプリカセットを検討できます。障害、アップグレード、またはメンテナンスの結果としてセカンダリがダウンした場合、書き込み操作を過半数コミットすることは不可能になります。変更ストリームは開いたままになりますが、通知は送信されません。手元のシナリオでは、アプリケーションが受信した最後の操作がその特定のレプリカセットのoplogにある限り、アプリケーションはダウンタイム中に発生したすべての操作に追いつく可能性があります。さらに、rs.printReplicationInfo（）コマンドを使用してoplogからデータを取得します。取得されるデータには、さまざまな操作とoplogのサイズが含まれます。
アップグレードを実行する場合や災害が発生した場合など、ダウンタイムが大幅に見積もられる場合は、oplogサイズを大きくすることが、より長い期間操作を保持するための最良のオプションになります。おおよそのダウンタイム。 oplogステータス情報を取得するために使用されるコマンドは、printReplicationInfo（）です。このコマンドは、oplogステータス情報だけでなく、oplogサイズと操作の時間範囲も取得します。
MongoDB変更ストリームの可用性
MongoDB変更ストリームは、レプリカセットとシャードクラスターで取得できます。懸念事項の「多数派」の有効化、ストレージエンジン、およびレプリカセットプロトコルのバージョンをお読みください。リードコンサーンの「マジョリティ」の有効化：MongoDBバージョン4.2以降では、「マジョリティ」のリードコンサーンサポートの一般的な状況に関係なく、変更ストリームにアクセスできます。つまり、リードコンサーンのマジョリティサポートを有効または無効にできます。MongoDBバージョン4.0および古いバージョンでは、変更ストリームは、「マジョリティ」読み取り懸念サポートがアクティブ化されている場合にのみ使用できます。
- ストレージエンジン：WiredTigerストレージエンジンは、レプリカセットとシャーディングされたクラスターで使用されるストレージエンジンタイプです。
- レプリカセットプロトコルバージョン：レプリカセットとシャードクラスターは、常にレプリカセットプロトコル（pv1）のバージョン1を使用する必要があります。
MongoDBシャードクラスター
MongoDBのシャードクラスターは、シャード、mongos、および構成サーバーで構成されます。シャードは、シャーディングされたデータのサブセットで構成されます。 MongoDB 3.6の場合、シャードはレプリカセットとして利用されます。 Mongosは、シャーディングされたクラスターとクライアントアプリケーション間のインターフェイスを提供します。 mongosはクエリルーターの役割を果たします。 MongoDBバージョン4.4以降では、mongosはレイテンシーを下げるためにヘッジされた読み取りをサポートしています。構成サーバーは、クラスター構成設定とメタデータの保管場所です。
変更ストリームは、グローバル論理クロックを使用して、シャード全体で変更のグローバル順序を提供します。 MongoDBは、変更の順序が維持され、変更ストリームの通知が受信された順序で安全に解釈されることを保証します。たとえば、3シャードクラスターに対して開かれた変更ストリームのカーソルは、3つのシャードにわたる変更の全順序に関する変更の通知を返します。
変更の全体的な順序を確認するために、Mongosは各シャードをチェックして、変更通知ごとに最近の変更があったかどうかを確認します。収集アクティビティがほとんどまたはまったくない、または「コールド」である1つから複数のシャードを持つシャードクラスターは、変更の全体的な順序を確認するためにモンゴがそれらのコールドシャードをチェックする必要があるため、変更ストリームの応答時間に悪影響を与える可能性があります。この効果は、シャードが地理的に分散している場合、またはほとんどの操作を伴うワークロードがクラスター内のシャードのサブセットで発生する場合に、より明らかになる可能性があります。シャードコレクションのアクティビティが高い場合、モンゴはすべてのシャードの変更を追跡できない可能性があります。この種のコレクションに通知フィルターを使用することを検討してください。たとえば、挿入操作のみをフィルターするように構成された$matchパイプラインを渡します。
シャードコレクションの場合、マルチ：適切な更新操作により、コレクションに対して開かれた変更ストリームが孤立したドキュメントの通知を送信する可能性があります。シャーディングされていないコレクションがシャーディングされてから、変更ストリームが最初の移行チャンクに到達するまで、変更ストリーム通知ドキュメントのdocumentKeyには、ドキュメントIDのみが含まれ、完全なシャードキーは含まれません。
変更ストリームの目的は、アプリケーションのデータ変更をリアルタイムで可能にすることであり、oplogをストーカーするリスクや、複雑さの痕跡を残すことはありません。 MongoDBアプリケーションは、変更ストリームを使用して、データベース、コレクション、またはデプロイメント上のデータ変更に署名し、それらに即座に対応します。変更ストリームは集約フレームワークを利用するため、アプリケーションは特定の変更をフィルタリングし、通知を自分で変換できます。