コレクションを分けるべきか、一緒にするべきか

株式会社インサイトテクノロジー　西村です。

データストアについてですが、同一種類のデータを、ログ収集

がごとく mongo に集めようとしています。

その時、そのデータを 1 つのコレクションにひたすら入れ続けた

方がいいのか、例えば日毎とかのコレクションにして入れた方が

いいのか悩んでいます。

データとしては、1 ドキュメントが 200-300 バイトで、1 日 150

万件ほどのデータが溜まります。

これをだいたい1-2 週間分ほどは持ちたい。

インデックスも張っているので、データのサイズはさらに大きな

ものになります。

1 つにまとめてしまうと、

・インデックスが全部メモリに乗らなくなる可能性がある

　ー＞インデックスの pagein/out で効率悪い

・データのメンテナンス（過去データ削除 = remove）の

　パフォーマンスが悪い

分けてもつと、

・管理が煩雑になりやすい

とか懸念があるのではと考えているのですが、皆さんはどのように

管理されているでしょうか。

補足：

作成したインデックスは、大体 2-3 GB になっていました。

これ単体であれば、インデックス全てをメモリに展開して

操作はできる大きさなのですが、このようなDB、コレク

ションが数多くあるので、そこが悩みの種と成っています。

全部合わせると、結局、どうやってもメモリに全てを載せ

きることはできないので、もともとパフォーマンスが悪い

と言われればそれまでです。

２週間分のデータ全部で約５GBちょっと、それにインデクス２〜３GBを加えて、約８GBのワーキング、という事ですか？

渡部です。

> そのデータを 1 つのコレクションにひたすら入れ続けた
> 方がいいのか、例えば日毎とかのコレクションにして入れた方が
> いいのか悩んでいます。
それはクエリ次第だと思います。
日ごとに集計したり削除するのであれば、日ごとにコレクションを分けた方が取り回しは楽ですよね。極端な話、クエリが「日ごとの集計」「その日の削除」しかないのであれば、インデックスは不要です。結局コレクションのフルスキャンしかしないので。

また、いまいちわからないのですが、コレクションを分けようが分けまいが、データの総量は変わらないのでインデックスの総量はかわらないですよね(B-Treeの高さは変わりますが)。
なので、
> 1 つにまとめてしまうと、
> ・インデックスが全部メモリに乗らなくなる可能性がある
>　 ー＞インデックスの pagein/out で効率悪いという文章がわからないです。
分けようが分けまいが、クエリが変わらなければ、必要なインデックス量は変わらず、メモリ使用量も変わりません。

データ量を考えると、どうやっても十数GBで収まり、インデックスはおろかデータも全てメモリに載りそうな量に思えます。

あまり考える必要はなさそうです。
何をどうやっても、indexがメモリから溢れる事態にはならないでしょう。

ただremove のやり方によっては面倒な事になりそうですね。

見積もった上でcappedにできれば、removeも心配ありません。

僕ならば、とりあえず、１コレクションに突っ込んでおいて、データ量が膨らむようならば

shardingも視野に入れる形で、プログラムで頑張らずにMongoDBに頑張ってもらいます。

鈴木さん

お世話になります。

そんな感じです。

で、このような DB(コレクション)が、これまた数百とかあります。

渡部さん

そうなんです。

総量としては、分けようが分けまいがそんなに大差はないものと

思います。

クエリの観点からは、ご指摘の通り、日毎、みたいなことを考え

ているので、その点では分けた方がいいのかと考えました。

ただ、日ごとに分けた中から、さらにキーで find していく（全件

検索ではない）ので、そう考えると、分けてもあんまり意味ない

かなー、と。

参考にさせてもらいます。

窪田さん

回答ありがとうございます。

確かに、一つにまとめてある方が、何かと楽（便利）と

思います。今のところ、sharding とか replicate は考えない

方向でシステムを考えているのですが、やっぱり、この辺を

うまく組み合わせる方が無難かもしれません。

＞データ量を考えると、どうやっても十数GBで収まり、インデックスはおろかデータも全てメモリに載りそうな量に思えます。

これ 1 コレクションであれば、十分（なメモリを準備する）なんですが、

このようなものがたくさんあって、それをまとめて処理しようとさせた

場合、総合してメモリとかが足らなくなる状況です。

そもそもデータ量が多いものを考えているので、当然といえば当然のこと

なんですが、そのあたりのメモリ管理部分も含めて、ベストプラクティス

的なものを探っている状態です。

西村 さん；

最近、このプレゼンを日本語訳しました。
http://www.slideshare.net/ippei_suzuki/mongo-db-41967590
シャーディングに関する最近のウェビナーですが、最初の数ページで顧客事例を紹介しており、その規模感も数字で示しています。
いずれもかなり巨大なデータストアをMongoDBで運用してますが、どちらも重要なポイントはデータ構造に着目しているのでは無く、アプリケーションからのデータアクセスパターンが何か、を重要視してデータベース設計を行っている点です。

8GB級のコレクションが数百ある、という事ですが、その上位のアプリでこのデータストアにあるデータすべてがリアルタイムでの検索対象なのでしょうか？想像するには、ある程度データを階層化して整理し、リアルタイムで頻繁にアクセスされるデータグループとそんなにリアルタイムでは無いが、たまには検索対象になるデータ群に大まかに分類する方法論があるのではないでしょうか？

もし、このデータ群、２つ、もしくは３つのグループに分ける事が出来るのであれば、それを分けるためのフィールドを見つける事が出来れば、そのフィールドをシャードキーとして設定し、アクセス頻度の高いシャードは高速IOPSなメモリ搭載のサーバでの運用、アクセス頻度の遅いものはそれなりのサーバ（もしくはクラウド）でディスク運用、という形で最適化する、という方法があると思います。
（アクセス頻度がそんなに高くないデータをわざわざ高額なOn-Memory運用しなくても良いのでは、という考え方です）
シャードキーとして良くあるパターンとしては、データ生成日時、場所、等の要素があると思います。カーディナリティの良いキーを選ぶ事がポイントです。

もし、そういう都合の良いキーが存在しない、という事であれば、データ生成時に何らがのタグ（最重要、重要、普通）を付与して、これをシャードキーにしてデータストアする、という方法もあります。シャード間のデータの移動も時折発生するのであれば、このキーを変える事によってMongoDBは自動的にバックエンドでデータの引っ越しをしてくれるはずです。

ついついRDBの世界の考え方で行くと、最初にデータ構造ありきでシステム設計してしまう傾向があります。これは一つの修正みたいなもので、なかなかこの世界からはなれるのは難しい所です。MongoDBはこの発想を根本的に変えさせてくれる要素があります。アプリケーションがデータをどのようにRead/Writeするのか、どのようにデータを利用するのか、という観点からまず設計を行い、それに最適なデータスキーマ、性能設計、セキュリティ設計、そして容量設計を決めていく、という手段です。

また、もしバックエンドのデータアクセスの頻度の比較的少ないデータがものすごく大量にある、という事であれば、MongoDB+Hadoopという組み合わせも事例がいっぱいあります。こちらのウェビナーも近々日本語化する予定ですので、後ほどご紹介します。北米では特にM2M／IoT関係の導入事例が非常に多く、この組み合わせがいわばデフォルトになっている業界もあります。

最近のスライドはここです。
http://www.mongodb.com/presentations/mongodb-and-hadoop-driving-business-insights
けっこう内容的には面白いので、是非参考にしてみてください。

鈴木いっぺい