拆分索引 API

拆分操作

从 N 个分片到 N+1 个分片，也称为增量重新分片，确实是许多键值存储所支持的功能。添加一个新的分片并将新数据推送到这个新的分片是不可行的：这可能会成为索引瓶颈，并且根据文档的 _id 确定文档属于哪个分片（这对于获取、删除和更新请求是必要的）将变得相当复杂。这意味着我们需要使用不同的哈希方案重新平衡现有数据。

键值存储有效地做到这一点的最常见方法是使用一致性哈希。当分片数量从 N 增加到 N+1 时，一致性哈希只需要重新定位 1/N 的键。然而，Elasticsearch 的存储单元（分片）是 Lucene 索引。由于其面向搜索的数据结构，获取 Lucene 索引的很大一部分（即使只有 5% 的文档），删除它们并将它们索引到另一个分片，通常比使用键值存储的成本要高得多。当按上述部分所述的乘法因子增加分片数量时，此成本保持在合理的范围内：这允许 Elasticsearch 在本地执行拆分，这反过来又允许在索引级别执行拆分，而不是重新索引需要移动的文档，以及使用硬链接进行高效的文件复制。

对于仅追加数据，可以通过创建一个新索引并将新数据推送到该索引来获得更大的灵活性，同时添加一个涵盖旧索引和新索引的别名以用于读取操作。假设旧索引和新索引分别有 M 和 N 个分片，那么与搜索一个具有 M+N 个分片的索引相比，这样做没有任何开销。

要将 my_source_index 拆分为一个名为 my_target_index 的新索引，请发出以下请求

response = client.indices.split(
  index: 'my_source_index',
  target: 'my_target_index',
  body: {
    settings: {
      'index.number_of_shards' => 2
    }
  }
)
puts response

POST /my_source_index/_split/my_target_index
{
  "settings": {
    "index.number_of_shards": 2
  }
}

一旦目标索引被添加到集群状态，上述请求就会立即返回，而不会等待拆分操作开始。

_split API 类似于 创建索引 API，并接受目标索引的 settings 和 aliases 参数

response = client.indices.split(
  index: 'my_source_index',
  target: 'my_target_index',
  body: {
    settings: {
      'index.number_of_shards' => 5
    },
    aliases: {
      my_search_indices: {}
    }
  }
)
puts response

POST /my_source_index/_split/my_target_index
{
  "settings": {
    "index.number_of_shards": 5 
  },
  "aliases": {
    "my_search_indices": {}
  }
}

可以使用 _cat recovery API 监控拆分过程，或者可以使用 集群运行状况 API 通过将 wait_for_status 参数设置为 yellow 来等待所有主分片都已分配。

_split API 在目标索引被添加到集群状态后立即返回，此时还没有分配任何分片。此时，所有分片都处于 unassigned 状态。如果由于任何原因无法分配目标索引，则其主分片将保持 unassigned 状态，直到可以在该节点上分配它为止。

一旦分配了主分片，它就会进入 initializing 状态，并且拆分过程开始。当拆分操作完成时，分片将变为 active 状态。此时，Elasticsearch 将尝试分配任何副本，并可能决定将主分片重新定位到另一个节点。

由于拆分操作会创建一个新的索引来将分片拆分到其中，因此索引创建时的 等待活动分片 设置也适用于拆分索引操作。