Какова идеальная формула массового размера в ElasticSearch?

Ответ 1

Для этого нет золотого правила. Извлечен из документа:

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

Ответ 2

Я получил эту информацию из класса Java API BulkProcessor. Он по умолчанию использует 1000 действий или 5 МБ, а также позволяет установить интервал очистки, но по умолчанию он не установлен. Я просто использую настройки по умолчанию.

Я бы предложил использовать BulkProcessor, если вы используете Java API.

Ответ 3

Внимательно прочитайте документ API ES bulk: https://www.elastic.co/guide/en/elasticsearch/guide/current/indexing-performance.html#_using_and_sizing_bulk_requests

• Попробуйте с 1 KiB, попробуйте с 20 KiB, затем с 10 KiB,... дихотомия
• Используйте массовый размер в KiB (или эквивалент), а не количество документов!
• Отправить данные навалом (без потоковой передачи), передать избыточный информационный URL-адрес API, если вы можете
• Удалите лишние пробелы в ваших данных, если это возможно
• Отключить обновления индекса индекса, активировать его позже
• Круглый доступ ко всем узлам данных

Ответ 4

Я искал об этом, и я нашел ваш вопрос :) Я нашел это в эластичной документации.. поэтому я буду исследовать размер моих документов.

Часто полезно следить за физическими размерами ваших объемных запросов. Одна тысяча документов 1 КБ сильно отличается от тысячи 1 МБ документов. Хороший объемный размер, чтобы начать играть с размером около 5-15 МБ

Ответ 5

В моем случае я не мог получить более 100 000 записей для вставки за раз. Начал с 13 миллионов, до 500 000, но безуспешно начал с другой стороны, 1 000, затем 10 000, затем 100 000, мой максимум.

Ответ 6

Я не нашел лучшего способа, чем метод проб и ошибок (т.е. традиционный процесс разработки), поскольку существует множество факторов, помимо аппаратного, влияющих на скорость индексации: структура/сложность вашего индекса (сложные отображения, фильтры или анализаторы), типы данных, независимо от того, является ли ваша рабочая нагрузка вводом-выводом или процессором, и ,так на.

В любом случае, чтобы продемонстрировать, насколько она может быть переменной, я могу поделиться своим опытом, поскольку он отличается от большинства опубликованных здесь:

Elastic 5.6 с кучей 10 ГБ, работающей на одном сервере vServer с 16 ГБ ОЗУ, 4 vCPU и SSD со средним значением 150 МБ/с при поиске.

Я могу успешно индексировать документы разного размера через http API api (curl), используя размер пакета 10k документов (20k строк, размер файла от 25 МБ до 79 МБ), каждый пакет занимает ~ 90 секунд. index.refresh_interval установлен на -1 во время индексации, но, что касается единственной "настройки", которую я сделал, все остальные конфигурации являются настройками по умолчанию. Я предполагаю, что это в основном из-за того, что сам индекс не слишком сложен.

VServer имеет примерно 50% ЦП, усреднение SSD при 40 МБ/с и 4 ГБ свободной ОЗУ, поэтому я, вероятно, мог бы сделать это быстрее, отправляя два файла параллельно (я попытался просто увеличить размер пакета на 50%, но начал получать ошибки), но после этого, вероятно, имеет смысл рассмотреть другой API или просто распределить нагрузку по кластеру.