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, выполните следующий запрос:

resp = client.indices.split(
    index="my_source_index",
    target="my_target_index",
    settings={
        "index.number_of_shards": 2
    },
)
print(resp)

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

const response = await client.indices.split({
  index: "my_source_index",
  target: "my_target_index",
  settings: {
    "index.number_of_shards": 2,
  },
});
console.log(response);

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

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

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

resp = client.indices.split(
    index="my_source_index",
    target="my_target_index",
    settings={
        "index.number_of_shards": 5
    },
    aliases={
        "my_search_indices": {}
    },
)
print(resp)

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

const response = await client.indices.split({
  index: "my_source_index",
  target: "my_target_index",
  settings: {
    "index.number_of_shards": 5,
  },
  aliases: {
    my_search_indices: {},
  },
});
console.log(response);

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

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

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

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

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