2

大規模なデータベースの展開に苦労しています。3 つのシャード クラスターをデプロイし、データのインデックス作成を開始しました。しかし、それから 16 日経ちましたが、まだ道半ばです。

質問は、すべてのデータをシャードされていないクラスターにインポートし、生​​データがデータベースに入ったらシャーディングをアクティブにしてから、さらにクラスターをアタッチしてインデックス作成を開始する必要がありますか? これは私のデータを自動的に調整しますか?

または、現在使用している方法については、さらに 16 日間待つ必要があります...

*編集: ここでは、セットアップとインポートされているデータの詳細について説明します...

このような 1 億 6000 万のドキュメントがあります

"_id" : ObjectId("5146ae7de4b0d58a864bcfda"),
"subject" : "<concept/resource/propert/122322xyz>",
"predicate" : "<concept/property/os/123ABCDXZYZ>",
"object" : "<http://host/uri_to_object_abcdy>"

インデックス: 主語、述語、目的語、主語 > 述語、目的語 > 述語 シャード キー: 主語、述語、目的語

セットアップ: AWS 上の 3 つのクラスター (それぞれに 3 つのレプリカ セットがある)、各ノードには 8 GiB RAM があります (構成サーバーは各クラスター内にあり、Mongos は別のサーバーにあります)。

データは Java プログラムによって Mongos にインポートされます。このデータ、インデックス、およびシャードをインポートする理想的な方法は何でしょうか。（プロセスが完了するのを1か月待たずに）

4

1 に答える 1

1

大規模な一括挿入を行う場合は、多くの場合、インデックスなしで挿入を実行してからコレクションのインデックスを作成する方が高速です。これは、Mongo がオンザフライでインデックスの更新を管理する方法に関係しています。

また、MongoDB は、インデックスを作成するときに特にメモリに敏感です。のインデックスのサイズを確認db.stats()し、DB をMongo Monitoring Serviceに接続します。

私の経験では、MongoDB に予想よりも多くの時間がかかる場合は常に、次の 2 つのいずれかが原因です。

  1. 物理メモリが不足しているか、貧弱な I/O パターンに陥っています。MMS は両方の診断に役立ちます。特にページ フォールトのグラフを確認してください。

  2. あなたの場合には当てはまりません。

于 2013-04-08T03:06:42.957 に答える