Manticore Search Manual

在许多情况下，整个数据集过大，无法频繁地从头重建，而新增记录的数量相对较少。例如，一个论坛可能有1,000,000条存档帖子，但每天只收到1,000条新帖子。

在这种情况下，可以使用“主+增量”方案实现“实时”（近实时）表更新。

该概念涉及设置两个源和两张表，一张“主”表用于存储很少变化（如果有的话）的数据，另一张“增量”表用于存储新文档。在示例中，1,000,000条存档帖子存储在主表中，而每天新增的1,000条帖子存储在增量表中。增量表可以频繁重建，使文档在几秒或几分钟内可供搜索。确定哪些文档属于哪张表以及重建主表可以完全自动化。一种方法是创建一个计数器表，跟踪用于划分文档的ID，并在主表重建时更新它。

使用时间戳列作为划分变量比使用ID更有效，因为时间戳不仅可以跟踪新文档，还可以跟踪被修改的文档。

对于可能包含被修改或删除文档的数据集，增量表应提供受影响文档的列表，确保它们被屏蔽并从搜索查询中排除。这是通过称为“杀死列表”的功能实现的。要杀死的文档ID可以在辅助查询中指定，该查询由sql_query_killlist定义。增量表必须使用killlist_target指令指明杀死列表将应用于的目标表。杀死列表对目标表的影响是永久性的，这意味着即使在没有增量表的情况下执行搜索，被屏蔽的文档也不会出现在搜索结果中。

注意我们在增量源中重写了sql_query_pre。我们必须显式包含此重写。如果不这样做，REPLACE查询也会在增量源构建期间执行，从而使其无效。

‹›

Example

Example

📋

# in MySQL
CREATE TABLE deltabreaker (
  index_name VARCHAR(50) NOT NULL,
  created_at TIMESTAMP NOT NULL  DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (index_name)
);
# in manticore.conf
source main {
  ...
  sql_query_pre = REPLACE INTO deltabreaker SET index_name = 'main', created_at = NOW()
  sql_query =  SELECT id, title, UNIX_TIMESTAMP(updated_at) AS updated FROM documents WHERE deleted=0 AND  updated_at  >=FROM_UNIXTIME($start) AND updated_at  <=FROM_UNIXTIME($end)
  sql_query_range  = SELECT ( SELECT UNIX_TIMESTAMP(MIN(updated_at)) FROM documents) min, ( SELECT UNIX_TIMESTAMP(created_at)-1 FROM deltabreaker WHERE index_name='main') max
  sql_query_post_index = REPLACE INTO deltabreaker set index_name = 'delta', created_at = (SELECT created_at FROM deltabreaker t WHERE index_name='main')
  ...
  sql_attr_timestamp = updated
}
source delta : main {
  sql_query_pre =
  sql_query_range = SELECT ( SELECT UNIX_TIMESTAMP(created_at) FROM deltabreaker WHERE index_name='delta') min, UNIX_TIMESTAMP() max
  sql_query_killlist = SELECT id FROM documents WHERE updated_at >=  (SELECT created_at FROM deltabreaker WHERE index_name='delta')
}
table main {
  path = /var/lib/manticore/main
  source = main
}
table delta {
  path = /var/lib/manticore/delta
  source = delta
  killlist_target = main:kl
}

合并表

Last modified: August 28, 2025

≫ 从表中添加数据

合并两个现有的普通表格可能比从头开始索引数据更高效，并且在某些情况下可能是需要的（例如在“main+delta”分区方案中合并“main”和“delta”表，而不是简单地重建“main”表）。因此，indexer 提供了一个选项来实现这一点。合并表格通常比重建更快，但对于巨大的表格来说仍然不是瞬间完成的。基本上，它需要读取两个表的内容一次，并写入结果一次。例如，合并一个100 GB和一个1 GB的表，将导致202 GB的I/O（但这仍然可能少于从头索引所需的量）。

基本命令语法如下：

sudo -u manticore indexer --merge DSTINDEX SRCINDEX [--rotate] [--drop-src]

除非指定了 --drop-src，否则只有 DSTINDEX 表会受到影响：SRCINDEX 的内容将被合并到 DSTINDEX 中。

如果 DSTINDEX 已经被 searchd 服务，则需要使用 --rotate 选项。

典型的使用模式是将较小的更新从 SRCINDEX 合并到 DSTINDEX 中。因此，在合并属性时，如果遇到重复的文档ID，SRCINDEX 中的值将优先使用。但是，请注意，在这种情况下，“旧”的关键字不会被自动删除。例如，如果 DSTINDEX 中文档123关联了关键字“old”，而 SRCINDEX 中关联了关键字“new”，合并后文档123将同时被这两个关键字找到。你可以提供一个显式条件来从 DSTINDEX 中删除文档以缓解此问题；相关的选项是 --merge-dst-range：

sudo -u manticore indexer --merge main delta --merge-dst-range deleted 0 0

此选项允许你在合并的同时对目标表应用过滤器。可以有多个过滤器；所有条件都必须满足，文档才会被包含在合并后的结果表中。在上面的示例中，过滤器只通过那些 'deleted' 为0的记录，排除了所有被标记为已删除的记录。

--drop-src 选项允许在合并后且旋转表之前删除 SRCINDEX，这在你将 DSTINDEX 指定为 DSTINDEX 的 killlist_target 时非常重要。否则，在旋转表时，已合并到 DSTINDEX 的文档可能会被 SRCINDEX 抑制。

主+增量模式纯表中的 Killlists

Last modified: August 28, 2025

使用普通表时，面临的一个挑战是需要保持表中的数据尽可能新鲜。

在这种情况下，会使用一个或多个辅助表（也称为增量表）来捕获主表创建时间与当前时间之间的修改数据。修改的数据可以包括新增、更新或删除的文档。搜索时会同时在主表和增量表中进行。这在仅向增量表添加新文档时工作得很顺畅，但当涉及更新或删除文档时，仍存在以下问题。

如果一个文档同时存在于主表和增量表中，搜索时可能会出现问题，因为引擎会看到文档的两个版本，不知道该选择哪个。因此，增量表需要以某种方式通知搜索，主表中有些已删除的文档应被忽略。这就是 kill list 的作用所在。

一个表可以维护一个文档 ID 列表，用于抑制其他表中的记录。此功能适用于使用数据库源的普通表或使用 XML 源的普通表。对于数据库源，源需要提供一个由 sql_query_killlist 定义的额外查询。该查询会在表中存储一个文档列表，服务器可以使用该列表从其他普通表中移除文档。

该查询预期返回多行单列数据，每行仅包含一个文档 ID。

在许多情况下，该查询是检索更新文档列表和删除文档列表的查询的联合，例如：

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

普通表可以包含一个名为 killlist_target 的指令，告诉服务器它可以提供一个文档 ID 列表，用于从某些现有表中移除文档。该表可以使用其文档 ID 作为该列表的来源，或提供一个单独的列表。

设置 kill-list 将应用到的表。可选，默认值为空。

当你使用普通表时，通常需要维护的不仅仅是单个表，而是一组表，以便更快地添加/更新/删除新文档（详见增量表更新）。为了抑制在后续（增量）表中更新或删除的前一个（主）表中的匹配项，你需要：

使用 sql_query_killlist 在增量表中创建 kill-list
在增量表设置中将主表指定为 killlist_target：

‹›

CONFIG

CONFIG

📋

table products {
  killlist_target = main:kl
  path = products
  source = src_base
}

当指定了 killlist_target 时，kill-list 会在 searchd 启动时应用到其中列出的所有表。如果 killlist_target 中的任何表被轮换，kill-list 会重新应用到这些表。应用 kill-list 后，受影响的表会将这些更改保存到磁盘。

killlist_target 有三种操作模式：

killlist_target = main:kl。增量表的 kill-list 中的文档 ID 会在主表中被抑制（参见 sql_query_killlist）。
killlist_target = main:id。增量表中的所有文档 ID 会在主表中被抑制。kill-list 会被忽略。
killlist_target = main。增量表中的文档 ID 及其 kill-list 中的文档 ID 都会在主表中被抑制。

可以指定多个目标，用逗号分隔，如：

killlist_target = table_one:kl,table_two:kl

你可以使用 ALTER 修改表的 killlist_target 设置，而无需重建表。

但是，由于“旧”的主表已经将更改写入磁盘，即使它不再是增量表的 killlist_target，在其中被删除的文档仍将保持删除状态。

‹›

SQL
HTTP

📋

ALTER TABLE delta KILLLIST_TARGET='new_main_table:kl'

合并表将一个表附加到另一个表

Last modified: August 28, 2025

主+增量方案

≫ 从表中添加数据

合并表格

Killlist 在普通表中的应用

表的 kill-list

从普通表中移除文档

killlist_target