星期日, 12月 18, 2005

MySQL 的全文搜尋效率

上個月才聲稱 MySQL 也支援全文檢索,但現在心裡卻頗有不滿。

怎麼回事?原來,MySQL 的全文搜尋效率並不好。當初的文件庫只有一萬多篇文件,效能還差強人意;但現在文件庫裡有了十幾萬篇文件,搜尋的時間竟然也是「直線上升」。那麼,做全文索引,還有什麼意義呢?

調了調幾項參數,都沒能改善效能。只好到網路上看看別人是否也有類似的經驗。喔,是了,確實有人做了些實驗,然後發現 MySQL 的全文效率,並不會比直接用 SQL 指令,下「WHERE content LIKE "% tag %"」來得好(其中,content 是資料庫儲存內容的欄位名稱,tag 是要搜尋的字串,% 表示任意字元都符合,而 tag 前後留有空白,是因為英文字是用空白來斷字的)。

這下子也真令人氣餒。雖說自己只是在做實驗性質的 prototype 或 demo,但尋找個「劉銘傳」、「海山口」竟也要花上半分鐘以上的時間,總讓人心裡不舒服。

於是,也強烈感覺到,強調互動的系統,「回應時間」是需要被關注的。 0.1 秒內取得檢索結果當然很好,但花個三秒鐘,也不會讓使用者覺得太難過。然而,如果需要超過五秒才有回應、甚至需要長達半分鐘的等待,那麼系統在「互動」上就顯得很不實際了。

6 則留言:

被掛掉的阿尼 提到...
網誌管理員已經移除這則留言。
被掛掉的阿尼 提到...

放心啦, 全文檢索只是過渡的階段, 給還不知道到怎麼做才好時的工具
到最後, 一定會弄一大堆METADATA(比你現在有的跟想像的多得多)在那兒作整合跟檢索條件的

lcat 提到...

看來還是得用花$的工具 :(

tu 提到...

阿尼所說的狀況,在「實際的系統」上,幾乎一定會發生(否則啊,就不能稱之為「系統」了 :p)。

可是,麻煩的是我的個性:即使是過渡的階段,還是會想要達到「可接受的效能」。更糟的是,這裡的「可接受」,標準還不算太低...

因此,人當然活得辛苦啦。連週末都在家裡嘗試著各種 work-around 方式。如此一來,連應該陪伴家人的時間,都耗上去了。結果,當然不會很好...

tu 提到...

喵說的有理啊~

被掛掉的阿尼 提到...

在智慧局的時候, 一開始系統的效能是丟了查詢進去, 要去泡一杯咖啡來喝等結果出來 ^^
後來還是弄到幾乎答案馬上出來