mysqlでのテーブル分割時の検索手法についてお聞きします。

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

情報不足で申し訳ございません。

物理的に違うDB（かつ違うサーバー）に分割したテーブルが置いてあります。

よって結合ができないのです。※アプリ側もテーブル分割を見越してjoinはほぼしない設計にはしてあります。

データの検索が頻繁にあるのでテンポラリテーブルをアクセス毎に生成するのは厳しそうです。

また、過大表現で失礼しました。

現在のデータ件数は1千万件ちょっとです。が、早い時期に5千万くらいに達してしまいそうなのです。

先々を見越してアプリ設計をしないとやばいことになりそうです。

とりあえずは5000万件くらいまで達したら2500万件ずつ分割しようと思っております。

それを繰り返していくと、日記データ全体から検索をかけた時にアクセス毎に2～4回ほどのselectを実行することに

なりますが、主キーでの絞り込みを心がけているので速度はそれなりに出るかなと思っています。

※ちなみにInnoDBです。マスタ・スレーブ構造です。

なるべくは外部ツール?などは使わずMysqlの機能だけでがんばって行きたいと思うところです。

よくmixiとかモバゲとかの巨大システムでのDB分割手法がよく紹介されていますが、

それらを横断的に検索する手法は書かれていないなぁと思うのは私だけでしょうか。

ありがとうございます。

なるほど、外部ツールとを商用ツールと勘違いしておりました。すみません。

idでの分割ではなく、時系列ですか。

しかし時系列だと古くなったテーブルが

だんだん参照されなくなっていく可能性はありませんかね？？

検索部分についてですが、多分私もgoodvnさんと思想が一緒だと思います。

Senna+Mecabによる全文検索専用のマスタ・スレーブ構造グループ別途用意。

日記データを更新で、Sennaマスタも更新されるようにしようと思いましたが、

Fulltextのインデックス更新のコストが高いので、キュー処理することに。

別途専用のキューデータベースを立て、Senna用キュー管理テーブルを用意し、(ここにはデータを一意に示すidしか入っていない)

PHPで作成したキュー更新デーモンが定期的にキュー管理テーブルに入ってるIDから実態データを引っ張り出し、

全文検索用にデータを加工(絵文字除去やごちゃごちゃしたことなど)を行ってから、

適宜Senna専用データベースを更新するという実装にしました。

全文検索時はSenna専用データベースから"match against"で一回検索→

取得した結果のIDを元に、分割されたテーブルの所在を示すマップから格納先DBを取得→

そのDBに対してwhere in (id,id,id)でみたいな感じで最終的に必要な日記データを取得。

みたいな感じです。idは主キーなので検索速度は件数が膨大でも早いです。

このように、全文検索時はそれなりに手間かからずいいのですが、

例えば日記の状態を示すフラグ(あいまいですみません）が1であるデータを

引っ張る必要がある時、分割されたテーブルすべてにSQLを発行し、

結果を取得。それらの結果からある値でソートを行う場合などは

アプリ側で結果配列を廻しまくる処理が入ってしまっているため、

ちょぃ自分のDB側設計ミスったかと思っております。。

もうちょっと頭冷やして考えてみます。

＞PS.

＞これだけの規模のシステムは，個人的に興味があります．ぜひ見てみたいです(^^;

本当ですか、是非一度お茶でも(^^)

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

MySQL Clusterですね、マスタ・スレーブ構造より、

管理が難しそうだと思い、検討からはずしていました。調査してみます。

しかし、データが巨大な故、ひとつのテーブルを二つやみっつに分割するのであり、

それらを別ホストに置くことにより負荷を下げているのですが、

Clusterだと全データノードで分割されたテーブルを持つ必要があると思われます。

そうなると結局テーブル１とテーブル２にselectかけて結果を受け取って、マージしてっていう処理は

同じように発生しますよね？？

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

ご提案通り、全文検索に関しては統合されたDBを用意してあります。

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

mergeテーブルはInnoDBでは使用できなそうです・・。

UNIONに関しては、テーブル分割(DBもホストも物理的に別)なので使用できなそうです・・。