А где я говорил что в ES хранятся метрики? Для метрик у там использовались специализированные хранилища на базе graphite / prometheus. Graphite перевели на backend на базе Clickhouse, а тугой prometheus на VictoriaMetrics.
ES нужен именно для полнотекстового поиска по разным исходным данным.
1) Baikalbeat (https://github.com/elabpro/baikalbeat/) не совсем корректное название, так как он не beat, а узко специализированная утилита, созданная с определенными допущениями. Kafkabeat - полноценный beat. Экономить приходилось на всем - от конкатенации строк до выкидывания JSON парсинга. За счет этого и получили нужные скорости с меньшим потреблением ресурсов
2) SAS ноды у нас легко были переведены в HOT - там ничего не тюнилось специально под это. Изначально при создании нод делался уже максимальнный тюнинг: RAID0 для создания быстрых объемных разделов, оптимизация файловой системы (xfs - журнализация), ограничение каждой ноды объемом в 32Gb RAM, тюнинг jvm и остального всего, до чего можно добраться на своем сервере.
1) у меня был хороший Netapp с хорошей гарантией, и нужный объем в несколько петабайт мне могли обеспечить. Но мне и не надо было много петабайт для дальнейшего роста, там уже лучше было тратить деньги на адаптацию инструментов и переход на Clickhouse подобные решения.
2) По ES на k8s - 2-3 раза обдумывали это решение и не нашли ему применения. Мало того, что сам k8s съедает часть ресурсов, так и его использование усложняет процесс troubleshooting-а. Его лучше использовать там, где требуется запускать множество разнородных процессов с динамическим распределением серверных ресурсов. В таких местах там как раз мы использовали кубер.
Насколько я помню его вспомнили при анализе и его производительность была на уровне Kafkabeat. Основная проблема в обработке данных была в том, что надо было вытащить имя индекса, а для этого нужен был JSON парсинг, который съедал много ресурсов при любом вариант реализации. Возьмем к примеру их публикацию ( https://www.rsyslog.com/performance-tuning-elasticsearch/ ) - там они радуются 30K/s. Для 3M/s мне бы потребовалось 100 инстансев с их конфигурацией. Это достаточно ресурсоемко и затратно. Я обходился гораздо меньшим количеством своих байкалбитов
А где я говорил что в ES хранятся метрики? Для метрик у там использовались специализированные хранилища на базе graphite / prometheus. Graphite перевели на backend на базе Clickhouse, а тугой prometheus на VictoriaMetrics.
ES нужен именно для полнотекстового поиска по разным исходным данным.
1) Baikalbeat (https://github.com/elabpro/baikalbeat/) не совсем корректное название, так как он не beat, а узко специализированная утилита, созданная с определенными допущениями. Kafkabeat - полноценный beat. Экономить приходилось на всем - от конкатенации строк до выкидывания JSON парсинга. За счет этого и получили нужные скорости с меньшим потреблением ресурсов
2) SAS ноды у нас легко были переведены в HOT - там ничего не тюнилось специально под это. Изначально при создании нод делался уже максимальнный тюнинг: RAID0 для создания быстрых объемных разделов, оптимизация файловой системы (xfs - журнализация), ограничение каждой ноды объемом в 32Gb RAM, тюнинг jvm и остального всего, до чего можно добраться на своем сервере.
3) Локальные диски мы использовали, но для наших объемов стоимость локального хранения выходила дороже, чем Netapp. В силу еще разных ценовых политик.
А если эти объемы считать в облаках, то там и ценники уходят в облака :)
1) у меня был хороший Netapp с хорошей гарантией, и нужный объем в несколько петабайт мне могли обеспечить. Но мне и не надо было много петабайт для дальнейшего роста, там уже лучше было тратить деньги на адаптацию инструментов и переход на Clickhouse подобные решения.
2) По ES на k8s - 2-3 раза обдумывали это решение и не нашли ему применения. Мало того, что сам k8s съедает часть ресурсов, так и его использование усложняет процесс troubleshooting-а. Его лучше использовать там, где требуется запускать множество разнородных процессов с динамическим распределением серверных ресурсов. В таких местах там как раз мы использовали кубер.
Насколько я помню его вспомнили при анализе и его производительность была на уровне Kafkabeat. Основная проблема в обработке данных была в том, что надо было вытащить имя индекса, а для этого нужен был JSON парсинг, который съедал много ресурсов при любом вариант реализации. Возьмем к примеру их публикацию ( https://www.rsyslog.com/performance-tuning-elasticsearch/ ) - там они радуются 30K/s. Для 3M/s мне бы потребовалось 100 инстансев с их конфигурацией. Это достаточно ресурсоемко и затратно. Я обходился гораздо меньшим количеством своих байкалбитов