ZhongZiChang’s Dao

+ 针对数据库的update操作多的情况，可以采用以下方式加快数据同步:

1. 用户在更新数据后，马上将该条记录的host,database,table,primary key name and value 发送给DBLu，DBLu可以选择将该记录加入等待更新的队列或者马上更新；

2. 如果实在不想在更新数据后的程序中执行任何修改，为了加快索引库的更新，可在程序启动时，将索引库装入内存中，搜索和更新操作面向的将会内存中的数据，并用另外的机器定期负责索引的全部重建工作，在索引全部重建后，在系统idel高时，将重建的索引库重新装入内存，覆盖原来内存镜像。即搜索和更新的操作完全的内存执行，而重建工作在文件系统上做。

8.28 ———————————

// 返回查询需要的时间

// 返回结果中，记录集的字段可以指定，通过url传递的returnFields=xx,yy,xx的方式

// 增加 指定分词器(analyzer)的功能

8.27 —————————

// 增加对数据量大的情况的数据 -
修改的文件包括 com.zhongzichang.lucene下的IndexOneScheduleTask.java 和 Database.java

// Database.java 关于连接时使用的encoding , 逻辑有问题 ,已改正

// 修改输出的xml文件的增加内容的cdata括号

// 增加用jdom验证xml 字符的合法性

// 删除代码中出现的 BasicConfig.config() 4 log4j 后,log4j的输出正常

8.17 DBLu的需求———————

数据量特别大的情况:
不需要用户来考虑，由内部处理

返回的结果可定制

返回执行查询需要的时间

分词器的指定 //

—

建议 “截断” 在搜索服务器处理

web方式的管理工具

日志

返回结果中包含库的最后更新时间

根据关键词匹配的程度返回结果

单元测试

8.16 ————————————

执行一次性的创建（定期检查配置文件的更新情况，如果没有建立索引的情况）
如果 schedule 的 attributes 没有 key ，则不执行删除操作，只执行追加

读取远程变化的 schedule properties 应该在计划任务中执行

路径问题

将 schedule 任务的全部创建部分加入到 一次性创建的任务列表中 ( *** 需要 *** ) ，注释掉 if(!hasSchedule) 就ok

limit 可以为 null
where 可以为 null

+ 各种情况测试，客户端测试

+ 描述各种情况下如何配置

1. 一次性全部创建；
说明：在系统启动后，延时指定的时间，将启动一次性全部创建的任务。将逐个执行一次性任务，直至所有任务完成。实际上，系统会以指定的时间间隔进行一次性的创建工作，只是检查到索引已建立，则放弃操作。所以如果用户删除某索引文件夹，则该索引将会在时间间隔的时间内重建。
系统设定的时间间隔为1分钟，执行一次性列表的任务的延迟时间也为1分钟，将系统启动后一分钟，将逐个执行一次性列表中的任务。
* 配置中没有 schedule 元素

2. 第一次全部创建(在系统启动时也会进行创建)，然后按计划局部更新(has key)；
* schedule 元素 中 需要 key 属性，系统根据 key 针对 的 数据库字段值进行更新

3. 第一次全部创建(在系统启动时也会进行创建)，然后按计划追加(no key)；
* schedule 元素中没有 key 属性， 所取得的数据全部追加到 索引库中

4. 当添加、删除、更新配置文件的情况；

5. sql中的where, orderby , limit 会变化；

6. 按计划全部重建（配置文件中的 schedule 中必须拥有 rebuild=”rebuild”）；

+ 按词截段，指定段的长度，最多多少段，截取后的长度限制

8.10——————————-

DBLu 的启动脚本和关闭脚本
目标：通过war直接部署，然后修改属性文件就可以正常使用
在 webapp 的上下文 中启动 DBLu
监听器
属性文件的位置
urls文件的更新检查
再次检查 DBLu的代码

一、为何需要DBLu

• 基于数据库的Web应用需要全文检索的能力
• 传统数据库的模糊匹配能力很差，像%like% 这样的查询会吃掉数据库服务器90%以上的数据库资源，因此系统需要将精准匹配保留个数据库系统，而将模糊匹配交给独立的检索系统

呵呵，我们的mysql经常因为用户的like操作而死掉:(

二、DBLu的特点

• 基于Lucene（高效、全文检索、平台无关等）;
• 部署简单 - 整个应用打成war包，可使用各种应用部署工具直接部署；
• 配置灵活 - 配置文件提供的配置选项可以满足用户的各种需求；
• 使用代价小 - 现有应用需要改动的只是将原向数据库引擎提出的搜索请求改为向DBLu发出。

三、索引规则

• 一次性全部创建:

用户对数据表进行一次性的索引，以后不再对索引库进行更新操作；

• 先全部创建，然后按计划更新（包含更改和追加操作）:

执行对数据表的一次性创建索引后，以后按计划局部更新数据表中的数据到索引库中；

• 先全部创建，然后按计划追加:

执行对数据表的一次性创建索引后，以后按计划局部追加数据表中的数据到索引库中；

• 按计划全部重建:

按计划，将数据表对应的索引库进行全部重建。

说明，索引规则最好根据数据表的情况来进行设置，对于一个数据表可以使用多种规则。一般情况下，对于一个数据表最好使用 “按计划全部重建”+按计划追加“两种规则。因为更新的情况下，索引机器的资源消耗太大，所以一般只能在应用服务器自己做更新日志，提供数据说明那些记录更新的情况下才使用，而针对日志式更新的工作还没有做，所以不建议使用第二种”按计划更新“规则。

四、其他注意问题

• 如果删除某个数据表对应的索引库，而描述该表的配置文件仍然生效，则表对应的索引库将会指定的时间间隔内被重建；
• 当删除、添加、更新配置文件的情况发生时；
• sql 中的 where、orderby、limit是可变化的情况；
• 按词截段，指定段的长度，最多多少段，截取后的长度限制（相当于Highlight啦）。

五、关于客户端

• 客户端主要工作是将XML数据转换成相应的对象object；
• PHP客户端使用SAX解释器，DOM存在PHP4和5的兼容问题。

我们的ISP按照一定的比率将域名解释到错误的（对我们来说）机器上，用户倍受强奸。网站推广的手段无所不用其极，到这样的地步真是让人无奈。浏览网站或者使用某些免费软件时被强行观看广告还说的过去，毕竟我们没有付钱给这个网站和软件的提供商。但是像ISP，我们上网可是付费的。看看协议是否能告它，但是没有时间做这种事，只有指定其他的服务器做域名解释。但绝大部分用户是不知道这么做的，只能继续享受网通提供的额外服务了。呵呵

这两年blog是断断续续的写，换了好几个地方，都不满意。很长一段时间都没有心情写了。本打算等wiki做好，以后就用wiki，但是wiki暂时没有时间弄，还在排期中。而且在 wiki 上写东西并不是很方便，因为它主要还是个整理资料的地方。so … 自己搭了一个wp，操作一下还算ok 。以后就算稳定下来了，起码数据可以备份和转移