Elasticsearch 的用途和注意事项

简介

在 Found 中，我们看到 Elasticsearch 有许多不同的用例。我们经常被问到“你们的典型客户是谁？”，但除了“他们宁愿花时间构建，也不愿意处理一堆集群！”之外，并没有明确的答案。我们了解到，Elasticsearch 有许多超赞的用途，有些用途甚至令人不可思议！

鉴于 Elasticsearch 仍然相当不成熟，我们的客户倾向于先在特定项目中使用 Elasticsearch，然后再加入更多的集群进行日志记录和分析。

一般来说，开发过程最初是为网站或文档集合构建简单的搜索。然后，可能会添加分面导航，以及拼写检查或“您是不是要找？”的回答。也许有必要添加模糊搜索和自动完成功能，甚至可能还要添加“输入即搜索”。由于相关度很重要，最终可能会根据用户的身份角色、用户所在的位置或用户认识的人添加更高级的排名方案。当然，要知道用户实际做了什么，就必须记录使用情况并存储指标，这样我们就能知道一切都在正常运行。

您可以使用 Elasticsearch 实现所有这些功能甚至更多功能，但是不同用途会产生截然不同的复杂性和资源需求。

众所周知的用途是搜索！（而且还在不断增加！）

不出意外的话，Elasticsearch 经常用于执行“搜索”，这通常意味着有一个带有放大镜图标的输入框。我们在这里所说的“搜索”可能会有歧义，因此我们将采用更具体的叫法。例如，我会将不同类型的搜索称为“简单搜索”、“模糊搜索”、“聚合”，简单指的是通过一个简单的 match 查询就能实现的搜索。

让很多人没有想到的是，简单搜索是 Elasticsearch 可以执行的资源消耗量最小的任务之一。如果您需要的只是常规、非模糊 match 查询的前十个结果，可通过每秒数百次的速度在价格低廉的硬件上持续搜索数千万个文档集合。但是，如果在需求列表中添加模糊搜索或分面导航，CPU 和内存需求就会大大增加。

现代搜索界面通常会有某种分面导航，以便用户快速了解搜索结果的分布情况。由特定作者撰写、处于特定价格范围且具有特定评分的书籍有多少？这些都是使用 Elasticsearch 中的聚合实现的，聚合的形式多种多样。您可以对词条、数值范围、日期范围、地理距离等进行聚合。

令很多人想不到的是，从数百万份文档中筛选出匹配文档要比以各种方式统计和聚合匹配文档更加轻松。尽管如此，与信息检索问题“哪十个文档与这些条件相匹配（且相关度最高）？”相比，聚合成本高昂。在通过评分找出最佳文档时，Lucene 会使用一些技巧，比如“这组文档不匹配其他文档匹配的所有内容，所以不可能是最佳文档，直接跳过”。 在筛选时，Elasticsearch 会大量使用筛选缓存。Elasticsearch 和 Lucene 的优势是尽可能减轻工作量，但使用聚合时，二者始终需要计算所有匹配内容。

在自下而上认识 Elasticsearch 中，我们介绍了倒排索引的工作原理，以及如何使用字典和发布列表执行简单的搜索。本文以及我们关于文本分析的文章应该清楚说明了为什么在使用搜索时务必正确处理文本。Elasticsearch 规模调整和生产环境中的 Elasticsearch 均详细说明了您可以如何使用内存。

分析

分析工作负载倾向于计数并汇总大量数据，甚至可能是大数据，不管这意味着什么！这些操作依赖于 Elasticsearch 的聚合，而聚合通常由 Kibana 等工具生成。

我们已经提到过，这些聚合在 CPU 和内存方面的成本十分高昂。对内存的需求很大，因为 Elasticsearch 需要快速查找给定文档的值，这就涉及到将所有文档的所有数据加载到“字段缓存”的内存中。使用“文档值”可以缓解这种情况，但在索引文档之前，需要在映射中启用“文档值”。

此外，分析搜索的执行对象通常是带有时间戳的数据，因此按时间划分索引（比如每日或每月索引）可能会比较合适。每个时间单位有一个索引，这样易于减少搜索空间，并清理和存档旧数据。

模糊搜索

模糊搜索是一种对拼写错误宽容的搜索。例如，在搜索 Levenstein 时，可以找到 Levenshtein。我们关于模糊搜索的文章更加详细地介绍了模糊搜索的使用方法和工作原理。

模糊搜索可轻松启用，并且可以大大提高“查全率”，但执行成本同样十分高昂。默认情况下，输入的一个词条会被改写为每个字段 50 个词条的 OR，再加上 multi_field，会导致改写后的查询中词条呈现组合爆炸式增长。

在将搜索的更改和改进交付生产之前，请务必始终使用实际数据量对其进行测试。在添加 fuzziness 参数时尤其要这样做。这一选项可轻松启用，但会使您的搜索成本提高几个数量级。

模糊搜索会消耗大量 CPU。请谨慎添加，而且可能不是每个字段都要添加。

自动完成和即时搜索

用户的输入即搜索有多种形式。可以是简单的建议（例如，现有标记），尝试根据搜索历史来预测搜索，或者只是为每个（受限制的）击键执行一次新搜索。

Elasticsearch 中有很多不同的功能有助于构建这些功能，例如 prefix 查询、match_phrase_prefix、索引 ngram 以及一系列不同的提示器。

这类搜索对延迟非常敏感。人类界定“即时”反应的阈值通常是 100 毫秒。搜索几乎每一个击键也会产生相当高的搜索吞吐量。因此，重要的是搜索成本低，这些索引与内存匹配。

自动完成搜索，同时显示最有可能完成的搜索结果（与 Google 的操作相似），应该视为两个独立的搜索问题。当自动完成先前的搜索时，要搜索的数据量可能比搜索的内容少得多，这会将其全部保存在内存中，使模糊搜索更加容易实现。由于自动完成搜索的搜索负载要比全面搜索高得多，因此，将两者分开，则有可能在完全独立的 Elasticsearch 集群中单独进行扩展。

Soundcloud 在改进搜索体验时，对搜索建议进行了提升。如果能够很好地实现，不仅会提高搜索精确度，还会明显减少支持全面搜索的基础架构的负载。人们搜索的内容通常呈 Zipf 分布：通常情况下，10% 的唯一搜索，会占有 90% 的搜索量 。因此，最佳搜索建议的全部结果很可能已缓存（在您的应用层），可以“即时”显示。

Elasticsearch 的提示器功能的实现，离不开 Soundcloud 的搜索提示器背后的诸多工程。Muir 和 Willauer 曾就 Lucene 查询建议做出精彩演讲，如需了解详情，强烈建议您观看。

多租户

通常情况下，您有多个客户或用户拥有单独的文档集合，用户永远无法搜索不属于自己的文档。在这种情况下，通常会导致采用各个用户拥有独立索引的设计。

但这往往会导致索引数过多。几乎在每种情况下，我们都能看到按用户建立索引的功能已经实现，但实际上最好使用更大的 Elasticsearch 索引。使用大量小型索引有几个主要缺点：

• 内存开销无法忽视。数千个小型索引将消耗大量堆空间。文件描述符的数量也会激增。
• 可能会出现大量重复内容。请考虑一下倒排索引的工作原理，以及 Lucene 如何分段写入和压缩内容。
• 快照/还原目前是连续的过程，每个索引都会产生开销。对数千个微型索引拍取快照所需的时间，比对几个大型索引拍取快照所需的时间要多一个数量级。

Elasticsearch 规模调整提供了关于分片和分区策略的更多信息以及大量参考资料。修复索引设计欠佳的应用程序需要付出巨大的努力，因此，花时间去了解不同的方法是值得的。

您可能不应为多租户应用程序的每个用户创建索引。

模式自由/用户定义的模式

对于拥有多个个人客户的情况，我们还发现，在很多用例中，不同的用户可能拥有完全不同的文档。例如，如果您要提供用户调查/问卷服务，不同的调查很可能包含完全不同的字段。

通常的结果是使用 Elasticsearch 的“动态映射”，有时会宣传 Elasticsearch 不区分模式。但是，Elasticsearch 会在后台为您创建映射，如果映射变得过大，就会导致“映射爆炸式增长”，从而带来问题。因此，请务必确保文档中的值最终呈现为值，而非单独的字段。“键/值问题”和“。

Elasticsearch 有各种映射功能，包括索引模板、动态模板、多字段等。用起来！

即使不使用映射，也要知道 Elasticsearch 为您创建了什么映射。

用户定义的搜索

与用户定义的模式有关通常表示需要让最终用户通过自定义筛选器、评分和聚合来定义其搜索。其中一种常见的方法是，将搜索请求限制在某些索引范围内，并且/或者使用筛选器包装用户的查询。

即使这样做，当用户可以定义自定义搜索请求时，也有几种情况会造成严重破坏，例如搜索的表达占用大量 CPU、导致内存独占，或者导致 Elasticsearch 崩溃。这些主题在导致 Elasticsearch 崩溃的六种情况和保护您的 Elasticsearch 集群中有所介绍。

请务必谨慎处理用户定义的搜索请求。

爬取和文档处理

有许多方法可以将数据导入 Elasticsearch。

河流是 Elasticsearch 的一个概念，表示 Elasticsearch 从源（比如 JDBC 连接的数据库、消息队列、Twitter 数据流或通过爬取网站）拉取数据。这些操作非常容易上手，但我们很快就可以发现，无论是在扩展方面还是在生产环境中运行，河流这一方法均具有挑战性。因此，“河流”已被弃用，我们应该寻求在 Elasticsearch 之外解决这些问题。Logstash 一直在竭力支持更多系统，因此可以取代大量河流。对于自定义应用程序而言，在将数据同步到 Elasticsearch 和准备 Elasticsearch 文档时，会遇到诸多挑战，河流这类简单通用的方法不足以应对此类挑战。在爬取时，人们将 Scrapy 和 Nutch 与 Elasticsearch 结合使用。

这涉及到将 Word 文档或 PDF 等文档处理和转换为 Elasticsearch 可以索引的纯文本。“mapper-attachments”插件可用于在 Elasticsearch 中完成此类转换。不过，虽然附件插件使用方便，但我们建议在将文档发送到 Elasticsearch 之前首先完成文档转换。这样，您就可以最大程度地控制文档的转换和优化。诸如此类的文档转换通常是“内容优化”的“文档/文本处理管道”中的第一步。您发送到 Elasticsearch 的文档应该是“内容优化/准备”的结果，让 Elasticsearch 完成最终的文本处理和索引。文档转换虽然会大量占用 CPU，但却容易并行化。最好让 Elasticsearch 将时间花在索引和搜索上，让“上游”客户端完成文档转换。

将处理后的数据推送到 Elasticsearch，而不是从 Elasticsearch 拉取数据并在其中进行处理。

总结

Elasticsearch 有很多内容需要学习，有时候很难知道自己需要学习哪些内容。

本文介绍了一些常见用例，以及所有这些用例中需要注意的一些重要事项。希望您已经找到与自己的需求相关的新内容，并更快地将 Elasticsearch 应用程序投入生产。