Скорость массового импорта эластичного поиска при обновлении данных

Question

Моя текущая конфигурация кластера эластичного поиска имеет один главный узел и шесть узлов данных каждый на независимых экземплярах AWS ec2.

Master t2.large [2 vcpu, 8G ram]

Каждый узел данных r4.xlarge [4 vcpu. 30.5GB]

Количество осколков = 12 [это слишком мало?]

Каждый день я запускаю массовый импорт данных из журналов размером 110 ГБ.

Импортируется в три этапа.

Сначала создайте новый индекс и импортируйте данные объемом 50 ГБ.

Этот импорт выполняется очень быстро и обычно выполняется за 50-65 минут

Затем я запускаю вторую задачу массового импорта данных объемом около 40 ГБ, которая фактически является обновлением ранее импортированных записей. [Абсолютно нет новой записи]

Эта задача обновления занимает в среднем около 6 часов.

Есть ли способ ускорить / оптимизировать весь процесс, чтобы он работал быстрее?

Опции, которые я рассматриваю

1 - Увеличить количество узлов данных с текущих 6 до 10.

OR

2 - Увеличение памяти / ЦП на каждом узле данных.

OR

3 - полностью отделить часть обновления и импортировать все данные в отдельные индексы. Это потребует обновления логики запросов на стороне приложения, а также для того, чтобы запрашивать несколько индексов, но кроме этого, есть ли недостатки для нескольких индексов?

ИЛИ

4- Любой другой вариант, который я мог упустить из виду?

EDIT:

Я продолжил увеличивать количество узлов в качестве тестового прогона, и я могу подтвердить следующие результаты. [Публиковать здесь на всякий случай, если это кому-то поможет]

Примечание: спецификации каждого узла остались такими же, как указано выше

Current System 6 nodes 12 shards
Main insert (~50G) = 54 Min
Update      (~40G) = 5H30min

Test 1 System 10 nodes 24 shards
Main insert (~50G) = 51 Min
Update      (~40G) = 2H15min

Test 2 System 12 nodes 24 shards
Main insert (~50G) = 51 Min
Update      (~40G) = 1H36min

Существует огромное улучшение, но он все еще ищет предложения, хотя наличие такого количества случаев экономически обременительно.

Answer 1

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

Поскольку Updates требует, чтобы Elasticsearch сначала находил документ, а затем перезаписывал его, создавая новый индекс с новым номером версии, а затем удаляя старый индекс, который имеет тенденцию становиться медленнее, чем больше шарды. Вариант 3, который вы выбрали, будет идеальным решением для него, но он может повлиять на ваше время запроса, так как он должен искать по двум различным индексам. Этого можно избежать, введя поле с именем «type» в том же индексе, которое можно использовать для различения документов, что облегчит написание запроса для индекса Es, а также время для извлечения.

Например, (ваш индекс будет выглядеть примерно так, как вы могли бы получать данные)

    { 
      data:'some data'
      type:'first-inserted'

    },

   { 
      data:'some data'
      type:'second-inserted'

    }