您是否正在以智能方式进行索引？

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

明确您的需求

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

为了提供边输入边搜索的体验，Meilisearch 需要以多种方式存储和组织数据，以便以最有效的方式检索数据。因此，文档在准备好进行搜索之前必须经过彻底的处理。

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

可搜索属性

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

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

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

说到这里：🤔唯一值……这听起来熟悉吗？💡主键！这是您可以安全地从可搜索属性列表中删除的另一个字段。

幕后

为了更好地理解自定义可搜索属性索引设置的重要性，让我们来看看可搜索属性所需的最大数据结构。在我们提到的十一个数据结构中，有三个构建时间最长：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）和数据集：对于类似大小的数据集，您可能会获得不同的结果。

水平轴表示数据集的大小，垂直轴表示索引时间

红线表示使用默认设置时的索引时间，蓝线表示使用自定义配置时的索引时间。在相同的机器和数据集下，我们观察到使用自定义设置时索引速度提高了 36%。

我们观察到数据库大小也有类似的改进，使用自定义设置时数据库大小显著减小

使用自定义设置时的数据库大小以蓝色显示，默认设置以红色显示

了解 Meilisearch 能为您的业务带来什么

与搜索专家交流

这就是全部了！我们介绍了加速索引过程的最佳实践。您知道这些技巧吗？遵循它们之后，您是否注意到索引速度有差异？在我们的 Discord 上分享您的经验！

您的反馈是帮助我们改进 Meilisearch 的关键！我再怎么强调也不为过，我也从不厌倦重复，因为这是事实。我们的社区与我们一起构建了 Meilisearch，并将继续帮助我们塑造它。

GitHub 上的问题或产品讨论，我们的路线图，我们的Discord 服务器……无论在哪里，无论如何，我们都想听到您的声音！