MongoDBのアーキテクチャ例
このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。
このトピックでは、MongoDBをコレクション データベースとして使用してSitecore Experience Database (xDB) をインストールする場合のMongoDB設定の標準的なアプローチの例を示します。この例では、1つのレプリカ セットにMongoDBインスタンスを可能な限り最小限に抑えながら、レプリケーションが確実に実施されるようにします。このセットアップは、プライマリとセカンダリの3つのAzure仮想サーバーで構成されています。
複製
複製
すべての運用デプロイでは、レプリケーションを使用して冗長性を提供し、データの可用性を向上させる必要があります。レプリケーションはデータを複数のサーバーにコピーするため、1つのサーバーに障害が発生してもデータが失われることはありません。サーバーを異なる地理的リージョンに配置し、デフォルトで一方に設定し、もう一方をディザスタリカバリ(DR)または高可用性(HA)フェイルオーバーのバックアップとして使用できます。
優先順位の設定
優先順位の設定
MongoDBの設定方法によっては、各インスタンスに優先度を設定することで読み取り容量を増やすことができます。プライマリは、書き込み操作を受け取ることができるレプリカ セットの唯一のメンバーです。各インスタンスに番号を割り当てることで優先度を設定し、最も大きい数値が最優先されます。
このトピックの例では、優先度10のメンバー (使用可能な場合) が常にプライマリに選出されます。優先度9の他のメンバーはセカンダリになります。アービターがある場合、プライマリになることはないため、優先度の設定はありません(データは保存されず、実際の用途は選挙中の投票のみです)。同様に、優先順位0のデータ・メンバーは1次になることはありませんが、データのコピーを保持し、適切な読み取り設定が使用されている場合は読み取りを処理できます。
プライマリが何らかの理由で使用できなくなった場合、MongoDBは選択を実行して、新しいプライマリになるメンバーを決定します。ゼロ (0) より大きい値を持つメンバーのみが選挙に参加でき、過半数の投票が必要です。
優先度は、たとえば、最も強力なハードウェアを持つノードを優先したり、プライマリ データセンターを優先したりするなど、他にも多くの便利な方法で使用できます。
どのノードがプライマリになるかをより予測しやすくするためだけに優先順位を設定すると、操作がより複雑になる可能性があるため、設定しないでください。この情報は、rs.status()方法を使用して簡単に見つけることができます。
レプリカセット、優先度の設定、および選択の詳細については、MongoDBのドキュメントを参照してください: MongoDBレプリケーション
アーキテクチャの例
アーキテクチャの例
コレクション・データベース (MongoDB) ダイアグラムは、3つのサーバー (3つのデータ・ノード) での標準的なMongoDBレプリカ・セット実装の例を示しています。信頼性と耐障害性のために、特に書き込みに関するw=majorityが使用されている場合 (ロールバックを回避するため)、およびノードの1つが使用できない期間 (メンテナンス、アップグレード、最適化中など) には、3つのデータ ノード (1つのプライマリ、2つのセカンダリ) が必要です。
シャーディング
シャーディング
コレクション データベースが大きくなると、より多くのストレージ領域が必要になることがわかります。また、読み取りと書き込みの速度が遅くなる場合もあります。MongoDBでは、これらの要求に対処するために環境を構成するさまざまな方法があります。シャーディングを使用すると、水平方向にスケーリングできます。これは、データを格納して負荷を分散するためにコンピューターを追加することを意味し、読み取り機能や書き込み速度の向上にも役立ち、一般的なパフォーマンスの向上に貢献します。
MongoDBのインストール、レプリケーション、および使用可能なさまざまな構成オプションの詳細については、MongoDBのWebサイトを参照してください。