Как планировать ресурсы (я подозреваю, elasticsearch экземпляров) в зависимости от нагрузки:Logstash/Elasticsearch/Kibana планирование ресурсов
С нагрузкой я имею в виду ≈500K события/мин, каждый из которых содержит 8-10 полей.
Какую конфигурационную ручку я должен повернуть? Я новичок в этом стеке.
500 000 событий в минуту - 8,333 событий в секунду, что должно быть довольно легко для небольшого кластера (3-5 машин) для обработки.
Проблема будет заключаться в том, что ежедневные документы 720M открываются в течение 60 дней (документы 43B). Если каждое из 10 полей составляет 32 байта, это 13.8 ТБ дискового пространства (около 28 ТБ с одной репликой).
Для сравнения, у меня есть 5 узлов с максимальным объемом (64 ГБ оперативной памяти, 31 гигабайт), с 1.2B-документами, потребляющими 1,2 ТБ дискового пространства (двойной с репликой). Этот кластер не мог справиться с нагрузкой с 32 ГБ оперативной памяти на машину, но теперь он счастлив с 64 ГБ. Это 10 дней данных для нас.
Грубо говоря, вы ожидаете иметь 40x количество документов, потребляющих 10x дискового пространства, чем мой кластер.
У меня нет точных цифр передо мной, но наш пилотный проект по использованию doc_values дает нам нечто вроде экономии на кучу на 90%.
Если все эти математические данные сохраняются, а doc_values - это хорошо, вы можете быть в порядке с похожим кластером до фактического индексирования байтов. Я хотел бы получить дополнительную информацию об издержках из-за того, что у вас так много отдельных документов.
Мы выполнили некоторую настройку поиска elasticsearch, но, вероятно, возможно больше, чем это можно было бы сделать.
Я бы посоветовал вам начать с нескольких 64-гигабайтных машин. Вы можете добавить больше по мере необходимости. Бросьте в несколько (меньших) клиентских узлов в качестве интерфейса для запросов индекса и поиска.
Спасибо. У меня есть многообещающие 64-гигабайтные операционные системы, пересматриваю мою политику хранения. Предположим, что у меня есть все это, 10 машин, обрабатывающих 30 Тб данных, будут иметь эластичный кластер, способный своевременно запрашивать, это примерно 1,5 тб на экземпляр для сканирования. – inteloid
Как долго вы собираетесь хранить данные? Какую нагрузку на запрос вы ожидаете от вас? В конечном итоге это будет зависеть от многих факторов, которые вы можете получить здесь (возможно, образованных) догадок; вам просто нужно попробовать это для себя. –
Спасибо за комментарий. Нагрузка вечна, удержание может составлять 2 месяца. Хранение здесь не проблема, возможность запроса. Запрос для панели инструментов, 1-2 человека должны использовать его одновременно, скажем, у меня 20-30 визуализаций на приборную панель. Я просто хочу знать, это целая группа серверов, или это <10? – inteloid