Какое железо выбрать для ElasticSearch?
70 views
Skip to first unread message
Stan
Apr 6, 2015, 3:46:26 PM4/6/15
to elastics...@googlegroups.com
Добрый день,
Просьба посоветовать. Сейчас под один проект планирую прикупить выделенный сервер, для ElasticSearch. Общий размер индексов - 25 Гбайт, около 42 млн. записей, количество которых растет очень малыми темпами. То есть почти фиксированная база данных. Проект делится на две части.
1. Сборка и пересборка данных. Происходит раз в неделю, перелапачивает всю базу чтобы в итоге сформировать наборы данных, отдаваемые юзерам.
2. Собственно, основная приоритетная задача - быстро отдать юзерам.
Вопрос 1 - как лучше организовать систему с такими характерстиками? На примете - три сервера:
Сервер 1 - 8 core CPU, 96 Gb RAM, 2x2Tb HDD
Сервер 2 - 8 core CPU, 96 Gb RAM, 2x600Gb SAS
Сервер 3 - 8 core CPU, 32 Gb RAM, 2x300Gb SSD
Насколько я понимаю, сам ES оптимально работает только при веделении ему памяти до 32 Гбайт. Исходя из этого, у меня в голове рисуются следующие комбинации настроек, чтобы получить практически полную работу in-memory.
1. 16 Gb под ES HEAP, 16 Gb - система, 64 Gb - временный диск в RAM для /tmp данных (сервер 1 или 2)
2. 64 Gb под ES HEAP (сервер 1 или 2)
3. 16 Gb под ES HEAP, и уповать на скорость SSD (сервер 3)
Или есть еще какие варианты? И насколько необходим SAS для такой нагрузки?
Вопрос 2 - раз в неделю осуществляется пересборка данных с помощью разных скриптов, которая занимает 2,5 часа и затрагивает до 30% объема записей. Все построено на bulk, mget, scroll, то есть на пакетных операциях. Опять же в порядке бреда в голове есть две мысли, как сделать оптимально:
1. На тестовом сервере осуществлять пересборку данных и потом уже просто потоком перелить все готовые записи с тестового сервера на production, не дергая большое число справочников, из которых состоит целевая запись. Плюсы: а) полная копия боевых данных на тестовом сервере, б) отсутствие лавинной непредсказуемой нагрузки на production сервере, в) не выбивание данных из кеша на период пересборки данных
2. Не париться, и делать пересборку данных на той же машине, не производя потом полной синхронизации. Плюсы: а) значительно упрощается инфраструктура ПО.
Все аргументы какие-то убогие получились, но это от незнания. Нужны просто best paractics. :)
Заранее спасибо!
Просьба посоветовать. Сейчас под один проект планирую прикупить выделенный сервер, для ElasticSearch. Общий размер индексов - 25 Гбайт, около 42 млн. записей, количество которых растет очень малыми темпами. То есть почти фиксированная база данных. Проект делится на две части.
1. Сборка и пересборка данных. Происходит раз в неделю, перелапачивает всю базу чтобы в итоге сформировать наборы данных, отдаваемые юзерам.
2. Собственно, основная приоритетная задача - быстро отдать юзерам.
Вопрос 1 - как лучше организовать систему с такими характерстиками? На примете - три сервера:
Сервер 1 - 8 core CPU, 96 Gb RAM, 2x2Tb HDD
Сервер 2 - 8 core CPU, 96 Gb RAM, 2x600Gb SAS
Сервер 3 - 8 core CPU, 32 Gb RAM, 2x300Gb SSD
Насколько я понимаю, сам ES оптимально работает только при веделении ему памяти до 32 Гбайт. Исходя из этого, у меня в голове рисуются следующие комбинации настроек, чтобы получить практически полную работу in-memory.
1. 16 Gb под ES HEAP, 16 Gb - система, 64 Gb - временный диск в RAM для /tmp данных (сервер 1 или 2)
2. 64 Gb под ES HEAP (сервер 1 или 2)
3. 16 Gb под ES HEAP, и уповать на скорость SSD (сервер 3)
Или есть еще какие варианты? И насколько необходим SAS для такой нагрузки?
Вопрос 2 - раз в неделю осуществляется пересборка данных с помощью разных скриптов, которая занимает 2,5 часа и затрагивает до 30% объема записей. Все построено на bulk, mget, scroll, то есть на пакетных операциях. Опять же в порядке бреда в голове есть две мысли, как сделать оптимально:
1. На тестовом сервере осуществлять пересборку данных и потом уже просто потоком перелить все готовые записи с тестового сервера на production, не дергая большое число справочников, из которых состоит целевая запись. Плюсы: а) полная копия боевых данных на тестовом сервере, б) отсутствие лавинной непредсказуемой нагрузки на production сервере, в) не выбивание данных из кеша на период пересборки данных
2. Не париться, и делать пересборку данных на той же машине, не производя потом полной синхронизации. Плюсы: а) значительно упрощается инфраструктура ПО.
Все аргументы какие-то убогие получились, но это от незнания. Нужны просто best paractics. :)
Заранее спасибо!
Igor Motov
Apr 7, 2015, 11:24:00 AM4/7/15
to elastics...@googlegroups.com
Размер хипа рекомендуют ограничивать 32G. Если остальную часть памяти оставить свободной - она будет использоваться кэшем файловой системы. Я думаю, это самый простой способ. Вы пробовали тестировать вашу сегодняшнюю систему подо нагрузкой? Что в ней тормозит? Процессор? Диск?
Stan
Apr 7, 2015, 12:44:33 PM4/7/15
to elastics...@googlegroups.com
Основная проблема - вытеснение редких записей из хипа, в результате чего их запрос занимает 200-500 мс вместо 10-30 мс. Хотелось бы этого избежать путем переноса всего в память на постоянной основе. Процессора хватает (как написал выше, на прогретых данных 10-30 мс), диск.... да какой-бы он был. Если не SSD, то задержка в момент подгрузки данных все равно будет.
вторник, 7 апреля 2015 г., 18:24:00 UTC+3 пользователь Igor Motov написал:
вторник, 7 апреля 2015 г., 18:24:00 UTC+3 пользователь Igor Motov написал:
Reply all
Reply to author
Forward
0 new messages