(ADAM-6000) с общим количеством параметров около 50-100 шт с частотой 300-500 мсек. Само приложение на .NET, хотя это неважно. Хотя пока для клиентской части аналитики особой не надо, кроме быстрых SELECT'ов. Целесообразно ли в данном случае использовать ClickHouse в данном OLTP сценарии? Спасибо!
Если задержка вставки не важна, то можно через буфер/кафку вставлять. Но если не будет аналитики - нецелесообразно. Лучше базу, которую люди умеют пользовать и администрировать.
Спасибо за разъяснения. Тогда лучше PostgresSQL или MariaDB буду использовать
Если я правильно понимаю, у вас получится: 1сек ~ 150-300 метрик. Если они не поля таблицы, то это 150-300 строк в секунду, размером минимум(на практике будет больше) - id,metric_id,metric_value + индекс по metric_id(это id,meric_lid) Итого: грубо 300 строк размером больше 5 * 4байта (минимум размер поля int) = 6Кб на секуду замеров. 9.3ярда строк и от56гиг размер таблицы за год. Это очень грубо, но прикиньте сколько вам нужно хранить данных, за какой период и какой производительности "мускуль" вам нужен. ЗЫ: date_time я провтыкал в расчётах
Вот и я поэтому призадумался, не использовать ли ClickHouse? Кое какая аналитика будет, но в основном надо будет в клиентском приложении быстро отображать данные за любой период. Тем более у клика есть сжатие. Пока в сомнениях.
клик берут тогда, когда мускула/постгри уже недостаточно, либо зуже раньше с кликом работают и на 100% понимают, что он здесь нужен
ну вполне себе юзкейс CH как мне кажется
Хм, в моем юзкейсе данные не надо всегда агрегировать, иногда м.б. надо показывать всякие средние за период, а так данные надо хранить в raw виде и отдавать клиенту быстрыми SELECT'ами.
у PG есть timescale для такого, и старые данные можно там пожать
Обсуждают сегодня