大量にある情報のリアルタイム絞込検索について

現在不動産の賃貸・売買のサイトをLAMP環境で構築しており、
HOMESやSUUMOのような検索画面の実装をしております。

http://www.homes.co.jp/mansion/tokyo/station/
http://suumo.jp/ms/chuko/tokyo/

絞込検索をするとリアルタイムで件数が反映されるようになっているのですが、
物件データが100万件程度あり、検索をするとそれなりに負荷がかかってしまいそうです。

現在検討しているのは、絞込条件の属性をもたせたデータを別のNoSQLなどのDBに
別途保持させて、そこを検索させるなどの手法もあるかと思って入るのですが、
なにが最適かアドバイスいただければと存じます。

また、物件データの追加・削除が不定期で行われるので、キャッシュの利用は難しいかもしれません。

よろしくお願いいたします。

行動規範の内容に同意します

回答2件

オンメモリ系のDBを利用するのがたぶん手っ取り早いですが、
（sho_csさんの紹介されてるRedisがそれ系では一般的です）
データ構造で対応する事が最もコスト的にはいい気がします。

例えば、以下の様なkeyで物件情報を保存します。
絞り込み条件/都道府県/市町村/番地
又は、geolocationの様な、緯度経度を数値化したものを、うまくハッシュ化してグルーピングするのもいいかもしれません。

個人的には後者が好みですが、前方一致検索が出来るモノであれば、大体可能だと思います。
具体的なお勧めとしてはS3でしょうか。DBじゃないですが、並列処理性能としては世界最高クラスのサービスです。
あと、信じられないほど安いです。

絞り込み条件分、重複したデータを保持する事になりますが、S3であればデータ容量は気にするのもばからしい程安いので、心配無用です。
また、データ更新に関しては、保持されるデータを場合によっては一物件当たり百件近く変更するかもしれませんが、
1サーバからの同時接続限界は100あるので、数万物件一気に書き込む様な場合でも、複数サーバから書き込めばすぐに完了します。

たぶん一般的なDBの考え方とは違うので、少し最初はとっつきにくいやり方だと思いますが、
このやり方で行くかどうかに拠らず、ビッグデータ系の処理はデータの持ち方自体が性能にダイレクトに響くので、
是非十分なご検討をお勧めします。

あと、蛇足かもしれませんが、
自社サーバで構築される場合、検索自体の負荷もそうですが、ネットワーク的な限界も考慮する必要があります。
例えばLinuxで立てる場合、利用可能ポートは6万程度で、デフォルトのTCP_TIMEWAITは60秒あります。
DB側はWebサーバ側のTCP Timestampを無効化すればTIMEWAITは10秒程度まで減らせますが、
それでも各種オーバーヘッドを考えて、1サーバ当たり秒間3000～4000程度のアクセスしかできない事にご注意ください。
そういう意味でも、データの持ち方自体でリクエストを減らし、検索範囲を狭める手法はお勧めです。

以上、ご参考になれば幸いです。

投稿2014/12/08 10:39