Я не нашел лучшего способа, чем метод проб и ошибок (т. е. традиционный инженерный процесс), поскольку на скорость индексации влияет множество факторов, помимо аппаратного обеспечения: структура/сложность вашего индекса (сложные сопоставления, фильтры или анализаторы), типы данных, независимо от того, связана ли ваша рабочая нагрузка с вводом-выводом или процессором, и так в.
В любом случае, чтобы продемонстрировать, насколько это может быть изменчиво, я могу поделиться своим опытом, поскольку он отличается от большинства опубликованных здесь:
Elastic 5.6 с кучей 10 ГБ, работающей на одном виртуальном сервере с 16 ГБ ОЗУ, 4 виртуальными ЦП и твердотельным накопителем со средней скоростью 150 МБ/с при поиске.
Я могу успешно индексировать документы самых разных размеров с помощью http API (curl), используя пакет размером 10 тыс. документов (20 тыс. строк, размер файла от 25 МБ до 79 МБ), каждый пакет занимает ~ 90 секунд. index.refresh_interval устанавливается в -1 во время индексации, но это единственная «настройка», которую я сделал, все остальные конфигурации по умолчанию. Я предполагаю, что это в основном связано с тем, что сам индекс не слишком сложен.
Виртуальный сервер использует примерно 50 % ЦП, SSD со средней скоростью 40 МБ/с и 4 ГБ ОЗУ свободно, поэтому я, вероятно, мог бы ускорить его, отправив два файла параллельно (я пытался просто увеличить размер пакета на 50 %, но начал получать ошибок), но после этого, вероятно, имеет смысл рассмотреть другой API или просто распределить нагрузку по кластеру.
person
jmng
schedule
12.11.2018