1

別のボックスに設定されたレプリカで Mongo を実行している実稼働アプリがあります。

おそらくPentahoを使用して、データの BI を開始したいと思います。

私の質問は、実稼働環境で BI を直接実行しないように、アーキテクチャをどのようにセットアップすればよいですか?

別の BI インスタンスを作成し、BI インスタンスに対して mongoexport を実行する必要がありますか?それとも、他のベスト プラクティスに従う必要がありますか?

4

2 に答える 2

3

データ セット、BI 要件、および MongoDB サーバーのバージョンに応じて、考慮すべきオプションがいくつかあります。レポート用にデータを読み取るだけの場合は、データを書き込む場合よりも多くのオプションがあります(例: map/reduce 操作)。MongoDB 2.2 では、以下に示すように、いくつかの非常に便利な機能と改善も導入されています。

一般に、レプリカ セット構成を使用すると、プライマリ MongoDB サーバーを中断することなくデータ セットの完全なコピーを利用できるようになるため、管理目的で非常に役立ちます。より大きなデータ セットと水平方向の書き込みスケーリングの場合、MongoDB のシャーディング機能を以下の提案のいずれかと組み合わせて使用​​することもできます。

BI データの分離に進む前に、ステージング環境でテストして、実際の影響を判断する価値があります。

次のアプローチは、本番環境から分離するための大まかな順序です。

  1. レプリカ セットを使用すると、読み取り設定を使用してクエリを適切なサーバーに送信できます。2.2 より前のバージョンの MongoDB では、一般的な読み取り設定は、プライマリからの読み取りに制限されていました。MongoDB 2.2 では、"secondary" (使用可能な場合はセカンダリから読み取り、そうでない場合はエラー) を含むいくつかの追加の読み取り設定があります。「プライマリ優先」（利用可能な場合はプライマリから読み取り、そうでない場合はセカンダリ）; および「最も近い」(ネットワーク遅延に基づいて最も近いプライマリまたはセカンダリ ノードから読み取る)。MongoDB 2 の読み取り設定。

  2. MongoDB 1.8 以降では、非表示のセカンダリ ノードでレプリカ セットを使用できます。非表示のノードは、通常、レプリカ セットに接続しているクライアントに通知されませんが、レポート生成のために直接接続できます。注: 非表示ノードは読み取り専用のセカンダリになるため、一部のクエリの使用が制限されます。たとえば、map/reduce では出力コレクションに保存するための書き込みアクセスが必要ですが、BI 要件によってはインライン map/reduce を使用できます。

  3. MongoDB 2.2 には、データベース レベルの書き込みロックがあります (グローバルな書き込みロックがあった以前のバージョンからの改善)。BI データを書き込む必要がある場合は、これを別のデータベースに保存して、ロックの競合を最小限に抑えることができます。全体的なリソース効果を考慮する必要があります。たとえば、BI の目的でかなりの数の古いドキュメントを処理すると、運用アプリケーションによってクエリされている最新のドキュメントのキャッシュと競合する可能性があります。

  4. BI データを本番環境から完全に分離したい場合は、MongoDBバックアップ戦略の 1 つを使用して別のインスタンスを作成できます。レプリケーションを有効にしている場合は、レプリカ セットのセカンダリからバックアップを作成できます。データ セットのサイズによっては、完全なmongodump/mongorestoreサイクルよりも、データのスナップショット コピー (既に構築されているインデックスを含む) を実行する方が高速になる可能性があります。

于 2012-09-07T11:34:59.593 に答える