Kentaro Hayashi
hayas****@clear*****
2017年 3月 31日 (金) 14:38:37 JST
On Fri, 31 Mar 2017 11:18:29 +0900 Kentaro Hayashi <hayas****@clear*****> wrote: > > 林です。 > > > On Thu, 30 Mar 2017 14:59:59 +0900 > <toshio_uchiy****@mirro*****> wrote: > snip > > 現在、漢字2文字だと早くて（わたくしの環境では、1ミリ秒以下）ローマ字5文字 > > apple だと遅い > > （わたくしの環境では、200ミリ秒程度）という傾向が見られます。 > > できれば、200文字 x 5000万行（ローマ字、ひらがな、カタカナ、漢字が混じって > > いる）で > > ローマ字の単語、ひらがなの単語、漢字の単語で検索した時に、どれも、1ミリ秒を > > 切って0.x ミリ秒 > > だと助かります。 > > マシンは、Fujitsu TX1310 M1、メモリー 32GB（アドテックのサーバー用）、HDD > > WD 1TBミラーリング > > （RAIDサーバー用 2 台）です。CPU は、Celeron G1820 です。 > > アドバイスあれば助かります。よろしくお願いします。 > > こちらについては、内山さんの環境で実際に試されないことにはなんとも言えません。。。 > 実際に試してみた結果こうだった、どうするといいでしょう？という疑問についてなら > 識者からのアドバイスがもらえるかもしれません。 念のためもう少し補足をすると、現在pg_bigmを使っていてかわりにPGroongaを試してみよう というのなら↑の状況が改善すると思います。 pg_bigmだと検索語句が2文字のケースでは(バイグラムなので2文字ごとの区切り) インデックスを使って高速に検索できますが、それより長い文字列だと遅い傾向があります。 appleを例にするとap - pp - pl - leとトークナイズして、かつそれらが隣り合っているか 並びのチェックもしないといけません。 しかし、pg_bigmは文字の出現位置の情報をもっていないので、隣り合っているかの チェックを高速に行えません。 一方、PGroongaの場合、インデックスに文字の出現位置の情報も保持しているので 並びも高速にチェックできます。また、実はトークナイズの際PGroongaの デフォルトではappleはap - pp - pl - leではなくappleとそのままトークナイズするので インデックスの比較が少なくて済むようになっています。 というわけで、内山さんの環境でappleみたいなケースでも 1ミリ秒以下で検索できるのではないかと考えられます。 -- Kentaro Hayashi <hayas****@clear*****> -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: 無し 型: application/pgp-signature サイズ: 833 バイト 説明: 無しDownload