關(guān)于對(duì)sql2000查詢(xún)結(jié)果進(jìn)行相關(guān)度排序的測(cè)試
sql2000的查詢(xún)結(jié)果進(jìn)行相關(guān)度排序,聽(tīng)起來(lái)好象很吸引人,不過(guò)真的是可以實(shí)現(xiàn)的。 上午上網(wǎng)看到了一篇利用微軟index server來(lái)做全文查詢(xún)的文章(這個(gè)以前也看到過(guò),在計(jì)算機(jī)管理中也自帶了這樣一個(gè)查詢(xún)功能)我的IIS默認(rèn)web服務(wù)器在g:/wwwroot下其中有10萬(wàn)多的html文檔 測(cè)試:strSearch = 'SELECT DocTitle, Path, FileName, Characterization, Size,write,RANK' & _ ' FROM SCOPE()' & _ ' WHERE CONTAINS ('' & Request.Form('txtSearchFor') & '') ORDER BY RANK; desc' 還進(jìn)行了相關(guān)度的排序,我沒(méi)有做時(shí)間的具體開(kāi)銷(xiāo)的計(jì)算,不過(guò)給人的感覺(jué)還可以接受,在翻頁(yè)的時(shí)候就非常快了。不過(guò)最大的缺點(diǎn)好象就是只能索引靜態(tài)頁(yè)面了。 下午我把以前的一個(gè)50多萬(wàn)條記錄(主要是歌曲名和歌手名)的數(shù)據(jù)庫(kù)在sql2000做了索引,晚上就可以開(kāi)始測(cè)試了。 測(cè)試一: 'select top 26 * from song1 where contains(songtitle,'愛(ài)')',對(duì)結(jié)果沒(méi)有進(jìn)行任何的處理,只是按照ID的升續(xù)排列時(shí)間開(kāi)銷(xiāo)基本上維持在0.016s,速度是很讓人滿(mǎn)意的,至少感覺(jué)不到慢。
測(cè)試二:利用rank值進(jìn)行了相關(guān)度的排序,'order by rank desc' or 'order by rank asc',查詢(xún)結(jié)果在排序的質(zhì)量上讓人滿(mǎn)意,都比較準(zhǔn)確的,不管是查詢(xún)時(shí)使用 or 或者and進(jìn)行多關(guān)鍵字的排序都還可以的,不過(guò)時(shí)間的開(kāi)銷(xiāo)讓我受不了,居然在6s到8s之間,而且cpu也占用比較高 我看到網(wǎng)上其他的搜索的相關(guān)度排序都比較快的,開(kāi)源的Lucene我沒(méi)有研究過(guò),因?yàn)槲也欢甹ava。不過(guò)我想如果在索引的時(shí)候?qū)γ總€(gè)關(guān)鍵字進(jìn)行相關(guān)度的運(yùn)算查詢(xún)起來(lái)應(yīng)該不會(huì)慢的啊,這個(gè)我也感到郁悶。
