ZhongZiChang’s Dao

dblu - 针对mysql的联合查询的问题

// 改动了122上的/proc/sys/fs/file-max

// mysql 的字符集编码问题(对java)

// 购物搜索的进度说明

// dblu的批量增加

// dblu的搜索结果分组 group by
–

== dblu的总体优化

// dblu 提供即时更新的接口
// 有空试用 ecshop2

o 为 discuz 的posts 表(16,100,000条记录，6个字段， 分别是fid tid invisible message subject，其中 message 和 subject 需要全文检索)创建索引的时间 65789064ms => 18.27474 个小时

o 检查分段 rebuild 是否生效

o dblu , 分段索引时，使用的sql语句，要加上 order by [primary key] ，按照 primary key 来分段和排序 ———– (取消)

o 等 posts 表的数据创建完毕，在远程服务器上再做测试修改后的DBLu

o 下午2点，讨论 cbdb 的需求

o 商品搜索项目需要接手，相关的资料需要阅读

o discuz 的 posts表需要索引的字段:
fid tid invisible message subject

o 分段搜索下的返回结果

o 当 按照beginPercent=”90″ 和 endPercent=”100″ 来更新的时候 ， db.getIndex 方法取回的 resultSet 为空，需要看代码检查原因。目前怀疑是根据百分比取到的 primary key 的值所在的记录可能不存在

o 调整架构

o 取消对 schedule 中 对 limit 的处理

o 按百分比分段检索

configListFilePath=/var/DBLu/list
dataDirectory=/mnt/ramfs/DBLu/data

/home/zczhong/var/DBLu/f/localhost.wiki.page.xml

threads 表，5个字段(tid, closed, fid, displayorder, subject)，其中subject做全文检索，100w条记录，用时39分钟，如果1000w的表，10%就是100w，也差不多是么长的时间

举例：

1. 每小时更新10%
<schedule time="0 * * *" percent="10" key="tid">

2. 每天(系统忙)7点到22点，每小时更新10%，(系统闲)1点和5点更新30%
<schedule time="0 7-22 * *" percent="10" key="tid"/>
<schedule time="0 1,5 * *" percent="30" key="tid"/>

* 请在设定时先检查更新的耗时，以便设计合适的更新计划。

// 由于在做索引工作的时间较长，mysql会将连接断掉，下面的数据不正确。这个 bug 已经改正。- 2006.9.3
create index:

cast time:5316584 - [host:192.168.0.42] [database:discuz] [table:threads]

update index:

18020983 [Timer-3] INFO com.zhongzichang.lucene.IndexSchedulerTask -
cast time:606630 - [host:192.168.0.42][database:discuz][table:threads]
[where:null][orderBy:null][limit:null][key:tid][url:null]
[rebuild:false][analyzerName:cjk][percent:10]

21621416 [Timer-3] INFO com.zhongzichang.lucene.IndexSchedulerTask -
cast time:607053 - [host:192.168.0.42][database:discuz][table:threads]
[where:null][orderBy:null][limit:null][key:tid][url:null]
[rebuild:false][analyzerName:cjk][percent:10]

25223611 [Timer-3] INFO com.zhongzichang.lucene.IndexSchedulerTask -
cast time:609248 - [host:192.168.0.42][database:discuz][table:threads]
[where:null][orderBy:null][limit:null][key:tid][url:null]
[rebuild:false][analyzerName:cjk][percent:10]

+ 针对数据库的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的兼容问题。