Sphinx 1.10-beta实时索引等新特性的体验报告——sphinx新特性体验(二)

sphinx 1.10推出了很多新特性:

比如:实时索引,字符串属性,prefork 和 threads支持,及SphinxSE 中的option添加等

详细请查阅原文:http://www.sphinxsearch.com/docs/manual-1.10.html#rel110

个人觉得 sphinx 1.10-beta 两个最大的新特性:字符串索引和实时索引。对sphinx使用来说是一个很大的飞跃

字符串索引:可以很方便的存储,如果结合实时索引的话,就已经形成了貌似nosql一样的数据缓存层。而且,很多数据不必二次在数据库中查询,自然对
程序开发和运维有很大的帮助。检索出来后直接使用其数据,不过这个和所有缓存数据一样,注意在数据更新操作的时候需要同步更新这里的sql_attr_string
或rt_attr_string

实时索引(Real-time indexes):
优点:
此功能是个人对sphinx的最大期待。在正式部署中,sphinx real-time 可以当成一个类似 memcache的数据存储插件,充分利用其查询、分布式
部署的便捷性,做到数据层次化管理。缓解数据库的压力。同时还支持事务操作,这个在很多nosql中是所缺少的。这,简直就是sql和nosql的混合体啊^_^

不足:
今天特别对实时索引进行了功能性的测试。虽然此功能很新颖且实用。但现阶段,若部署在生产环境下可能会遇到以下几个问题:

a、数据插入问题:Real-time的功能采取的是类似 标准sql的语句执行数据存储。如:

insert into(id,gid,title,content) values(1,234,’hello sphinx ‘,’I am superman!’);

这里的id必须人工计算:不能像mysql的auto_increment对主键进行自动累加。
另外,不能使用标准sql 的函数 max获取最大值,如:select max(id) from testrt,(sphinxQL中提示可以使用函数,但我在尝试过,系统提示语法错误,可能暂时只针对 非实时索引sphinxSE方式)
如果数据多的话,而且并发量比较大的话,在程序端实现起来自然会出现异常。

我这里暂时采用了一个办法处理这个问题:
查询 最大的id,并每次进行累加

select * from testrt order by id desc limit 1;

获取结果集的 id即为最大,相当于mysql中的auto_increment 变量。然后再对每次数据插入进行累加。具体做法可以参照前一篇的程序代码

b、数据删除:只能使用唯一的语句 delete from testrt where id=123; 如果数据量大的话,必须在逻辑层循环删除。而且不支持 in操作,不过文档中已提到,in操作已经在
计划中了,期待着。 另外,不能全部清空数据,不能像 数据库操作的 truncate table那样便捷。若索引很大并想重建索引的话,那就。。。等着抓狂吧

c、索引数据更新:sphinx没有提供标准sql的update操作(其实也没必要),而是采取了类似mysql 的replace 语法。
实例:repalce into(id,gid,title,content) values(1,234,’hello sphinx ‘,’I am superwomen!’); 不过遗憾的是不能进行条件更新

d、查询:Real-time的sql查询还是很方便,或者很健全,比如:对字段查询、属性过滤、分组聚合、排序、评分等。完全满足一个搜索引擎的查询需求。但此版本还是缺少支持一些
数据库的常用函数。正如刚才提到的max、min等;以及对字段的较复杂的操作。
比如:select count(gid) as amount from testrt;就会报语法错误,这个例子可以采取变通的方式处理

select * from testrt group by gid;

其结果集中存在 @groupby @count变量值

文档中有提及在sphinxSE中可以使用函数,不过在这里暂时用不了,还是期待!

综上所述:sphinx的实时索引特性,暂时在生产部署上功能可能欠缺一些,必须采用其他办法变通,故,生产需谨慎,还是期待正式版吧!

以上即是对sphinx 1.10的2个新特性的体验报告^_^。当然以上的结论只是因个人在工作中可能会遇到的问题而提出的,我不能期望sphinx完全取代数据库
但是,sphinx小弟弟,你能帮就多帮帮你大哥mysql吧,你看他每天累得cpu冒汗,还分布式的累,不容易啊!

分享到QQ空间

Comments are closed.