coreseek/sphinx文档摘要_综合

1.这些都可以用charset_type 和 charset_table 选项为每个索引单独配置.charset_type指定文档的编码是单字节的（SBCS）还是UTF-8的。在Coreseek中，如果通过charset_dictpath设置中文词典启动了中文分词模式后，不仅可以使用UTF-8编码的，还可以使用GBK及BIG5的编码（需要编译时提供iconv支持）；但是在内部实现中，仍然是预先转换成UTF-8编码在进行处理的.charset_table则指定了字母类字符到它们的大小写转换版本的对应表，没有在这张表中出现的字符被认为是非字母类字符，并且在建立索引和检索时被当作词的分割符来看待。

在Coreseek中，启用中文分词后，系统会使用MMSeg内置的码表（被硬编码在MMSeg的程序中），因此，charset_table在启用分词后将失效。

2.由于历史原因，PHP API对结果集的行进行按文档ID的有序hash，因此用PHP API进行对MVA属性的分组操作时你还需要使用 SetArrayResult().

3.当采用外部存储方式时，searchd总是在RAM中保持一份.spa文件的拷贝（该文件包含所有文档的所有文档信息）。这是主要是为了提高性能，因为磁盘的随机访问太慢了。相反，内联存储并不需要任何额外的RAM，但代价是索引文件的体积大大地增加了；请注意，全部属性值在文档ID出现的每一处都被复制了一份，而文档ID出现的次数恰是文档中不同关键字的数目。仅当有一个很小的属性集、庞大的文本数据集和受限的RAM时，内联存储才是一个可考虑的选择。在大多数情况下，外部存储可令建立索引和检索的效率都大幅提高。

检索时，采用外部存储方式产生的的内存需求为 (1+属性总数)*文档总数*4字节，也就是说，带有两个属性和一个时间戳的1千万篇文档会消耗(1+2+1)*10M*4 = 160 MB的RAM。这是每个检索的守护进程（PER DAEMON）消耗的量，而不是每次查询，searchd仅在启动时分配160MB的内存，读入数据并在不同的查询之间保持这些数据。子进程并不会对这些数据做额外的拷贝。

对于所有的基于SQL驱动，建立索引的过程如下：

连接到数据库;
执行预查询 (参见第 11.1.11 节 “sql_query_pre：待索引数据获取前查询”) ，以便完成所有必须的初始设置，比如为MySQL连接设置编码;
执行主查询 (参见第 11.1.12 节 “sql_query：获取待索引数据查询”) ，其返回的的数据将被索引;
执行后查询 (参见第 11.1.30 节 “sql_query_post：数据获取后查询”) ，以便完成所有必须的清理工作;
关闭到数据库的连接;
对短语进行排序 (或者学究一点, 索引类型相关的后处理);
再次建立到数据库的连接;
执行索引后查询 (参见第 11.1.31 节 “sql_query_post_index：数据索引后查询”) ，以便完成所有最终的清理善后工作;
再次关闭到数据库的连接.

索引系统需要通过主查询来获取全部的文档信息，一种简单的实现是将整个表的数据读入内存，但是这可能导致整个表被锁定并使得其他操作被阻止（例如：在MyISAM格式上的INSERT操作），同时，将浪费大量内存用于存储查询结果，诸如此类的问题吧。为了避免出现这种情况，CoreSeek/Sphinx支持一种被称为 区段查询的技术.首先，CoreSeek/Sphinx从数据库中取出文档ID的最小值和最大值，将由最大值和最小值定义自然数区间分成若干份，一次获取数据，建立索引。现举例如下：

例 3.1. 范围查询用法举例

# in sphinx.confsql_query_range	= SELECT MIN(id),MAX(id) FROM documents
sql_range_step = 1000
sql_query = SELECT * FROM documents WHERE id>=$start AND id<=$end

如果这个表（documents）中，字段ID的最小值和最大值分别是1 和2345，则sql_query将执行3次：

将 $start 替换为1，并且将 $end 替换为 1000;
将 $start 替换为1001，并且将 $end 替换为 2000;
将 $start 替换为2001，并且将 $end 替换为 2345.

显然，这对于只有2000行的表，分区查询与整个读入没有太大区别，但是当表的规模扩大到千万级（特别是对于MyISAM格式的表），分区区段查询将提供一些帮助。

6.合并两个已有的索引比重新对所有数据做索引更有效率，而且有时候必须这样做（例如在“主索引＋增量索引”分区模式中应合并主索引和增量索引，而不是简单地重新索引“主索引对应的数据）

基本的命令语法如下：

indexer --merge DSTINDEX SRCINDEX [--rotate]

SRCINDEX的内容被合并到DSTINDEX中，因此只有DSTINDEX索引会被改变。若DSTINDEX已经被searchd于提供服务，则--rotate参数是必须的。最初设计的使用模式是，将小量的更新从SRCINDEX合并到DSTINDEX中。因此，当属性被合并时，一旦出现了重复的文档ID，SRCINDEX中的属性值更优先（会覆盖DSTINDEX中的值）。不过要注意，“旧的”关键字在这个过程中并不会被自动删除。例如，在DSTINDEX中有一个叫做“old”的关键字与文档123相关联，而在SRCINDEX中则有关键字“new”与同一个文档相关，那么在合并后用这两个关键字都能找到文档123。您可以给出一个显式条件来将文档从DSTINDEX中移除，以便应对这种情况，相关的开关是--merge-dst-range:

indexer --merge main delta --merge-dst-range deleted 0 0

这个开关允许您在合并过程中对目标索引实施过滤。过滤器可以有多个，只有满足全部过滤条件的文档才会在最终合并后的索引中出现。在上述例子中，过滤器只允许“deleted”为0的那些条件通过，而去除所有标记为已删除（“deleted”）的记录（可以通过调用UpdateAttributes()设置文档的属性）。

7.. RT实时索引定义

index rt
{type = rtpath = /usr/local/sphinx/data/rtrt_field = titlert_field = contentrt_attr_uint = gid
}

RT索引目前还在继续开发完善中（从版本1.10-beta开始）。因此，他可能缺乏某些特定的功能：例如，前缀/中缀索引，MVA属性等目前尚不支持。但是，所有常规索引功能和搜索功能都已经实现，并且经过了内部的测试。我们还有一些实际运营生产环境（并非最不重要的部分）已经在使用RT索引，并且取得了较好的效果。