Исправление router, (текущая версия) :
Данных по производительности TimescaleDB пока не нашёл. Есть краткое сравнение
https://docs.google.com/spreadsheets/d/1sMQe9oOKhMhIVw9WmuCEWdPtAoccJ4a-IuZv4...
Без привязки к сабжу, в общих чертах, TSDB это не СУБД, а специализированая база ( как nosql предназначен для хранения key-value, так tsdb для хранения метрик производительности ). Нет необходимости в связях между базами, запись - только дополнение, но не модификация и т.д.
За счёт таких жертв на своей задаче работают существенно быстрее, и существенно менее требовательны к ресурсам.
Ну и свой язык запросов, позволяющий выполнять операции над несколькими временными рядами ( например, построить график (a(t)+b(t))/c(t)*100 ). Есть правила, как поступать, когда данных по одной из time series за определённый timestamp нет. Есть свои операции над векторами
См. например https://prometheus.io/docs/prometheus/latest/querying/basics/
Опять же, это всё теория, и непосредственно timescaledb я не щупал. Т.к. я не разработчик и меня интересуют более-менее готовые к использованию игрушки, к которым уже есть примеры работы :)
TSDB используются в современных системах мониторинга ( prometheus, influxdb stack и т.д. ). Недавно в zabbix добавили поддержку, но пока не смотрел
Как timescaledb чувствует себя поверх универсальной СУБД не знаю. Но из плюсов можно назвать полноценную репликацию ( у influxdb только в коммерческой версии, причём говорят работает не айс ) и бекапы
Исходная версия router, :
Данных по производительности TimescaleDB пока не нашёл. Есть краткое сравнение
https://docs.google.com/spreadsheets/d/1sMQe9oOKhMhIVw9WmuCEWdPtAoccJ4a-IuZv4...
Без привязки к сабжу, в общих чертах, TSDB это не СУБД, а специализированая база ( как nosql предназначен для хранения key-value, так tsdb для хранения метрик производительности ). Нет необходимости в связях между базами, запись - только дополнение, но не модификация и т.д.
За счёт таких жертв на своей задаче работают существенно быстрее, и существенно менее требовательны к ресурсам.
Ну и свой язык запросов, позволяющий выполнять операции над несколькими временными рядами ( например, построить график (a(t)+b(t))/c(t)*100 ). Есть правила, как поступать, когда данных по одной из time series за определённый timestamp нет. Есть свои правила взаимодействия над векторами
См. например https://prometheus.io/docs/prometheus/latest/querying/basics/
Опять же, это всё теория, и непосредственно timescaledb я не щупал. Т.к. я не разработчик и меня интересуют более-менее готовые к использованию игрушки, к которым уже есть примеры работы :)
TSDB используются в современных системах мониторинга ( prometheus, influxdb stack и т.д. ). Недавно в zabbix добавили поддержку, но пока не смотрел
Как timescaledb чувствует себя поверх универсальной СУБД не знаю. Но из плюсов можно назвать полноценную репликацию ( у influxdb только в коммерческой версии, причём говорят работает не айс ) и бекапы