Просьба посоветовать. Сейчас под один проект планирую прикупить выделенный сервер, для 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 же позволяет достраивать индексы. Скажем, раз в 6-12 часов можно было бы.
Полное in-memory vs большой file-cache — in-memory все равно когда-то сохранять надо будет, верно?.. И что тогда делать будете?
У меня данные поступают большими порциями раз в неделю. Затем на основе этих данных меняются справочники (около десятка), а затем на основе справочников формируются готовые выдачи клиентам. Я пробовал отслеживать только изменения, но постоянно где-то рассинхронизация наступала. С точки зрения простоты поддержки системы и кода оказалось, проще просто перестраивать все заново.
4 cores, 32 Gb (8 Gb ES HEAP), HW RAID 2xSATA диска. Тянет, но редко используемые данные вытесняются из кеша, и при запросе их задержка достигает 100-150 мс. Второй запрос уже 25-40 мс, что приятнее.
Stan_1: по моему 100-150мс ни о чём
у нас Search - Query: 463.5ms 460.46ms 489.78ms 526.43m
4 ноды в кластере. Правда у нас за 100 миллионов документов, объём индекса около 12 гигабайт. На каждой ноде по 50 гигов оперативы, в HEAP выделено по 30гигов. Для хранилища используются диски SSD.
У нас очень тяжёлые запросы идут на него потому такие задержки. Когда было 2 ноды получалось держать всего 40-50 миллионов документов.
ИМХО пока что не вижу нужды сильно заморачиваться. Попробуйте кластер - это должно уменьшить время запросов. Для кластера и машинки можно с меньшим объёмом памяти брать.
HDD для хранилища даже не рассматривайте - Elastic очень чуствителен к IO
Да, ещё обратите внимание на mappings - выставьте корректные типы данных - нам позволило это сократить индекс в 6,5 раз от первоначальных результатов.
Средний
