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

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

一、采用动态Mapping
若是不定义Mapping，Elasticsearch会根据输入的数据，建立对应的Mapping，这看起来很是完美，可是Elasticsearch的动态Mapping并不老是精确的。
动态Mapping对于入门颇有用，但在某些时候您须要结合业务数据指定Mapping。

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

二、聚合设置不当致使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

四、集群不作规划，遇到问题再说
1“我须要多少存储空间、多大的内存？”是用户常常问本身的问题。

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

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

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

五、线程池设置不合理
ES节点具备许多线程池，以便改进节点内线程的管理方式。 可是每一个线程能够处理多少数据存在限制。 要跟踪此值，咱们可使用ES属性：

1threadpool.bulk.queue_size：2000

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

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

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

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