→ gpmm:咦…好像一整個脫離 Ajax 範圍…囧a" 05/18 02:51
→ TonyQ:話說回來 , cache 最頭痛的就是對應即時更新 , 05/18 03:17
→ TonyQ:我現在的設計只有在必要或者很無所謂的地方才會用cache 05/18 03:17
→ TonyQ:不然有user 在 complain 看到cache 的舊資料也是頗麻煩XD 05/18 03:18
推 Kelunyang:ajax也是有後端的咩XDDD（誤 05/18 09:19
※ 引述《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