[Manticore Search] 索引和数据类型

参考文献

Basics of Manticore Indexes
manticore Creating a local table
manticore Data types

索引类型

Manticore Search支持两种存储索引类型：

• Plain (also called offline or disk) index。数据在创建时索引一次，它支持非文本属性的在线重建和在线更新
• RealTime index。与数据库表类似，在线更新在任何给定时间都是可能的

此外，一个基于RealTime类型的特殊索引，称为 percolate，可以用于存储 Percolate Queries。

在当前版本中，索引使用与普通数据库表类似的模式。架构可以有三种大类型的列：

• 第一列总是一个无符号的64位非零数字，称为id。与数据库不同，没有自动递增机制，因此需要确保文档id是唯一的
• fulltext fields-它们包含索引内容。每个索引可以有多个全文字段。可以对所有字段进行全文搜索，也可以进行选择性搜索。当前未存储原始文本，如果需要在搜索结果中显示其内容，则必须使用搜索结果提供的id（或其他标识符）访问原始源
• attributes-它们的值被存储，不用于全文匹配。相反，它们可以用于常规的筛选、分组和排序。它们也可以用于分数排名的表达。

以下数据类型可以存储为 attributes ：

• 无符号32位和有符号64位整数
• 32位单精度浮点
• UNIX时间戳
• 布尔运算
• String
• JSON对象
• unsigned 32-bit integers 或 signed 64-bit integers 的多值属性列表

Manticore Search还支持一种称为distributed的无存储索引类型，它允许在多个索引上进行搜索。连接的索引可以是本地索引，也可以是远程索引。分布式索引允许在多台机器上传播大数据或构建高可用性设置。
另一种无存储索引类型是 template。模板索引不存储任何数据，但它可以像带存储的索引一样保存标记化设置。它可以用于测试标记化规则或生成 highlights(查询中标识想搜索的词)。

Plain index

除了numeric（包括MVA）属性外，plain index中的其余数据是不可变的。如果需要更新/添加新记录，则需要再次执行重建。当索引正在重建时，现有的索引仍然可以为请求提供服务。当新版本准备就绪时，将执行一个称为轮换的过程，使新版本联机并丢弃旧版本。

索引性能过程取决于几个因素：

• 源提供数据的速度
• 标记化设置（tokenization settings）
• 硬件资源（CPU功率、存储速度）

在最简单的使用场景中，我们将使用一个简单的索引，我们会不时地重建它。

这意味着：

• 索引不如源中的数据新鲜
• 索引持续时间随着数据的增长而增长

如果我们想让数据更新鲜，我们需要缩短索引创建的时间间隔。如果时间花费太多，甚至会使索引之间的时间重叠，这是一个主要问题。但是，Manticore Search可以对多个索引执行搜索。由此产生了一个想法，即使用仅捕获最新更新的辅助索引（main+delta index）。

Real-Time index

RealTime indexes 允许在线更新，但更新 fulltext data 和 non-numeric attributes需要完整的行替换。
RealTIme index 可以以与数据库表相同的方式添加、替换、更新或删除数据。更新首先保存在由 rt_mem_limit 定义的内存区域（称为RAM块）中。当它被使用完后，它被转储为磁盘块作为结构，它类似于plain index。随着磁盘块数量的增加，搜索性能会降低，因为搜索是按块顺序进行的。为了克服这个问题，需要将块合并为一个块，这是通过OPTIMIZE INDEX命令完成的。

RealTime indexes可以通过两种方式添加数据：INSERT或将普通索引转换为RealTime。现有数据可以一次由一条记录插入，也可以将多条记录批处理到一个插入中。插入数据的多个线程将加快速度，但将使用更多的CPU。

RAM块的大小会影响更新的速度，更大的RAM块将提供更好的性能，但需要根据可用内存来调整大小。还必须注意的是，rt_mem_limit仅限制RAM块的大小。磁盘块（基本上是一个普通索引）将有自己的内存需求（用于加载字典或属性）。

RAM块的内容在关闭期间或周期性地写入磁盘，由rt_flush_period指令定义（可以使用FLUSH RTINDEX命令强制执行）。RT索引还可以使用binary logging 记录来记录更改。binlog可以在后台进程启动时重播，以便在不干净的关闭后进行恢复，并在RAM块刷新到磁盘后清除。
刷新binlog策略（类似于MySQL的innodb_flush_log_at_trx_commit）可能会对性能产生影响。
binlog也可以被禁用（通过设置一个空的binlog路径），但这对尚未刷新到磁盘的更新没有任何保护。

数据类型

Full-text fields 和 attributes

Manticore的数据类型可以分为两类：Full-text fields 和 attributes。

Full-text fields

• 可以使用自然语言处理算法进行索引，因此可以搜索关键字。
• 不能用于排序或分组。
• 可以检索原始文档的内容。
• 原始文档的内容可用于 highlights。

Full-text fields 由数据类型 text 表示。所有其他数据类型都称为“attributes”。

Attributes

Attributes 是与每个文档相关联的 non-full-text values，可用于在搜索过程中执行非全文过滤、排序和分组。

通常，不仅需要根据匹配的文档ID及其排名，还需要根据许多其他每个文档的值来处理全文搜索结果。例如，可能需要按日期和相关性对新闻搜索结果进行排序，或者搜索指定价格范围内的产品，或者将博客搜索限制为选定用户的帖子，或者按月对结果进行分组。为了有效地做到这一点，Manticore不仅允许全文字段，还允许向每个文档添加其他属性。这些属性可用于筛选、排序或分组全文匹配，或仅按属性进行搜索。

与 full-text fields 不同，这些属性不进行全文索引。它们存储在表中，但无法将它们作为全文进行搜索。
一个很好的例子是论坛帖子表。假设只有标题和内容字段需要全文搜索，但有时也需要将搜索限制在某个作者或子论坛（即，仅搜索具有author_id或forum_id特定值的行）；或者按post_date列对匹配进行排序；或者按post_ date的月份对匹配帖子进行分组并计算每组匹配计数。

Row-wise and columnar attribute 存储

它们存储数据的方式不同。传统的 row-wise storage：

• 存储未压缩的属性。
• 同一文档的所有属性都存储在彼此靠近的一行中。
• 行被逐一存储。
• 访问属性基本上是通过将行ID乘以步幅（单个向量的长度）并从计算出的内存位置获取所请求的属性来完成的。它提供了非常低的随机访问延迟。
• 属性必须在内存中才能获得可接受的性能，否则由于存储的逐行性质，Manticore可能不得不从磁盘读取太多不需要的数据，这在许多情况下是次优的。

使用 columnar storage：

• 每个属性都独立于所有其他属性存储在其单独的“列”中。
• 存储被拆分为65536个条目的块。
• 这些块被压缩存储。这通常允许只存储几个不同的值，而不是像在行存储中那样存储所有值。高压缩比允许更快地从磁盘读取，并使内存需求大大降低。
• 当数据被索引时，每个块的存储方案都是独立选择的。例如，如果一个块中的所有值都相同，则它将获得“const”存储，并且整个块只存储一个值。如果每个块的唯一值少于256个，它将获得“表”存储，并将索引存储到值表中，而不是值本身。
• 如果很明显请求的值不在块中，则可以提前拒绝块中的搜索。