1

私は mongodb の専門家ではないので、現在のサーバーのセットアップについて少し確信が持てません。

私は、単一のインスタンスで mongo3.0.2 を wiretiger で実行しており、読み取り操作と書き込み操作の両方を受け入れています。クライアントからログを収集するので、書き込み負荷はそこそこあります。1 日に 1 回、このログを処理し、集計フレームワークを使用していくつかのメトリックを計算したいのですが、処理するデータ セットは先月のすべてのログのようなもので、すべての計算に約 5 ～ 6 時間かかります。コレクションのロックを回避するために、書き込みと読み取りを分割することを考えています (サーバーは読み取り中にログを書き込み続けます。新しく書き込まれたログはクエリと一致する可能性がありますが、100% の精度は必要ないためスキップできます) ）。

つまり、レプリケーションが継続的に実行されていないが、すべての読み取り操作が開始される前に、構成された時間またはそれ以上に開始される読み取り用のセカンダリを使用してセットアップを行いたいです。

私はnode.jsからすべての処理を行っているので、ここに表示される1つのオプションは、[昨日、今日]のようなある期間に作成されたデータをエクスポートし、それをインポートして自分でインスタンスを読み取り、インポートが完了した後に計算することです. 可能なセットアップとしてレプリカ セットとマスター/スレーブ レプリケーションを検討していましたが、説明されているシナリオを実現するための構成方法がわかりませんでした。だから多分私は間違っていて、ここで何かを見逃していますか？これを達成するための他のオプションはありますか？

4

1 に答える 1

0

レプリカ セットを使用するというあなたの考えには、いくつかの理由で欠陥があります。

まず、レプリカ セットは常に mongod インスタンス全体を複製します。コレクションの特定のドキュメントだけでなく、個々のコレクションに対して有効にすることはできません。

第 2 に、レポートの生成を開始する前にレプリケーションを無効にして有効にすることもお勧めできません。レプリケーションを有効にしても、新しいスレーブはすぐには最新のものになりません。マスターとの最後の接続以降の変更が処理されるまで、しばらく時間がかかります。これにかかる時間を知る方法はありません (セカンダリを使用し、その日付rs.status()と比較して、セカンダリがプライマリよりどれだけ遅れているかを確認できます)。optimeDatelastHeartbeat

ただし、タイムスパンによって選択されたドキュメントのサブセットに対してデータ マイニングを実行する場合は、別の解決策があります。

分析するドキュメントを新しいコレクションに転送します。これは、先月のドキュメントに一致する $match とそれに続く$outのみで構成される集計パイプラインを使用して実行できます。out-operator は、集約の結果がアプリケーション/シェルに送信されず、代わりに新しいコレクションに書き込まれることを指定します (これが発生する前に自動的に空になります)。その後、実際のコレクションをロックせずに、新しいコレクションでレポートを実行できます。また、はるかに小さなコレクションで操作しているため、特にインデックスを使用できないクエリが高速になるという利点もあります。また、データは集計間で変更されないため、集計間でデータが変更されてもレポートに不整合が生じることはありません。

レポートの生成に 2 台目のサーバーが必要になることが確実な場合でも、レプリケーションを使用して、セカンダリで集計を実行できます。ただし、適切なレプリカ セット(プライマリ、セカンダリ、アービターで構成される) を構築し、レプリケーションを常にアクティブにしておくことを強くお勧めします。これにより、レポートを生成するときにデータが古くなっていないことが保証されるだけでなく、何らかの理由でプライマリがダウンした場合の自動フェイルオーバーの重要な利点も得られます。

于 2015-04-22T20:48:21.910 に答える