Monday, June 18, 2007

rsync - 同步索引

仿照Solr 中同步索引数据的方式用rsync 把index mster 上的索引同步到各个 search slave 。同步的操作可以简单描述为：

cp -lr ${data_dir}/index ${data_dir}/${short_name}-wip
rm -f ${data_dir}/${short_name}-wip/segments
rm -f ${data_dir}/${short_name}-wip/*.del
rsync -Wa --size-only --delete rsync://${master_host}:${rsync_port}/${module}/${short_name}/ ${data_dir}/${short_name}-wip
mv ${data_dir}/${short_name}-wip ${data_dir}/${short_name}

注意source path 结尾处的'/'：A trailing '/' on a source name means "copy the contents of this directory". Without a trailing slash it means "copy the directory". 下面是rsync 的man page 中给出的两者的区别。

rsync -avz foo:src/bar /data/tmp

this would recursively transfer all files from the directory src/bar
on the machine foo into the /data/tmp/bar directory on the local machine.
The files are transferred in "archive" mode, which ensures that symbolic links,
devices, attributes, permissions, ownerships etc are preserved in the transfer.
Additionally, compression will be used to reduce the size of data portions of the transfer.

rsync -avz foo:src/bar/ /data/tmp

a trailing slash on the source changes this behavior to transfer all files
from the directory src/bar on the machine foo into the /data/tmp/.
A trailing / on a source name means "copy the contents of this directory".
Without a trailing slash it means "copy the directory".
This difference becomes particularly important when using the --delete option.

参考：

deduplicating - 排重

基于Bloom Filter 的排重

Bruno Martins 用java 实现了bloom filter，并且还移植了Maciej Ceglowski 在Using Bloom Filters一文中给出的用于计算最优bit size 和 hash function number 的模型，但由于java.lang.Math.pow 方法存在bug，用移植后的方法往往会得到完全错误的结果。

于是想到用Maciej Ceglowski 提供的方法[1]预算出几种可能会用到的结果，以便于在程序中进行选择，但结果却又大失所望 :(

keys	error rate	lowest bits size	best hash functions
20000000	0.0001	383459095.926706	13
20000000	1e-05	479331722.287969	17
20000000	1e-06	575105573.54478	20
100000000	1e-05	2396658611.43985	17
100000000	1e-06	2875527867.7239	20
100000000	1e-07	3354894536.66848	23

过于密集的hash functions 导致了大量的冲突，使得实际的error rate 与预期的相差很远！

无奈之下，最后还是选择了最原始的方法选择来可以接受的结果。最后得到下面的结果：

keys	error rate	bits size	hash functions
<20000000		100000000	3

注：
[1]，请直接访问 Using Bloom Filters 以获得方法的最新版本。

基于Bekerley DB的排重

基于bekerley db 的排重结果：6340260 rows duplicated [total:13195827, deleted: 0, malformed:0]

基于bloom filter 的排重结果：6482366 rows duplicated [total:13195827, deleted: 0, malformed:0]

对13m的数据进行排重处理，实际重复的数据为6.34m，而bloom filter 过滤的结果是6.48m。

Sunday, June 3, 2007

重新开始sf search 的开发

重新拾起sf search 的开发

经过长时间的搁置，sf search 的升级与开发工作又重新被提上了日程。此次的升级面临着更多更棘手的问题：

千万级别的数据
100次每秒的请求
分钟级别的数据同步
更过扩展功能的支持

一个众人瞩目的项目/产品。

还是基于Lucene

因为短时间内找不到更好的lucene（java）替代品，所以近期的升级与改进还是基于lucene。

针对目前sfsearch 所存在的问题，近期会着重解决：

索引的存储
索引的更新周期
I/O 优化

SF Search Blog