※ 引述《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