URL、サイト名、サイト説明、最終更新日、と言ったデータを数百万レコード、20〜30GB程度を検索したいのですが、PHP+PostgreSQL又はPHP+MySQLでは実用的ではないのでしょうか?
このようなことをしたい場合は通常どのような組合せが良いのでしょうか?
また先日インデックスの重要性について他の質問で教えていただいたのですが、上記の例のようなデータの場合どこをどうやってインデックスするのでしょうか?
初心者向けの基本的なことで構いませんのでお願いします。
何も知らない私としてはURLでも検索したいし、キーワードでも検索したいと思うのでインデックスを作っても結局全てのデータを検索しなければならないような感じがするので何をどうすればよいのか根本がわかりません。
またGoogleやYahooのような巨大な検索エンジンはどうやってインデックスを作っているのか。
なども簡単におしえて頂ければ幸いです。
Yahooなどで全文検索で検索する。
==============================================
参考
日本語全文検索
Tsearch2j (PostgreSQL)
https://www.oss.ecl.ntt.co.jp/tsearch2j/
PostgreSQL
システム構築手順
https://www.oss.ecl.ntt.co.jp/tsearch2j/source/tsearch2j.pdf
Rast (Berkeley DB)
http://projects.netlab.jp/rast/?FrontPage.ja
(http://blog.postgresql.jp/28)
ある程度以上の大きさになると、
専用エンジンの方が効率がよいと思います。
Yahoo! Search Technology
http://internet.watch.impress.co.jp/www/column/kensaku/0225.htm
まず、どのような構成を考えていらっしゃいますでしょうか。
自分でサーバを立てるのか、レンタルサーバを立てるのか、などインフラ構築のイメージは出来ていますか。
例えば、レンタルサーバの場合、20GB~30GBの容量を借りるとそれなりの維持費用がかかります。
(月々2万円~ぐらいでしょうか。)
自分でサーバを立てる場合、同時接続ユーザ数はどの程度想定していますでしょうか。
ローカルに立てたサーバでご自身が検索するだけでしょうか。
それともWEBで公開して不特定多数に検索させるのでしょうか。
また、どの程度のレスポンスを期待していますか。
多数のユーザが同時に検索すると処理が追いつかなくなり(メモリ不足とそれに起因するI/Oの増加)、レスポンスが著しく悪化する可能性があります。
その場合、DBサーバをいくつも準備し、適切な負荷分散を行う必要があります。
サーバ費用と電気代などがそれなりにかかると思います。
(すでに考慮済みでしたら申し訳ありません。)
そういった話は抜きにして、インデックスの使い方についてはオフィシャルのマニュアル(の日本語訳)を参照すると良いと思います。
インデックスと一言にいってもいくつか種類がありますし、データの内容、検索の仕方によって適切なインデックスは変わってきます。
このあたりのパフォーマンスチューニングはDBの中でももっとも難しい領域の1つで、「これが正解」というものはありません。
とりあえず、最初のうちはためしに色々とインデックスを張ってみれば良いと思います。
インデックスなしの状態で検索をしてみた速度(処理時間)とインデックスを張った後の速度を比較すれば効果は一目瞭然です。
(特に値の分布が大きい列に対してはB-Treeインデックスはかなり有効です。)
上記の例の場合でしたら、ディスク容量の問題などがなければ、検索対象になる列全てにインデックスを張れば良いでしょう。
また、前回の質問への回答時に説明しておくべきだったのかもしれませんが、URLの検索とサイト名の検索を同じ語句で行う必要はあまりありませんよね?
検索対象ごとに処理はキチンと分けた方が良いです。
「全ての列を対象に検索」というのは最後の手段にするべきです。
私はDBの専門家ではないので、的外れな部分もあるかもしれませんが、想定する規模によって対策は大きく異なってくるのは間違いありませんので、今後の回答者から有益な情報を得るために、どのような規模でどの程度のユーザ数を想定しているかを明記してみてはいかがでしょうか。
少しでも参考になれば幸いです。
ありがとうございます。
そうですよねどのような状態で使うのかが重要ですよね。
あくまでも将来的にはと言う前提で解釈してください。
まず、最初は共用のレンタルサーバーを考えています。
負荷に耐えられないようなら専用のレンタルサーバーに変更します。
ということでサーバーは自宅には置きません。
ちなみに「DBサーバをいくつも準備して適切な負荷分散を行う」ということまではさすがに金銭的余裕はありません。
使い道は一般的なサイトと同様、WEBで公開して不特定多数の人に利用してもらいます。
リクエスト数は22:00〜1:00頃の時間帯で多くて毎秒10回。
その他は毎秒4〜5回程度でしょうか。
レスポンスは遅くても3秒以内を希望します。
現在数MB程度のテキストデータを上記のようなアクセス状況で使っていますが毎秒10回くらいのリクエストでも3秒以内には返事が返ってきます。
(数千円程度の共用サーバーです)
データをこの数万倍に増やしても同じようなレスポンスを求めています。
教えていただいたURLを早速拝見してみます。
> 上記の例の場合でしたら、ディスク容量の問題などがなければ、検索対象になる列全てにインデックスを張れば良いでしょう。
> また、前回の質問への回答時に説明しておくべきだったのかもしれませんが、URLの検索とサイト名の検索を同じ語句で行う必要 はあまりありませんよね?
> 検索対象ごとに処理はキチンと分けた方が良いです。
> 「全ての列を対象に検索」というのは最後の手段にするべきです。
フォームに「旅行」と入れる人もいれば「travel.xxx」というドメインで探す人もいますよね。
こういう事を考えるとそれぞれにインデックスを作っておき、キーワードがURL以外と判断できる場合はサイト名や説明文を検索し、URLと思われるときはURLを検索すればよいと言うことなのでしょうか?
>やはり全文検索が有効なのでしょうか?
RDBMSで索引のイメージは 検索キーを抽出して
登録って事ですよね。
全文索引はデータから検索キーに必要なものを自動で抽出して
索引をまとめて作成するようなイメージに近い。
http://ja.wikipedia.org/wiki/%E5%85%A8%E6%96%87%E6%A4%9C%E7%B4%A...
KAKASI - 漢字→かな(ローマ字)変換プログラム
検索エンジンの裏技を第1回~ 見てみては
http://internet.watch.impress.co.jp/www/column/kensaku/0311.htm
ありがとうございました。
やはり全文検索が有効なのでしょうか?
「Tsearch2日本語化パッチによる日本語全文検索」拝見させていただきました。
これは自分で辞書の内容を追加できるのでしょうか。
ちょっと調べてみます。
> http://blog.postgresql.jp/28
引用 : 通常のLIKE文だと1秒以上かかっていたのが、Rastを使うと6msとかになってたりしています。
凄いですね。
興味が沸きます。
ありがとうございました。