ElasticSearch的一些限制及推荐配置

限制

数组字段，数组大小无限制。

There is no hard limit but it’s definitely recommended to keep those arrays “reasonable”. When performing an update, Elasticsearch needs to fetch the entire doc, apply the update, then index the updated document and replicate the entire updated document to the replica, so very large arrays would come with a performance penalty indeed.

文档大小限制：2GB

Given that the default http.max_content_length is set to 100MB, Elasticsearch will refuse to index any document that is larger than that. You might decide to increase that particular setting, but Lucene still has a limit of about 2GB.

https://stackoverflow.com/questions/28841221/what-is-the-maximum-elasticsearch-document-size/28841656#28841656

https://www.elastic.co/guide/en/elasticsearch/reference/current/general-recommendations.html

单字段大小限制

未找到资料，感觉整个文档不超就好

推荐配置

模板参考配置

从ES 5.x开始，索引级设置需要写在模板中，或者在创建索引时指定，我们把各个索引通用的配置写到了模板中，这个模板匹配全部的索引，并且具有最低的优先级，让用户定义的模板有更高的优先级，以覆盖这个模板中的配置。

{
  "template": "*",
  "order": 0,
  "settings": {
    "index.merge.policy.max_merged_segment": "2gb",
    "index.merge.policy.segments_per_tier": "24",
    "index.number_of_replicas": "1",
    "index.number_of_shards": "24",
    "index.optimize_auto_generated_id": "true",
    "index.refresh_interval": "120s",
    "index.translog.durability": "async",
    "index.translog.flush_threshold_size": "1000mb",
    "index.translog.sync_interval": "120s",
    "index.unassigned.node_left.delayed_timeout": "5d"
  }
}

避免热索引分片不均

默认情况下，ES的分片均衡策略是尽量保持各个节点分片数量大致相同。但是当集群扩容时，新加入集群的节点没有分片，此时新创建的索引分片会集中在新节点上，这导致新节点拥有太多热点数据，该节点可能会面临巨大的写入压力。因此，对于一个索引的全部分片，我们需要控制单个节点上存储的该索引的分片总数，使索引分片在节点上分布得更均匀一些。

例如，10个节点的集群，索引主分片数为5，副本数量为1，那么平均下来每个节点应该有(5×2)/10=1个分片，考虑到节点故障、分片迁移的情况，可以设置节点分片总数为2：

curl --location --request PUT 'http://127.0.0.1:9200/myindex/_settings' \
--header 'Content-Type: application/json' \
--data '{
  "index": {
    "routing.allocation.total_shards_per_node": "2"
  }
}'

延时分片分配策略(节点离开延迟分片分配)

当节点出于任何原因（人为原因或系统异常）离开集群时，主节点会做出以下反应（如下称为步骤 X 是方便后续的解读）：

步骤1：将副本分片提升为主分片以替换节点上的任何主分片。
步骤2：分配副本分片以替换丢失的副本（在有足够的节点的前提下）。
步骤3：在其余节点之间均匀地重新平衡分片。

以上操作的好处是：避免集群数据丢失，确保集群高可用。

但可能带来的副作用也非常明显：其一，会给集群带来额外的负载（分片分配非常耗费系统资源）；其二，若离开集群的节点很快返回，上述机制的必要性就有待商榷。

此时，延迟分片分配就显得非常必要，设置如下：

PUT _all/_settings
{
  "settings": {
    "index.unassigned.node_left.delayed_timeout": "5m"
  }
}

延时分片分配策略的本质：

当节点离开集群并确认几分钟（自己设定）可以快速上线的情况下，离开的过程中只触发步骤1的将离开节点上的对应的副本分片提升为主分片。此时集群至少不是red 状态，而是yellow状态。步骤2、步骤3不会发生，此时集群是可用的，待设定的几分钟内下线集群确保重新上线后，分片再重新转为副本分片，此时集群恢复绿色状态。

这个过程有效避免了步骤2、步骤3的分片分配，整体上以最短的时间确保了集群的高可用性。

https://www.elastic.co/guide/en/elasticsearch/reference/current/delayed-allocation.html

每个节点将被恢复的并发分片数

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.node_concurrent_recoveries": 3
  }
}

以上配置:node_concurrent_incoming_recoveries和 node_concurrent_outgoing_recoveries同时生效。
incoming_recoverie:通常是其他节点上的副本 shard 恢复到该节点上outgoing_recoveries:通常是当前节点上的主分片 shard 恢复副本分片到其他节点上。

https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-cluster.html