ElasticSearch 6.x / 7.x - Дизайн индекса

Question

У нас есть трехузловой кластер ElasticSearch (для узла HDD: 50 ТБ, ОЗУ: 128 ГБ, ядер: 22) с ежедневной вставкой документов 500 000 000.

У кластера проблемы со слишком большим количеством открытых индексов, размером кучи и т. Д. Слишком много осколков на узел.

Так как типы документов ES v6 больше не должны использоваться, вместо этого вы должны использовать отдельные индексы для каждого. Поэтому я изменил дневной индекс на 9 различных субиндексов с очень разными размерами контента в день:

, например

biggest sub-Index per day: 156.9m

medium sub-index per day: 17.6m

smallest sub-index per day: 2k

Разумно ли / лучшие практики разбивать на множество субиндексов или это оказывает большое влияние на кучу?

Заранее спасибо

Answer 1

В нашем сценарии регистрации / мониторинга мы потребляем ~ 30 ТБ в день. Это то, что я узнал в прошлые годы: не важно количество документов, размер осколка элементарен!

Идеальный размер индекса зависит от количества и размера основного шарда. Есть приятное место для размера индекса и количества первичных осколков. Как это найти? Проверьте!

Настройка одного индекса шарда без реплик. Заполните его как можно быстрее (с реальными документами) и следите за производительностью записи / индексации. Проводите параллельный поиск в соответствии с вашим SLA. Индекс и время поиска должны расти линейно с добавлением объема данных до момента, когда задержка будет внезапно расти экспоненциально. Это максимальный размер осколка для вашей машины / установки. Если вы не хотите тестировать, стремитесь получить 10-40 ГБ за осколок, как правило.

Таким образом, если ваш кластер состоит из трех узлов и трех сегментов на индекс (как вы, вероятно, хотите распределить записи по узлам), ваш «идеальный» индекс может составлять около 30–120 ГБ. Если вам нужны более быстрые записи, добавьте больше основных шардов - но не опускайтесь ниже 10 Гб за шард При таком размере затраты на управление осколками и накладные расходы на lucene больше, чем выгода от дополнительного осколка.

Просто чтобы было сказано:

• Чтобы предотвратить использование 64-битных указателей в JVM, никогда не следует создавать экземпляры с кучей больше 32 ГБ и дополнительными 32 ГБ, оставленными свободными для lucene.
• Предотвращение медленного (сетевого подключения) хранилища. Локальное хранилище - королева, SSD (или быстрее) - король. Но при использовании быстрого оптоволоконного канала SAN с поддержкой SSD / NVME должен работать так же, как и у нас.

В вашем случае подсчитайте, сколько времени займет заполнение индекса «идеального» размера и фрагмента. Затем поверните в этом интервале. Контролируйте и увеличивайте / уменьшайте количество первичных осколков, если это необходимо.

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

Ура!

Answer 2

Спасибо, что поделились своим опытом с es index design:)

Это создается ежедневно:

event-moduleA-2019.05.20 -> 5 shards -> 1 replication -> primary storage size: 60 gb
event-moduleB-2019.05.20 -> 5 shards -> 1 replication -> primary storage size: 2000 kb
event-moduleC-2019.05.20 -> 5 shards -> 1 replication -> primary storage size: 3000 kb
event-moduleD-2019.05.20 -> 5 shards -> 1 replication -> primary storage size: 10 gb
event-moduleE-2019.05.20 -> 5 shards -> 1 replication -> primary storage size: 5 gb
event-moduleF-2019.05.20 -> 5 shards -> 1 replication -> primary storage size: 50 gb
event-moduleG-2019.05.20 -> 5 shards -> 1 replication -> primary storage size: 4000 kb

Обычно мы запрашиваем событие- *, например.

Вопрос в том, должен ли я объединить все в гигантский индекс, такой как event-2019.05.20, с объемом основного хранилища: 120 ГБ - 200 ГБ в зависимости от дня. Но тогда мне нужно было бы добавить дополнительное поле к каждому документу с именем типа модуля (каждый тип модуля имеет разные, а также некоторые общие поля документа), Q1: это имеет влияние?

Q2: Будет ли лучше объединить все и разделить их? Хорошо, очень маленькие значения, я могу уменьшить количество осколков до 1:)

В3: ES 7 имеет мягкое ограничение на 1000 шардов / узел. Должны ли мы купить дополнительный узел, чтобы достичь 1000 шардов на узел? Сколько узлов вы бы взяли:)?