Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Выпуск СУБД TimescaleDB 2.0"	+/–
Сообщение от opennews (??), 24-Дек-20, 10:51
Опубликован  выпуск СУБД TimescaleDB 2.0, предназначенной для хранения и обработки данных в форме временного ряда (срезы значений параметров через заданные промежутки времени, запись образует время и набор соответствующих этому времени значений). Подобная форма хранения оптимальна для таких применений как системы мониторинга, торговые платформы, системы сбора метрик и состояний датчиков. Предоставляются средства для интеграции с проектом Grafana и Prometheus. Проект TimescaleDB реализован в виде расширения к PostgreSQL и распространяется под лицензией Apache 2.0... Подробнее: https://www.opennet.me/opennews/art.shtml?num=54308
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 24-Дек-20, 10:51	–10 +/–
Если бы как вариант движка для MySQL запилили - можно было бы щупать. А так - ну, есть...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #11

2. Сообщение от 1 (??), 24-Дек-20, 10:52	+1 +/–
Нда ... Заплати и сделают ... Хоть к sqlite
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

3. Сообщение от Omnonm (?), 24-Дек-20, 10:55	–1 +/–
Встречал только однажды как бд под немаленький заббикс, на замену штатному постгресу когда перевалило за полтерабайта. Где ещё оно имеет плюсы в использовании?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8, #10, #13, #15

4. Сообщение от lockywolf (ok), 24-Дек-20, 11:06	–1 +/–
Чем оно лучше rrdtool?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #7, #9, #24

5. Сообщение от 1 (??), 24-Дек-20, 11:09	+/–
наверное тем, что хранит все данные.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #6

6. Сообщение от lockywolf (ok), 24-Дек-20, 11:15	–1 +/–
> наверное тем, что хранит все данные. можно по-длиннее rrdtool
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

7. Сообщение от Богдан Помазан (?), 24-Дек-20, 11:54	+1 +/–
Как вариант БД для логирования и трекинга транспорта можно использовать
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

8. Сообщение от Вшталик (?), 24-Дек-20, 11:55	+/–
Котировки тикетов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

9. Сообщение от Аноним (11), 24-Дек-20, 11:56	+3 +/–
>  Чем оно лучше rrdtool? Тем, что не нужно учить очередной DSL. Плюс нет нужды в написании или поиске отдельного драйвера для своего ЯП - любую нормальную ORM можно использовать для запросов к Time-series данным, что позволяет вообще писать на своём бекенд языке (речь не о JavaScript). Другие преимущества в этой новости перечислены, читайте внимательнее)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

10. Сообщение от Аноним (11), 24-Дек-20, 11:58	+1 +/–
> Где ещё оно имеет плюсы в использовании? Так любой кейс, где нужны TimeSeries - данные с датчиков (очень много предметных областей), метрики (same).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

11. Сообщение от Аноним (11), 24-Дек-20, 12:02	+6 +/–
> MySQL > Time Series Так TimeSeries это про производительность, где очень много записей на единицу времени. Вы бы ещё спойлер для осла попросили бы - за деньги Вам сделают, но зачем, если для каждой задачи свой инструмент и нужно корректно подбирать решение под проблему.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #12

12. Сообщение от mos87 (ok), 24-Дек-20, 12:26	+1 +/–
товарищ не довёл до логического гм конца - нужно не для MySQL, а на SQL Server Бызнес фор Энтерпрайзыс Идишн Экзекьютив Инсайтс фор БигДата только тогда труЪ
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

13. Сообщение от Виталий (??), 24-Дек-20, 12:41	+4 +/–
Любые данные где есть время и сами данные не должны меняться. аудит ( когда кто что сделал) финансовые операции (когда кто  что кому перевел) IOT (когда какой датчик что показал) Везде где таких данных ожидается много timescaledb сильно улучшает работу PostgeSQL и облегчает DBA работу. На небольших объемах (10 000 000 000) - очень удобно, даже на одном узле справляется, если нужно больше - то есть кластеризация (но ее сам не пробовал, она раньше платной была, да и у меня кейс простой, весь трафик муниципального транспорта одного региона хранить 3 месяца).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

14. Сообщение от Аноним12345 (?), 24-Дек-20, 13:11	+1 +/–
Базы данных становятся все более мощными и более безумными
Ответить | Правка | Наверх | Cообщить модератору

15. Сообщение от valyala (?), 24-Дек-20, 13:14	+1 +/–
Главный плюс TimescaleDB - она работает поверх Postgresql. Это значит, что пользователю доступны все плюшки postgresql при работе с TimescaleDB. Дальше идут одни минусы: - жрет disk IO быстро гробит SSD диски - тормозит на HDD - плохо сжимает данные, поэтому требует много дискового пространства по сравнению с другими TSDB - тормозит на больших объемах данных Поэтому лучше использовать VictoriaMetrics. https://valyala.medium.com/promscale-vs-victoriametrics-reso...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #16, #17

16. Сообщение от PetrG (ok), 24-Дек-20, 14:05	+/–
Впечатляет, но эти тесты показывают как оно работает из коробки под ваши задачи (например ACID и запросы вас не интересуют похоже). Я бы у Promscale поспрашивал что они по этому поводу думают - мне кажется что это можно настроить. Скорее всего всё равно медленнее будет (потому что TS сжимает с задержкой) но не настолько.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

17. Сообщение от Виталий (??), 24-Дек-20, 14:06	+3 +/–
> жрет disk IO быстро гробит SSD диски Откуда такая информация?! >- тормозит на HDD Вообще-то оно ускоряет вставку в тот же postgresql (т.е если вы пишете в postgresql без timescaledb и с timescaledb - у вас результаты будут лучше с timescaledb) >- плохо сжимает данные, поэтому требует много дискового пространства по сравнению с другими TSDB Опять странная информация, откуда она? На голом postgesql у меня набор данных занимал 307GB, после сжатия стало 41GB - это очень "не плохо". > тормозит на больших объемах данных Он предназначен для работы в PostgreSQL - на объемах для postgresql - вообще не тормозит, на оборот, ускоряет работу PostgreSQL. >Поэтому лучше использовать VictoriaMetrics Чем лучше? Как там у VictoriaMetrics c Geospacial данными или хотя бы транзакциями? PS Нету лучшей и худшей БД, нужно всегда смотреть что лучше подходит под конкретную задачу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #22

18. Сообщение от Аноним (18), 24-Дек-20, 14:06	–1 +/–
Не нужно, есть influxdb и clickhouse.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #21, #23, #26, #27

21. Сообщение от Аноним (11), 24-Дек-20, 15:34	+/–
Не в каждой компании есть время и ресурсы, чтобы учить дополнительные DSL и развёртывать дополнительные сервисы с накручиванием дополниьтельной интеграции. TimescaleDB хорош как раз для случаев малых и средних компаний - не нужно искать/писать дополнительный драйвер (все полноценные ORM дружат с TimeScaleDB), не надо тратить время на изучение как с этим общаться, как развёртывать и как поддерживать ещё один сервис докучи - тот же Postgres, только немного по-другому обрабатывающий определённую табличку. Ничего от него не ломается, все джоины и прочие запросы могут выполняться между time-series и обычными данными. А так, для крупных предприятий с многомиллионными бюджетами на человекочасы, лицензии и железо - да, InfluxDB и ClickHouse.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

22. Сообщение от valyala (?), 24-Дек-20, 16:54	–3 +/–
>> жрет disk IO быстро гробит SSD диски > Откуда такая информация?! Из статьи, на которую приведена ссылка в предыдущем комментарии. >>- тормозит на HDD > Вообще-то оно ускоряет вставку в тот же postgresql > (т.е если вы пишете в postgresql без timescaledb и с timescaledb - > у вас результаты будут лучше с timescaledb) TimescaleDB позиционируется как база данных для временных рядов (TSDB). Поэтому логично ее сравнивать с другими TSDB, а не сравнивать с Postgresql. Так вот, TimescaleDB намного хуже показывает себя по сравнению с другими специализированными TSDB вроде VictoriaMetrics. См. графики использования disk IO bandwidth и disk IOPS в следующих статьях: * https://valyala.medium.com/promscale-vs-victoriametrics-reso... * https://valyala.medium.com/measuring-vertical-scalability-fo... >>- плохо сжимает данные, поэтому требует много дискового пространства по сравнению с другими TSDB > Опять странная информация, откуда она? > На голом postgesql у меня набор данных занимал 307GB, после сжатия стало > 41GB - это очень "не плохо". Все данные в упомянутых выше статьях. >>Поэтому лучше использовать VictoriaMetrics > Чем лучше? Как там у VictoriaMetrics c Geospacial данными или хотя бы > транзакциями? Geo-spatial функции пока планируются. Транзакции для типичных задач, решаемых с помощью time series БД, не нужны. Типичные требования под задачи для TSDB: * записывать постоянный поток данных со скоростями в миллионы строк в секунду * быстро выполнять запросы по определенным рядам на определенных интервалах времени для построения всяких дашбордов в Grafana * быстро выполнять запросы по недавно вставленным данным для всяких алертов * быстро удалять устаревшие данные TimescaleDB не подходит ни под одно из этих требований. TimescaleDB подходит под часть из этих требований с большой натяжкой. VictoriaMetrics удовлетворяет всем этим требованиям. Она спокойно справляется с потоком данных в миллион метрик в секунду и потоком запросов в 100 запросов в секунду на одном компе. При этом в БД хранится 10 триллионов (aka 10000 миллиардов) строк. См. https://victoriametrics.github.io/CaseStudies.html
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #25, #28

23. Сообщение от Аноним (23), 24-Дек-20, 17:02	+/–
Не нужно, есть TimescaleDB.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

24. Сообщение от Аноним (24), 25-Дек-20, 08:40	–2 +/–
Один из явных минусов rrdtool это GPLv2. И не надо ляля про локалхост-поделки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

25. Сообщение от Аноним (11), 25-Дек-20, 10:00	+/–
> Поэтому лучше использовать VictoriaMetrics Насчёт плюсов и минусов Вы правы (ну, почти). Только насчёт "лучше использовать мою разработку" - спорное утверждение. TimesclaeDB для малых и средних компаний обойдётся дешевле в поддержке (человекочасы как минимум) и развёртывании, аиспользовать VictoriaMetrics - оверинжиниринг, развёртывание ради развёртывания (или закладывание на годы/десятилетия, на случай роста). Не у всех есть DBA, но у всех есть бэкендер и фронтендер или хотя бы один фуллстек, а учить и прикручивать интеграции фуллстеку - ну такое, у заказчика всегда есть задачи посрочнее, чем трата времени на ещё одну технологию, у которой своя экасистема и свои потребности в изучении, развёртывании и обслуживании, бизнесу далеко не всегда такое объяснишь с первого раза. А если у компании есть объёмы больше терабайта, то да - Ваш продукт именно в этом сценарии лучше. То есть у компании при таких объёмах и доступных ресурсов должно быть больше (а не полтора разраба, как это часто бывает). > быстро выполнять запросы по недавно вставленным данным для всяких алертов В приведённых Вами статьях не использовались Continuous Aggregates, что показывает, что вы даже не разбирвались в тестируемом продукте, ибо это упоминается на главной же (даже не документации) странице TimescleDB. То есть Вы сделали тест ради тестов, зная как пользоваться только своей разработкой, не удосужившись даже открыть документацию конкурента. Любой, кто хотя бы это сделает (в отличие от Вас) поймёт, что тесты сделаны чисто в маркетинговых целях. При этом Вы называете себя Core Developer, а не PR-менеджером.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #29

26. Сообщение от Аноним12345 (?), 25-Дек-20, 15:40	–2 +/–
У меня тоже первая мысль была - это же про кликхаус ! Теплый и ламповый ...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

27. Сообщение от йо (?), 25-Дек-20, 18:40	+1 +/–
Clickhouse не конкурент, не самое лучшее решение для timeseries (хотя идеальное для эвентов и логов). Influx конкурент, да, но, во-первых, не open source, поэтому оффтопик на этом сайте, во-вторых жрет памяти в 10 раз больше, и диска в 2 раза больше, в третьих -- язык запросов не PromQL с расширениями, как у Victoria metrics.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

28. Сообщение от Yilativs (?), 25-Дек-20, 20:30	–1 +/–
>>> жрет disk IO быстро гробит SSD диски >> Откуда такая информация?! >Из статьи, на которую приведена ссылка в предыдущем комментарии. Там нет никакой информации о том, как был настроен postgresql - Вы верите статье на статьям производителя о конкурентах? А сами не пробовали тест воспроизвести? Может они как timescaledb - еще и тесты в github выкладывают, что бы можно было на своем железе потестить? >Geo-spatial функции пока планируются. Тогда в огромном классе задач связаных с IoT  и позиционированием они бесполезны.   >Транзакции для типичных задач, решаемых с помощью time series БД, не нужны Учет финансовых операций - типичная задача для time series баз данных и они часто ходят парой, т.е с одного счета списали, на другой записали. Расскажите, как это сделать бес транзакций? >Типичные требования под задачи для TSDB: > записывать постоянный поток данных со скоростями в миллионы строк в секунду Сотни или миллиарды уже не TS? Опеределение TS - вообще не связано с объемом. > быстро выполнять запросы по определенным рядам на определенных интервалах времени для построения всяких дашбордов в Grafana TS вообще ничего не знают про Grafana- картинки, это частный случай. TS базы данных - это базы, которые  сохраняют данные в которых присутствует  время, при этом данные не меняются после записи(append only) и добавляются в конец (recent). Классы задач под это: Аудит, мониторинг, финансовые транзакции, geo tracking Меньше верьте рекламным статьям, Сэр )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #30, #34

29. Сообщение от RNZ (ok), 25-Дек-20, 21:25	+1 +/–
"Что-ты несёшь???" Континиус агрегаты - это как раз костыль что-бы компенсировать низкую производительность и в рантайме выполнять приращения. И чисто технически ничего не мешает разработчику victoriametrics запилить такую же функциональность в каком-нибудь из релизов на манер как это сделано для snapshot'ов http://<victoriametrics-addr>:8428/aggregate/create и в data правила агрегации.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #32

30. Сообщение от RNZ (ok), 25-Дек-20, 21:34	+/–
>>Geo-spatial функции пока планируются. >Тогда в огромном классе задач связаных с IoT  и позиционированием они бесполезны. Да ладно? Посчитать на apps религия не позволяет? И в timescaledb geospartial тоже не самостоятельно поддержано, а через postgis.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #31, #33

31. Сообщение от Аноним (11), 28-Дек-20, 10:53	+/–
> И в timescaledb geospartial тоже не самостоятельно поддержано, а через postgis. Вот ведь открытие! Так об этом и речь, что обычными SQL-запросами можно и TimeSeries, и GeoSpatial сохранять/обрабатывать/считывать. И никакого DSL не нужно, никаких сторонних библиотек, никакого допиливания драйвров/коннекторов. То есть Вы даже не спрашиваете, в каких случая и и как будет применяться инструмент, а просто набрасываетесь на аргументы? Просто потому что VictoraMetrics не умеет? Что, у VictoriaMetrics настолько плохо с маркетингом?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #36

32. Сообщение от Аноним (11), 28-Дек-20, 10:55	+/–
Так раз ты PR-щик VictoriaMetrics, скажи менеджерам, чтобы разрабы реализовали. А пока, не надо фичу, которой нет у твоего продукта, называть костылём. Или любые View и Materialized View, хранимые функции и процедуры - костыли? Если так, иди и скажи это миру РСУБД.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #35

33. Сообщение от Аноним (11), 28-Дек-20, 10:59	+/–
1. Вы когда-нибудь бэкенд-разработкой занимались? 2. Вы когда-нибудь высоконагруженный сервис поддерживали? Если ответ на оба вопроса - да, то расскажите, пожалуйста, в каких случаях расчёты TimeSeries и GeoSpatial происходят "на apps"? А то мы, бедненькие бэкендеры, оказывается, не знаем как правильно, следим за потреблением памяти приложения, чтобы оно за гигабайты не сильно выходило, а вон оно как - надо базугнать в приложение и уже там ворочать данными, SQL не нужен, GeoSpatial не нужен, материалиованные представления не нужны, всё надо в памяти при каждом запросе считать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #37

34. Сообщение от Аноним (11), 28-Дек-20, 11:06	+/–
> Меньше верьте рекламным статьям, Сэр ) Так он их и пишет, вот и продвигает свой продукт - он PR-менеджер. А судя по его аргументам, использовать оба продукта под реальной нагрузкой на проде никогда не пробовал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

35. Сообщение от RNZ (ok), 28-Дек-20, 18:41	+/–
Никакого отношения к victoriametrics не имею. Так что мимо. И как не называй, костыль, он от этого костылём не перестаёт быть. И да view и mview это тоже костыли, суть которых компенсировать ограничения RDBMS. А вот ХП - это уже функциональность, суть - возможность реализовать расширенную логику на уровне СУБД. Мир про РСУБД давно понял, потому есть другие DBMS.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

36. Сообщение от RNZ (ok), 28-Дек-20, 18:49	+/–
У кого-то воображение разыгралось. Я не набрасывался на аргументы, а возразил на один единственный. Мне не нужно спрашивать, я знаю в каких случаях нужно применять timeseries и geopartial и где есть профит от pg с расширениями. > Что, у VictoriaMetrics настолько плохо с маркетингом? без понятия
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

37. Сообщение от RNZ (ok), 28-Дек-20, 19:37	+/–
> Если ответ на оба вопроса - да Да. > в каких случаях расчёты TimeSeries и GeoSpatial происходят "на apps"? 80G-100G в сутки с realtime детектированием пересечения геолокаций и 180млн запросов в сутки достаточно для пересмотра методов хранения и оперирования данными, ну и вашей риторики?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #38, #39

38. Сообщение от Аноним (11), 29-Дек-20, 09:26	+/–
Вы не ответили на вопрос - в каких случаях. 1. При запросах 2000 в секунду - как раз в базе и надо выполнять предрасчёты, чтобы не тянуть всё в приложение. 2. При объёмах 80-100 Gb тем более, если Вы действительно всё в память приложения загоняете, то Вам нужно либо архитектуру приложения пересматривать, либо менять профессию. 3. Сходите на Highload++, что ли, чтобы понимать, как и почему делаются такие приложения. Хотя да, у Вас же есть слово "realtime", оно должно пугать неопытных разрабов, аргументище.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #40

39. Сообщение от Аноним (11), 29-Дек-20, 09:30	+/–
А, тогда выступите с докладом на Highload++, там Вы хоть от вопросов не увернётесь, а то здесь ни на один не ответили прямо, только уход.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #41

40. Сообщение от RNZ (ok), 29-Дек-20, 16:41	+/–
А я не стремился приводить все случаи, одного примера достаточно. При минимуме информации делать выводы, утверждать "как...надо" и давать примитивные советы - глупость, уймите её в себе. Ну и между прочим - это не я про "огромный класс задач" распинался. Моё возражение было про то, что и без geospartial-функций на уровне СУБД можно вполне обходиться, быстродействие СУБД может быть более приоритетным, чем наличие в ней вспомогательных функций.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

41. Сообщение от RNZ (ok), 29-Дек-20, 16:45	+/–
Ну во первых выступление мне не нужно (нет такой потребности), во вторых утверждение о том, что на выступлениях не уворачиваются от вопросов - ложно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема