AEMを使用したMongoDBのケース

主にMongoDBは、古いCRXクラスター構成に代わるHA構成を提供します。実際には、アーキテクチャは、真のクラスタリングというよりも、NFSまたはNetApp上の共有カタログに似ています。 MongoDBを使用している作成者と発行者は、必ずしもお互いを認識しているわけではありません。

邪魔にならないようにしましょう-CRXクラスタリングには完璧な実績はありません。ローカルのみのオブジェクトカタログに固有の課題の1つは、大規模に、単一のカタログがいくつかの利点を提供することです。

• データの重複を減らす
• パフォーマンス分析とチューニングのための集中スコープ
• マルチノードの相互作用を必要としないHAの可用性
• 冗長性とパフォーマンスのための水平スケーリング

完全に機能するCRXクラスターを使用しても、これらの利点のいずれにも対処できません。昔の共有データ層を入力してください。

5.6.1以前では、大規模で成長しているデプロイメントは、オブジェクトリポジトリを共有NFSとしてマウントでき、プロトコルまたはNFSサーバーは、衝突の少ないマルチ書き込み動作のロックサポートを提供していました。これは依然として実行可能なオプションですが、NetAppを採用しない限り、n*9アーキテクチャを妨げるコントローラーまたはデータ層で単一障害点が発生するリスクがあります。

MongoDBマイクロカーネルのAEM6.xへの導入は、私たちが愛する流行語の多いデータベースと本質的に同じアーキテクチャを提供します。

MongoMKの主なユースケースは、AEM作成者インスタンスの場合です。この場合、アクティブなユーザー制限（〜25-30）は、水平スケーリングが最初に同時実行の問題に対処する必要があることを意味します。ここでは、パフォーマンスがスケーリングと一貫性の2番目のフィドルであると同時に、ノード間の通信の必要性を排除するため、共有データ層が最も輝いています。

同様の方法でサイト運営者に参加することは確かに可能ですが、同時実行性の問題がないため（つまり、より規模を拡大するためにサイト運営者を追加するだけ）、非ローカルカタログのパフォーマンスが低下するため、メリットは減少します。

以上です。無限大以上にスケール！

スローダウン、バズ・ライトイヤー、問題があります。シングルサイトのMongoDBは、高速アクセスデータとインラインネットワーキングのオプションを考慮すると、非常に効果的に拡張できると期待されています。ここでは、空が限界かもしれません。ただし、MongoDBレプリカセットが異なるデータセンターと未知のマイルのファイバー間で通信する必要があるマルチサイト展開を検討してください。操作ログ（oplog）を入力します。

oplogは、レプリカが同期を維持するための仲介者です。基本的に、順番に適用される一連のデルタ操作を提供します。これは、他の特定のデータベースクラスター構成とかなり似ています。

最適化された操作中、MongoDBはドリフトを許可しますが、oplogは可能な限りプライマリでリアルタイムに近い形で実行されます。ただし、マルチサイト運用中は、ワイヤレイテンシと運用レイテンシがスタックしてドリフトが大きくなり、この構成に次の課題が生じる可能性があります。

• oplogは機能的にはコマンドのスタックです。
• 多くのスタックと同様に、先入れ先出しです。
• スタックの動作により、次のプッシュでポップされていないレコードが上書きされると、データが失われます。

MongoDBプログラマーは、再構築後に（新しい）oplogからレプリカ停止、再構築、および同期を行うことで、この状況をキャッチして対処することを選択しました。

表面的には、この操作についてエキゾチックで危険なものは何もありません。最初にrebuild操作を検討します。この操作では、すべてのデータがワイプされてから、既知の正常なプライマリから新しいコピーがプルされます。エクスポートが完了するまでに0秒かかる場合でも、潜在的なワイヤを介したデータボリュームのコピーは、リモートレプリカがインポートを完了する前に、本質的にドリフトを引き起こします。また、ワイヤ遅延が唯一の課題であると想定します。そのため、再構築後、oplogには再構築によって導入されたドリフトのみが含まれます。レプリケーションラグを引き起こした元の問題が残っているため、時間の経過とともに、新しく構築されたセカンダリが再構築を余儀なくされることが予想されます。

場合によっては、この動作はレプリケーションラグと再構築の終わりのないループに入り、リモートセカンダリが機能状態になることはありません。

AEMの場合、これは、クロスサイトオーサリングのプライマリデータソースとしてMongoDBレプリカを使用すると、リモートの作成者が重大なリスクにさらされることを意味します。