0

インデックス付きフィールドであっても、クエリに一致するコレクション内のレコード数をカウントするには、時間がかかりすぎます。たとえば、10000 レコードで構成されるコレクションがあり、このコレクションの creationDate フィールドにインデックスがあるとします。コレクションから最後の 10 レコードを取得する方が、最終日に作成されたレコード数をカウントするよりも高速です。カウント クエリの結果を返すのに 5 秒以上、場合によっては最大 70 秒かかります。この問題を解決する方法を知っていますか? この問題を解決する最善の方法は何ですか?

ところで、モルフィアも使用していますが、モルフィアを介してカウントを取得するのはさらに遅いことがわかったので、カウント クエリの場合、モルフィア クエリを Java ドライバ クエリに変換します。誰もが同様の状況に遭遇しましたか?モルフィアの応答がさらに遅いのはなぜですか? これは count クエリでのみ発生しますか、それとも Java ドライバーのみを使用する場合に比べて一般的に遅いですか?

ヘルプ、提案、または回避策をいただければ幸いです。私たちのアプリケーションはカウント クエリに大きく依存しており、システムの遅さは現在私たちにとって本当に迷惑です。

前もって感謝します。

4

2 に答える 2

1

これが最終的な答えではないかもしれませんが、始めてこれをさらに進化させましょう。

  1. インデックスは常に RAM に収まる必要があります。そうしないと、パフォーマンスが非常に悪くなります。

  2. RAM の使用量を評価するには、10gen の MMS を使用するか、さまざまなツールで確認します。説明と (常駐) メモリ使用量が少ない理由については、http://www.kchodorow.com/blog/2012/05/10/thursday-5-diagnosing-high-readahead/ を参照してください。または、まだ十分なデータにアクセスしていない場合は、MongoDB の touchを使用できます(ただし、既にパフォーマンスの問題が発生しているため、それは疑わしいです)。

RAM を追加して利用可能なすべての RAM を確実に使用することに加えて、未使用のインデックスを削除するか、可能であれば複合インデックスを使用することもできます。

于 2012-12-28T16:16:21.153 に答える
0

修正を待ちます。

Asya Kamsky がコメントしたように、2.2 ではカウントのパフォーマンスが非常に悪いです。私たちが見つけた唯一の回避策は、それらをできるだけ避けることです。

(集計クエリなど、mongodb で説明できないほど遅いものは他にもあります。それらのほとんどは JIRA の問題に関連しており、現在取り組んでいる/スケジュールされています)

于 2012-12-28T16:30:46.610 に答える