API разделения индекса

Операция разделения:

Переход с N фрагментов на N+1 фрагментов, т.е. инкрементное перераспределение фрагментов, действительно поддерживается многими хранилищами значений. Добавление нового фрагмента и перенос новых данных только в этот новый фрагмент не является вариантом: это, скорее всего, станет узким местом индексирования, и определение того, к какому фрагменту принадлежит документ, учитывая его _id, что необходимо для запросов get, delete и update, станет довольно сложной задачей. Это означает, что нам необходимо перебалансировать существующие данные с использованием другой схемы хеширования.

Наиболее распространенный способ эффективного выполнения этого в хранилищах значений — использование консистентного хеширования. Консистентное хеширование требует только 1/N-й части ключей для перемещения при увеличении количества фрагментов с N до N+1. Однако единицей хранения Elasticsearch являются фрагменты — индексы Lucene. Из-за их ориентированной на поиск структуры данных, взятие значительной части индекса Lucene, будь то только 5% документов, удаление их и индексирование их на другом фрагменте, как правило, сопряжено с гораздо большими затратами, чем в случае хранилища значений. Эти затраты остаются приемлемыми при увеличении количества фрагментов в кратном значении, как описано в предыдущем разделе: это позволяет Elasticsearch выполнять разделение локально, что, в свою очередь, позволяет выполнять разделение на уровне индекса, а не переиндексировать документы, которые нужно переместить, а также использовать жесткие ссылки для эффективного копирования файлов.

В случае данных только для добавления можно получить больше гибкости, создав новый индекс и перенеся в него новые данные, добавив псевдоним, охватывающий как старый, так и новый индекс для операций чтения. Предполагая, что у старого и нового индексов соответственно M и N фрагментов, это не имеет накладных расходов по сравнению с поиском в индексе, у которого было бы M+N фрагментов.

Чтобы разделить my_source_index на новый индекс с именем my_target_index, выполните следующий запрос:

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

Вышеуказанный запрос возвращает результат немедленно, как только целевой индекс добавлен в состояние кластера — он не ожидает начала операции разделения.

API _split аналогичен create index API и принимает параметры settings и aliases для целевого индекса:

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

Процесс разделения можно отслеживать с помощью _cat recovery API, или можно использовать cluster health API для ожидания, пока все первичные фрагменты не будут распределены, установив параметр wait_for_status в значение yellow.

_split API возвращает результат, как только целевой индекс добавлен в состояние кластера, прежде чем какие-либо фрагменты будут распределены. В этот момент все фрагменты находятся в состоянии unassigned. Если по какой-либо причине целевой индекс не может быть распределен, его первичный фрагмент останется в состоянии unassigned до тех пор, пока его не удастся распределить на этом узле.

После того как первичный фрагмент будет распределен, он переходит в состояние initializing, и начинается процесс разделения. Когда операция разделения завершается, фрагмент становится active. В этот момент Elasticsearch попытается распределить любые реплики и может принять решение о перемещении первичного фрагмента на другой узел.

Поскольку операция разделения создает новый индекс для разделения фрагментов, параметр ожидание активных фрагментов при создании индекса также применяется к операции разделения индекса.