2023 年 1 月 23 日

您的索引方式是否明智？

将您的文档添加到 Meilisearch 是否花费太长时间？了解您可以采取哪些措施来加快索引过程。

Carolina FerreiraMeilisearch 的开发者布道师@CarolainFG

如果您只是使用我们的快速入门指南中的电影数据集试用 Meilisearch，那么索引您的数据可能只需要几秒钟。但是，如果您使用的是更大的数据集，那么花费的时间可能会更长。在本文中，我们将回顾一些最佳实践，以帮助您高效地索引数据并加快索引过程。

定义您的需求

Meilisearch 以离散记录的形式存储数据，称为文档，每个文档都必须有一个唯一的标识符——主键。文档被分组到集合中，称为索引。

为了提供即时搜索体验，Meilisearch 需要以多种方式存储和组织数据，以便尽可能高效地检索数据。因此，文档必须经过彻底的处理才能准备好进行搜索。

Meilisearch 中每个索引大约有 20 个数据结构，而构建这些结构是索引过程中最耗时的部分。更改索引设置可能会使许多这些数据结构失效，并需要重新索引您的数据。因此，通常最好在添加文档之前定义索引设置。

可搜索属性

默认情况下，添加到 Meilisearch 的所有文档字段都是可搜索的。但是，在可搜索属性列表中列出的字段中出现的词语需要最多的数据结构，确切地说是 11 个。加快索引速度的一个好方法是确保可搜索属性列表中的所有属性都是您真正希望检查是否与查询词匹配的属性。

例如，假设一个包含图片 URL 字段的文档。您可能希望向用户显示图片，但我怀疑用户有兴趣能够在 URL 中搜索查询词。不要忘记，并非所有显示的字段都需要是可搜索的！

在可搜索属性列表中指定实际需要的字段不仅重要，而且避免在可搜索字段中出现无意义、随机或唯一的值也至关重要。想象一下，所有那些充满“https”、“www”、“com”或“I77lHE”等值的数据库，在试图查找特定产品或电影时并非特别有用 😱

说到这里： 🤔唯一值…您是否觉得有点耳熟？ 💡主键！这是您可以安全地从可搜索属性列表中删除的另一个字段。

底层原理

为了更好地理解自定义可搜索属性索引设置的重要性，让我们来看看可搜索属性所需的最大数据结构。在我们提到的 11 个中，有 3 个构建时间最长：WORD_DOCIDS、WORD_POSITION_DOCID 和 WORD_PAIR_PROXIMITY_DOCIDS。

为了更好地理解每个数据结构的工作原理，我们将使用以下文档集作为示例

{
    "id": 1,
    "description": "New York City is the most populous city in the USA"
},
{
    "id": 2,
    "description": "New York was named in honor of the Duke of York"
},
{
    "id": 3,
    "description": "Tel Aviv is the new most expensive city in the world"
}

在 WORD_DOCIDS 中，每个词都与包含该词的文档的主键相关联

“new” => [1, 2, 3]
“york” => [1, 2]

在 WORD_POSITION_DOCID 中，键是词及其在文档中的位置。与键关联的值是该词占据相同位置的文档。在上面的文档中，id 将是属性 0，而 description 是属性 1

new(1,0) => [1, 2]：在文档 1 和 2 中，“new”一词位于属性 1，位置 0，它是属性 description 的第一个词
new(1, 4) => [3]：在文档 3 中，“new”位于属性 1，位置 4

最后，在 WORD_PAIR_PROXIMITY_DOCIDS 中，Meilisearch 会跟踪索引中所有文档的词对之间的距离。词语之间的距离必须在 8 个词语以内才能存储，因为距离较远的词语不被认为是同一上下文的一部分，因此不相关。

在上面的示例文档中，Meilisearch 将存储以下词对

newyork1 => [1, 2]
newcity2 => [1]
newcity3 => [3]

附加到词对的数字表示它们之间的距离

1 表示词语彼此相邻
2 表示它们之间相隔一个词语
3 表示它们之间相隔两个词语

如您所见，每个新词都代表 Meilisearch 内部数据结构中的额外行。诸如唯一 ID 或 URL 字符串之类的值可能会使数据库大幅增长，而且很可能是不必要的。

优化 Meilisearch 应该搜索哪些字段对于减少索引时间至关重要。它还可以提高相关性和搜索速度，因为结果不会被不相关的数据污染。

可过滤和可排序的属性

某些字段不包含任何词，但对于帮助用户找到他们需要的结果仍然至关重要。此类型的数据可能比常规的基于文本的搜索更适合进行过滤和排序。

可过滤属性是可以用作过滤器来优化搜索结果的属性。您可以使用它们来限制特定用户的搜索结果，或者创建分面搜索界面，允许用户根据他们选择的标准缩小结果列表范围。布尔类型的值非常适合用作过滤器。

可排序属性是可用于在搜索时进行排序的属性，这允许用户决定他们想要首先查看哪些文档。数值非常适合排序。

根据经验，如果您的数据集中包含具有数值和布尔字段值的文档，请花时间评估它们是否可以成为可过滤或可排序属性列表的一部分。

排名规则

排名规则负责搜索结果的相关性。 Meilisearch 包含六个内置排名规则

[
  "words",
  "typo",
  "proximity",
  "attribute",
  "sort",
  "exactness"
]

您还可以为升序和降序排序向此列表添加自定义规则

[
  "words",
  "typo",
  "proximity",
  "attribute",
  "sort",
  "exactness",
  "price:asc"
]

与用于在搜索时进行排序的可排序属性不同，自定义排名规则用于设置默认顺序。

如果您需要这种默认排序，最好预先配置。在文档已索引后添加新规则将触发重新索引，并可能让您感到沮丧！

缩小规模并批量处理

仅索引您真正需要的内容。您的数据库中的所有列都是必要的吗？数据集中的列越少，文档就越小。文档越小，它们的重量就越小，它们到达 Meilisearch 的速度就越快，然后 Meilisearch 将能够更快地处理它们。

Meilisearch 将连续的文档添加请求合并到一个批次中并一起处理。这大大加快了索引过程。由于每个批次的最终大小将取决于 Meilisearch 在处理最新文档添加请求时收到的数据量，因此建议以组的形式发送文档，而不是一个一个地发送。

出于同样的原因，请考虑压缩您的数据。Meilisearch 支持 br、deflate 和 gzip 压缩方法。您可以在我们的文档中找到更多信息。

保持更新并及时通知我们

使用最新的 Meilisearch 稳定版本。新版本通常包含性能改进，可以显著提高索引速度。

如果您遇到任何索引问题，请报告它们！这对于改进产品至关重要！

不要相信我，相信数据

在创建一些基准测试时，引擎团队的软件工程师 Many 创建了以下图表。请注意，索引时间高度依赖于机器的大小（CPU、RAM）和数据集：对于类似大小的数据集，您可能会获得不同的结果。

Line graph that compares the indexing time with two different configurations (default and custom) in relation to the dataset size. In all cases, the speed is higher with a custom configuration.