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

每個文檔都有一個 _version （版本）號，當文檔被修改時版本號遞增。 Elasticsearch 使用這個 _version 號來確保變更以正確順序得到執行。如果舊版本的文檔在新版本之后到達，它可以被簡單的忽略。

在應用中，上面兩種方式只能選擇一種，官方推薦使用第一種_seq_no、_primary_term