Sphinx 的那些麻烦事

Sphinx 搭了一个全文检索。虽说 Sphinx 本身已经实现了很多功能,简单应用基本只需要配置就行用,不需要做很多开发。但我做的玩意不简单,所以还是碰到了不少麻烦事。

一个是分布式索引更新问题。文档里说是分布式索引也支持更新。但我搭了一个两层的索引,第一层是 remote 的,第二层是 local 的,结果就返回0(失败)。后来咨询了一下,再试验了一下,发现单层的分布索引没问题,两层 remote 或者两层 local 也没问题,就是混用不行…… 不清楚这么设计的意图是啥。

Sphinx 出于搜索性能考虑,并没有直接实现增量索引功能,需要自己实现。一般是先为增量部分单独建一个小索引,然后合并回原来的索引。虽然会引起两倍于原索引的IO,但速度还挺快。

配置文件不灵活也是个缺点。Sphinx 的配置文件不支持 include 。每个不同的 searchd 实例需要加载不同的配置文件。如果不同的配置文件里有不少重复的部分,每个 copy 一份维护就麻烦。只好用模版程序生成了。我用的 coreseek 的版本。其中加入了一个 python 数据源。我用它包装了一个 json pipe 数据源。然后需要配置一个命令行命令。然后发现,所有能用的配置项都写死在了程序里。只有这些配置项能用。想增加新的配置项只有去改源代码。为了避免以后维护补丁的麻烦,就只好复用原来的 xmlpipe_command 了。好歹是个 command……

Sphinx 还是不够成熟,但对于小型网站来说足够简单易用,功能很丰富,性能也很好,并且有许多语言的绑定。但是在可扩展性和二次开发上还是不够。

 

Chrome 的数组遍历顺序问题

昨天发现 Chrome 在遍历一个键名为数字形式的字符串的对象时,并不是像其他浏览器一样按定义的顺序。

  
var hash = {‘3′:3,’1′:1,’5′:5,’2′:2,’4’:4};
var s = ”;
for (var k in hash) {
s+= k+’:’+hash[k]+”n”;
}
alert(s);
  

比如这个代码,在其他浏览器里都是31524,在 Chrome 里却是 12345 。当然 Chrome 也不是就把它们排序了,试试其他的数字,比如 {‘7553′:1,’5441′:2,’77335′:3,’222′:4,’1114’:5} 。

去看了一下 ECMAScript 草案,倒也没规定对象属性的遍历的顺序什么的。所以在遍历对象的时候最好不要依赖于属性的特定顺序。