Опубликован выпуск СУБД TimescaleDB 1.7, предназначенной для хранения и обработки данных в форме временного ряда (срезы значений параметров через заданные промежутки времени, запись образует время и набор соответствующих этому времени значений). Подобная форма хранения оптимальна для таких применений как системы мониторинга, торговые платформы, системы сбора метрик и состояний датчиков. Предоставляются средства для интеграции с проектом Grafana и Prometheus...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=52759
Годнота
и чем же оно годнота? тем что поверх pgsql - а на кой ляд во временных рядах возможность изменения данных.
Подскажи тогда годноту, если ты такой эксперт
Victoriametrics.
А если мне нужно не для метрик, а для исторических данных на десятки терабайт?
> А если мне нужно не для метрик, а для исторических данных на
> десятки терабайт?а sql им зачем?
Для запросов
а теперь расскажи нам, как выглядит запрос к бд с метрикой, снимающеся раз в, допустим, пять минут, чтобы нарисовать график ее изменения за год.Если ты хотя бы немножко умеешь кодить - ты поймешь, почему sql для этой цели абсолютно неудачный выбор. Если еще и математику в школе учил - вспомни что такое "скрытый экстремум", выкинь мысленно уже написанный тобой гуанокод и начинай заново.
Если в школе ты учил только основы религиозных культур, а кодить умеешь только в .md, то можешь не морщить лобик.
Скрытый экстремум сам придумал?
ну просто намек, что очевидный алгоритм "в лоб" будет неверным - "съест" резкие отклонения, которые мы как раз, наверное, хотим увидеть, можно неточными.На мой взгляд правильного ответа в рамках sql и единственной таблицы timestamp,value - не существует в принципе.
> а sql им зачем?Чтобы самим не писать вручную алгоритмы доступа к данным, включая миллионную в мире кривую реализацию Hash Merge.
А оный Merge возникнет рано или поздно при сопоставении разных групп наблюдений.
> А оный Merge возникнет рано или поздно при сопоставении разных групп наблюдений.хренассе... а точно-точно timescale это то, что подходит для подобных данных?
(просто вроде принято считать, что если в sql запросе возникает hash merge, это чаще всего признак неправильной структуры базы, и даже "прямая" реализация тут плохо помогает - все равно это худший вариант)
> хренассе... а точно-точно timescale это то, что подходит для подобных данных?Агрегировать и фильтровать умеет, результат в виде таблицы выдаёт. Дальше вопрос уже к постгресу.
> (просто вроде принято считать, что если в sql запросе возникает hash merge,
> это чаще всего признак неправильной структуры базы, и даже "прямая" реализация
> тут плохо помогает - все равно это худший вариант)Это верно лишь для трансакционных систем. Аналитические хранилища строят по другим принципам, и там сканирование таблиц (в поколоночном варианте - столбцов) скорее правило, чем исключение.
“ и чем же оно годнота? тем что поверх pgsql - а на кой ляд во временных рядах возможность изменения данных.“ ?Ви таки собрались изменять «исторические данные» задним числом ?
Не вопрос. Подскажи что-нибудь для хранения исторических данных и разнообразных запросов к ним без возможности изменения.
Victoriametrics же выше сказали. Отключай автоматический ретеншн, и будут твои данные "историческими".
А друшой момент: бывают данные не срвсем исторические, но скорость изменения которых падает пропорционально их возрасту.
Не мы такие, жись такая.Вот идет поток, скажем, от GPS-трекера. И все бы хорошо, но время от времени этот чертов трекер начинает досылать данные, накопленные в своем черном ящике,
а где тут "изменение данных" ? Просто добавление не синхронное же.
> А если мне нужно не для метрик, а для исторических данных на
> десятки терабайт?В подходящей базе десятки терабайт превращаются в просто терабайты, а если повезёт, то и в гигабайты, за счёт data-aware компрессии.
Для olap -- кликхаус. Для метрик -- victoriametrics.
У таймскейла вообще никакая компрессия, всё время тормозит из-за IO.
> Подскажи тогда годноту, если ты такой эксперткликхаус
> кликхаусТаки либо облако, либо ковыряй сам - поддержки не будет даже за деньги.
Скажите мне непросвещённому, чем оно лучше того же MySQL?
mysql не поддерживает time series?
А разве на СУБД без подобных расширений нельзя хранить выборки через заданные промежутки времени? А то разработчики всяких там АИИС КУЭ и не знают.
Можно, но mysql вряд ли сможет нормально работать с таблицей с триллионами записей на одном сервере, в то время как для специализированных БД для временных рядов - это детская нагрузка. https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/Case...
осталось понять, являются ли сопли и клей поверх postgres "специализированной бд для временных рядов", и насколько быстро тот постгрез лопнет.
> являются ли сопли и клей поверх postgresВ каких-то пределах являются.
Разумной альтернативой является разве что Informix с его Time Series, концептуально история аналогично.
И да, там только за деньги (не очень большие, правда), и ни разу не open source.
это если хочется именно sql.
Тем же, чем и блокчейн[ т.е ничем, но хомяки одобрят ]
> одобрятВы им не говорите, что данные менять нельзя, а то не одобрят.
чем оно лучше кликхаус?
чем анонимчик отличается от дегенерата?
Ничем, duh...
Аргументы пожалуйста
тем что тормознутее, ибо pq не колоночная DB.
> тем что тормознутее, ибо pq не колоночная DB.В subj для хранения временных рядов используются специфические структуры данных.
Построчное хранение идентификационной информации по рядам не обязательно плохо влияет на производительность, там данных обычно на 3 копейки, особенно на фоне самих рядов.
А чем сабж лучше чем DB2?
> А чем сабж лучше чем DB2?Не совсем сравнимо. Скорее аналог - Informix Time Series, который проработан существенно лучше, но реализует ту же самую идею.
В clickhouse нет транзакций например.
то плюс для таймсериес
> тем что тормознутее, ибо pq не колоночная DB.А вот не факт.
Приложения разные бывают.
отсутствие транзакций никогда не является плюсом, это всегда компромис во имя чего-то другого
Интересно, насколько хорошо timescaledb работает с триллионами строк? Victoriametrics нормально работает, судя по https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/Case...
Представьте себе: хранить нужно не только метртки.
Если timeseries, то victoriametrics. Если OLAP, то ClickHouse.
> Если timeseries, то victoriametrics. Если OLAP, то ClickHouse.Расскажите об этом коллегам из Teradata, Microsoft, IBM, Oracle, SAP и Vertica.
В целом - жизнь немножко шире любых представлений о ней ;)
вот она база данных для научных вычислений и экспериментов. вопрос только в том выдержит она скажем записи данных с одронного коллайдера или других физических экспериментов с миллионами мелких датчиков?))
> вопрос только в том выдержит она скажем записи данных с одронного коллайдера или других физических экспериментов с миллионами мелких датчиков?))Интересный вопрос.
Когда я последний раз интересовался (довольно давно), самая здоровая единая реляционная БД в мире как раз обслуживала вроде бы ЦЕРН-овский, если не путаю, ускоритель. И сделана она была на DB2 в горизонтально масштабируемой конфигурации (Database Partitioning Feature = DPF, если быть точным).Но воды с тех пор немало утекло, так что рекордсмен наверное поменялся.
Наверное путаете, в цене судя по докаладам оракл во все поля за редким исключением.
> Наверное путаете, в цене судя по докаладам оракл во все поля за редким исключением.Не путаю, у Оракла встроенный "шардинг" лишь относительно недавно появился, и до сих пор довольно кривенький.
В коллайдере у них там несколько уровней предобработки данных перед записью, на каждом уровне по 99% данных выбрасываются за ненужностью. И только потом записываются. Иначе в мире дисков не хватит чтобы сырые данные с одного эксперимента записать.