MongoDBの最大サイズに関しての質問です。

[TKC]

初めまして

MongoDB上に、画像やその他ファイルを保存していこうと思っています。

その場合、データベースで扱える最大サイズなどはあるのでしょうか？

またはサーバーの環境に完全に依存するのでしょうか？

また、ファイルがデータベースサイズが大きくなる事でパフォーマンスに影響はあるのでしょうか？

効率的な保存形式などはありますでしょうか？

質問ばかりとなりますが、

よろしくお願いします。

現在のサーバー環境

CentOS 6

cpu 2G

メモリ2G

HDD容量　100G

[Fumikazu Kiyota]

質問のお答えになっているか分かりませんが、
参考までにお返事させて頂きます。

GridFS か BinData があります。

GridFS（http://docs.mongodb.org/manual/core/gridfs/）は、
1 document の制限は 16M ですので、それを超える場合、GridFSに保存する必要があります。
あと、特徴としてメモリーにロードしないので、フロントでプロキシを立てそちらでキャッシュを使ってデータを配信したりすることも考えられます。
ファイルのアップデートなどに関してもGridFSの場合注意するところあります。詳しくは下記にあります。
http://docs.mongodb.org/manual/faq/developers/#faq-developers-when-to-use-gridfs

16Mをこさない場合、BinData も考えられます。
http://docs.mongodb.org/manual/reference/mongodb-extended-json/
私が使い始めたときは対応していなかったと思うので、GridFSを使っています。

また、サーバーの環境設定で注意すべき点は、下記のページで詳しく紹介されています。
http://docs.mongodb.org/manual/administration/production-notes/

マフォーマンス影響を与える箇所について、上部のproduction-notesにまとめて詳しくまとめられているので、参考にしてみるとよいと思います。

プロダクションで利用する際に知っておいた方が良い事を箇条書きでざっとまとめておきます。（production-notesからの抜粋です）
Disk IOやネットワークの帯域やメモリーサイズが結構重要な箇所になると思います。

1. Linux kernel 2.6.36 or later
If you use the Ext4 file system, use at least version 2.6.23 of the
Linux Kernel.
If you use the XFS file system, use at least version 2.6.25 of the Linux Kernel.
If you are using a Red Hat derived distribution, use at least version
2.6.245.el5 of the Linux Kernel.　とのこと
2. atime は必ずoffにする
3. ulimit の設定を必ずする
http://docs.mongodb.org/manual/reference/ulimit/
4. NUMA をdisableにする
6. MongoDB データは Swap に保存されない
7. RAID-10 つかったほうがよいかも
8. monitoring もしっかりやる
例）iostat -xm 2 や bwm-ng やらやってみる
9. 64bit ビルドを使う
10. ドキュメントサイズは16Mまで、わすれないでおこう
11. write concern しっかり押さえよう
12. journaling は大切

以上です。




2013年4月29日 13:29 TKC <loosef...@gmail.com>:

> --
> このメールは Google グループのグループ「MongoDB JP」の登録者に送られています。
> このグループから退会し、メールの受信を停止するには、mongodb-jp+...@googlegroups.com
> にメールを送信します。
> このグループに投稿するには、mongo...@googlegroups.com にメールを送信してください。
> http://groups.google.com/group/mongodb-jp?hl=ja からこのグループにアクセスしてください。
> その他のオプションについては、https://groups.google.com/groups/opt_out にアクセスしてください。
>
>



--
Fumikazu KIYOTA - 清田 史和
kiyotaman@twitter
fumikazu.kiyota@facebook

www: http://snapdi.sh
app: http://snapdi.sh/get-free-app

Vuzz Inc.
t/f:0422-24-6341

180-0005
Gotenyama 1-5-6 NEST 403
Musashino City Tokyo Japan

Access Map: http://4sq.com/xm1OmK

[ryuji tamagawa]

玉川です。

探してみましたが、意外とデータベースやコレクションの最大サイズに関する記述がないですね(--;

http://stackoverflow.com/questions/4327723/mongodb-limit-storage-size

あたりを見ると、一応1TBでもなんとか動くみたいな感じのことが書かれてはいます。

特に気をつけなければいけないのは、

・1つのドキュメントの最大サイズは16MB。これ以上のサイズのデータをひとまとめに扱う場合はGridFSを使う。

・MongoDBの場合、OSが使える物理メモリ上に「ホット」なデータが載るかどうかで、パフォーマンスが大きく変わります。
　CentOSは64bitでしょうか？64bitにして、メモリをたくさん載せるのがまず大事。

といったあたりですかね。
--
玉川竜司@大阪

2013/4/29 TKC <loosef...@gmail.com>

[TKC]

早速のお返事をありがとうございます！！

ユーザーごとのファイルを管理しようと思い。

ファイルサーバーのような使用方法ができればと思っています。

サーバー性能をあげる事で、扱えるデータも増やしていければと思っていました。

事例では1TBまではなんとかとの事でしたが、

やはり、Mongo上でファイルの管理を完結するのは難しいかもしれませんね、

1TB以上のファイルを管理する場合、

ファイルサーバーとその情報を管理するMongoDBといった使いかたが自然なのですかね。

ありがとうございます。

また、気になった記述に

http://blog.wordnik.com/12-months-with-mongodb 

says they're storing 3 TB per node.

とありました。

このper nodeのnodeというのは、

なにを指しているのでしょうか(サーバー？データベース？)？

2013年4月29日月曜日 14時24分13秒 UTC+9 ryuji tamagawa:

といったあたりですかね。
--
玉川竜司@大阪

2013/4/29 TKC <loosef...@gmail.com>

このグループから退会し、メールの受信を停止するには、mongodb-jp+unsubscribe@googlegroups.com にメールを送信します。

[ryuji tamagawa]

ノードというのは、サーバーを指していると思えばいいでしょう。
MongoDBで大規模なデータベースを扱う場合、シャーディングでデータベースを分割しますが、シャード化されたそれぞれのサーバーのことをノードと言います。もちろん、シャード化していないサーバーもノードと呼べないことはないですね（レプリカセットもあるし）。
--
玉川竜司@大阪

2013/4/29 TKC <loosef...@gmail.com>

このグループから退会し、メールの受信を停止するには、mongodb-jp+...@googlegroups.com にメールを送信します。

[Hiroaki Kubota]

窪田と申します。

MongoDBの場合、バージョンにも拠りますが、１ドキュメントのサイズ制限は１６MB迄です。
これ以上大きなファイルはGridFSという仕組みで分割保存する必要があります。

GridFSのファイル制限はありません。

一言でパフォーマンスと言っても色々な観点があり、一概には言えません。
例えば、、
　・１レコード辺りの処理速度
　・バイトサイズ毎のスループット
などなど、、

大きなファイルではスループットの方が重要でしょう。
基本的には数百キロバイト程度のデータならば、スループットは良好で、１レコード辺りの処理速度もそれなりに出ます。

個人的にh最近出た２．４で色々計測していますが（その内公開します）
　数十～数百キロバイト程度のドキュメントがバランスが良いです。
　単にスループットだけなら４MBまでは問題ありませんが、１レコード辺りの速度はかなり落ちます。


個人的にはGridFSをお勧めします。

GridFSの分割単位はデフォルトで256キロバイトで無難な性能が出る域に分割されますし
メタデータに色々な検索要素を盛り込めるので、柔軟に運用できます。

2013年4月29日 13:29 TKC <loosef...@gmail.com>:

初めまして

[Hiroaki Kubota]

みんな早いなぁｗ
書いてる途中にたくさんメールが来ました

2013年4月29日 17:06 Hiroaki Kubota <cat.s...@gmail.com>:

[TKC]

ご返信をありがとうございます。

GridFS、参考にさせて頂きます。

一つのファイルの容量は大きくても5M程度までと考えております。

また、確認したいのが、

Amazon EC2のようなサーバー上で、

MongoDBをファイルサーバーとして運用していった時に、

将来的にどこまでの容量のファイルが保存可能であるかの部分です。

ノード（サーバー）単位で3TBという情報や1TBまで運用が可能といった情報がある事は、

お教え頂きましたが、

公式な情報があったら、今の案件を進めやすいを思いまして、、

なにか確定的なソースがあればそれを指標としていきたとは思っています。

頂いた情報を元にすると、

1TBまではファイルサーバーとしての運用が可能かとは思っています。

ありがとうございます。

2013年4月29日月曜日 17時06分44秒 UTC+9 crumbjp:

このグループから退会し、メールの受信を停止するには、mongodb-jp+unsubscribe@googlegroups.com にメールを送信します。

[Hiroaki Kubota]

MongoDBは64bit版ならば、容量制限は事実上ありません。（mmapによる64bitOSの仮想アドレスサイズ＝16EiB程度）
特にGridFSの場合はシーケンシャルリード処理が多くなり、DBサイズに対するメモリ不足もそれ程気にならないはずです。

ただMongoDBは上手く使わないと、データサイズ以上のストレージサイズを使ってしまいガチです。
それで無くともEC2の場合はEBSのお値段が高めなので、いい値段になるかと思います。

参考までにSAKURA VPS 2G では
　1. 4MBのドキュメントを1万件入れるのには20分弱掛かります。
　2. 400KBのドキュメントを10万件入れるのは17分程度です。
　3. 400KBのドキュメントを250件ランダムに引くのに100秒程度。（ワーストケース）
  4. シーケンシャルリードの場合はその約１０倍
　5. （高頻度データなど）オンメモリーのデータの場合は更に速くなります。

　GridFSの場合は3. 4. 5. の辺りになるでしょう。

2013年4月29日 18:52 TKC <loosef...@gmail.com>:

このグループから退会し、メールの受信を停止するには、mongodb-jp+...@googlegroups.com にメールを送信します。

[TKC]

ありがとうございます。

大変参考になりました！

2013年4月29日月曜日 20時34分46秒 UTC+9 crumbjp: