1、采用动态模板
如果不定义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名球员和以及他们的支持球员，那么聚合将如下所示
{
"aggs" : {
"play_aggs" : {
"terms" : {
"field" : "players",
"size" : 10
},
"aggs" : {
"other_aggs" : {
"terms" : {
"field" : "players",
"size" : 5
}
}
}
}
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
聚合将返回前10名球员的列表以及每位顶级球员的前五名支持球员的列表 - 这样总共将返回50个值。这个看上去简单的查询可以轻而易举地消耗大量内存。
terms聚合可以显示为使用每个级别的桶的树。因此，以上聚合中每个顶级球员的桶将构成第一级，而另一个聚合中的每个支持球员的桶将构成第二级。因此，一个团队将生产n²桶。想象一下，如果您拥有5亿个文档的数据集会发生什么。
Collection Mode用于帮助控制子聚合的执行方式。聚合的默认Collection Mode称为深度优先，首先需要构建整个树，然后修剪边缘。虽然深度优先是大多数聚合的适当收集模式，但它不适用于上面的运动员聚合示例。因此，Elasticsearch允许您将特定聚合中的收集模式更改为更合适的方式。
诸如上面的示例之类的规范应该使用广度优先收集模式，该模式一次构建和修剪树一级以控制聚合爆炸。 此收集模式极大地帮助减少消耗的内存量并保持节点稳定。
{
"aggs" : {
"play_aggs" : {
"terms" : {
"field" : "players",
"size" : 10,
"collect_mode" : "breadth_first"
},
"aggs" : {
"other_aggs" : {
"terms" : {
"field" : "players",
"size" : 5
}
}
}
}
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
3. ES索引设置不当
3.1 集群名称配置
ES启动的默认群集名称称为elasticsearch。 如果群集中有许多节点，最好保持命名标志尽可能一致，例如：
cluster.name:app_es_production
node.name:app_es_node_001
1
2
3.2 集群恢复设置
节点的恢复设置也很重要。 假设群集中的某些节点由于故障而重新启动，并且某些节点在其他节点之后重启。 为了使所有这些节点之间的数据保持一致，我们必须运行一致性程序，以使所有集群保持一致状态。
举例1：只要10个数据或主节点已加入群集，即可恢复。
gateway.recover_after_nodes：10
1
举例2：集群中期待启动节点达到20个以及时间超过7分钟后，集群重启或恢复。
gateway.expected_nodes：20
gateway.recover_after_time：7m
1
2
使用正确的配置，可能需要数小时的恢复缩减到只需要分钟级，极大提高工作效率。
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属性：
threadpool.bulk.queue_size：2000
1
这会向ES通知分片中的请求数，当没有可用于处理请求的线程时，新请求可以在节点中排队等待执行。 如果任务数高于此值，您将获得RemoteTransportException。 该值越高，节点机器上所需的堆空间量就越大，并且JVM堆也将被消耗。
此外，你应该在代码的开发阶段做好异常处理。
注意：ES官网不建议修改此值。
小结
Elasticsearch的使用过程中总会遇到这样、那样的问题，多总结、多思考，形成针对业务场景的有效的解决方案。
同时，也要多吸取国内外社区、论坛、博客中的精华，取长补短。
注意：网络文献一般没有涉及版本，老版本ES一些配置不一定适用于6.X最新版本，但，底层的技术永远不过时。
参考：
[1] https://logz.io/blog/the-top-5-elasticsearch-mistakes-how-to-avoid-them/
