※ 引述《TonyQ (沉默是金)》之銘言： : 真的要用關鍵字 , 我玩過 Compass 的玩法 . : (本質是lucene底,只是包裝過介面 , 是java體系的東西.) : 他是怎麼玩咧 , 基本上他是用所謂 resource 的機制 . : 每一筆資料要設定某一特定主值 (通常就是 db table的 pk) , : 然後對內文做中文斷詞 (那時用的是庖丁這套大陸分詞系統) , : 按照 key , words 的配對模式存到索引檔裡面去. : (只是概念上 , 這是文件上寫的 , 實際存法我沒研究. XD) : 然後查詢時 , 也要針對查詢的關鍵字用一樣的斷詞系統先斷過一次 , : 再針對被斷詞後的關鍵字"群" , : 在索引檔中做查詢跟評分動作 , 跳出分數高的來列出 pk , : 你可以再針對這些 pk 去查出detail的資料. : (是也可以直接把所有資料存進去啦:p) : 我想 , 要自己實做的話 , 不外乎就是這些流程 , : 只是 compass 是有跟我們用的 OR-Mapping (也就是Hibernate) 介接 , : 所以我們資料表有新增資料時它會自動build index , : 刪除資料時也會自己 update , 所以操作起來非常愉快. XD : btw , 要自己實作的話 , 當然還是以檔案 io 為主最快了... : ps. 前兩天我玩了一下 sql 2008 的全文檢索 , : 雖然說效果可能沒有非常好 , 但是感覺似乎還算是可以接受... 其實 T 大跟小弟講的已經是同一件事了 XDD 就是 natural language 斷句去做搜尋引擎的 base table， 還有其後的衍生應用（像 keyword 權重或交叉積分之類的…） 當然如果 orm 包裝的好，整個用起來一定很快樂。 不過雖然 io 是最快，但是要設計架構/結構和 data lock（這個超煩 XDD） 就很花時間和腦力了，如果沒有太多時間就還是丟給 mysql/mssql 去做吧， : : 如果要作中文全文搜尋的話，之前看過DB版深藍站長大大說過一種 : : 用空間換取時間的方法，就是把中文關鍵字拆解成一張資料表，到 : : 了要搜尋的時候可以藉由WHERE查詢比LIKE快（在目前中文全文搜尋 : : 機制仍然不理想的情況下的作法） : : 那這樣是不是類似gpmm大的說法，就事先作好很多的View存下來先前的查詢結果 : : 然後再進一步的作filter就好了呢？（還是我誤會的gpmm大的意思） K 大這邊提到的先前查詢結果，已經是又另外一層了， 如果 keyword table 已經超過二十幾萬筆， 那就乾脆另外拉一個常用的 hight weight keyword table， 專門存積分超過某一個限度的… （其實架構設計優良的 keyword table，即使到百萬筆效能應該都還過得去。 不過老實講，keyword table 塞起來是很快的… orz） 還有一種是所謂的時間性熱門查詢，或普遍的熱門查詢， 這種比較建議把相關的結果集預先收到 cache 或檔案裡， 可以有效降低熱門關鍵字對 DB 的摧殘， 不要忘記如果有了新資料進來，要去更新相關的 cache 或檔案就是。 : :前文恕刪，不過gpmm大的意思是不是server端準備一張表格 : :把查詢過的記錄存起來，如果同一個session發動不同的request再查詢 : :如果不是就中斷查詢的process（好像是Windows Form裡中斷Thread的作法 : :可是資料庫有可能嗎@@?） : :不知道這部分我有沒有會錯意 回過頭來講這個，要中斷資料庫的 query 是可以的，kill 掉就好了， 只是這既暴力又危險，不管什麼情況大概都不可能讓系統自己跑， K 大這邊提到的中斷查詢的process，比較是小弟指的， 在每一個流程上（DB 操作以外）的檢查點做中斷， 實做上和 K 大你說得也差不多， 準備一個資料去記錄同隻 session 最後更新的 request， 在每一個 query 操作結束後，先比對現在的 request 和最新收到的是否一致， 若不一致，那是否要把現在已經取出的 result rows 丟掉，重新對 DB query， 或著拿現在的結果集再加以利用， 大概是這樣 :P --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.136.225.239