1.批量更新数量大小限制

https://www.elastic.co/guide/cn/elasticsearch/guide/current/bulk.html#_How_Big_Is_Too_Big

整个批量请求都需要由接收到请求的节点加载到内存中，因此该请求越大，其他请求所能获得的内存就越少。批量请求的大小有一个最佳值，大于这个值，性能将不再提升，甚至会下降。但是最佳值不是一个固定的值。它完全取决于硬件、文档的大小和复杂度、索引和搜索的负载的整体情况。

幸运的是，很容易找到这个最佳点：通过批量索引典型文档，并不断增加批量大小进行尝试。当性能开始下降，那么你的批量大小就太大了。一个好的办法是开始时将 1,000 到 5,000 个文档作为一个批次, 如果你的文档非常大，那么就减少批量的文档个数。

密切关注你的批量请求的物理大小往往非常有用，一千个 1KB 的文档是完全不同于一千个 1MB 文档所占的物理大小。一个好的批量大小在开始处理后所占用的物理大小约为 5-15 MB。

2.跨集群复制（CCR）

https://www.elastic.co/cn/blog/cross-datacenter-replication-with-elasticsearch-cross-cluster-replication
付费功能

在 Elasticsearch 6.7 中引入跨集群复制后，无需再依赖其他技术便可跨数据中心、跨地区或者跨 Elasticsearch集群来复制数据。

买阿里云实例也可以。https://help.aliyun.com/zh/es/use-cases/use-the-ccr-feature-to-migrate-data

3.并发版本控制

方式1：两个字段控制并发：_seq_no、_primary_term（使用时传参_seq_no必须=当前文档）
https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control

To ensure an older version of a document doesn’t overwrite a newer version, every operation performed to a document is assigned a sequence number by the primary shard that coordinates that change. The sequence number is increased with each operation and thus newer operations are guaranteed to have a higher sequence number than older operations. Elasticsearch can then use the sequence number of operations to make sure a newer document version is never overridden by a change that has a smaller sequence number assigned to it.
译文：为了确保文档的旧版本不会覆盖新版本，负责协调变更的主分片会为对文档执行的每个操作分配一个序列号。该序列号会随着每次操作而增加，因此可以保证新操作的序列号高于旧操作。Elasticsearch 随后可以使用操作的序列号来确保新文档版本永远不会被分配了较小序列号的变更所覆盖。

方式2：_version（使用时传参_version必须>=当前文档）。
https://www.elastic.co/guide/cn/elasticsearch/guide/current/optimistic-concurrency-control.html