こんにちはゲストさん。会員登録(無料)して質問・回答してみよう!

解決済みの質問

巨大なデータに対する検索に適したデータベース

巨大なデータベースに対する検索をなるべく高速にこなせるフリーのデータベースを探しています(windows)。
これまでmySQL5.5を使って比較的簡単なデータ検索を行ってきました。
データ構造自体は簡単で例えば下記のように
name[char] / weight_gram[int] / country [char]
数桁のintと十数文字の文字列情報をもつエントリーで構成されるテーブルとします。
ただ問題がデータの量で、ある事情で10-100億件のエントリー(rows)があり、そのせいで単純なクエリー、例えば
select * from my_big_table where weight in (51000,60000,82000)
のような簡単な検索にも非常に時間がかかります。
パーティショニング、インデクスを試し、速度は向上しましたがまだ時間がかかりすぎてしまいます(数分)。

最近になってnoSQLのことを知り。その多くは大量のデータ処理に適していると聞き、簡単な比較なども見ましたがどれが最適なのかいまいちよく分かりません。
特に大半がunix/linux環境用でwindowsで利用可能なものは限られているようです。
そこで

-Windows 7/vista 64 bitで動く
-フリーで利用できる
-大量のデータをもつテーブルに対するquery(検索)が高速
-C++ API (mysql connectorのようなもの)がある

の条件に合うnoSQLを教えていただけないでしょうか。

投稿日時 - 2012-08-17 07:52:01

QNo.7648171

困ってます

質問者が選んだベストアンサー

No.1です。
レコード数が多いだけにメモリ上に全部は乗らないし、HDD上でも巨大なファイルになってしまうので扱いにくいですね。
さらに、weight_gramが同じ値が何度も現れるので、インデックスをつくるのにかなり時間がかかってしまうようですね。

さて、これもご存知かもしれませんが、フリーのものとして
mongoDBがあります。
http://www.mongodb.org/
多くのOSに対応し、APIもいろいろあるようです。

こんな比較記事をみつけました。
http://mojix.org/2011/06/15/couchdb-mongodb

また、ベンチマークも
http://blog.livedoor.jp/sasata299/archives/51429383.html

投稿日時 - 2012-08-30 17:20:56

ANo.2

このQ&Aは役に立ちましたか?

3人が「このQ&Aが役に立った」と投票しています

回答(2)

ANo.1

直接の回答ではないのですが、
ご存知かもしれませんが、noSQLの記事がITproにいくつかあります。
http://itpro.nikkeibp.co.jp/article/Active/20120816/416184/?act05
http://itpro.nikkeibp.co.jp/article/Active/20110928/369593/?act05
http://itpro.nikkeibp.co.jp/article/Active/20110928/369592/?act05
などまだまだあるようです。

こちらで2000万件程度のデータベースを作ろうと考えておりまして、その前の予備的な検討として質問者さんの書かれてるデータに近いものでテストしてみました。SQLite3でLinuxです。
データは
99742435|1234|A000099742434
のような感じで、最初がprimary key, 二番目が数字(5桁の整数), 三番目が文字列という簡単なものです。
データ数は1億件です。インデックスなしでファイルサイズが約3GB、インデックス作成に6時間程度かかり6GBまでファイルサイズが増えてしまいました。
こんなに巨大になって、こりゃ駄目かなと思っていたのですが、検索に要する時間が100ms程度なので十分実用的な範囲のようです。
SQLite3は非力なイメージがあったのですが、巨大なデータでも結構使えそうです。

質問欄にあるように10-100億件となると同じ比率でファイルが大きくなるとすると60-600GBとなります。SQLiteのファイル上限もありますので、1つのファイルにするのは無理ですが、適当にデータを分割して、分散処理あるいは逐次処理をすれば結構実用的にできそうに思います。
幸いにしてSQLite3はサーバーではなく単なるプログラムですので並列処理もできそうですし。データも単なるファイルですので。

ところで、
>パーティショニング、インデクスを試し、速度は向上しましたがまだ時間がかかりすぎてしまいます(数分)
とありますが、何件程度の登録で数分かかているのでしょか。

投稿日時 - 2012-08-28 18:00:57

補足

ためになる記事の紹介ありがとうございます。
NoSQLは様々なデータベースがあるのでこのようなまとめの記事はとても役に立ちます。


>>パーティショニング、インデクスを試し、速度は向上しましたが
>>まだ時間がかかりすぎてしまいます(数分)
>とありますが、何件程度の登録で数分かかているのでしょか


name[char] / weight_gram[int] / country [char]
のようなかたちのテーブルに10億件ほどの登録(rows)があってサイズが60Gバイトあるテーブルですが、weight_gramを指定してselectすると
(例:select name from my_table where weight_gram in (41145,42125,51768,55456,62235,72476,81467) )
2-3分ほどかかります。実行環境はWin Vista 64bit でデータはinnodbをHDDにweight_gramで区切ったパーティションを1000個作って格納しています。
my.iniのチューニングを試すなどし、少しは早くなりましたが目的の速度(数秒)には程遠い状況です。
explain partitions では特定のパーティションのみを見ているようなのでパーティションの作成が速度向上に働いているとは思いますが、mySQLはパーティション数の上限があるので(1025 per table)パーティションを用いたこれ以上の改善は無理なようです。

同様の形式のデータでも1億以下の登録の場合は十分な速度(数秒)が出ているのでデータのサイズが速度低下を招いているんだろうと思い、それで大規模なデータに使われているというnoSQLについて調べているところです。

投稿日時 - 2012-08-30 08:15:18

あなたにオススメの質問