Рекомендации по аппаратному обеспечению Elastic Search [закрыто]

Есть ли хорошие руководства по аппаратному уровню для поддержки ElasticSearch? Рекомендации для Lucene или Solr - хорошее место для начала? Мы смотрим на развертывание развертывания, начиная с

• 27 миллионов документов, 8 ТБ данных
• добавить 300 тыс. документов в день

Затем увеличить это примерно в 10 раз, чтобы

• 270 миллионов документов, 80 ТБ данных
• добавить 3 миллиона документов / день

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

Есть много факторов, которые могут вступить в игру, поэтому я не думаю, что есть много общих рекомендаций.

Вам следует провести оценку в меньшем масштабе, возможно, с 1/5 начального набора данных, чтобы увидеть, как себя ведут, когда вы добавляете ожидаемую индексацию и поисковую нагрузку при настройке. Это позволит вам понять, сколько места ваши данные будут фактически занимать в поисковой системе. Для эластичного поиска зависит, сохраняете ли вы исходный json и как анализируются поля и сохраняются ли они.

EC2 может быть разумным способом оценки эластичного поиска без больших затрат на расход.

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

Мы запускаем кластер с 35 миллионами документов с общим размером индекса около 300 ГБ x 2, поскольку все индексы реплицируются. Для поддержки этого и очень большого количества запросов у нас есть 4 узла, каждый с 24 ядрами, 48 ГБ ОЗУ и 1 ТБ хранилища с 10 КБ дисков в raid10. Недавно мы увеличили размер диска, чтобы у нас было больше свободного места.

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

Низкий объем поиска фактически снижает производительность, поскольку кэши (как внутренние, так и используемые диски и ОС) не будут хорошо прогреваться.

Надеюсь, это поможет, Пол