あき
attin****@kk*****
2007年 8月 9日 (木) 00:37:55 JST
Forkあきです。
> > 最近、表示速度の高速化について真剣に考えています。
> > ある程度目星はつけているのですが、見当違いでないかどうかだけ、確認させ
> > て下さい。
> >
> > 今目をつけているのは lib/Wiki/DefaultStorage.pm の get_page_list です。
> > この中で、data_dir ディレクトリからファイルの一覧を取得しています。
> >
> > これを、ディレクトリ内を見るのではなく、ファイルリストを設定ファイル内
> > に保存しておき、それを参照するような仕組みにしたらどうだろうかと考えて
> > います。
>
> これはすでに仰るような修正を実施済みです。
> CVS HEADを試してみてください。
> 実際にかなり早くなる場合もあるみたいです。
なるほど…。
3.6.3dev1で対応してるのですね？(笑)
ソース内に _create_page_list_file なるメソッドが…。
> > それからもう一点…、
> > 他に、検索機能に関してですが、ちょっとこんな仕組みも考えています。
> > これは、私が実務で独自DBを作成した際に用いたワザです。
>
> すでに実績のある全文検索エンジンがありますので
> 可能であればそちらを導入したほうがよいと思いますが、
> レンタルサーバですと設置が難しいケースも多いと
> 思いますのでなにかいい方法があれば実装したいです。
>
> あきさんの方法では少ない文字数で検索された場合や
> 英文がメインの場合だと逆効果かもしれないと思いました。
実は…そのとおりなんです。(^_^;)
一応代替案はありますが、実際にやってみるか否かは微妙です。
Perlだとメリットないかも…。
一応ご紹介だけ…。
各文字コードをそのリスト化するのではなく、ハッシュ値を求めてリストを
作成しします。
例えば、文字コードをそのまま使用するのではなく、16で割った値をハッシュ
値とした場合…（って、こんなハッシュ関数、本当は適当じゃないですが…）
文字 コード ハッシュ値
プ 0xA5D7 ÷16＝ 0x0A5D
ラ 0xA5E9 ÷16＝ 0x0A5E
グ 0xA5B0 ÷16＝ 0x0A5B
イ 0xA5A4 ÷16＝ 0x0A5A
ン 0xA5F3 ÷16＝ 0x0A5F
ア 0xA5A2 ÷16＝ 0x0A5A
ッ 0xA5C3 ÷16＝ 0x0A5C
プ 0xA5D7 ÷16＝ 0x0A5D
デ 0xA5C7 ÷16＝ 0x0A5C
ー 0xA1BC ÷16＝ 0x0A1B
ト 0xA5C8 ÷16＝ 0x0A5C
~~↑~~ ~~↑~~
そのままだとコレ ハッシュ化するとコレ
↓それぞれ重複を取って数を数えると…
そのままの時 10種
ハッシュ化した時 7種
こんな感じで、ハッシュ値の求め方次第でDBサイズを小さくまとめるができま
す。
後は、これらの情報を１文書１ファイルで管理せずに、ページ一覧インデック
スファイルと同様に１ファイルで管理する…などのようにすれば、オーバー
ヘッドもそれなりに小さく抑えられると思います。
まぁ、どれほど効果があるかは微妙ですけど…。
あまり効果ないかな？
後、英文のときかぁ…。
確かに…。
いろいろ問題が多いですね。(^_^;)
> msearchのような単純なやり方でもそれなりに効果があると
> 思いますが、やはり大量データになると厳しいですよね…。
msearch かぁ。
使ったことがないのでよく分らないのですが、どうなんでしょう？
インデックスの更新とか、大変そうな気が…。
インデックスファイルも大きそうですし…。
個人的には外部ツールには頼りたくないなぁ。
やっぱり何とかしたいなぁ。
もう少しいろいろ考えてみます。