3

OK、MongoDBの専門家、私のコレクションを見てください：

[{
  "_id" : "item_0",
  "Name" : "Item 0",
  "Description" : "Some description for this item...",
  "Properties" : {
    "a" : 5.0,
    "b" : 0.0,
    "c" : 6.0,
    "d" : 6.0,
    "e" : 2.0,
    "f" : 0.0,
    "g" : 9.0,
    "h" : 3.0,
    "i" : 4.0,
    "j" : 5.0
  }
},
{ // 5.000-10.000 more items... }
]

この集計を使用して、選択したプロパティのセット（この場合はa、b、c、d）を乗算し、それらを積で並べ替えています。

{
    "aggregate": "item",
    "pipeline": [
        {
            "$project": {
                "_id": 1,
                "Name": 1,
                "s": {
                    "$multiply": [
                        "$Properties.a",
                        "$Properties.b",
                        "$Properties.c",
                        "$Properties.d"
                    ]
                }
            }
        },
        {
            "$sort": {
                "s": -1
            }
        },
        {
            "$limit": 100
        }
    ]
}

これで問題なく動作しますが、アイテムとプロパティの数が増えると、集計の実行時間が大幅に長くなります。

このようなことを達成するためのより良い方法（より効率的な）はありますか？最高の製品（プロパティのセットの複数）の検索は迅速でなければなりません。プロパティのすべての異なる組み合わせを使用してこれにインデックスを付け、それらをキャッシュする方法がある場合はどうでしょうか。クエリが高速である限り、インデックス作成に時間がかかることは問題ありません。

この件に関してご協力いただきありがとうございます。ありがとうございました。

4

1 に答える 1

4

より高速な検索と効率に対する要件を考えると、より良いアプローチは、出力コレクションで Map/Reduce を使用することだと思います (少なくとも、Aggregation Framework が出力用のコレクションの使用をサポートするまでは)。

ユースケースで出力コレクションを使用することには、いくつかの利点があります。

特に：

  • 柔軟なインデックス作成とソートを行うことができます
  • クエリごとに結果をリアルタイムで計算する必要はありません
  • インライン結果の 16Mb BSON ドキュメント サイズに制限されない

mergeMap/Reduce の出力オプションを使用して、出力コレクションの計算を更新できます (基本的に、これはキャッシュになります)。

さまざまなプロパティが更新される頻度に応じて、「最終更新」タイムスタンプまたは値をいつ再計算する必要があるかを判断できるその他の基準に基づいて、増分アプローチを調査します。これにより、コレクションが大きくなっても、バッチ サイズを管理しやすくすることができます。

于 2012-08-23T11:11:29.703 に答える