mongodb - GridFS はファイル名をインデックスとして使用します

Question

私は現在、レプリカセットと GridFS を使用して、mongoDB を使用した「単純な」写真システムに取り組んでいます。

原理は簡単です。GridFS を使用して多くの写真を配置し、クライアントはファイル名を認識し、ファイル名からファイルを取得できます。

GridFS はファイル名をインデックスとして使用していますか? はい、うまくいけば、公式ドキュメントに書き留められていませんでした。

私の統計は次のとおりです。

     {
        "ns" : "photos.socialphotos.files",
        "count" : 758086,
        "size" : 168295128,
        "avgObjSize" : 222.00004748801587,
        "storageSize" : 220647424,
        "numExtents" : 15,
        "nindexes" : 2,
        "lastExtentSize" : 43311104,
        "paddingFactor" : 1,
        "flags" : 1,
        "totalIndexSize" : 125084624,
        "indexSizes" : {
            "_id_" : 22925504,
            "filename_1_uploadDate_1" : 102159120
        },
        "ok" : 1
    }

編集: reIndex() コレクションによって、私は 30 Go を獲得しましたが、それでも高すぎます..

私のインデックスは次のとおりです。

{
    "v" : 1,
    "key" : {
        "_id" : 1
    },
    "ns" : "photos.socialphotos.files",
    "name" : "_id_"
},
{
    "v" : 1,
    "key" : {
        "filename" : 1,
        "uploadDate" : 1
    },
    "ns" : "photos.socialphotos.files",
    "name" : "filename_1_uploadDate_1"
}

索引サイズ:

"keysPerIndex" : {
    "photos.socialphotos.files.$_id_" : 758086,
    "photos.socialphotos.files.$filename_1_uploadDate_1" : 758086
}

保管していないので一度も使っ_id_ていませんが、外しても大丈夫ですか？インデックスサイズは 125084624 です。これは、ほとんどすべての写真を RAM に保存する必要があることを意味しますが、これは少し奇妙です。

追加の質問:

統計 : mongostats が基本です。監視用の別の優れたツールはありますか、それとも独自のツールを作成する必要がありますか?
障害 : 大量の挿入を行っているときに、LOT (1 秒あたり約 100) が表示されることがあります。コンソールには何もありません...どこを調査すればよいですか?
JAVA/Tomcat を使用した接続プール: 私は MongoDB への単純な Tomcat webapp 接続を使用しています。リクエストごとに mongoDB への新しい接続を開くことをお勧めしますか (私はそうではないと思います)、または参照を Mongo オブジェクトのシングルトンとして保持することをお勧めします (たとえば、ホルダーを使用するか、適切なプールを使用しますが、標準のプールが見つかりませんでしたか?

どうもありがとうございました！

score 4 · Accepted Answer

質問に対処するには:

1) Java ドライバーを使用して GridFS コレクションを初期化すると、そのドライバーは .files および .chunks コレクションにインデックスを自動的に作成します。

2) MongoDB では、'_id' フィールドと一意の '_id' インデックスが必要です。デフォルトの '_id' の長さはわずか 12 バイトです。これを使用しても大きなオーバーヘッドはありません。

参照: http://www.mongodb.org/display/DOCS/Object+IDs

3) 「filename_1_uploadDate_1」インデックスの統計は、インデックスのサイズのみを示します。このインデックスには、ファイル名とアップロードデータフィールドの内容のみが含まれます。写真データ自体は含まれません。パフォーマンス上の理由から、インデックスのアクティブな部分を RAM に収めたい場合。

参考文献:

4) 高度な統計と監視が必要な場合は、10gen が提供する無料の MMS 監視システムにシステムを登録してください。詳細については、こちらから始めてください: https://mms.10gen.com/help/

5) 新しいデータをロードするとき、ページフォールトは正常です。MongoDB はメモリマップトファイルを使用するため、データファイル内の新しい場所に書き込むたびに、OS はそのページでフォールトする必要があります。

メモリマップファイルの詳細については、http: //docs.mongodb.org/manual/faq/storage/を参照してください。

6) MongoDB Java ドライバーは、独自の接続プールを提供します。非常に高性能なアプリケーションを実行しているのでない限り、おそらく Mongo オブジェクトをシングルトンとして使用するのが最善でしょう。

score 2 · Accepted Answer

各「通常の」ドキュメントに_idフィールドが必要なようです：

http

：//www.mongodb.org/display/DOCS/Object+IDs 生成方法を指定しない場合、MongoDBは次を使用して自動生成しますBsonObjectIdデータ型であり、その上にインデックスを自動的に作成します。これは、Mongoがこのフィールドの一意性を確信しているためです。しかし、それを使用したくない場合は、あなたの場合のように、filename + dateuploadを_idフィールドに入れて、Mongoにそのインデックスを処理させることができます

。 _idのインデックスのサイズ。あなたの写真の合計サイズははるかに大きいかもしれません..RAMの125MBは私には無害に見えます。
障害をより適切に調査する方法はわかりませんが、64ビットを使用していると想定しています。32ビットの場合、DBサイズは2GBに制限されます。挿入はその前のある時点で失敗し始めます。

とにかく、接続に関しては、いくつかのリクエストで、1回は個別の接続で、もう1回はシングルトンでテストしてみてください。シングルトンの方がパフォーマンスが良いと思います。パフォーマンスをテストしたり、負荷テストを実行したりするには、Jmeterを使用できます：http：

//jmeter.apache.org/

mongodb - GridFS はファイル名をインデックスとして使用します

2 に答える 2

Related

Reference