Comments 11
Рекомендую посмотреть именно выступление. Оно на редкость интересное
Также Павел делал схожий доклад на одном из митапов по Rust'у в рамках coLaboratory от Лаборатории Касперского. Рассказывал про плюсы и минусы использования экосистемы Rust'а, ситуации с драйверами к СУБД и т. п. аспектов.
UFO just landed and posted this here
сугубо субъективно. здесь в общем случае не существует решения. Как за основу можно взять числа кажущимися правильными, затем сделать «анализ на чувствительность» немного изменяя каждый из весов смотреть, какая база будет чаще встречаться. та, что при начальном задании весов или какая-то другая
Один из вариантов: «Сумма весов равна количеству оцениваемых критериев».
Важно веса зафиксировать до фактических испытаний систем, иначе начнется подстраивание весов под ожидаемые итоги.
Важно веса зафиксировать до фактических испытаний систем, иначе начнется подстраивание весов под ожидаемые итоги.
В вопросах бенчмарков решений есть такая проблема: все бенчмаркают good path. А послевкусие от эксплуатации остаётся от количества sad pathes, которые оказались bad pathes.
Тот же инфлюкс — няшка слов нет, только до определённой версии тяжёлая query продолжала фигачить в бэкграунде (с поеданием памяти) даже если запросивший закрыл сокет. Так сказать, лучший метод позвать дедушку OOM'а на новогодний праздник, это попытаться отрыть тяжёлый график, и нажать кнопку reload пять раз.
И для других СУБД такая же история. Пока не наешься, бенчмаркать глупо. А наешься в продакшене. Так что вариант «попробовать в продакшене» — не самый глупый, потому что затраты времени сравнимые, а результат куда более релевантный.
Потому что потратить пол-года на бенчмарки и найти Лучшую СУБД, чтобы через месяц продакшена обнаружить, что Лучшая СУБД течёт памятью по o(t * n) и фиксить эту фичу в апстриме не планируют…
Тот же инфлюкс — няшка слов нет, только до определённой версии тяжёлая query продолжала фигачить в бэкграунде (с поеданием памяти) даже если запросивший закрыл сокет. Так сказать, лучший метод позвать дедушку OOM'а на новогодний праздник, это попытаться отрыть тяжёлый график, и нажать кнопку reload пять раз.
И для других СУБД такая же история. Пока не наешься, бенчмаркать глупо. А наешься в продакшене. Так что вариант «попробовать в продакшене» — не самый глупый, потому что затраты времени сравнимые, а результат куда более релевантный.
Потому что потратить пол-года на бенчмарки и найти Лучшую СУБД, чтобы через месяц продакшена обнаружить, что Лучшая СУБД течёт памятью по o(t * n) и фиксить эту фичу в апстриме не планируют…
Для этого и есть тестовая эксплуатация. (Не путать с тестированием.)
По поводу инфлюкса именно на этапе тестовой эксплуатации мне пришлось от него отказаться в пользу clickhouse. Т.к. InfluxDB наполненный реальными метриками с продакшена через месяц начал постепенно деградировать по скорости. Самое печальное — он не выдержал проверку на необходимое время с момента рестарта сервера до момента когда InfluxDB начинает обрабатывать запросы — требовались минуты, при размере БД в 50gb.
По поводу инфлюкса именно на этапе тестовой эксплуатации мне пришлось от него отказаться в пользу clickhouse. Т.к. InfluxDB наполненный реальными метриками с продакшена через месяц начал постепенно деградировать по скорости. Самое печальное — он не выдержал проверку на необходимое время с момента рестарта сервера до момента когда InfluxDB начинает обрабатывать запросы — требовались минуты, при размере БД в 50gb.
ClickHouse умеет timespecific запросы? Например, derivative от time-series?
Насколько я помню такого счастья нет. Но у него достаточно быстро работает математический аппарат, можно построить и запросом, но если нужна глубокая специфика именно по timeseries то используте инструмент для этого предназначенный.
Clickhouse больше для аналитики по гигабайтам данных, особенно для изучения этих данных с целью построения итоговых моделей. После того как модель обработки данных определена аналитиком — лучше подумать о узкоспециализированном инструменте под эту модель.
Clickhouse больше для аналитики по гигабайтам данных, особенно для изучения этих данных с целью построения итоговых моделей. После того как модель обработки данных определена аналитиком — лучше подумать о узкоспециализированном инструменте под эту модель.
Sign up to leave a comment.
Выбираем СУБД для хранения временных рядов