sphinx.conf/csft.conf配置

目录

11.1. 数据源配置选项

11.1.1. type:数据源类型

数据源类型。必须选项,无默认值。 可用的类型包括 mysql, pgsql, mssql, xmlpipe and xmlpipe2, odbc,以及python.

在CoreSeek的分发版本中,新增了python数据源类型,从而得以启用Python数据源支持。

所有其他与数据源相关的选项都依赖于这个选项指定的源类型。与SQL数据源(即MSSQL、MySQL和PostgreSQL)相关的选项以“sql_”开头,而与xmlpipe和xmlpipe2数据源相关的选项则以“xmlpipe_”开头。 除了xmlpipe是默认支持外,其他数据源类型的支持是有前提条件的;依赖与您的设置和已安装的数据库客户端库文件,它们可能被支持或者不被支持。例如,mssql仅在Windows系统提供支持。odbc在Windows系统上是原生支持,而在Linux系统上通过UnixODBC library支持。

在CoreSeek的分发版本中,python通过Python提供支持,在安装了Pythin的Windows系统和Linux系统上都可以支持。

示例:

type = mysql

11.1.2. sql_host:数据库服务器

要连接的SQL服务器主机地址。必须选项,无默认值。仅对SQL数据源(mysql, pgsql, mssql)有效。

最简单的情形下,Sphinx与MySQL或PostgreSQL服务器安装在同一台主机上,此时您只须设置为localhost即可。注意,MySQL 客户端库根据主机名决定是通过TCP/IP还是UNIX socket连接到服务器。一般来说,“localhost”使之强制使用UNIX socket连接(这是默认的也是推荐的模式),而“127.0.01”会强制使用TCP/IP。细节请参考 MySQL manual

示例:

sql_host = localhost

11.1.3. sql_port:数据库端口

要连接的SQL服务器的IP端口。可选选项,默认值为mysql端口3306,pgsql端口5432。仅适用于SQL数据源(mysql, pgsql, mssql)。注意,此选项是否实际被使用依赖于sql_host选项。

示例:

sql_port = 3306

11.1.4. sql_user:数据库用户名

连接到sql_host时使用的SQL用户名。必须选项,无默认值。仅适用于SQL数据源(mysql, pgsql, mssql)。

示例:

sql_user = test

11.1.5. sql_pass:数据库密码

连接到sql_host时使用的SQL用户密码。必须选项,无默认值。 仅适用于SQL数据源(mysql, pgsql, mssql)。

示例:

sql_pass = mysecretpassword

11.1.6. sql_db:数据库名称

连接到SQL数据源之后使用的SQL数据库,此后的查询均在此数据库上进行。必须选项,无默认值。 仅适用于SQL数据源(mysql, pgsql, mssql)。

示例:

sql_db = test

11.1.7. sql_sock:数据库Socket文件

连接到本地SQL服务器时使用的UNIX socket名称。可选选项,默认值为空(使用客户端库的默认设置)。 仅适用于SQL数据源(mysql, pgsql, mssql)。

在Linux上,通常是/var/lib/mysql/mysql.sock。 而在FreeBSD上通常是/tmp/mysql.sock。注意此选项是否实际被使用依赖与sql_host的设置。

示例:

sql_sock = /tmp/mysql.sock

11.1.8. mysql_connect_flags:MySQL连接参数

MySQL客户端的连接标志(connection flags)。可选选项,默认值为0(不设置任何标志)。仅适用于mysql数据源。

此选项必须包含各标志相加所得的整型值。此整数将被原样传递给mysql_real_connect() 。 可用的标志在mysql_com.h中列举。下面列举的是几个与索引相关的标志和它们的值:

  • CLIENT_COMPRESS = 32; 允许使用压缩协议 protocol

  • CLIENT_SSL = 2048; 握手后切换到SSL

  • CLIENT_SECURE_CONNECTION = 32768; 新的MySQL 4.1版本身份认证

例如,标志2080(2048+32)代表同时使用压缩和SSL,32768代表仅使用新的身份验证。起初这个选项是为了在indexermysql位 于不同主机的情况下使用压缩协议而引入的。尽管降低了网络带宽消耗,但不管在理论上还是在现实中,在1Gbps的链路上启用压缩很可能恶化索引时间。然而 在100Mbps的连输上启用压缩可能会明显地改善索引时间(有报告说总的索引时间降低了20-30%)。根据您网络的连接情况,您获得的改善程度可能会 有所不同。

示例:

mysql_connect_flags = 32 # 启用压缩

11.1.9. mysql_ssl_cert, mysql_ssl_key, mysql_ssl_ca:MySQL的SSL连接

连接MySQL服务器时使用的SSL认证选项。可选参数,默认值是空串(即不使用SSL认证)。 仅适用于mysql数据源。

这些指令用来在indexer和MySQL之间建立安全的SSL连接。关于怎样建立认证机制和设置MySQL服务器的信息可以参考MySQL文档。

示例:

mysql_ssl_cert = /etc/ssl/client-cert.pem
mysql_ssl_key = /etc/ssl/client-key.pem
mysql_ssl_ca = /etc/ssl/cacert.pem

11.1.10. odbc_dsn:ODBC连接字符串(DSN)

要连接的ODBC DSN。必须选项,没有默认值。 仅适用于odbc数据源。

DBC DSN(数据源名字,Data Source Name)指定了连接ODBC数据源时使用的认证选项(主机地址,用户名,密码等)。具体的格式与ODBC的具体驱动有关。

示例:

odbc_dsn = Driver={Oracle ODBC Driver};Dbq=myDBName;Uid=myUsername;Pwd=myPassword

11.1.11. sql_query_pre:待索引数据获取前查询

索引数据获取前执行的查询(pre-fetch query),或预查询(pre-query)。多值选项,可选选项,默认为一个空的查询列表。 仅适用于SQL数据源(mysql, pgsql, mssql)。

多值意思是您可以多次设置该指令,从而指定多个预查询。它们在索引数据获取查询sql_query之前执行,而且会严格按照在配置文件中出现的顺序执行。预查询的结果会被忽略。

预查询在很多时候有用。它们被用来设置字符集编码,标记待索引的记录,更新内部计数器,设置SQL服务器连接选项和变量等等。

也许预查询最常用的一个应用就是用来指定服务器返回行时使用的字符编码。这必须与Sphinx期待的编码相同(在charset_type charset_table 选项中设置)。以下是两个与MySQL有关的设置示例:

sql_query_pre = SET CHARACTER_SET_RESULTS=cp1251
sql_query_pre = SET NAMES utf8

对于MySQL数据源,在预查询中禁用查询缓冲(query cache)(仅对indexer连接)是有用的,因为索引查询一般并会频繁地重新运行,缓冲它们的结果是没有意义的。这可以按如下方法实现:

sql_query_pre = SET SESSION query_cache_type=OFF

示例:

sql_query_pre = SET NAMES utf8
sql_query_pre = SET SESSION query_cache_type=OFF

11.1.12. sql_query:获取待索引数据查询

获取即将索引的文档(数据)的主查询。必须的选项,无默认选项。 仅适用于SQL数据源(mysql, pgsql, mssql)。

只能有一个主查询。它被用来从SQL服务器获取文档(文档列表)。可以指定多达32个全文数据字段(严格来说是在sphinx.h中定义的SPH_MAX_FIELDS个)和任意多个属性。所有既不是文档ID(第一列)也不是属性的列的数据会被用于建立全文索引。

文档ID必须是第一列,而且必须是唯一的正整数值(不能是0也不能是负数),既可以是32位的也可以是64位的,这要根据Sphinx是如何被构建的,默认情况下文档ID是32位的,但在运行configure脚本时指定--enable-id64选项会打开64位文档ID和词ID的支持。

示例:

sql_query = \
	SELECT id, group_id, UNIX_TIMESTAMP(date_added) AS date_added, \
		title, content \
	FROM documents

11.1.13. sql_joined_field:SQL连接字段设置

连接/有效载荷字段获取查询。 多值选项,可选,默认值为空。 仅对SQL数据源有效 (mysql, pgsql, mssql) .

sql_joined_field 提供两种不同的方式:连接字段,或者有效载荷(有效载荷字段)。其语法格式如下:

sql_joined_field = FIELD-NAME 'from'  ( 'query' | 'payload-query' ); \
    QUERY [ ; RANGE-QUERY ]

where

  • FIELD-NAME 是 连接/有效载荷 字段名称;

  • QUERY 是一个用于获取数据到索引的SQL查询.

  • RANGE-QUERY 是一个可选的用于获取范围知道索引的SQL查询. (版本2.0.1-beta增加.)

Joined fields let you avoid JOIN and/or GROUP_CONCAT statements in the main document fetch query (sql_query). This can be useful when SQL-side JOIN is slow, or needs to be offloaded on Sphinx side, or simply to emulate MySQL-specific GROUP_CONCAT funcionality in case your database server does not support it.

The query must return exactly 2 columns: document ID, and text to append to a joined field. Document IDs can be duplicate, but they must be in ascending order. All the text rows fetched for a given ID will be concatented together, and the concatenation result will be indexed as the entire contents of a joined field. Rows will be concatenated in the order returned from the query, and separating whitespace will be inserted between them. For instance, if joined field query returns the following rows:

( 1, 'red' )
( 1, 'right' )
( 1, 'hand' )
( 2, 'mysql' )
( 2, 'sphinx' )

then the indexing results would be equivalent to that of adding a new text field with a value of 'red right hand' to document 1 and 'mysql sphinx' to document 2.

Joined fields are only indexed differently. There are no other differences between joined fields and regular text fields.

Starting with 2.0.1-beta, ranged queries can be used when a single query is not efficient enough or does not work because of the database driver limitations. It works similar to the ranged queries in the main indexing loop, 参见 第 3.7 节 “区段查询”. The range will be queried for and fetched upfront once, then multiple queries with different $start and $end substitutions will be run to fetch the actual data.

Payloads let you create a special field in which, instead of keyword positions, so-called user payloads are stored. Payloads are custom integer values attached to every keyword. They can then be used in search time to affect the ranking.

The payload query must return exactly 3 columns: document ID; keyword; and integer payload value. Document IDs can be duplicate, but they must be in ascending order. Payloads must be unsigned integers within 24-bit range, ie. from 0 to 16777215. For reference, payloads are currently internally stored as in-field keyword positions, but that is not guaranteed and might change in the future.

Currently, the only method to account for payloads is to use SPH_RANK_PROXIMITY_BM25 ranker. On indexes with payload fields, it will automatically switch to a variant that matches keywords in those fields, computes a sum of matched payloads multiplied by field wieghts, and adds that sum to the final rank.

示例:

sql_joined_field = \
	tagstext from query; \
	SELECT docid, CONCAT('tag',tagid) FROM tags ORDER BY docid ASC

11.1.14. sql_query_range:分区查询范围

分区查询设置。可选选项,默认为空。 仅适用于SQL数据源(mysql, pgsql, mssql)。

设置这个选项会启用文档的区段查询(参看第 3.7 节 “区段查询”)。分区段查询有助于避免在索引大量数据时发生MyISAM表臭名昭著的死锁问题。(同样有助于解决其他不那么声名狼藉的问题,比如大数据集上的性能下降问题,或者InnoDB对多个大型读事务(read transactions)进行序列化时消耗额外资源的问题。)

此选项指定的查询语句必须获取用于分区的最小和最大文档ID。它必须返回正好两个整数字段,先是最小ID然后是最大ID,字段的名字会被忽略。

当启用了分区段查询时,sql_query要求包括$start  $end宏(因为重复多次索引整个表显然是个错误)。注意,$start .. $end所指定的区间不会重叠,因此不会在查询中删除ID正好等于$start  $end的文档。第 3.7 节 “区段查询”中的例子解释了这个问题,注意大于等于或小于等于比较操作是如何被使用的。

示例:

sql_query_range = SELECT MIN(id),MAX(id) FROM documents

11.1.15. sql_range_step:分区查询步进值

区段查询的步进值。可选选项,默认为1024。 仅适用于SQL数据源(mysql, pgsql, mssql)。

仅当启用ranged queries 时有效。用sql_query_range 取得的文档ID区间会被以这个不小的间隔步数跳跃遍历。例如,如果取得的最小和最大ID分别是12和3456,而间隔步数是1000,那么indexer会用下面这些值重复调用几次sql_query

  • $start=12, $end=1011

  • $start=1012, $end=2011

  • $start=2012, $end=3011

  • $start=3012, $end=3456

示例:

sql_range_step = 1000

11.1.16. sql_query_killlist:Kill-list查询

用于得到Kill-list的查询。可选选项,默认为空(不设定查询)。 仅适用于SQL数据源(mysql, pgsql, mssql)。 版本0.9.9-rc1引入.

这个查询返回的结果集应该只有一列,每行是一个文档ID。返回的这些文档ID将被存储在一个索引里。根据查询中提到的索引的顺序,一个索引的kill-list会抑制来自其他(顺序在其前面)索引的结果。这个设计的目的是要帮助用户实现在现有索引上的删除或者更新,而不用重建索引(甚至根本不用访问这个索引),尤其是为了结果解决“幽灵结果”问题。

让我们来分析一个实际的例子。假设我们有两个索引,‘main’和‘delta’。假设文档2、3和5在上一次重建索引‘main’的时候就被删除了,而 文档7和文档11则被更新了(即他们的文字内容发生了变化)。假设在建立索引‘main’的时候,关键字‘test’在所有这些提到的文档中都出现了。而 当我们建立索引‘delta’的时候文档7中也出现了关键字‘test’,但是文档11中不再有关键字‘test’了。现在我们重新建立索引 ‘delta’,然后以合适的顺序(较旧的排在较新的之前)对这两个索引进行检索:

$res = $cl->Query ( "test", "main delta" );

首先,我们要正确地处理删除的情况。结果集合不应该包含文档2、3或5。其次,我们也要避免出现幽灵结果。如果我们不做点什么,文档11就会出现在搜索结果中。因为它会被在‘main’中查到(但在‘delta’中查不到它),并出现在最终的结果集合中,除非我们做点什么防止这种情况的发生。

Kill-list,或者缩写成K-list就是我们要做的。附加在‘delta’索引上的Kill-list会屏蔽掉前面所有各索引中检索到的特定行,在这个例子中,也就是‘main’中的行。因此,想要得到预期的结果,我们应该将更新了的删除了的文档ID都放进Kill-list。

示例:

sql_query_killlist = \
	SELECT id FROM documents WHERE updated_ts>=@last_reindex UNION \
	SELECT id FROM documents_deleted WHERE deleted_ts>=@last_reindex

11.1.17. sql_attr_uint:整数属性

声明无符号整数属性(attribute)。可声明同一类型的多个不同名称的属性,可选项。 仅适用于SQL数据源(mysql, pgsql, mssql)。

被声明的列的值必须在32位无符号整型可表示的范围内。超出此范围的值也会被接受,但会溢出。例如-1会变成 2^32-1 或者说4,294,967,295。

您可以在属性名后面附加“:BITCOUNT”(见下面的示例)以便指定整型属性的位数。属性小于默认32位(此时称为位域)会有损性能。但它们在外部存储(extern storage)模式下可以节约内存:这些位域被组合成32位的块存储在.spa属性数据文件中。如果使用内联存储(inline storage),则位宽度的设置会被忽略。

示例:

sql_attr_uint = group_id
sql_attr_uint = forum_id:9 # 9 bits for forum_id

11.1.18. sql_attr_bool:布尔属性

声明布尔属性(attribute)。可声明同一类型的多个不同名称的属性,可选项。仅适用于SQL数据源(mysql和pgsql)。 仅适用于SQL数据源(mysql, pgsql, mssql)。 等价于用sql_attr_uint声明为1位。

示例:

sql_attr_bool = is_deleted # 将被编码为1个bit

11.1.19. sql_attr_bigint:长整型属性

64位整数属性(attribute)声明。多个值(可以同时声明多个属性),可选选项。 仅适用于SQL数据源(mysql, pgsql, mssql)。 注意,与sql_attr_uint不同,这些值是有符号的。于版本0.9.9-rc1引入。

示例:

sql_attr_bigint = my_bigint_id

11.1.20. sql_attr_timestamp:UNIX时间戳属性

声明UNIX时间戳属性(attribute)。可声明同一类型的多个不同名称的属性,可选项。 仅适用于SQL数据源(mysql, pgsql, mssql)。

这个列的值必须是UNIX格式的时间戳,即32位无符号整数表示的自格林尼治平时1970年1月1日午夜起过去的秒数。时间戳在内部是按整数值存储和处理 的。但除了将时间戳按整数使用,还可以对它们使用多种与日期相关的函数——比如时间段排序模式,或为分组(GROUP BY)抽取天/星期/月/年。注意MySQL中的DATE和DATETIME列类型不能直接作为时间戳使用,必须使用UNIX_TIMESTAMP函数将这些列做显式转换。

请注意MySQL的DATE或者DATETIME字段类型不能直接在Sphinx之中作为timestamp属性使用;如果这样的字段需要在Sphinx中进行范围过滤,在sql_query中你需要明确使用MySQL的UNIX_TIMESTAMP函数来转换这样的字段。

还必须注意的是UNIX时间戳不支持1970年1月1日之前的日期,在MySQL中使用UNIX_TIMESTAMP()时将不会返回预期的结果。如果你 只需要处理日期而不是时间(小时或者分钟或者秒),可以考虑使用MySQL的TO_DAYS()函数(从年份0开始的天数)。

示例:

sql_attr_timestamp = UNIX_TIMESTAMP(added_datetime) AS added_ts

11.1.21. sql_attr_str2ordinal:字符串序数排序属性

声明字符串序数属性(属性 )。可声明同一类型的多个不同名称的属性,可选项。 仅适用于SQL数据源(mysql, pgsql, mssql)。

这个属性类型(简称为字串序数)的设计是为了允许按字符串值排序,但不存储字符串本身。对字串序数做索引时,字符串值从数据库中取出、暂存、排序然后用它们在该有序数组中的序数代替它们自身,因此字串序数是个整型,对它们的大小比较与在原字串上做字典序比较结果相同。

早期版本上,对字串序数做索引可能消耗大量的RAM。自svn r1112起,字串序数的积累和排序也可在固定大小的内存中解决了(代价是额外的临时磁盘空间),并受 mem_limit 设置限制。

理想中字符串可以根据字符编码和本地字符集(locale)排序。例如,如果已知字符串为KOI8R编码下的俄语字串,那么对字节0xE0,0xE1和 0xE2排序结果应为0xE1,0xE2和0xE0,因为0xE0在KOI8R中代表的字符明显应在0xE1和0xE2之后。但很不幸,Sphinx目前 不支持这个功能,而是简单地按字节值大小排序。

请注意,这里的序号是每个索引根据自身数据计算的,因此在同时读取多个索引事实无法同时保留正确的顺序进行合并的。处理后的字符串被替换为处理时其在索引 中的序列号,但是不同的索引具有不同的字符串集。例如,如果'main'索引包含字符串"aaa", "bbb", "ccc", 直到 "zzz",它们将会被分别分配数值为1,2,3,直到26。但是'delta'如果仅包含"zzz",则会被分配数值1。那么在合并后,该顺序将被打 乱。不幸的是,在不存储原始字符串的情况下,这个问题无法解决(一旦存储原始字符串,序号将没有任何用处了)。

示例:

sql_attr_str2ordinal = author_name

11.1.22. sql_attr_float:浮点数属性

声明浮点型属性 attribute 。 可声明同一类型的多个不同名称的属性,可选项。 仅适用于SQL数据源(mysql, pgsql, mssql)。

属性值按单精度32位IEEE754格式存储。可表示的范围大约是1e-38到1e+38。可精确表示的小数大约是7位。浮点属性的一个重要应用是存储经度和纬度值(以角度为单位),经纬度值在查询时的地理位置距离计算中有用。

示例:

sql_attr_float = lat_radians
sql_attr_float = long_radians

11.1.23. sql_attr_multi:多值属性(MVA)属性

声明多值属性(多值属性 ,MVA)). 可声明同一类型的多个不同名称的属性,可选项。 仅适用于SQL数据源(mysql, pgsql, mssql)。

简单属性每篇文档只允许一个值。然而有很多情况(比如tags或者类别)需要将多个值附加给同一个属性,而且要对这个属性值列表做过滤或者分组。

声明格式如下(用反斜线只是为了清晰,您仍可以在一行之内完成声明):

sql_attr_multi = ATTR-TYPE ATTR-NAME 'from' SOURCE-TYPE \
	[;QUERY] \
	[;RANGE-QUERY]

其中

  • ATTR-TYPE 是 'uint' 或者 'timestamp' 之一

  • SOURCE-TYPE 是 'field', 'query', 或者 'ranged-query' 之一

  • QUERY 是用来取得全部(文档ID,属性值)序对的SQL查询

  • RANGE-QUERY 是用来取得文档ID的最小值与最大值的SQL查询,与'sql_query_range'类似

示例:

sql_attr_multi = uint tag from query; SELECT id, tag FROM tags
sql_attr_multi = uint tag from ranged-query; \
	SELECT id, tag FROM tags WHERE id>=$start AND id<=$end; \
	SELECT MIN(id), MAX(id) FROM tags

11.1.24. sql_attr_string:字符串属性(可返回原始文本信息)

字符串属性定义。 多值选项(即可以有一个或多个这样子的定义),可选项。仅对SQL数据源类型有效 (mysql, pgsql, mssql) 。 版本2.0.1-beta引入。

String attributes can store arbitrary strings attached to every document. There's a fixed size limit of 4 MB per value. Also, searchd will currently cache all the values in RAM, which is an additional implicit limit.

As of 1.10-beta, strings can only be used for storage and retrieval. They can not participate in expressions, be used for filtering, sorting, or grouping (ie. in WHERE, ORDER or GROUP clauses). Note that attributes declared using sql_attr_string will not be full-text indexed; you can use sql_field_string directive for that.

示例:

sql_attr_string = title # will be stored but will not be indexed

11.1.25. sql_attr_str2wordcount:文档词汇数记录属性

词汇数属性定义。多值选项(即可以有一个或多个这样子的定义),可选项。仅对SQL数据源类型有效 (mysql, pgsql, mssql) 。 版本2.0.1-beta引入。

Word-count attribute takes a string column, tokenizes it according to index settings, and stores the resulting number of tokens in an attribute. This number of tokens ("word count") is a normal integer that can be later used, for instance, in custom ranking expressions (boost shorter titles, help identify exact field matches, etc).

示例:

sql_attr_str2wordcount = title_wc

11.1.26. sql_column_buffers:结果行缓冲大小

每行缓冲大小。 可选项,默认值为空(自动计算大小)。 仅对SQL数据源类型有效 (mysql, pgsql, mssql) 。 版本2.0.1-beta引入。

ODBC and MS SQL drivers sometimes can not return the maximum actual column size to be expected. For instance, NVARCHAR(MAX) columns always report their length as 2147483647 bytes to indexer even though the actually used length is likely considerably less. However, the receiving buffers still need to be allocated upfront, and their sizes have to be determined. When the driver does not report the column length at all, Sphinx allocates default 1 KB buffers for each non-char column, and 1 MB buffers for each char column. Driver-reported column length also gets clamped by an upper limie of 8 MB, so in case the driver reports (almost) a 2 GB column length, it will be clamped and a 8 MB buffer will be allocated instead for that column. These hard-coded limits can be overridden using the sql_column_buffers directive, either in order to save memory on actually shorter columns, or overcome the 8 MB limit on actually longer columns. The directive values must be a comma-separated lists of selected column names and sizes:

sql_column_buffers = <colname>=<size>[K|M] [, ...]

示例:

sql_query = SELECT id, mytitle, mycontent FROM documents
sql_column_buffers = mytitle=64K, mycontent=10M

11.1.27. sql_field_string:字符串字段(可全文搜索,可返回原始文本信息)

组合字符串属性和全文字段定义。 Combined string attribute and full-text field declaration. 多值选项(即可以有一个或多个这样子的定义),可选项。 仅对SQL数据源类型有效 (mysql, pgsql, mssql) 。 版本2.0.1-beta引入。

sql_attr_string only stores the column value but does not full-text index it. In some cases it might be desired to both full-text index the column and store it as attribute. sql_field_string lets you do exactly that. Both the field and the attribute will be named the same.

示例:

sql_field_string = title # will be both indexed and stored

11.1.28. sql_field_str2wordcount:文档词汇数记录字段(可全文搜索,可返回原始信息)

组合词汇数属性与全文字段定义。 多值选项(即可以有一个或多个这样子的定义),可选项。 仅对SQL数据源类型有效 (mysql, pgsql, mssql) 。 版本2.0.1-beta引入。

sql_attr_str2wordcount only stores the column word count but does not full-text index it. In some cases it might be desired to both full-text index the column and also have the count. sql_field_str2wordcount lets you do exactly that. Both the field and the attribute will be named the same.

示例:

sql_field_str2wordcount = title # will be indexed, and counted/stored

11.1.29. sql_file_field:外部文件字段

实际数据存储于文件的字段定义。 仅对SQL数据源类型有效 (mysql, pgsql, mssql) 。 版本2.0.1-beta引入。

This directive makes indexer interpret field contents as a file name, and load and index the referred file. Files larger than max_file_field_buffer in size are skipped. Any errors during the file loading (IO errors, missed limits, etc) will be reported as indexing warnings and will not early terminate the indexing. No content will be indexed for such files.

示例:

sql_file_field = my_file_path # load and index files referred to by my_file_path

11.1.30. sql_query_post:数据获取后查询

取后查询。可选项,默认值为空。 仅适用于SQL数据源(mysql, pgsql, mssql)。

此查询在sql_query成功执行后立即执行。如果取后取查询产生了错误,该错误被当作警告被报告,但索引不会因此终止。取后查询的结果会被忽略。注意当取后查询执行时索引还尚未完成,而后面的索引仍然可能失败。因此在这个查询中不应进行任何永久性的更新。例如,不应在此查询中更新辅助表中存储的最近成功索引的文档ID值,请在后索引查询(索引后查询sql_query_post_index )中操作。

示例:

sql_query_post = DROP TABLE my_tmp_table

11.1.31. sql_query_post_index:数据索引后查询

索引后查询。可选项,默认值为空。 仅适用于SQL数据源(mysql, pgsql, mssql)。

此查询在索引完全成功结束后执行。如果此查询产生错误,该错误会被当作警告报告,但索引不会因此而终止。该查询的结果集被忽略。此查询中可以使用宏$maxid,它会被扩展为索引过程中实际得到的最大的文档ID。如果没有文档被索引,则$maxid会设置为0。

示例:

sql_query_post_index = REPLACE INTO counters ( id, val ) \
    VALUES ( 'max_indexed_id', $maxid )

11.1.32. sql_ranged_throttle:分区查询间隔时间

分区查询的间隔时间(throttling),单位是毫秒。可选选项,默认值为0(无间隔时间)。 仅适用于SQL数据源(mysql, pgsql, mssql)。

此选项旨在避免indexer对数据库服务器构成了太大的负担。它会使indexer在每个分区查询的步之后休眠若干毫秒。休眠无条件执行,并在取结果的查询之前执行。

示例:

sql_ranged_throttle = 1000 # sleep for 1 sec before each query step

11.1.33. sql_query_info_pre:命令行信息获取前查询

命令行查询前查询。 可选选项,默认为空。 仅对 mysql 数据源有效。

仅被命令行搜索所用,用来在命令行查询之前执行查询,一般用于设置查询的字符集编码

示例:

sql_query_info_pre = SET NAMES utf8

11.1.34. sql_query_info:命令行信息获取查询

文档信息查询。 可选选项,默认为空。 仅对 mysql 数据源有效。

仅被命令行搜索所用,用来获取和显示文档信息,目前仅对MySQL有效,且仅用于调试目的。此查询为每个文档ID获取CLI搜索工具要显示的文档信息。 它需要包含$id宏,以此来对应到查询的文档的ID。

示例:

sql_query_info = SELECT * FROM documents WHERE id=$id

11.1.35. xmlpipe_command:数据获取命令

调用xmlpipe流提供者的Shell命令。必须选项。仅对xmlpipe  xmlpipe2数据源有效。

指定的命令会被运行,其输出被当作XML文档解析。具体格式描述请参考 第 3.8 节 “xmlpipe 数据源”  第 3.9 节 “xmlpipe2 数据源” 

示例:

xmlpipe_command = cat /home/sphinx/test.xml

11.1.36. xmlpipe_field:字段设置

声明xmlpipe数据字段。可声明同一类型的多个不同名称的属性,可选项。仅对xmlpipe2数据源有效。参考 第 3.9 节 “xmlpipe2 数据源”.

示例:

xmlpipe_field = subject
xmlpipe_field = content

11.1.37. xmlpipe_field_string:字符串字段

xmlpipe字段和字符串属性定义。 多值,可选项。 仅对 xmlpipe2 数据源来性有效。参见 第 3.9 节 “xmlpipe2 数据源”. 版本2.0.1-beta引入。

Makes the specified XML element indexed as both a full-text field and a string attribute. Equivalent to <sphinx:field name="field" attr="string"/> declaration within the XML file.

示例:

xmlpipe_field_string = subject

11.1.38. xmlpipe_field_wordcount:词汇数存储字段

xmlpipe字段和词汇数属性定义。 多值,可选项。 仅对 xmlpipe2 数据源来性有效。参见 第 3.9 节 “xmlpipe2 数据源”. 版本2.0.1-beta引入。

Makes the specified XML element indexed as both a full-text field and a word count attribute. Equivalent to <sphinx:field name="field" attr="wordcount"/> declaration within the XML file.

示例:

xmlpipe_field_wordcount = subject

11.1.39. xmlpipe_attr_uint:整数属性

声明xmlpipe整型属性。可声明同一类型的多个不同名称的属性,可选项。仅对xmlpipe2数据源有效。语法与 sql_attr_uint相同。

示例:

xmlpipe_attr_uint = author

11.1.40. xmlpipe_attr_bool:布尔属性

声明xmlpipe布尔型属性。可声明同一类型的多个不同名称的属性,可选项。 仅对xmlpipe2数据源有效。语法与 sql_attr_bool相同。

示例:

xmlpipe_attr_bool = is_deleted # will be packed to 1 bit

11.1.41. xmlpipe_attr_timestamp:UNIX时间戳属性

声明xmlpipe UNIX时间戳属性。可声明同一类型的多个不同名称的属性,可选项。 仅对xmlpipe2数据源有效。语法与 sql_attr_timestamp相同。

示例:

xmlpipe_attr_timestamp = published

11.1.42. xmlpipe_attr_str2ordinal:字符串序列属性

声明xmlpipe字符序数属性。可声明同一类型的多个不同名称的属性,可选项。 仅对xmlpipe2数据源有效。语法与 sql_attr_str2ordinal相同。

示例:

xmlpipe_attr_str2ordinal = author_sort

11.1.43. xmlpipe_attr_float:浮点数属性

声明xmlpipe浮点型属性。可声明同一类型的多个不同名称的属性,可选项。 仅对xmlpipe2数据源有效。语法与 sql_attr_float相同。

示例:

xmlpipe_attr_float = lat_radians
xmlpipe_attr_float = long_radians

11.1.44. xmlpipe_attr_multi:多值属性

声明xmlpipe MVA属性。可声明同一类型的多个不同名称的属性,可选项。 仅对xmlpipe2数据源有效。

这个选项为xmlpipe2流声明一个MVA属性标签。该标签的内容会被试图解析成一个整型值的列表(数组),此列表构成一个MVA属性值,这与把MVA属性的数据源设置为“字段”时sql_attr_multi分析SQL列内容的方式类似。

示例:

xmlpipe_attr_multi = taglist

11.1.45. xmlpipe_attr_string:字符串属性

xmlpipe字符串定义。 多值,可选项。 Applies to xmlpipe2 source type only. 版本2.0.1-beta引入。

This setting declares a string attribute tag in xmlpipe2 stream. The contents of the specified tag will be parsed and stored as a string value.

示例:

xmlpipe_attr_string = subject

11.1.46. xmlpipe_fixup_utf8:UTF-8修复设置

在Sphinx端进行UTF-8验证和过滤,防止XML分析器因为碰上非UTF-8文档而犯疯卡死。可选选项,默认值为0。只适用于xmlpipe2数据源。 仅对xmlpipe2数据源有效。

在某些特定情况下很难甚至不可能保障输入的xmlpipe2文档体都是完美有效一致的UTF-8编码。例如,输入流中可能溜进一些特定国家的单字节编码文 本。Libexpat这个XML分析器非常脆弱,遇到这种情况就会停止工作。UTF-8修复(UTF-8 fixup)功能能让这种情况得到避免。当启动了修复选项的时候,Sphinx会对输入留进行预处理,其后再传给XML分析器,其间非法的UTF-8序列 全部被替换成空格。

示例:

xmlpipe_fixup_utf8 = 1

11.1.47. mssql_winauth:Windows集成认证

标志位,代表是否使用MS SQL的windows身份认证。布尔型,可选选项,默认值是0(假)。只适用于mssql数据源。于版本0.9.9-rc1引入。

这个选项指出在连接到MS SQL Server时时候使用现在正登录的windows账户的凭据作来进行身份验证。注意当searchd作为服务运行时,账户的用户名可能与安装这个服务的账户不同。

示例:

mssql_winauth = 1

11.1.48. mssql_unicode:Unicode设置

MS SQL编码类型标志位。布尔型,可选选项,默认值是0(假)。只适用于mssql数据源。于版本0.9.9-rc1引入。

这个选项指出在对MS SQL Server进行查询时,是使用Unicode还是单字节数据。这个标志位必须charset_type指令同步,也就是说,要索引Unicode数据,则既要设置charset_type选项(设为‘utf-8’),又要设置数据源的mssql_unicode选项(设为1)。多说一句:MS SQL实质上返回UCS-2编码的数据,而不是UTF-8,但Sphinx可以自动处理这个情况。

示例:

mssql_unicode = 1

11.1.49. unpack_zlib:SQL数据源解压字段设置

使用zlib(即gnuzip)来解压(unpack,deflate)的列。多个值,可选选项,默认值是列的空列表。仅适用于SQL数据源(mysql, pgsql, mssql)。于版本0.9.9-rc1引入。

indexer会使用标准zlib算法(称作deflate,gunzip也实现了这个算法)对这个选项指定的那些列进行解压缩。当建立索引的动作发生在数据库所在机器以外的机器时,这个选项会降低数据库的负载,并节约网络带宽。要想使用这个特性,就必须保证在建立时zlib和zlib-devel都是可用的。

示例:

unpack_zlib = col1
unpack_zlib = col2

11.1.50. unpack_mysqlcompress:MySQL数据源解压字段设置

使用MySQL UNCOMPRESS()算法解压的列。多个值,可选选项,默认值是列的空列表。仅适用于SQL数据源(mysql, pgsql, mssql)。于版本0.9.9-rc1引入。

indexer会使用MySQL COMPRESS()和UNCOMPRESS()使用的修改过的zlib算法对这个选项指定的那些列进行解压缩。 当建立索引的动作发生在数据库所在机器以外的机器时,这个选项会降低数据库的负载,并节约网络带宽。要想使用这个特性,就必须保证在建立时zlib和 zlib-devel都是可用的。

示例:

unpack_mysqlcompress = body_compressed
unpack_mysqlcompress = description_compressed

11.1.51. unpack_mysqlcompress_maxsize:MySQL数据源解压缓冲区设置

用于UNCOMPRESS()解压后数据的缓冲区大小。可选选项,默认值是16M。于版本0.9.9-rc1引入。

当使用unpack_mysqlcompress选项时,由于实现方法本质上的限制,不可能减小缓冲区大小方面的需求。因此缓冲区必须预先分配好,解压出的数据也不能超过缓冲区大小。这个选项控制这个缓冲区大小值,既可以用于限制indexer的内存使用,也可以用于在需要的时候使解压非常大的数据变为可能。

示例:

unpack_mysqlcompress_maxsize = 1M

11.2. 索引配置选项

11.2.1. type:索引类型设置

索引类型。可用的值包括plain(普通本地索引)、distributed(分布式)或rt(实时索引)。可选选项,默认值为plain(索引为普通本地索引)。

Sphinx支持几种不同的索引类型。 版本0.9.x支持两种索引类型:普通本地索引--在本机上存储和处理,和分布式索引--不仅涉及本地搜索,而且同时通过网络向远程searchd实例做查询(查看第 5.8 节 “分布式搜索”了解详情)。 版本1.10-beta也增加了被称为实时索引(简称为RT索引)的索引类型,它也支持在本机上存储和处理,除此之外还支持全文索引数据的即时更新(查看第 4 章 RT实时索引了解详情)。 需要提醒的是attributes值在普通本地索引或者RT索引中都可以被即时更新。

你可以根据需要设置索引内行。索引默认是普通本地索引。

示例:

type = distributed

11.2.2. source:文档源

向本地索引增加文档源。可以出现多次,必须选项。

为当前索引指定一个从中可以获取文档的文档源。必须至少有一个文档源。可以有多个文档源,任何数据源类型都可接受:即您可以从MySQL服务器中获取一部分数据,从PostgreSQL中获取另一部分,再在文件系统上使用xmlpipe2获取一部分。

然而,对源数据却有一些限制。首先,文档ID必须在所有源的总体上是唯一的。如果这个条件不满足,那可能导致非预期的搜索结果。其次,源的模式必须相同,以便在同一个索引中存储。

数据来源的ID不会被自动存储。因此,为了获知匹配的文档是从哪个数据源中来的,需要手工存储一些额外的信息。通常有两种方法:

  1. 修改文档ID,将源ID编码进去:

    source src1
    {
    	sql_query = SELECT id*10+1, ... FROM table1
    	...
    }
    
    source src2
    {
    	sql_query = SELECT id*10+2, ... FROM table2
    	...
    }
  2. 将数据来源存储为一个属性:

    source src1
    {
    	sql_query = SELECT id, 1 AS source_id FROM table1
    	sql_attr_uint = source_id
    	...
    }
    
    source src2
    {
    	sql_query = SELECT id, 2 AS source_id FROM table2
    	sql_attr_uint = source_id
    	...
    }

示例:

source = srcpart1
source = srcpart2
source = srcpart3

11.2.3. path:索引文件路径

索引文件的路径和文件名(不包括扩展名)。必须选项。

path既包括文件夹也包括文件名,但不包括扩展名。indexer在产生永久和临时索引文件的最终名字时会附加上不同的扩展名。永久数据文件有几个不同的扩展名,都以“.sp”开头,临时文件的扩展名以“.tmp”开头。如果indexer没有成功地自动删除.tmp*文件,手工删除是安全的。

以下是不同索引文件所存储的数据种类,供参考:

  • .spa 存储文档属性(仅在extern 文档信息存储模式中使用);

  • .spd 存储每个词ID可匹配的文档ID列表;

  • .sph 存储索引头信息;

  • .spi 存储词列表(词ID和指向.spd文件的指针);

  • .spk 存储kill-lists;

  • .spm 存储MVA数据;

  • .spp 存储每个词ID的命中(或者说记账,或者词的出现)列表;

  • .sps 存储字符串属性数据.

示例:

path = /var/data/test1

11.2.4. docinfo:文档信息存储模式

文档信息(docinfo)的存储模式。可选选项,默认是“extern”,可用的值包括'none', 'extern' 和 'inline'.。

此选项确切定义了文档信息在磁盘和RAM中的物理存储方式。“none”意思是根本不存储文档信息(没有任何属性)。通常并不需要显式设置为“none” 因为当没有配置任何属性时Sphinx会自动选择“none”。“inline”代表文档信息与文档ID列表一同存储在在.spd文件中。“extern”代表文档信息与文档ID分开(在外部)存储(在.spa文件中)。

基本上,外部存储的文档信息在查询时必须保持在内存中。这是性能的原因。因此有时候“inline”是唯一的选择。然而这种情况并不多见,文档信息默认是“extern”存储的。深入的探讨和RAM使用的估计请参见第 3.2 节 “属性”

示例:

docinfo = inline

11.2.5. mlock:缓冲数据内存锁定

已缓冲数据的内存锁定。可选选项,默认为0(不调用mlock())

为提高性能,searchd.spa.spi文件预取到内存中,并一直在内存中保存它们的拷贝。但如果一段时间内没有对该索引的搜索,则对这份缓冲的拷贝没有内存访问,而操作系统可能会决定将它交换到磁盘上去。对这些“冷却”了的索引的访问会导致其交换回内存并得到一个较大的延迟。

将mlock选项设置为1会使Sphinx使用mlock(2)系统调用将存储上述缓冲了的数据的系统内存锁定,这将避免内存交换(详情参见man 2 mlock)。mlock(2)是特权调用,因此可能需要searchd以root账户运行或通过其他办法赋予足够的权限。如果mlock()失败会发出警告,但索引会继续进行。

示例:

mlock = 1

11.2.6. morphology:词形处理

词形处理器的列表。可选选项,默认为空(不使用任何词形处理器)。

词形处理器可以将待索引的词从各种形态变成基本的规则的形态。例如,英语词干提取器(English stemmer)可以将“dogs”和“dog”都变成“dog”,这使搜索这两个词的结果都相同。

内置的词形处理器包括英语词干提取器,俄语词干提取器(支持UTF-8和Windows-1251编码),Soundex和Metaphone。后面两个会将词替换成特殊的语音编码,这会使发音相近的词表示形式相同。Snowball 项目的libstemmer 库提供的额外词干提取器可以通过在编译期对configure 脚本使用--with-libstemmer选项来启用。内建的英语和俄语词干提取器要比它们在libstemmer中的对应物模块运行更快,但它们的结果可能略有不同,因为内建的版本基于较旧的版本。Metaphone基于Double Metaphone算法实现。Metaphone是 基于Double Metaphone的算法和索引的主要代码实现的。

morphology选项中可使用的内建值包括

  • none - 不做任何词形处理,保持原样;

  • stem_en - 应用实现的英语词干;

  • stem_ru - 应用实现的俄语词干;

  • stem_enru - 应用实现的英语和俄语词干;

  • stem_cz - 应用实现的捷克语词干;

  • soundex - 用关键字的SOUNDEX编码取代它;

  • metaphone - 用关键字的METAPHONE编码取代它.

libstemmer提供的额外值格式为“libstemmer_XXX”,XXX指libstemmer算法的代号。(完整列表参见libstemmer_c/libstemmer/modules.txt

可以指定多个词干提取器(以逗号分隔)。这些提取器按列出的顺序应用于输入词串,整个处理会在第一个真正修改了原词的词干提取器之后停止。另外,当wordforms 特性启用时,词会现在词形字典中查询,如果词典中有对应的条目,那么词干提取器干脆不会被使用。换个说法,wordforms选项可以用来补充指定词干提取器的例外情况。

示例:

morphology = stem_en, libstemmer_sv

11.2.7. dict:关键字词典类型

关键字词典的类型。 可用值为crc或者keywords。 可选项,默认为crc。 版本2.0.1-beta引入。

The default dictionary type in Sphinx, and the only one available until version 2.0.1-beta, is a so-called CRC dictionary which never stores the original keyword text in the index. Instead, keywords are replaced with their control sum value (either CRC32 or FNV64, depending whether Sphinx was built with --enable-id64) both when searching and indexing, and that value is used internally in the index.

That approach has two drawbacks. First, in CRC32 case there is a chance of control sum collision between several pairs of different keywords, growing quadratically with the number of unique keywords in the index. (FNV64 case is unaffected in practice, as a chance of a single FNV64 collision in a dictionary of 1 billion entries is approximately 1:16, or 6.25 percent. And most dictionaries will be much more compact that a billion keywords, as a typical spoken human language has in the region of 1 to 10 million word forms.) Second, and more importantly, substring searches are not directly possible with control sums. Sphinx alleviated that by pre-indexing all the possible substrings as separate keywords (参见 第 11.2.18 节 “min_prefix_len:最小索引前缀长度”, 第 11.2.19 节 “min_infix_len:最小索引中缀长度”directives). That actually has an added benefit of matching substrings in the quickest way possible. But at the same time pre-indexing all substrings grows the index size a lot (factors of 3-10x and even more would not be unusual) and impacts the indexing time respectively, rendering substring searches on big indexes rather impractical.

Keywords dictionary, introduced in 2.0.1-beta, fixes both these drawbacks. It stores the keywords in the index and performs search-time wildcard expansion. For example, a search for a 'test*' prefix could internally expand to 'test|tests|testing' query based on the dictionary contents. That expansion is fully transparent to the application, except that the separate per-keyword statistics for all the actually matched keywords would now also be reported.

Indexing with keywords dictionary should be 1.1x to 1.3x slower compared to regular, non-substring indexing - but times faster compared to substring indexing (either prefix or infix). Index size should only be slightly bigger that than of the regular non-substring index, with a 1..10% percent total difference Regular keyword searching time must be very close or identical across all three discussed index kinds (CRC non-substring, CRC substring, keywords). Substring searching time can vary greatly depending on how many actual keywords match the given substring (in other words, into how many keywords does the search term expand). The maximum number of keywords matched is restricted by the expansion_limit directive.

Essentially, keywords and CRC dictionaries represent the two different trade-off substring searching decisions. You can choose to either sacrifice indexing time and index size in favor of top-speed worst-case searches (CRC dictionary), or only slightly impact indexing time but sacrifice worst-case searching time when the prefix expands into very many keywords (keywords dictionary).

示例:

dict = keywords

11.2.8. index_sp:索引句子和段落信息

是否检测并索引句子和段落边界。 可选值,默认为0(不检测和索引)。 版本2.0.1-beta引入。

This directive enables sentence and paragraph boundary indexing. It's required for the SENTENCE and PARAGRAPH operators to work. Sentence boundary detection is based on plain text analysis, so you only need to set index_sp = 1 to enable it. Paragraph detection is however based on HTML markup, and happens in the HTML stripper. So to index paragraph locations you also need to enable the stripper by specifying html_strip = 1. Both types of boundaries are detected based on a few built-in rules enumerated just below.

Sentence boundary detection rules are as follows.

  • Question and excalamation signs (? and !) are always a sentence boundary.

  • Trailing dot (.) is a sentence boundary, except:

    • When followed by a letter. That's considered a part of an abbreviation (as in "S.T.A.L.K.E.R" or "Goldman Sachs S.p.A.").

    • When followed by a comma. That's considered an abbreviation followed by a comma (as in "Telecom Italia S.p.A., founded in 1994").

    • When followed by a space and a small letter. That's considered an abbreviation within a sentence (as in "News Corp. announced in Februrary").

    • When preceded by a space and a capital letter, and followed by a space. That's considered a middle initial (as in "John D. Doe").

Paragraph boundaries are inserted at every block-level HTML tag. Namely, those are (as taken from HTML 4 standard) ADDRESS, BLOCKQUOTE, CAPTION, CENTER, DD, DIV, DL, DT, H1, H2, H3, H4, H5, LI, MENU, OL, P, PRE, TABLE, TBODY, TD, TFOOT, TH, THEAD, TR, and UL.

Both sentences and paragraphs increment the keyword position counter by 1.

示例:

index_sp = 1

11.2.9. index_zones:索引标签区域信息

字段内需要索引的HTML/XML区域的标签列表。 可选项,默认为空(不索引区域)。 版本2.0.1-beta引入。

Zones can be formally defined as follows. Everything between an opening and a matching closing tag is called a span, and the aggregate of all spans corresponding sharing the same tag name is called a zone. For instance, everything between the occurrences of <H1> and </H1> in the document field belongs to H1 zone.

Zone indexing, enabled by index_zones directive, is an optional extension of the HTML stripper. So it will also require that the stripper is enabled (with html_strip = 1). The value of the index_zones should be a comma-separated list of those tag names and wildcards (ending with a star) that should be indexed as zones.

Zones can nest and overlap arbitrarily. The only requirement is that every opening tag has a matching tag. You can also have an arbitrary number of both zones (as in unique zone names, such as H1) and spans (all the occurrences of those H1 tags) in a document. Once indexed, zones can then be used for matching with the ZONE operator, 参见 第 5.3 节 “扩展查询语法”.

示例:

index_zones = h*, th, title

11.2.10. min_stemming_len:词干化最小词长

启用词干化的最小词长。可选选项,默认为1(对任何词都进行词干化)。于版本0.9.9-rc1引入。

词干化方法并不完美,有时会产生用户不想要的结果。例如,如果用英语的Porter stemmer词干化算法处理关键词“gps”,得到的结果是“gp”,显然这是不对的。min_stemming_len这个特性允许根据词的长度来决定是否跳过词干化,即不对较短的词进行词干化。注意,词长等于这个选项设置的值的词被词干化。因此要避免对3个字符长的关键词进行词干化,必须指定这个选项的值为4。要活的更细粒度的控制,请参考wordforms这个特性。

示例:

min_stemming_len = 4

11.2.11. stopwords:停止词

停用词文件列表(空格分隔)。可选选项,默认为空。

停用词是不被索引的词。停用词表一般包括最常用的高频词,因为它们对搜索结果没有多大帮助却消耗很多处理资源。

可以指定多个文件名,用空格分隔。所有文件都会被载入。停用词文件的格式是简单的纯文本。其编码必须与charset_type选项所指定的索引编码相匹配。文件数据会根据charset_type选项的设置进行切分,因此您可以使用与待索引数据相同的分隔符。词干提取器(stemmers)也会在停用词文件的分析中使用。

尽管停用词不会被索引,它们却影响关键词的位置。例如,假设“the”是一个停用词,文档1包含一行“in office”,而文档2包含“in the office”。将“in office”作为确切词组搜索则只会得到文档1,虽然文档2里的the是停用的。

示例:

stopwords = /usr/local/sphinx/data/stopwords.txt
stopwords = stopwords-ru.txt stopwords-en.txt

11.2.12. wordforms:词形字典

词形字典。 可选选项,默认为空。

词形字典在输入文档根据charset_table切 碎后使用。本质上,它使您可以将一个词替换成另一个。这通常被用来将不同的词形变成一个单一的标准形式(即将词的各种形态如 “walks”,“walked”,“walking”变为标准形式“walk”)。也可以用来实现取词根的例外情况,因为词形字典中可以找到的词不会经 过词干提取器的处理。

索引和搜索中的输入词都会利用词典做规则化。因此要使词形字典的更改起作用,需要重新索引并重启searchd

Sphnix的词形支持被设计成可以很好地支持很大的字典。它们轻微地影响索引速度:例如,1M个条目的字典会使索引速度下降1.5倍。搜索速度则完全不 受影响。额外的内存占用大体上等于字典文件的大小,而且字典是被多个索引共享的,即如果一个50MB的词形字典文件被10个不同的索引使用了,那么额外的searchd内存占用就是大约50MB。

字典文件的格式是简单的纯文本。每行包括一个源词形和一个目标词形,编码应与charset_type选项所指定的完全相同,二者用大于号分隔。文件载入时会经过charset_table选项指定的规则的处理。因此基本上在大小写是否敏感这个问题上它是与待索引的全文数据相同的,即通常是大小写无关的。一下是个文件内容的例子:

walks > walk
walked > walk
walking > walk

我们提供了一个spelldump工具,它可以帮您从ispell  MySpell(OpenOffice提供)格式的.dict.aff字典文件生成Sphinix可接受的格式。

从版本0.9.9-rc1开始,可以将好几个源词对应到同一个目标词上。由于这个过程作用于符号化之后的结果而不是原始文本,空白字符和标记语言都被忽略。

core 2 duo > c2d
e6600 > c2d
core 2duo > c2d

Notice however that the destination wordforms are still always interpreted as a single keyword! Having a mapping like "St John > Saint John" will result in notmatching "St John" when searching for "Saint" or "John", because the destination keyword will be "Saint John" with a space character in it (and it's barely possible to input a destination keyword with a space).

示例:

wordforms = /usr/local/sphinx/data/wordforms.txt

11.2.13. exceptions:词汇特例处理

Token特例文件。 可选选项,默认为空。

对于使用Coreseek的中文用户,这一选项无效。Coreseek为Sphinx贡献的中文分词法内置了Token特例化支持,具体参阅Coreseek MMSeg分词法的文档。不过,值得高兴的是,Token特例化的文件格式两者是同样的。

此选项允许将一个或多个Token(Token中,可以包括在正常情况下会被过滤的字符)映射成一个单独的关键词。exceptions选项与wordforms选项很类似,它们都代表某种映射,但有一些重要的不同点。

这些不同点简要总结如下:

  • exceptions 大小写敏感, wordforms大小写无关;

  • exceptions 允许检测一串记号, wordforms仅对单独的词有效;

  • exceptions 可以使用charset_table中没有的特殊符号,wordforms完全遵从charset_table;

  • exceptions 在大字典上性能会下降,wordforms则对百万级的条目应对自如。

输入文件的格式仍然是纯文本,每行一个分词例外,而行的格式如下:

map-from-tokens => map-to-token

示例文件:

AT & T => AT&T
AT&T => AT&T
Standarten   Fuehrer => standartenfuhrer
Standarten Fuhrer => standartenfuhrer
MS Windows => ms windows
Microsoft Windows => ms windows
C++ => cplusplus
c++ => cplusplus
C plus plus => cplusplus

这里全部的符号都是大小写敏感的:它们不会charset_table选项的规则处理。因此,在上述例外文件下,“At&t”会被分成两个关键字“at”和“t”,因为其中的小写字母。而“AT&T”却被精确匹配并产生一个单独的关键字“AT&T”。

需要注意的是,前述映射文件的目标关键词(右侧)a)总是被解释成一个单独的词,而且b)不仅是大小写敏感的,而且是空白符号敏感的!在上述样例中,查询“ms windows”不会匹配包含“MS Windows”的文档。这个查询会被解释成两个词“ms”和“Windows”。而“MS Windows”映射到的是一个单独的 关键字“ms windows”,包括中间的空格。另一方面“standartenfuhrer”会取回带有“Standarten Fuhrer”或者“Standarten Fuehrer”内容的文档(大写字母必须与此处列出的完全相同),或者关键词本身大小写随意的任何版本,例如“staNdarTenfUhreR”。 (然而“standarten fuhrer”不会匹配。这段文本无法与列出的任何一个例外相匹配,因为大小写不同。因此被索引为两个分开的关键字)

映射源部分的空白符(white space)不会被忽略,但空白符的数量无所谓。任何数量的空白符都匹配已索引的文档或者查询中的任意数量的空白符。例如映射源部分(“=>”左 端)的“AT€&€T”可以匹配“AT€€&€T”,不管被映射部分或已索引全文数据中实际有几个空格。根据上述例子中的第一条,上述文 本会作为“AT&T”关键字被索引。 对于使用Coreseek的中文用户,这个特性目前尚不被支持。Coreseek将在后续版本支持这个特性。

exceptions选项也允许特殊字符(这是通用charset_table选项规则的例外(exception),此选项因而得名)。假设您一般不想把“+”当作有效的字符,但仍想搜索一些例外情况,比如“C++”。上述例子正好可以做到这点,完全不管哪些字符在表中,哪些字符不在。

Exceptions选项被应用于原始输入文档和索引、搜索时的查询数据。因此要使文件的改动生效,需要重建索引并重启searchd

示例:

exceptions = /usr/local/sphinx/data/exceptions.txt

11.2.14. min_word_len:最小索引词汇长度

最小索引词长度。可选选项,默认为1(索引任何词)

只有长度不小于这个最小索引词长度的词会被索引。例如,如果min_word_len为4,那么“the”这个词不会被索引,但“they”会。

示例:

min_word_len = 4

11.2.15. charset_type:字符集编码

字符集编码类型。可选选项,默认为“sbcs”。可用的值包括“sbcs”和“utf-8”。 对于使用Coreseek的中文用户,可选的值还可以有“zh_cn.utf-8 ”、“zh_cn.gbk”和“zh_cn.big5”(需要编译时提供iconv支持)。当设置charset_type值为上面的值时,系统默认您开启了中文分词特性。

不同的编码将它们的内部字符代码映射到特殊字节序列的方法不同。目前两个最常见的方法是单字节编码和UTF-8。它们对应的charset_type值分 别是“sbcs”(代表Single Byte Character Set单字节字符集)和“utf-8”。选定的编码类型会在搜索被使用的任何情况下使用:索引数据时,对索引查询时,产生摘要时,等等。

注意,尽管“utf-8”暗示解码出来的值应按unicode码点数值对待,“sbcs”却对应一系列不同的编码,它们对不同字节值的处理不同,这要在charset_table设置中正确地反应出来。例如,同一个值244(十六进制0xE0)根据使用的是koi-8r还是windows-1251编码而映射到不同的俄语字符。

示例:

charset_type = utf-8

11.2.16. charset_table:字符表和大小写转换规则

接受的字符表和大小写转换规则。可选选项,默认值与charset_type 选项的值有关。 对于使用Coreseek的中文用户,Coreseek 提供的MMseg分词法内置了可接受的字符表,并且用户不可修改。当启用分词功能时,自动开启。

charset_table频繁应用于Sphinx的分词过程,即从文档文本或查询文本中抽取关键字的过程。它控制哪些字符被当作有效字符接受,哪些相反,还有接受了的字符如何转换(例如大小写信息保留还是去除)。

可以把charset_table想成一个对超过100K个Unicode字符中每一个的映射关系的大表(或者一个256个字符的小表,如果你使用 SBCS)。默认每个字符都对应0,这表示它不在关键字中出现,应被视为分隔符。一旦在此表中被提及,字符就映射到另一个字符(通常是它自身或者自身的小 写版本),同时被当作一个可以出现在关键字中的有效字符。

值的格式是逗号分隔的映射列表。两种最简单的映射分别是声明一个字符为有效和将一个简单字符映射为另一个字符。但用这种格式指定整个表会导致其体积臃肿、无法管理。因此提供了一些语法上的快捷方式,用它们可以一次指定一定范围的字符。详细的列表如下:

  • A->a

  • 单个字符映射,声明源字符“A”为允许出现在关键字中的字符,并将之映射到目的字符“a”(这并没有声明“a”是允许的)。

  • A..Z->a..z

  • 范围映射,声明源范围中的全部字符允许出现在关键字中,并将它们映射到目的范围。并不声明目的范围是允许的。此外会检查 (长度必须相等)

  • a

  • 单一字符映射,声明一个允许的字符,将它映射到它自身。相当于单个字符映射 a->a 。

  • a..z

  • 杂散范围映射,声明范围中的全部字符为允许,将它们映射到自身。相当于范围映射 a..z->a..z 。

  • A..Z/2

  • 棋盘范围映射。映射每相邻两个字符到其中的第二个。形式化地说,声明范围中的奇数字符为允许,将它们映射到偶数字符上。同时允许偶数字符并映射到其自身。例如, A..Z/2 相当于 A->B, B->B, C->D, D->D, ..., Y->Z, Z->Z。这个映射接将捷径方便声明大小写字符交替而非大小写字符分别连续的Unicode块。

编码为0到31之间的控制字符总是被视作分隔符。编码32到127的字符即7位ASCII字符可以原样使用在映射中。为避免配置文件的编码问题,8位 ASCII字符和Unicode字符必须以U+xxx形式指定,“xxx”是码点对应的十六进制数。也可以用这个形式编码7位ASCII编码中的特殊字 符,例如用U+20来编码空格符,U+2E来编码句点,U+2C来编码逗号。

示例:

# 'sbcs' defaults for English and Russian
charset_table = 0..9, A..Z->a..z, _, a..z, \
	U+A8->U+B8, U+B8, U+C0..U+DF->U+E0..U+FF, U+E0..U+FF

# 'utf-8' defaults for English and Russian
charset_table = 0..9, A..Z->a..z, _, a..z, \
	U+410..U+42F->U+430..U+44F, U+430..U+44F

11.2.17. ignore_chars:忽略字符表

忽略字符表。 可选选项,默认为空。

有些字符,如软断字符(U+00AD),不是仅仅要当作分隔符,而且应该被完全忽略。例如,如果“-”只是不在charset_table里,那么 “abc-def”会被当作两个关键字“abc”和“def”来索引。相反,如果将“-”加到ignore_char列表中,那么相同的文本会被当作一个 单独的关键字“abcdef”索引。

此选项的语法与 charset_table相同,但只允许声明字符,不允许映射它们。另外,忽略的字符不能出现在charset_table里。

示例:

ignore_chars = U+AD

11.2.18. min_prefix_len:最小索引前缀长度

索引的最小前缀长度。可选选项,默认为0(不索引前缀)。

前缀索引使实现“wordstart*”形式的通配符成为可能(通配符语法的细节请参考 enable_star 选项)。当最小前缀长度被设置为正值,indexer除了关键字本身还会索引所有可能的前缀(即词的开头部分)。太短的前缀(小于允许的最小值)不会被索引。

例如,在min_prefix_len=3设置下索引关键字“example”会导致产生5个索引项“exa”, “exam”, “examp”, “exampl”和该词本身。对这个索引搜索“exam”会得到包含“example”的文档,即使该文档中没有“exam”自身。然而,前缀索引会使索 引体积急剧增大(因为待索引关键字增多了很多),而且索引和搜索的时间皆会恶化。

在前缀索引中没有自动的办法可以提高精确匹配(整个词完全匹配)的评分,但有一些技巧可以实现这个功能。首先,可以建立两个索引,一个带有前缀索引,另一个没有,同时在这两个索引中搜索,然后用 SetIndexWeights() 来设置二者的权重。其次,可以启用星号语法并重写扩展模式的查询:

# in sphinx.conf
enable_star = 1

// in query
$cl->Query ( "( keyword | keyword* ) other keywords" );

示例:

min_prefix_len = 3

11.2.19. min_infix_len:最小索引中缀长度

索引的最小中缀长度。可选选项,默认为0(不索引中缀)。

中缀索引是实现“start*”, “*end”, and “*middle*”等形式的通配符成为可能(通配符语法的细节请参考 enable_star 选项)。当最小中缀长度设置为正值,indexer除了对关键字本身还会对所有可能的中缀(即子字符串)做索引。太短的中缀(短于允许的最小长度)不会被索引。

例如,在min_infix_len=2设置下索引关键字“test”会导致产生6个索引项 "te", "es", "st", "tes", "est"等中缀和词本身。对此索引搜索“es”会得到包含“test”的文档,即使它并不包含“es”本身。然而,中缀索引会使索引体积急剧增大(因为 待索引关键字增多了很多),而且索引和搜索的时间皆会恶化。

在中缀索引中没有自动的办法可以提高精确匹配(整个词完全匹配)的评分,但可以使用与 prefix indexes 选项中相同的技巧。

示例:

min_infix_len = 3

11.2.20. prefix_fields:前缀索引字段列表

做前缀索引的字段列表。可选选项,默认为空(所有字段均为前缀索引模式)。

因为前缀索引对索引和搜索性能均有影响,可能需要将它限制在某些特定的全文数据字段:例如,对URL提供前缀索引,但对页面内容不提供。prefix_fields指定哪些字段要提供前缀索引,其他字段均会使用普通模式。值的格式是逗号分隔的字段名字列表。

示例:

prefix_fields = url, domain

11.2.21. infix_fields:中缀索引字段列表

做中缀索引的字段列表。可选选项,默认为空(所有字段均为中缀索引模式)。

 prefix_fields选项类似,但限制的是哪些字段做中缀索引。

示例:

infix_fields = url, domain

11.2.22. enable_star:星号语法

允许前缀/中缀索引上的星号语法(或称通配符)。可选选项,默认为0(不使用通配符),这是为了与0.9.7版本的兼容性。可用的值为0和1。

此特性启用搜索前缀或中缀索引时的“星号语法”,或者说通配符语法。仅影响搜索,因此要使改变生效只须重启 searchd,而不需要重新索引。

默认值为0,意思是禁止星号语法,所有关键字都根据索引时的 min_prefix_len  min_infix_len settings设置被视为前缀或者中缀。取值1的意思是星号(“*”)可以用在关键字的前面或后面。星号与零个或多个字符匹配。

例如,假设某索引启用了中缀索引,且enable_star值为1。搜索过程按如下工作:

  1. 查询 "abcdef" 仅匹配确切含有“abcdef”这个词的文档;

  2. 查询 "abc*" 可匹配含有以“abc”开头的词的文档(包括精确匹配词“abc”的文档);

  3. 查询 "*cde*" 匹配在任何地方含有“cde”的词的文档(包括精确匹配词“cde”的文档);

  4. 查询 "*def" 匹配含有以“def”结束的词的文档(包括精确匹配词“def”的文档)

示例:

enable_star = 1

11.2.23. ngram_len:N-gram长度

N-gram索引的N-gram长度。可选选项,默认为0(禁用n-gram索引)可用的值是0和1(其他长度尚未实现) 对于使用Coreseek的中文用户,在启用了中文分词的情况下,本节内容可忽略。

N-gram提供对未分词CJK(Chinese, Japanse, Koreasn中日韩)文本的基本支持。CJK搜索的问题在于词与词之前没有清晰的界限。理想中,文本可以通过一个称作分词程序(segmenter)的 特殊程序的过滤,之后分隔符即被加入到适当位置。然而分词过程缓慢而易错,因此通常会转而索引连续的一组N个字符,或称N-gram。

启用此特性,CJK字符流会被当作n-gram索引。例如,如果输入文本为“ABCDEF”(A到F均代表CJK字符) ,而此选项设置的长度为1,那它们会被当作“A B C D E F”而索引。(如果此选项设置的长度是2,那会产生“AB BC CD DE EF”,但目前仅支持1)。只有那些在 ngram_chars 选项表中列出的字符会这样分割,其他不受影响。

注意,如果搜索查询是已分词的,即单独的词之间有分隔符分隔,那么在扩展模式中将这些词放入引号中搜索会得到正确的匹配结果,即使文档没有分词。例如,假设原查询为“BC DEF”,在应用程序端用引号将索引包起来,看起来是“BC” “DEF”(包括引号),这个查询被传给Sphinx并在其内部分割成1-gram,查询变成“B C” “D E F”,仍然包括作为词组查询操作符的引号。该查询会匹配正确的文本,即使文本中没有相应的分隔符。

即使搜索查询没有分词,Sphinx也可以返回较好的结果,这要感谢基于词组的相关度计算:它会使相近的词组匹配(在n-gram中CJK词相当于多个字符的词匹配)排在前面。

示例:

ngram_len = 1

11.2.24. ngram_chars:N-gram字符列表

N-gram字符列表。 可选选项,默认为空。 对于使用Coreseek的中文用户,在启用了中文分词的情况下,本节内容可忽略。

 ngram_len选项联用,此列表定义了从中抽取n-gram的字符序列。其他字符组成的词不受n-gram索引特性的影响。值的格式与charset_table相同。

示例:

ngram_chars = U+3000..U+2FA1F

11.2.25. phrase_boundary:词组边界符列表

词组边界符列表。 可选选项,默认为空。

此列表控制哪些字符被视作分隔不同词组的边界,每到一个这样的边界,其后面的词的“位置”值都会被加入一个额外的增量,可以借此用近似搜索符来模拟词组搜索。语法与charset_table选项相似,但没有字符之间的映射关系,而且这些词组边界符不能重复出现在其他任何设置选项中。

自每个词组边界起,后面的词的“位置”都会被加入一个额外的增量(由 phrase_boundary_step定 义)。这使通过近似搜索符实现词组搜索成为可能:不同词组中的词之间的距离肯定大于phrase_boundary_step,因此相似距离小于 phrase_boundary_step的近似搜索其实是在搜索在一个词组范围内出现了全部给定查询词的情况,相当于词组搜索。

只有词组边界符后面紧跟着一个分隔符时,词组边界才被激活,这是为了避免S.T.A.L.K.E.R 或 URLs 等缩写被错当成若干个连续的词组(因为“.”属于词组边界符)。

示例:

phrase_boundary = ., ?, !, U+2026 # horizontal ellipsis

11.2.26. phrase_boundary_step:词组边界位置增量

词组边界上词位置的增量。可选选项,默认为0。

在词组边界上,当前词位置会加上此选项设置的额外增量。详细请参考 phrase_boundary 选项。

示例:

phrase_boundary_step = 100

11.2.27. html_strip:HTMl标记清理

是否从输入全文数据中去除HTML标记。可选标记,默认为0。已知值包括0(禁用)和1(启用)。

HTML标签和实体都可以被标记并且得到处理。

HTML标签会被删除,但是其内容(即<P> 与 </P>之间的部分)默认情况下会保留。你可以选择标签中需要保留和索引的属性(例如A标签中的HREF属性,或者IMG标签中的ALT属 性)一些常见的内嵌标签会被完全清除,其他标签都被视为块级并被替换为空格。例如:'te<B>st</B>'文本将被单做一个 单一的关键字'test'被索引,但是,'te<P>st</P>'将被当做两个关键字'te'和'st'被索引。已知的内嵌标 签如下:A, B, I, S, U, BASEFONT, BIG, EM, FONT, IMG, LABEL, SMALL, SPAN, STRIKE, STRONG, SUB, SUP, TT.

HTML实体会被解码并替换为对应的UTF-8字符。剥离器同时支持数字形式(例如&#239;)和文本形式(例如& oacute;或& nbsp;)。所有由HTML4标准规定的实体都支持。

此特性对 xmlpipe 数据源无效(建议升级到 xmlpipe2 )。这个去除HTML标记的模块应该很好地工作于正确格式化的HTML和XHTML,但就像大多数浏览器一样,对于格式错误的文本(例如带有无法配对的<和>的HTML)可能产生不希望的输出。

只有HTML标签和HTML注释会被删除。要同时删除标签的内容(例如要删除内嵌的脚本),请参考 html_remove_elements 选项。标签名没有限制,即任何看起来像有效的标签开头、结束或者注释的内容都会被删除。

示例:

html_strip = 1

11.2.28. html_index_attrs:HTML标签属性索引设置

去除HTML标记但要索引的标记属性列表。可选选项,默认为空(不索引标记的属性)。

指定被保留并索引的HTML标记属性,而HTML标记本身会被被删除。格式是对每个标记列举可以索引的属性,请看下例:

示例:

html_index_attrs = img=alt,title; a=title;

11.2.29. html_remove_elements:HTML元素清理

完全清空HTML标签列表,不仅这些标签本身会被删除,标签本身包含的内容也会被删除。可选选项,默认为空(不删除任何标签的内容)。

此特性允许删除标签包含的内容,即在开始标记和结束标记之间的所有东西。一般用于删除内嵌的脚本或CSS等。短的没有实际内容的标签(即<br />)也支持;类似不会这样的标签中的内容将被删除。

值为逗号分隔的标签名称列表。标签名大小写无关。

示例:

html_remove_elements = style, script

11.2.30. local:本地索引声明

分布式索引 distributed index中的本地索引声明。可以出现多次, 可选选项,默认为空。

此设置用于声明分布式索引被搜索时要搜索的本地索引。全部本地索引会被依次搜索,仅使用1个CPU或核。要并行处理,可以配置searchd查询它自身(细节参考 第 11.2.31 节 “agent:远程索引声明” )。可以为每个分布式索引声明多个本地索引。每个本地索引可以在其他分布式索引中多次引用。

示例:

local = chunk1
local = chunk2

11.2.31. agent:远程索引声明

分布式索引(distributed index)中的远程代理和索引声明。可以出现多次,可选选项,默认为空。

此设置用来声明搜索分布式索引时要搜索的远程代理。代理可以看作网络指针,它指定了主机、端口和索引名。在最基本的情况下,代理可以与远程物理主机对应。更严格的来说,这不一定总是正确:可以将多个代理指向同一台远程主机,甚至指向同一个searchd实例(以便利用多个CPU或核)。

值的格式如下:

agent = specification:remote-indexes-list
specification = hostname ":" port | path

“hostname”是远程主机名,“port”是远程TCP端口,"path"是Unix域套接字的路径, 而“remote-index-list”是一个逗号分隔的远程索引列表。

全部代理会被并行搜索。然而同一个代理的多个索引是依次搜索的。这使您可以根据硬件来优化配置。例如,如果两个远程索引存储在一个相同的硬盘上,最好是配 置一个带有多个按顺序搜索的索引,避免频繁的磁头寻址。如果这些索引存储在不同的硬盘上,那配置两个代理会更有利,因为这可以使工作完全并行。对于CPU 也是如此,虽然在两个进程间切换对性能的影响比较小而且常常被完全忽略。

在有多个CPU和硬盘的机器上,代理可以指向相同的机器以便并行地使用硬件,降低查询延迟。并不需要为此设置多个searchd实例,一个实例与自身通信是合法的。以下是一个示例设置,它是为一台有4个CPU的机器准备的,可以并行地使用4个CPU,各处理一个查询:

index dist
{
	type = distributed
	local = chunk1
	agent = localhost:9312:chunk2
	agent = localhost:9312:chunk3
	agent = localhost:9312:chunk4
}

注意其中一块是本地搜索的,而同一个searchd示例又向本身查询,以便并行地启动其他三个搜索。

示例:

agent = localhost:9312:chunk2 # contact itself
agent = /var/run/searchd.s:chunk2
agent = searchbox2:9312:chunk3,chunk4 # search remote indexes

11.2.32. agent_blackhole:远程黑洞代理

分布式索引( distributed index)中声明远程黑洞代理。多个值,可选选项,默认是空。于版本0.9.9-rc1引入。

agent_blackhole 选项使用户可以向远程代理发送“即发即忘”的查询(fire-and-forget queries)。这在调试(或者仅仅是测试)即将投入生产的集群的时候很有用:可以设置一个单独的调试/测试searchd实例,然后从实际生产中使用的主服务器(master,或称聚集者aggregator)实例向这个测试服务器转发查询请求,但不干扰生产系统的工作。主(master)searchd会以正常的方式尝试连接和查询黑洞代理,但是它既不会等待也不会处理黑洞代理的反馈。同时,发生在黑洞代理上的全部网络错误也都被忽略。值的格式与普通的 agent 完全相同。

示例:

agent_blackhole = testbox:9312:testindex1,testindex2

11.2.33. agent_connect_timeout:远程查询时间

远程代理的连接超时时间,单位为毫秒。可选选项,默认为1000(即1秒)。

连接到远程代理时,searchd最多花这些时间等待connet()调用成功完成。如果达到了超时时间connect()仍没有完成,而 and retries 选项是启用的,那么将开始重试。

示例:

agent_connect_timeout = 300

11.2.34. agent_query_timeout:远程查询超时时间

远程代理查询超时时间,以毫秒为单位。可选选项,默认为3000(即3秒)。

连接后,searchd最多花这这些时间等到远程查询完成。这个超时时间与连接超时时间是完全独立的。因此一个远程代理最多能造成的延迟为agent_connection_timeoutagent_query_timeout之和。如果超时时间已到,查询不会再重试,同时产生警告。

示例:

agent_query_timeout = 10000 # our query can be long, allow up to 10 sec

11.2.35. preopen:索引文件预开启

预先打开全部索引文件还是每次查询时再打开索引。可选选项,默认为0(不预先打开)。

此选项令searchd在启动时(或轮换索引时)预先开打全部索引文件并在运行过程中保持打开。目前,默认是预先打开这些文件(此行为可能在未来改变)。预先打开的每个索引文件会占用若干(目前是两个)文件描述符。但每次查询可以节约两个open()调用而且不会受高负载情况下索引轮换过程中可能发生的微妙的竞争条件(race condition)的影响。另一方面,当提供很多索引服务(几百到几千)时,必须每次查询时打开索引文件以便节约文件描述符。

这个指令不影响indexer的任何行为,只对searchd有用。

示例:

preopen = 1

11.2.36. ondisk_dict:字典文件保持设置

指定是将字典文件(.spi)保持在磁盘上还是将它预先缓冲在内存中。可选选项,默认值是0(预先缓冲在内存里)。于版本0.9.9-rc1引入。

字典文件(.spi)既可以驻留在内存中也可以保持在磁盘上。默认情况下是将整个字典缓冲在内存中。这样做提高性能,但可能带来过大的内存压力,尤其是使用了前缀或中缀的时候。启用ondisk_dict为每次查询的每个关键词带来一次磁盘I/O操作,但是会减少内存使用。

这个指令不影响indexer的任何行为,只对searchd有用。

示例:

ondisk_dict = 1

11.2.37. inplace_enable:原地索引倒转设置

是否启用原地索引倒转(in-place index inversion)。可选选项,默认值是0(使用单独的临时文件)。于版本0.9.9-rc1引入。

inplace_enable 选项极大地减少了建立索引时的磁盘压力,代价是略慢的索引速度(少使用大约两倍的磁盘空间,速度方面能达到原有性能的90-95%)

建立索引的过程有两个主要的阶段。第一个阶段主要是收集、处理文档以及对文档根据关键词进行部分的排序,中间结果被写入到临时文件(.tmp*)中。第二 个阶段则对文档进行完全排序并创建总重的索引文件。因此,重建一个正在应用于生产的索引将导致一个三倍大的磁盘占用峰值:第一倍,中间结果临时文件,第 二,新建的副本,和第三,在一切发生时旧的索引仍然占用一份磁盘空间,以便继续服务。(中间结果的大小与最终索引的大小相当)。对于很大的数据集,这将是 一笔很大的磁盘开销,而inplace_enable 选项用于减少这个开销。一旦启用这个选项,临时文件将被重复利用,最终的数据写回到临时文件中,最后改个名字就可以作为最终结果使用了。然而,这可能导致更多的临时数据块重新分配,因此性能会有一点损失。

这个指令不影响searchd的任何行为,只对indexer有用。

示例:

inplace_enable = 1

11.2.38. inplace_hit_gap:原地索引倒转匹配点空隙设置

微调原地倒转(In-place inversion)行为的选项。控制预先分配的匹配点列表(hitlist)的空隙的大小。可选选项,默认是0。于版本0.9.9-rc1引入。

这个指令不影响searchd的任何行为,只对indexer有用。

示例:

inplace_hit_gap = 1M

11.2.39. inplace_docinfo_gap:原地索引倒转文档信息空隙设置

微调原地倒转(In-place inversion)行为的选项。控制预先分配的文档信息(docinfo)的空隙的大小。可选选项,默认是0。于版本0.9.9-rc1引入。

这个指令不影响searchd的任何行为,只对indexer有用。

示例:

inplace_docinfo_gap = 1M

11.2.40. inplace_reloc_factor:原地索引倒转重定位内存设置

微调原地倒转(In-place inversion )行为的选项。控制重定位缓冲区占用索引时的内存的比例。可选选项,默认是0.1。于版本0.9.9-rc1引入。

这个指令不影响searchd的任何行为,只对indexer有用。

示例:

inplace_reloc_factor = 0.1

11.2.41. inplace_write_factor:原地索引倒转写缓冲内存设置

微调原地倒转(In-place inversion )行为的选项。控制原地写缓冲占用索引时的内存的比例。可选选项,默认是0.1。于版本0.9.9-rc1引入。

这个指令不影响searchd的任何行为,只对indexer有用。

示例:

inplace_write_factor = 0.1

11.2.42. index_exact_words:词干化后原词索引

是否在词干化处理后还索引原词(是否在索引原关键词的词干化/重映射后的形式的同时也索引原词)。可选选项,默认值是0(不索引额外的形式)。于版本0.9.9-rc1引入。

一旦启用,index_exact_words强制indexer除了词干化的版本外,将原始的关键字也加入索引。这样做也使查询语言中的精确匹配搜索符可用。这个选项将对索引大小和索引时间带来延迟。然而搜索的性能不会被影响。

示例:

index_exact_words = 1

11.2.43. overshort_step:短词位置增量

在经过过短的词(比 min_word_len短的词)处后增加位置值。 可选选项,允许的值是0或者1,默认是1。于版本0.9.9-rc1引入。

这个指令不影响searchd的任何行为,只对indexer有用。

示例:

overshort_step = 1

11.2.44. stopword_step:通用词位置增量

在经过 停用词 处后增加位置值可选选项,允许的值是0或者1,默认是1。于版本0.9.9-rc1引入。

这个指令不影响searchd的任何行为,只对indexer有用。

示例:

stopword_step = 1

11.2.45. hitless_words:位置忽略词汇列表

位置忽略词汇列表。 可选项,可用值为all或者列表所在的文件名。 版本2.0.1-beta引入。

By default, Sphinx full-text index stores not only a list of matching documents for every given keyword, but also a list of its in-document positions (aka hitlist). Hitlists enables phrase, proximity, strict order and other advanced types of searching, as well as phrase proximity ranking. However, hitlists for specific frequent keywords (that can not be stopped for some reason despite being frequent) can get huge and thus slow to process while querying. Also, in some cases we might only care about boolean keyword matching, and never need position-based searching operators (such as phrase matching) nor phrase ranking.

hitless_words lets you create indexes that either do not have positional information (hitlists) at all, or skip it for specific keywords.

Hitless index will generally use less space than the respective regular index (about 1.5x can be expected). Both indexing and searching should be faster, at a cost of missing positional query and ranking support. When searching, positional queries (eg. phrase queries) will be automatically converted to respective non-positional (document-level) or combined queries. For instance, if keywords "hello" and "world" are hitless, "hello world" phrase query will be converted to (hello & world) bag-of-words query, matching all documents that mention either of the keywords but not necessarily the exact phrase. And if, in addition, keywords "simon" and "says" are not hitless, "simon says hello world" will be converted to ("simon says" & hello & world) query, matching all documents that contain "hello" and "world" anywhere in the document, and also "simon says" as an exact phrase.

示例:

hitless_words = all

11.2.46. expand_keywords:词汇展开

尽可能展开关键字的精确格式或者型号形式。 可选项,默认为0(不展开关键字)。 版本2.0.1-beta引入。

Queries against indexes with expand_keywords feature enabled are internally expanded as follows. If the index was built with prefix or infix indexing enabled, every keyword gets internally replaced with a disjunction of keyword itself and a respective prefix or infix (keyword with stars). If the index was built with both stemming and index_exact_words enabled, exact form is also added. Here's an example that shows how internal expansion works when all of the above (infixes, stemming, and exact words) are combined:

running -> ( running | *running* | =running )

Expanded queries take naturally longer to complete, but can possibly improve the search quality, as the documents with exact form matches should be ranked generally higher than documents with stemmed or infix matches.

Note that the existing query syntax does not allowe to emulate this kind of expansion, because internal expansion works on keyword level and expands keywords within phrase or quorum operators too (which is not possible through the query syntax).

This directive does not affect indexer in any way, it only affects searchd.

示例:

expand_keywords = 1

11.2.47. blend_chars:混合字符列表

混合字符列表。 可选项,默认为空。 版本2.0.1-beta引入。

Blended characters are indexed both as separators and valid characters. For instance, assume that & is configured as blended and AT&T occurs in an indexed document. Three different keywords will get indexed, namely "at&t", treating blended characters as valid, plus "at" and "t", treating them as separators.

Positions for tokens obtained by replacing blended characters with whitespace are assigned as usual, so regular keywords will be indexed just as if there was noblend_chars specified at all. An additional token that mixes blended and non-blended characters will be put at the starting position. For instance, if the field contents are "AT&T company" occurs in the very beginning of the text field, "at" will be given position 1, "t" position 2, "company" positin 3, and "AT&T" will also be given position 1 ("blending" with the opening regular keyword). Thus, querying for either AT&T or just AT will match that document, and querying for "AT T" as a phrase also match it. Last but not least, phrase query for "AT&T company" will also match it, despite the position

Blended characters can overlap with special characters used in query syntax (think of T-Mobile or @twitter). Where possible, query parser will automatically handle blended character as blended. For instance, "hello @twitter" within quotes (a phrase operator) would handle @-sign as blended, because @-syntax for field operator is not allowed within phrases. Otherwise, the character would be handled as an operator. So you might want to escape the keywords.

Starting with version 2.0.1-beta, blended characters can be remapped, so that multiple different blended characters could be normalized into just one base form. This is useful when indexing multiple alternative Unicode codepoints with equivalent glyphs.

示例:

blend_chars = +, &, U+23
blend_chars = +, &->+ # 2.0.1-beta and above

11.2.48. blend_mode:混合类型

混合类型列表。可选项,默认为 trim_none。 版本2.0.1-beta引入。

By default, tokens that mix blended and non-blended characters get indexed in there entirety. For instance, when both at-sign and an exclamation are in blend_chars, "@dude!" will get result in two tokens indexed: "@dude!" (with all the blended characters) and "dude" (without any). Therefore "@dude" query will not match it.

blend_mode directive adds flexibility to this indexing behavior. It takes a comma-separated list of options.

blend_mode = option [, option [, ...]]
option = trim_none | trim_head | trim_tail | trim_both | skip_pure

Options specify token indexing variants. If multiple options are specified, multiple variants of the same token will be indexed. Regular keywords (resulting from that token by replacing blended with whitespace) are always be indexed.

  • trim_none

  • Index the entire token.

  • trim_head

  • Trim heading blended characters, and index the resulting token.

  • trim_tail

  • Trim trailing blended characters, and index the resulting token.

  • trim_both

  • Trim both heading and trailing blended characters, and index the resulting token.

  • skip_pure

  • Do not index the token if it's purely blended, that is, consists of blended characters only.

Returning to the "@dude!" example above, setting blend_mode = trim_head, trim_tail will result in two tokens being indexed, "@dude" and "dude!". In this particular example,trim_both would have no effect, because trimming both blended characters results in "dude" which is already indexed as a regular keyword. Indexing "@U.S.A." withtrim_both (and assuming that dot is blended two) would result in "U.S.A" being indexed. Last but not least, skip_pure enables you to fully ignore sequences of blended characters only. For example, "one @@@ two" would be indexed exactly as "one two", and match that as a phrase. That is not the case by default because a fully blended token gets indexed and offsets the second keyword position.

Default behavior is to index the entire token, equivalent to blend_mode = trim_none.

示例:

blend_mode = trim_tail, skip_pure

11.2.49. rt_mem_limit:RT索引内存限制

内存区块限制大小。 可选项,默认为空。 版本2.0.1-beta引入。

RT index keeps some data in memory (so-called RAM chunk) and also maintains a number of on-disk indexes (so-called disk chunks). This directive lets you control the RAM chunk size. Once there's too much data to keep in RAM, RT index will flush it to disk, activate a newly created disk chunk, and reset the RAM chunk.

The limit is pretty strict; RT index should never allocate more memory than it's limited to. The memory is not preallocated either, hence, specifying 512 MB limit and only inserting 3 MB of data should result in allocating 3 MB, not 512 MB.

示例:

rt_mem_limit = 512M

11.2.50. rt_field:字段设置

全文字段定义。 多值选项,必须设置。 版本2.0.1-beta引入。

Full-text fields to be indexed are declared using rt_field directive. The names must be unique. The order is preserved; and so field values in INSERT statements without an explicit list of inserted columns will have to be in the same order as configured.

示例:

rt_field = author
rt_field = title
rt_field = content

11.2.51. rt_attr_uint:整数属性

无符号整数属性定义。 多值选项(允许设置任意个此属性),可选项。 声明一个32位的无符号数属性。 版本2.0.1-beta引入。

示例:

rt_attr_uint = gid

11.2.52. rt_attr_bigint:长整数属性

BIGINT属性定义 多值选项(允许设置任意个此属性),可选项。 声明一个64位的有符号数属性。 版本2.0.1-beta引入。

示例:

rt_attr_bigint = guid

11.2.53. rt_attr_float:浮点数属性

浮点数属性定义。 多值选项(允许设置任意个此属性),可选项。 声明一个单精度,32为的IEEE 754格式的浮点数属性 版本2.0.1-beta引入。

示例:

rt_attr_float = gpa

11.2.54. rt_attr_timestamp:UNIX时间戳属性

时间戳属性定义。 多值选项(允许设置任意个此属性),可选项。 版本2.0.1-beta引入。

示例:

rt_attr_timestamp = date_added

11.2.55. rt_attr_string:字符串属性

字符串属性定义。 多值选项(允许设置任意个此属性),可选项。 版本2.0.1-beta引入。

示例:

rt_attr_string = author

11.3. indexer 程序配置选项

11.3.1. mem_limit:索引内存限制

索引过程中内存使用限制。可选选项,默认32M。

这是indexer不会超越的强制内存限制。可以以字节、千字节(以K为后缀)或兆字节(以M为后缀)为单位。参见示例。当过小的值导致I/O缓冲低于8KB时该限制会自动提高,此值的最低限度依赖于待索引数据的大小。如果缓冲低于256KB,会产生警告。

最大可能的限制是2047M。太低的值会影响索引速度,但256M到1024M对绝大多数数据集(如果不是全部)来说应该足够了。这个值设得太高可能导致 SQL服务器连接超时。在文档收集阶段,有时内存缓冲的一部分会被排序,而与数据库的通信会暂停,于是数据库服务器可能超时。这可以通过提高SQL服务器 端的超时时间或降低 mem_limit来解决。 在Coreseek的分发版本中,如果使用python数据源,则在Python部分的处理不会受mem_limit的限制。

示例:

mem_limit = 256M
# mem_limit = 262144K # same, but in KB
# mem_limit = 268435456 # same, but in bytes

11.3.2. max_iops:每秒IO操作限制

每秒最大I/O操作次数,用于限制I/O操作。可选选项,默认为0(无限制)。

与I/O节流有关的选项。它限制了每秒钟最大的I/O操作(读或写)的次数。值0意思是不加限制。

indexer在索引时可能导致突发的密集磁盘I/O,因此需要限制它磁盘活动(给同一台机器上运行的其他程序留出一些资源,比如searchd)。 I/O节流就是用来实现上述功能的。它的工作原理是,在indexer的连续磁盘I/O操作之间强制增加一个保证的延迟。现代SATA硬盘每秒钟可以执行多达70-100以上次的I/O操作(主要受磁头寻道时间的限制)。将索引I/O限制为上述数值的几分之一可以减轻由索引带来的搜索性能下降。

示例:

max_iops = 40

11.3.3. max_iosize:最大IO操作限制

最大允许的I/O操作大小,以字节为单位,用于I/O节流。可选选项,默认为0(不限制)。

与I/O节流有关的选项。它限制indexer文件I/O操作的单次最大大小。值0代表不加限制。超过限制的读写操作会被分成几个小的操作,并被max_iops 计为多次。在本文写作时,全部I/O操作都被限制在256KB以下(默认的内部缓冲大小),因此大于256KB的max_iosize值没有任何作用。

示例:

max_iosize = 1048576

11.3.4. max_xmlpipe2_field:最大字段大小

对于XMLLpipe2数据源允许的最大的字段大小,以字节为单位。可选选项,默认值为2MB。

示例:

max_xmlpipe2_field = 8M

11.3.5. write_buffer:写缓冲大小

写缓冲区的大小,单位是字节。可选选项,默认值是1MB。

在建立索引过程中,写缓冲用于写入临时行而最终的索引文件。写缓冲区越大则所需的磁盘写入次数越少。缓冲区使用的内存不计入 mem_limit选项的值。注意对于不同的文件,会分配多个缓冲区(目前最多4个),这会引起内存占用增加。

示例:

write_buffer = 4M

11.3.6. max_file_field_buffer:外部文件缓冲大小

文件字段可用的最大缓冲区大小,字节为单位。 可选项,默认为8MB,最小值为1MB.

File field buffer is used to load files referred to from sql_file_field columns. This buffer is adaptive, starting at 1 MB at first allocation, and growing in 2x steps until either file contents can be loaded, or maximum buffer size, specified by max_file_field_buffer directive, is reached.

Thus, if there are no file fields are specified, no buffer is allocated at all. If all files loaded during indexing are under (for example) 2 MB in size, butmax_file_field_buffer value is 128 MB, peak buffer usage would still be only 2 MB. However, files over 128 MB would be entirely skipped.

示例:

max_file_field_buffer = 128M

11.4. searchd 程序配置选项

11.4.1. listen:监听设置

指定searchd监听的IP地址和端口,或UNIX域socket的路径。于版本0.9.9-rc1引入。

一个非正式的listen语法说明如下:

listen = ( address ":" port | port | path ) [ ":" protocol ]

即,用户可以指定IP地址(或主机名)和端口号,或者仅仅是端口号,或者Unix socket的路径。如果仅指定了端口号而没有地址,那么searchd会在所有的网络接口上监听。Unix路径都带有一个前导的斜杠”/”。

从版本0.9.9-rc2开始,还可以指定一个协议处理器(protocl handler),或者叫监听器(listener),应用于这个socket上的连接。支持的协议值包括‘sphinx’(Sphinx 0.9.x API协议)和mysql41(版本4.1到至少5.1的MySQL使用的协议)。关于MySQL协议的更多细节可以参考 第 5.10 节 “MySQL 协议支持与 SphinxQL” 

示例:

listen = localhost
listen = localhost:5000
listen = 192.168.0.1:5000
listen = /var/run/sphinx.s
listen = 9312
listen = localhost:9306:mysql41

可以有多个listen指令,searchd 会在所有这些指令纸浆的端口和socket上监听,以备用户连接。如果没有找到listen指令,服务器会在所有的网络接口上用默认端口(9312)监听。 从版本1.10-beta开始,也会自动监听默认的SphinxQL端口9306。这两个端口号是由IANA(查看http://www.iana.org/assignments/port-numbers了解详情)所分配的,因此可以正常使用。

在Windows上不支持Unix域套接字。

11.4.2. address:监听地址

要绑定的接口IP地址。可选项,默认为0.0.0.0(即在所有接口上监听)。 不推荐, 建议使用 listen 

address 设置指定searchd在哪个接口上绑定、监听和接受输入的网络连接。默认值为0.0.0.0,意思是在所有接口上监听。目前不能指定多个接口。

示例:

address = 192.168.0.1

11.4.3. port:监听端口

searchd 的TCP端口号。 不推荐, 建议使用 listen 。 必选项,默认为9312。

示例:

port = 9312

11.4.4. log:搜索系统日志

日志文件名。可选项,默认为“searchd.log”。全部searchd运行时事件会被记录在这个日志文件中。

Also you can use the 'syslog' as the file name. In this case the events will be sent to syslog daemon. To use the syslog option the sphinx must be configured '--with-syslog' on building.

示例:

log = /var/log/searchd.log

11.4.5. query_log:搜索查询日志

查询日志文件名。可选项,默认为空(不记录查询日志)。全部搜索查询会被记录在此文件中。其格式在第 5.9 节 “搜索服务(searchd) 查询日志格式”中描述。

In case of 'plain' format, you can use the 'syslog' as the path to the log file. In this case all search queries will be sent to syslog daemon with LOG_INFO priority, prefixed with '[query]' instead of timestamp. To use the syslog option the sphinx must be configured '--with-syslog' on building.

示例:

query_log = /var/log/query.log

11.4.6. query_log_format:查询日志格式

查询日志格式。 可选项,可用值为plain、sphinxql,默认为plain。 版本2.0.1-beta引入。

Starting with version 2.0.1-beta, two different log formats are supported. The default one logs queries in a custom text format. The new one logs valid SphinxQL statements. This directive allows to switch between the two formats on search daemon startup. The log format can also be altered on the fly, using SET GLOBAL query_log_format=sphinxql syntax. Refer to 第 5.9 节 “搜索服务(searchd) 查询日志格式” for more discussion and format details.

示例:

query_log_format = sphinxql

11.4.7. read_timeout:远程读取超时时间

网络客户端请求的读超时时间,单位是秒。可选项,默认是5秒。 searchd 强制关闭在此时间内未能成功发出查询的客户端连接。

示例:

read_timeout = 1

11.4.8. client_timeout:客户端超时时间

在使用持久连接时,两次查询之间等待的最长时间(单位是秒)。可选选项,默认是5分钟。

示例:

client_timeout = 3600

11.4.9. max_children:子进程数目限制

子进程的最大数量(或者说,并行执行的搜索的数目)。可选项,默认为0,不限制。

用来控制服务器负载。任何时候不可能有比此设置值更多的搜索同时运行。当达到限制时,新的输入客户端会被用临时失败(SEARCH_RETRY)状态码驳回,同时给出一个声明服务器已到最大连接限制的消息。

示例:

max_children = 10

11.4.10. pid_file:PID文件

searchd PID文件名。必选项。 Mandatory.

PID文件会在启动时重建(并锁定)。主守护进程运行时它含有该进程的ID,而当守护进程退出时该文件会被删除。这个选项是必须的,因为Sphinx在内部使用它做如下事:检查是否已有一个searchd示例;停止searchd;通知searchd应该轮换索引了。也可以被各种不同的外部自动化脚本所利用。

示例:

pid_file = /var/run/searchd.pid

11.4.11. max_matches:最大返回匹配数

守护进程在内存中为每个索引所保持并返回给客户端的匹配数目的最大值。可选选项,默认值为1000。

引入此选项是为了控制和限制内存使用,max_matches设置定义了搜索每个索引时有多少匹配项会保存在内存中。每个找到的匹配项都会被处理,但只有它们中最佳的N个会在内存中保持并最终返回给客户端。假设索引中包括2000000个当前查询的匹配项,你几乎总是不需要它们中的全部。 通常您需要扫描它们并根据某种条件(即按相关度排序、或者价格、或者其他什么)选出最好的那些,比如500个,并以在页面上显示20到100项。只跟踪最 好的500个匹配要比保持全部的2000000个匹配项大大地节约内存和CPU,之后可以对这些最佳匹配排序,然后丢弃除了要在页面上要显式的20项之外 的结果。max_matches控制“最佳N个匹配”中的N。

此参数明显影响每个查询消耗的内存和CPU。1000到10000的值通常就可以满足需求,但更高的值要小心使用。粗心地把max_matches增加到1000000意味着searchd被迫为每一个查询分配1M条匹配项的缓冲。这会明显增大查询的内存消耗,有时会明显影响性能。

特别注意!此限制还可在另一个地方指定。max_matches可以通过对应的API调用实时降低,该调用的默认值是1000。因此要使应用程序获取超过1000个匹配结果,必须修改配置文件,重启searchd,再用SetLimits()调用设置合适的限制。还要注意,API调用设置的限制不能大于.conf文件中的设置,这是为了预防恶意的或错误的请求。

示例:

max_matches = 10000

11.4.12. seamless_rotate:无缝轮换

防止 searchd 轮换在需要预取大量数据的索引时停止响应。可选选项,默认为1(启用无缝(seamless)轮换)。

索引可能包含某些需要预取到内存中的数据。目前.spa, .spi  .spm文件会被完全预取到内存中(它们分别包含属性数据,MVA数据和关键字索引)。若无无缝轮换,轮换索引时会尽量使用较小的内存,并如下工作:

  1. 新的查询暂时被拒绝(用“retry”错误码);

  2. searchd 等待目前正在运行的查询结束;

  3. 旧的索引被释放,文件被重命名;

  4. 新的索引文件被重命名,分配所需的内存;

  5. 新的索引属性和字典数据预调进内存;

  6. searchd 恢复为新索引提供查询服务。

然而,如果有大量的属性或字典数据,那么预调数据的步骤可能消耗大量的时间——预调1.5GB的文件可能需要几分钟的时间。

当启用了无缝轮换,轮换按如下工作:

  1. 为新索引分配内存;

  2. 新索引的属性和字典数据异步地预调进内存;

  3. 如果成功,旧的索引被释放,新旧索引文件被重命名;

  4. 如果失败,释放新索引;

  5. 在任意时刻,查询服务都正常运行——或者使用旧索引,或者使用新索引。

无缝轮换以轮换过程中更大的峰值内存消耗为代价(因为当预调新索引时.spa/.spi/.spm数据的新旧拷贝需要同时保持在内存中)。平均内存耗用不变。

示例:

seamless_rotate = 1

11.4.13. preopen_indexes:索引预开启

是否在启动是强制重新打开所有索引文件。可选选项,默认为1(全部打开)。

Starting with 2.0.1-beta, the default value for this option is now 1 (foribly preopen all indexes). In prior versions, it used to be 0 (use per-index settings).

设置为 1 时,该配置会覆盖并对所有提供服务的索引强制 打开 preopen 选项 They will be preopened, no matter what is the per-index preopen setting. When set to 0, per-index settings can take effect. (And they default to 0.)

Pre-opened indexes avoid races between search queries and rotations that can cause queries to fail occasionally. They also make searchd use more file handles. In most scenarios it's therefore preferred and recommended to preopen indexes.

示例:

preopen_indexes = 1

11.4.14. unlink_old:旧索引清理

索引轮换成功之后,是否删除以.old为扩展名的索引拷贝。可选选项,默认为1(删除这些索引拷贝)。

示例:

unlink_old = 0

11.4.15. attr_flush_period:属性刷新周期

UpdateAttributes()实时更新文档属性时,所产生的变化首先写入到这些属性在内存中的一份拷贝中(必须将docinfo设置成extern)。其后,一旦searchd正常关闭(通过发送SIGTERM信号),这些变化才写入磁盘。于版本0.9.9-rc1中引入。

从版本0.9.9-rc1开始,可以令searchd每隔一段时间就将变化写回磁盘,防止丢失这些变化。这个间隔时间通过attr_flush_period选项设置,单位是秒。

默认值是0,即关闭隔一段时间就将变化写回磁盘的特性,但是正常关闭时的写回不被关闭。

示例:

attr_flush_period = 900 # persist updates to disk every 15 minutes

11.4.16. ondisk_dict_default:索引字典存储方式

 ondisk_dict 指令的全局的默认值。 可选选项,默认值是0(将字典预先缓冲到内存)。于版本0.9.9-rc1中引入。

这个选项用于为当前使用的这份searchd正在提供服务的所有索引指定ondisk_dict选项的默认值。如果某个索引的这个选项做了显式设定,那么这个设定覆盖上述实例级的默认设置,这种机制提供了细粒度的控制。

示例:

ondisk_dict_default = 1 # keep all dictionaries on disk

11.4.17. max_packet_size:最大包大小

网络通讯时允许的最大的包的大小。这个限制既对来自客户端的查询包有效,也对分布式环境下远程代理返回的响应包有效。只用于内部校验,不直接影响内存占用和性能。可选选项,默认值是8M。于版本0.9.9-rc1引入。

示例:

max_packet_size = 32M

11.4.18. mva_updates_pool:MVA更新共享内存

用于多值属性MVA更新的存储空间的内存共享池大小。可选选项,默认大小是1M。于版本0.9.9-rc1引入。

这个设置控制用于存储多值属性MVA更新后的值共享存储池的大小。如果指定大小为0则意味着完全禁用多值属性MVA的更新。一旦达到了这个内存池大小的限 制,尝试更新多值属性MVA将得到错误。但普通的(标量的)属性仍然可以更新。由于内部实现上的技术困难,一旦多值属性MVA有所更新,则索引上发生的任何更新改变都不能在索引重建前被写入(store,flush)磁盘,尽管这可能在未来实现。同时,多值属性MVA是设计用来在索引重建前迅速反应数据库中的变化,而不是一种永久存储的机制。

示例:

mva_updates_pool = 16M

11.4.19. crash_log_path:崩溃日志

崩溃日志文件的路径(正式地说叫做前缀)。可选选项,默认值为空(不创建崩溃日志文件)。于版本0.9.9-rc1引入。 从版本2.0.1-beta开始不再推荐使用,崩溃调试信息将以文本格式会记录到searchd.log日志文件中,独立的二进制崩溃文件不再需要了。

11.4.20. max_filters:最大过滤器数目

每次查询允许设置的过滤器的最大个数。只用于内部检查,不直接影响内存使用或性能。可选选项,默认值是256。于版本0.9.9-rc1引入。

示例:

max_filters = 1024

11.4.21. max_filter_values:单个过滤器最大过滤值数目

单个过滤器允许的值的最大个数。只用于内部检查,不直接影响内存使用或性能。可选选项,默认值是4096。于版本0.9.9-rc1引入。

示例:

max_filter_values = 16384

11.4.22. listen_backlog:带处理监听队列

TCP监听待处理队列长度。可选选项,默认值是5。

在Windows系统上创建的Sphinx目前(版本0.9.9)只能一个接一个地处理请求。同时发生的请求会被操作系统级别的TCP协议栈装入到一个队 列中,无法如对的请求立即失败并收到“连接被拒”错误信息。listen_backlog选项控制这个连接队列的长度。非Windows平台上创建的 Sphinx使用默认值即可。

示例:

listen_backlog = 20

11.4.23. read_buffer:读缓冲区

每个关键字的读缓冲区的大小。可选选项,默认值是256K。

对于每个搜索查询中的每个关键词,有两个相关的读缓冲区(一个针对文档列表,一个针对关键词出现位置列表)。本选项允许控制他们的大小,增加每次查询的内存占用,但可能会减少IO时间。

示例:

read_buffer = 1M

11.4.24. read_unhinted:无匹配时读取大小

无匹配时读操作的大小。可选选项,默认值是32K。

当系统处理查询时,对于一些读取操作,系统预先就知道要读取的数据的确切长度,但是有一些却相反。其中对常见的是已匹配位置列表(hitlist)的长度 目前是无法预先取得的。这个选项控制在这些情况下读取多少数据。它会影响IO时间,对于比本选项设置值大的列表,IO时间减少,而对于那些较小的列表则是 IO时间增加。内存占用受影响,因为读缓冲区已经是分配好了的。也因此这个选项的设置值不能超过选项read_buffer的设置值。

示例:

read_unhinted = 32K

11.4.25. max_batch_queries:最大批量查询

每次批量查询的查询数限制。 可选项,默认为32个。

Makes searchd perform a sanity check of the amount of the queries submitted in a single batch when using multi-queries. Set it to 0 to skip the check.

示例:

max_batch_queries = 256

11.4.26. subtree_docs_cache:子树优化文档缓存

每个查询的公共子树文档缓存大小。 可选值,默认为0(禁止)。

Limits RAM usage of a common subtree optimizer (参见 第 5.11 节 “批量查询”). At most this much RAM will be spent to cache document entries per each query. Setting the limit to 0 disables the optimizer.

示例:

subtree_docs_cache = 8M

11.4.27. subtree_hits_cache:子树优化命中缓存

每个查询的公共子树命中缓存大小。 可选值,默认为0(禁止)。

Limits RAM usage of a common subtree optimizer (参见 第 5.11 节 “批量查询”). At most this much RAM will be spent to cache keyword occurrences (hits) per each query. Setting the limit to 0 disables the optimizer.

示例:

subtree_hits_cache = 16M

11.4.28. workers:MPM模式

多处理模式(MPM)。 可选项;可用值为none、fork、prefork,以及threads。 默认在Unix类系统为form,Windows系统为threads。 版本2.0.1-beta引入。

Lets you choose how searchd processes multiple concurrent requests. The possible values are:

  • none

  • All requests will be handled serially, one-by-one. Prior to 1.x, this was the only mode available on Windows.

  • fork

  • A new child process will be forked to handle every incoming request. Historically, this is the default mode.

  • prefork

  • On startup, searchd will pre-fork a number of worker processes, and pass the incoming requests to one of those children.

  • threads

  • A new thread will be created to handle every incoming request. This is the only mode compatible with RT indexing backend.

Historically, searchd used fork-based model, which generally performs OK but spends a noticeable amount of CPU in fork() system call when there's a high amount of (tiny) requests per second. Prefork mode was implemented to alleviate that; with prefork, worker processes are basically only created on startup and re-created on index rotation, somewhat reducing fork() call pressure.

Threads mode was implemented along with RT backend and is required to use RT indexes. (Regular disk-based indexes work in all the available modes.)

示例:

workers = threads

11.4.29. dist_threads:并发查询线程数

Max local worker threads to use for parallelizable requests (searching a distributed index; building a batch of snippets). Optional, default is 0, which means to disable in-request parallelism. 版本2.0.1-beta引入。

Distributed index can include several local indexes. dist_threads lets you easily utilize multiple CPUs/cores for that (previously existing alternative was to specify the indexes as remote agents, pointing searchd to itself and paying some network overheads).

When set to a value N greater than 1, this directive will create up to N threads for every query, and schedule the specific searches within these threads. For example, if there are 7 local indexes to search and dist_threads is set to 2, then 2 parallel threads would be created: one that sequentially searches 4 indexes, and another one that searches the other 3 indexes.

In case of CPU bound workload, setting dist_threads to 1x the number of cores is advised (creating more threads than cores will not improve query time). In case of mixed CPU/disk bound workload it might sometimes make sense to use more (so that all cores could be utilizes even when there are threads that wait for I/O completion).

Note that dist_threads does not require threads MPM. You can perfectly use it with fork or prefork MPMs too.

Starting with version 2.0.1-beta, building a batch of snippets with load_files flag enabled can also be parallelized. Up to dist_threads threads are be created to process those files. That speeds up snippet extraction when the total amount of document data to process is significant (hundreds of megabytes).

示例:

index dist_test
{
	type = distributed
	local = chunk1
	local = chunk2
	local = chunk3
	local = chunk4
}

# ...

dist_threads = 4

11.4.30. binlog_path:二进制日志路径

Binary log (aka transaction log) files path. Optional, default is build-time configured data directory. 版本2.0.1-beta引入。

Binary logs are used for crash recovery of RT index data that would otherwise only be stored in RAM. When logging is enabled, every transaction COMMIT-ted into RT index gets written into a log file. Logs are then automatically replayed on startup after an unclean shutdown, recovering the logged changes.

binlog_path directive specifies the binary log files location. It should contain just the path; searchd will create and unlink multiple binlog.* files in that path as necessary (binlog data, metadata, and lock files, etc).

Empty value disables binary logging. That improves performance, but puts RT index data at risk.

示例:

binlog_path = # disable logging
binlog_path = /var/data # /var/data/binlog.001 etc will be created

11.4.31. binlog_flush:二进制日志刷新

Binary log transaction flush/sync mode. Optional, default is 2 (flush every transaction, sync every second). 版本2.0.1-beta引入。

This directive controls how frequently will binary log be flushed to OS and synced to disk. Three modes are supported:

  • 0, flush and sync every second. Best performance, but up to 1 second worth of committed transactions can be lost both on daemon crash, or OS/hardware crash.

  • 1, flush and sync every transaction. Worst performance, but every committed transaction data is guaranteed to be saved.

  • 2, flush every transaction, sync every second. Good performance, and every committed transaction is guaranteed to be saved in case of daemon crash. However, in case of OS/hardware crash up to 1 second worth of committed transactions can be lost.

For those familiar with MySQL and InnoDB, this directive is entirely similar to innodb_flush_log_at_trx_commit. In most cases, the default hybrid mode 2 provides a nice balance of speed and safety, with full RT index data protection against daemon crashes, and some protection against hardware ones.

示例:

binlog_flush = 1 # ultimate safety, low speed

11.4.32. binlog_max_log_size:二进制日志大小限制

Maximum binary log file size. Optional, default is 0 (do not reopen binlog file based on size). 版本2.0.1-beta引入。

A new binlog file will be forcibly opened once the current binlog file reaches this limit. This achieves a finer granularity of logs and can yield more efficient binlog disk usage under certain borderline workloads.

示例:

binlog_max_log_size = 16M

11.4.33. collation_server:服务端默认字符集

Default server collation. Optional, default is libc_ci. 版本2.0.1-beta引入。

Specifies the default collation used for incoming requests. The collation can be overridden on a per-query basis. Refer to 第 5.12 节 “字符串排序规则” section for the list of available collations and other details.

示例:

collation_server = utf8_ci

11.4.34. collation_libc_locale:服务端libc字符集

Server libc locale. Optional, default is C. 版本2.0.1-beta引入。

Specifies the libc locale, affecting the libc-based collations. Refer to 第 5.12 节 “字符串排序规则” section for the details.

示例:

collation_libc_locale = fr_FR

11.4.35. plugin_dir:插件目录

Trusted location for the dynamic libraries (UDFs). Optional, default is empty (no location). 版本2.0.1-beta引入。

Specifies the trusted directory from which the UDF libraries can be loaded. Requires workers = thread to take effect.

示例:

workers = threads
plugin_dir = /usr/local/sphinx/lib

11.4.36. mysql_version_string:MySQL版本设置

A server version string to return via MySQL protocol. Optional, default is empty (return Sphinx version). 版本2.0.1-beta引入。

Several picky MySQL client libraries depend on a particular version number format used by MySQL, and moreover, sometimes choose a different execution path based on the reported version number (rather than the indicated capabilities flags). For instance, Python MySQLdb 1.2.2 throws an exception when the version number is not in X.Y.ZZ format; MySQL .NET connector 6.3.x fails internally on version numbers 1.x along with a certain combination of flags, etc. To workaround that, you can usemysql_version_string directive and have searchd report a different version to clients connecting over MySQL protocol. (By default, it reports its own version.)

示例:

mysql_version_string = 5.0.37

11.4.37. rt_flush_period:RT索引刷新周期

RT indexes RAM chunk flush check period, in seconds. Optional, default is 0 (do not flush). 版本2.0.1-beta引入。

Actively updated RT indexes that however fully fit in RAM chunks can result in ever-growing binlogs, impacting disk use and crash recovery time. With this directive the search daemon performs periodic flush checks, and eligible RAM chunks can get saved, enabling consequential binlog cleanup. 参见 第 4.4 节 “二进制日志” for more details.

示例:

rt_flush_period = 3600

11.4.38. thread_stack:线程堆栈

Per-thread stack size. Optional, default is 64K. 版本2.0.1-beta引入。

In the workers = threads mode, every request is processed with a separate thread that needs its own stack space. By default, 64K per thread are allocated for stack. However, extremely complex search requests might eventually exhaust the default stack and require more. For instance, a query that matches a few thousand keywords (either directly or through term expansion) can eventually run out of stack. Previously, that resulted in crashes. Starting with 2.0.1-beta, searchd attempts to estimate the expected stack use, and blocks the potentially dangerous queries. To process such queries, you can either the thread stack size by using the thread_stackdirective (or switch to a different workers setting if that is possible).

A query with N levels of nesting is estimated to require approximately 30+0.12*N KB of stack, meaning that the default 64K is enough for queries with upto 300 levels, 150K for upto 1000 levels, etc. If the stack size limit is not met, searchd fails the query and reports the required stack size in the error message.

示例:

thread_stack = 256K

11.4.39. expansion_limit:关键字展开限制

The maximum number of expanded keywords for a single wildcard. Optional, default is 0 (no limit). 版本2.0.1-beta引入。

When doing substring searches against indexes built with dict = keywords enabled, a single wildcard may potentially result in thousands and even millions of matched keywords (think of matching 'a*' against the entire Oxford dictionary). This directive lets you limit the impact of such expansions. Setting expansion_limit = N restricts expansions to no more than N of the most frequent matching keywords (per each wildcard in the query).

示例:

expansion_limit = 16

11.4.40. compat_sphinxql_magics

Legacy SphinxQL quirks compatiblity mode. Optional, default is 1 (keep compatibility). Introduced in version 2.0.1-beta.

Starting with version 2.0.1-beta, we're bringing SphinxQL in closer compliance with standard SQL. However, existing applications must not get broken, andcompat_sphinxql_magics lets you upgrade safely. It defauls to 1, which enables the compatibility mode. However, SphinxQL compatibility mode is now deprecated and will be removed once we complete bringing SphinxQL in line with standard SQL syntax. So it's advised to update the applications utilising SphinxQL and then switch the daemon to the new, more SQL compliant mode by setting compat_sphinxql_magics = 0. Please refer to 第 7.21 节 “SphinxQL 升级备注, version 2.0.1-beta” for the details and update instruction.

Example:

compat_sphinxql_magics = 0 # the future is now

11.4.41. watchdog

Threaded server watchdog. Optional, default is 1 (watchdog enabled). Introduced in version 2.0.1-beta.

A crashed query in threads multi-processing mode (workers = threads) can take down the entire server. With watchdog feature enabled, searchd additionally keeps a separate lightweight process that monitors the main server process, and automatically restarts the latter in case of abnormal termination. Watchdog is enabled by default.

Example:

watchdog = 0 # disable watchdog