MySQLで1億レコード保持するテーブルの横断検索について。


現在2000万PV/Dayのサイトを運営しておりますが、
いつの間にかレコード数が1億に達するテーブルが存在していることが発覚しました。

さすがにこの件数ともなるとクエリが重くなり、サービスの稼働にも大きく影響しております。

そこで皆様のお知恵をお借りしたいのですが、
1億またはそれ以上のレコード数を保持するテーブルについて
データを複数台サーバに分散化させた場合の
”一元的な横断検索を実用レベルで可能とするアイデア”
をお教え頂けますでしょうか。

現在の環境は以下の通りです。

OS:CentOS5.5
アプリ:PHP5.2.6
ディスク:INTEL SSDSA2CW120G3
メモリ:16GB
MySQLのバージョン:5.0.88と、5.0.67+tritonn.1.0.12(全文検索)

よろしくおねがいいたします。

回答の条件
  • 1人5回まで
  • 登録:
  • 終了:2011/12/06 14:00:26
※ 有料アンケート・ポイント付き質問機能は2023年2月28日に終了しました。

ベストアンサー

id:pretaroe No.3

回答回数531ベストアンサー獲得回数75

ポイント300pt

>MySQLレベルで分散化

結論は難しい。

データの特性や検索パターンを利用して
アプリケーションからのアプローチも必要な場合が多い。


レコードを半分のテーブル作成して2テーブル。
1テーブル目でヒットすれば、今までの半分の時間
2テーブル目でヒットすれば、今迄通りの時間
こういう風な感じの原理を利用するとか。

mixiとかもその手の方法論を導入してたと思いますよ。


>データを複数台サーバに分散化させた場合
これ、更新があるのかどうかとか更新の頻度にもよります。

・よく検索されるパターンの結果を保持しておく
・更新系と参照系の2つもつとか

基本的に、ベタで泥臭い方法しかないと思う。

id:osamuaa

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

やはりアプリの作り込みでしょうか。
更新は随時発生し得るため、分散化させた場合は
それぞれをマスタ・スレーブ形式にしないといけないですし、
またバックアップも考えるとなるとかなり重い作業になりそうです(==;

mixi様が同様のことをやってらっしゃった記事を以前見かけたのですが、
数年前?であったため、今ならもう少し簡単なソリューションなどないものかと思い、
今回質問させていただいております。

泥臭い方法でもとにかくやるしかないですね!ありがとうございました!

2011/12/01 11:10:42

その他の回答2件)

id:kodairabase No.1

回答回数661ベストアンサー獲得回数80

ポイント30pt

MySQLレプリケーション環境下での負荷分散手法のまとめ
http://epidemic.jp/2011/06/11/how_to_mysql_loadbalance/

公式マニュアル「レプリケーション」
http://dev.mysql.com/doc/refman/5.1/ja/replication.html

id:osamuaa

ご回答ありがとうございます。
MySQLレベルで分散化はやはり難しいでしょうか。

尚、情報が漏れており申し訳ありませんが、
フレームワークに関しましては自社製のものを使用しております。
アプリで対応となると作りこむのが大変そうです・・・。

2011/11/29 16:31:31
id:windofjuly No.2

回答回数2625ベストアンサー獲得回数1149

ポイント170pt

ボトルネックがデータベースサーバー側にあるのならば、
まずは単体での高速化を目指しても良いのではないかと思います

1億レコードにまで膨れ上がるということは、
結構な頻度で追加や更新処理もあるでしょうから、
更新が入ると劇的に遅くなるTriton(SennaのMySQLへの実装)ではなく、
後継であるmroonga(groongaのMySQL実装)の採用を考えてみてはどうですか?

データベースエンジンを変えるだけなので、
作りこみは特に必要ないと思いますけど・・・

特徴とインストール方法
http://mroonga.github.com/ja/docs/characteristic.html
全文検索エンジンのドキュメント
http://groonga.org/ja/docs/characteristic.html

id:osamuaa

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

実は半年ほど前にmroongaやプラグイン形式のパーサーを試したことがあるのですが、
その時は今回問題となっている巨大テーブルのみインデックス構築でエラーとなってしまい、
結局tritonnのまま落ち着いたという経緯があります。

1億レコード以上のテーブルをWebサービスで扱うとなると、選択肢もかなり限定されてしまいますので、
なかなか答えづらい質問かとは思いますが、よろしくお願いいたします。

2011/11/29 20:04:54
id:pretaroe No.3

回答回数531ベストアンサー獲得回数75ここでベストアンサー

ポイント300pt

>MySQLレベルで分散化

結論は難しい。

データの特性や検索パターンを利用して
アプリケーションからのアプローチも必要な場合が多い。


レコードを半分のテーブル作成して2テーブル。
1テーブル目でヒットすれば、今までの半分の時間
2テーブル目でヒットすれば、今迄通りの時間
こういう風な感じの原理を利用するとか。

mixiとかもその手の方法論を導入してたと思いますよ。


>データを複数台サーバに分散化させた場合
これ、更新があるのかどうかとか更新の頻度にもよります。

・よく検索されるパターンの結果を保持しておく
・更新系と参照系の2つもつとか

基本的に、ベタで泥臭い方法しかないと思う。

id:osamuaa

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

やはりアプリの作り込みでしょうか。
更新は随時発生し得るため、分散化させた場合は
それぞれをマスタ・スレーブ形式にしないといけないですし、
またバックアップも考えるとなるとかなり重い作業になりそうです(==;

mixi様が同様のことをやってらっしゃった記事を以前見かけたのですが、
数年前?であったため、今ならもう少し簡単なソリューションなどないものかと思い、
今回質問させていただいております。

泥臭い方法でもとにかくやるしかないですね!ありがとうございました!

2011/12/01 11:10:42
  • id:tdoi
    そもそもパフォーマンスが低下した原因がレコード数にあるのかまずは検討すべきでしょうね。
    かなり特化したことをやるなら、スキーマや想定されるクエリとかにも依存するでしょうし、情報がこれだけだと答えにくい気がします。

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

回答リクエストを送信したユーザーはいません