Elasticsearch常见的5个错误及解决策略

网罗Elasticsearch最佳实践，实际应用场景中常见错误要预知和避免，以最大化提升集群性能。

1、采用动态Mapping

如果不定义Mapping，Elasticsearch会根据输入的数据，创建对应的Mapping，这看起来非常完美，但是Elasticsearch的动态Mapping并不总是精确的。 动态Mapping对于入门很有用，但在某些时候您需要结合业务数据指定Mapping。

举例1：5.x版本之后，需要分词的字段需要设定text类型和对应的analyzer ；仅需要精确匹配的可直接设置为keyword类型。 举例2：长文本高亮需要在text类型的基础上，设置fast-vector-highlighter高亮方式，高亮效率能提升20倍以上。

2、聚合设置不当导致OOM

在某些聚合中，没有足够的内存来支持复杂的嵌套聚合，导致聚合结果超时甚至OOM。

举例说明：

现有9亿条数据，45个索引，每条数据大小为2k左右 在查询时候， 首先要按照时间进行排序，然后做三次分组操作？ https://elasticsearch.cn/question/6323

群友讨论实际问题

聚合爆炸是计算问题，可能导致某些聚合的桶生成呈指数增长，并可能导致不受控制的内存使用。

Elasticsearch“terms”字段根据您的数据构建存储桶，但无法预测将提前创建多少存储桶。 对于由多个子聚合组成的父聚合，这可能会有问题。 组合每个子聚合中的唯一值可能会导致创建的桶数量大幅增加。

我们来看一个例子。

假设您有一个代表运动队的数据集。 如果你想特别关注那支球队的前10名球员和以及他们的支持球员，那么聚合将如下所示

1{
 2"aggs" : {
 3"play_aggs" : {
 4"terms" : {
 5"field" : "players",
 6"size" : 10
 7},
 8"aggs" : {
 9"other_aggs" : {
10"terms" : {
11"field" : "players",
12"size" : 5
13}
14}
15}
16}
17}
18}

聚合将返回前10名球员的列表以及每位顶级球员的前五名支持球员的列表 - 这样总共将返回50个值。这个看上去简单的查询可以轻而易举地消耗大量内存。

terms聚合可以显示为使用每个级别的桶的树。因此，以上聚合中每个顶级球员的桶将构成第一级，而另一个聚合中的每个支持球员的桶将构成第二级。因此，一个团队将生产n²桶。想象一下，如果您拥有5亿个文档的数据集会发生什么。

Collection Mode用于帮助控制子聚合的执行方式。聚合的默认Collection Mode称为深度优先，首先需要构建整个树，然后修剪边缘。虽然深度优先是大多数聚合的适当收集模式，但它不适用于上面的运动员聚合示例。因此，Elasticsearch允许您将特定聚合中的收集模式更改为更合适的方式。

诸如上面的示例之类的规范应该使用广度优先收集模式，该模式一次构建和修剪树一级以控制聚合爆炸。 此收集模式极大地帮助减少消耗的内存量并保持节点稳定。

1{
 2"aggs" : {
 3"play_aggs" : {
 4"terms" : {
 5"field" : "players",
 6"size" : 10,
 7"collect_mode" : "breadth_first"
 8},
 9"aggs" : {
10"other_aggs" : {
11"terms" : {
12"field" : "players",
13"size" : 5
14}
15}
16}
17}
18}
19}

推荐阅读：http://t.cn/RHndSgY

3. ES索引设置不当

3.1 集群名称配置

ES启动的默认群集名称称为elasticsearch。 如果群集中有许多节点，最好保持命名标志尽可能一致，例如：

1cluster.name:app_es_production
2node.name:app_es_node_001

3.2 集群恢复设置

节点的恢复设置也很重要。 假设群集中的某些节点由于故障而重新启动，并且某些节点在其他节点之后重启。 为了使所有这些节点之间的数据保持一致，我们必须运行一致性程序，以使所有集群保持一致状态。

举例1：只要10个数据或主节点已加入群集，即可恢复。

1gateway.recover_after_nodes：10

举例2：集群中期待启动节点达到20个以及时间超过7分钟后，集群重启或恢复。

1gateway.expected_nodes：20
2gateway.recover_after_time：7m

使用正确的配置，可能需要数小时的恢复缩减到只需要分钟级，极大提高工作效率。

3.3 防脑裂配置

minimum_master_nodes对于群集稳定性非常重要。 它们有助于防止脑裂。 此设置的建议值为（N / 2）+ 1 ， 其中N是候选主节点的节点数。 有了这个，如果你有10个可以保存数据并成为主数据的 候选主节点，那么该值将是6。 如果您有三个专用主节点和1,000个数据节点，则该值为两个（仅计算候选主节点）： discovery.zen.minimum_master_nodes：2

4、集群不做规划，遇到问题再说

1“我需要多少存储空间、多大的内存？”是用户经常问自己的问题。

遗憾的是，没有固定的公式，但可以采取某些步骤来协助规划资源。 推荐方法：模拟实际用例。 步骤1：创建ES集群。 步骤2：使用与生产设置所需的数据速率几乎相同的数据。 步骤3：启动节点，用真实文档填充它们，然后推送填充数据到索引分片。

在模拟实际用例过程中了解资源利用率非常重要，因为它允许您为节点保留适当的RAM量，配置JVM堆空间并优化整个测试过程。

根据模拟结果，决定实际集群的内存、CPU、磁盘容量。

5、线程池设置不合理

ES节点具有许多线程池，以便改进节点内线程的管理方式。 但是每个线程可以处理多少数据存在限制。 要跟踪此值，我们可以使用ES属性：

1threadpool.bulk.queue_size：2000

这会向ES通知分片中的请求数，当没有可用于处理请求的线程时，新请求可以在节点中排队等待执行。 如果任务数高于此值，您将获得RemoteTransportException。 该值越高，节点机器上所需的堆空间量就越大，并且JVM堆也将被消耗。 此外，你应该在代码的开发阶段做好异常处理。

注意：ES官网不建议修改此值。

小结

Elasticsearch的使用过程中总会遇到这样、那样的问题，多总结、多思考，形成针对业务场景的有效的解决方案。 同时，也要多吸取国内外社区、论坛、博客中的精华，取长补短。

注意：网络文献一般没有涉及版本，老版本ES一些配置不一定适用于6.X最新版本，但，底层的技术永远不过时。

参考：

[1] http://t.cn/RRv9dw9

[2]http://t.cn/E2iBb3X

推荐阅读：

重磅 | 死磕Elasticsearch方法论认知清单（国庆更新版）