The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

"Выпуск СУБД TimescaleDB 1.7"  +/
Сообщение от opennews (??), 18-Апр-20, 10:48 
Опубликован   выпуск СУБД TimescaleDB 1.7, предназначенной для хранения и обработки данных в форме временного ряда (срезы значений параметров через заданные промежутки времени, запись образует время и набор соответствующих этому времени значений). Подобная форма хранения оптимальна для таких применений как системы мониторинга, торговые платформы, системы сбора метрик и состояний датчиков. Предоставляются средства для интеграции с проектом Grafana и Prometheus...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52759

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 18-Апр-20, 10:48   –2 +/
Годнота
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #10

3. Сообщение от Аноним (3), 18-Апр-20, 10:57   –8 +/
Скажите мне непросвещённому, чем оно лучше того же MySQL?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #15, #30

10. Сообщение от анонимчик (?), 18-Апр-20, 12:38   +1 +/
и чем же оно годнота? тем что поверх pgsql - а на кой ляд во временных рядах возможность изменения данных.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #16

11. Сообщение от анонимчик (?), 18-Апр-20, 12:39   –5 +/
чем оно лучше кликхаус?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #20, #22, #24, #32

15. Сообщение от Catwoolfiiemail (ok), 18-Апр-20, 13:24   +2 +/
mysql не поддерживает time series?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #34

16. Сообщение от Аноним (1), 18-Апр-20, 13:44   –2 +/
Подскажи тогда годноту, если ты такой эксперт
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #17, #28

17. Сообщение от Аноним (17), 18-Апр-20, 14:01   +2 +/
Victoriametrics.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #23

20. Сообщение от Аноним (-), 18-Апр-20, 15:19   +7 +/
чем анонимчик отличается от дегенерата?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #21

21. Сообщение от КО (?), 18-Апр-20, 16:10   +/
Ничем, duh...
Аргументы пожалуйста
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

22. Сообщение от Аноним (22), 18-Апр-20, 16:14   +2 +/
тем что тормознутее, ибо pq не колоночная DB.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #51

23. Сообщение от Аноним (1), 18-Апр-20, 16:24   +/
А если мне нужно не для метрик, а для исторических данных на десятки терабайт?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #27, #29, #68

24. Сообщение от Аноним (24), 18-Апр-20, 18:08   +/
А чем сабж лучше чем DB2?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #50

27. Сообщение от нах. (?), 18-Апр-20, 18:22   +/
> А если мне нужно не для метрик, а для исторических данных на
> десятки терабайт?

а sql им зачем?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #31, #56

28. Сообщение от анонимчик (?), 18-Апр-20, 19:15   +1 +/
> Подскажи тогда годноту, если ты такой эксперт

кликхаус

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #48

29. Сообщение от Lex (??), 18-Апр-20, 20:25   +2 +/
“ и чем же оно годнота? тем что поверх pgsql - а на кой ляд во временных рядах возможность изменения данных.“ ?

Ви таки собрались изменять «исторические данные» задним числом ?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #37, #38, #42

30. Сообщение от Lex (??), 18-Апр-20, 20:27   –3 +/
Тем же, чем и блокчейн[ т.е ничем, но хомяки одобрят ]
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #65

31. Сообщение от Аноним (31), 18-Апр-20, 20:40   +/
Для запросов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #41

32. Сообщение от Аноним (31), 18-Апр-20, 20:43   +/
В clickhouse нет транзакций например.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #35

33. Сообщение от Аноним (36), 18-Апр-20, 21:35   +/
Интересно, насколько хорошо timescaledb работает с триллионами строк? Victoriametrics нормально работает, судя по https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/Case...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #39

34. Сообщение от Аноним (34), 18-Апр-20, 21:38   –1 +/
А разве на СУБД без подобных расширений нельзя хранить выборки через заданные промежутки времени? А то разработчики всяких там АИИС КУЭ и не знают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #36

35. Сообщение от анонимчик (?), 18-Апр-20, 21:41   +1 +/
то плюс для таймсериес
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #52, #63

36. Сообщение от Аноним (36), 19-Апр-20, 02:23   +2 +/
Можно, но mysql вряд ли сможет нормально работать с таблицей с триллионами записей на одном сервере, в то время как для специализированных БД для временных рядов - это детская нагрузка. https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/Case...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #40

37. Сообщение от funny.falcon (?), 19-Апр-20, 09:24   +/
Не вопрос. Подскажи что-нибудь для хранения исторических данных и разнообразных запросов к ним без возможности изменения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #66

38. Сообщение от funny.falcon (?), 19-Апр-20, 09:26   +/
А друшой момент: бывают данные не срвсем исторические, но скорость изменения которых падает пропорционально их возрасту.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

39. Сообщение от funny.falcon (?), 19-Апр-20, 09:27   –1 +/
Представьте себе: хранить нужно не только метртки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #44

40. Сообщение от нах. (?), 19-Апр-20, 09:52   –1 +/
осталось понять, являются ли сопли и клей поверх postgres "специализированной бд для временных рядов", и насколько быстро тот постгрез лопнет.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #49

41. Сообщение от нах. (?), 19-Апр-20, 10:00   –3 +/
а теперь расскажи нам, как выглядит запрос к бд с метрикой, снимающеся раз в, допустим, пять минут, чтобы нарисовать график ее изменения за год.

Если ты хотя бы немножко умеешь кодить - ты поймешь, почему sql для этой цели абсолютно неудачный выбор. Если еще и математику в школе учил - вспомни что такое "скрытый экстремум", выкинь мысленно уже написанный тобой гуанокод и начинай заново.

Если в школе ты учил только основы религиозных культур, а кодить умеешь только в .md, то можешь не морщить лобик.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #46

42. Сообщение от Алексей Морозов (ok), 19-Апр-20, 16:36   +4 +/
Не мы такие, жись такая.

Вот идет поток, скажем, от GPS-трекера. И все бы хорошо, но время от времени этот чертов трекер начинает досылать данные, накопленные в своем черном ящике,

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #59

43. Сообщение от анонимуслинус (?), 19-Апр-20, 16:44   +/
вот она база данных для научных вычислений и экспериментов. вопрос только в том выдержит она скажем записи данных с одронного коллайдера или других физических экспериментов с миллионами мелких датчиков?))
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #55, #67

44. Сообщение от anonymous (??), 19-Апр-20, 18:21   –1 +/
Если timeseries, то victoriametrics. Если OLAP, то ClickHouse.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #53, #54

46. Сообщение от Аноним (46), 19-Апр-20, 19:51   +3 +/
Скрытый экстремум сам придумал?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #57

48. Сообщение от DeadMustdieemail (??), 19-Апр-20, 20:47   +/
> кликхаус

Таки либо облако, либо ковыряй сам - поддержки не будет даже за деньги.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

49. Сообщение от DeadMustdieemail (??), 19-Апр-20, 20:50   +/
> являются ли сопли и клей поверх postgres

В каких-то пределах являются.
Разумной альтернативой является разве что Informix с его Time Series, концептуально история аналогично.
И да, там только за деньги (не очень большие, правда), и ни разу не open source.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #60

50. Сообщение от DeadMustdieemail (??), 19-Апр-20, 20:52   +/
> А чем сабж лучше чем DB2?

Не совсем сравнимо. Скорее аналог - Informix Time Series, который проработан существенно лучше, но реализует ту же самую идею.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

51. Сообщение от DeadMustdieemail (??), 19-Апр-20, 20:54   +/
> тем что тормознутее, ибо pq не колоночная DB.

В subj для хранения временных рядов используются специфические структуры данных.
Построчное хранение идентификационной информации по рядам не обязательно плохо влияет на производительность, там данных обычно на 3 копейки, особенно на фоне самих рядов.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

52. Сообщение от DeadMustdieemail (??), 19-Апр-20, 20:55   +/
> тем что тормознутее, ибо pq не колоночная DB.

А вот не факт.
Приложения разные бывают.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

53. Сообщение от DeadMustdieemail (??), 19-Апр-20, 20:56   +2 +/
> Если timeseries, то victoriametrics. Если OLAP, то ClickHouse.

Расскажите об этом коллегам из Teradata, Microsoft, IBM, Oracle, SAP и Vertica.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

54. Сообщение от DeadMustdieemail (??), 19-Апр-20, 20:57   +/
В целом - жизнь немножко шире любых представлений о ней ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

55. Сообщение от DeadMustdieemail (??), 19-Апр-20, 21:02   +/
> вопрос только в том выдержит она скажем записи данных с одронного коллайдера или других физических экспериментов с миллионами мелких датчиков?))

Интересный вопрос.
Когда я последний раз интересовался (довольно давно), самая здоровая единая реляционная БД в мире как раз обслуживала вроде бы ЦЕРН-овский, если не путаю, ускоритель. И сделана она была на DB2 в горизонтально масштабируемой конфигурации (Database Partitioning Feature = DPF, если быть точным).

Но воды с тех пор немало утекло, так что рекордсмен наверное поменялся.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #62

56. Сообщение от DeadMustdieemail (??), 19-Апр-20, 21:04   +1 +/
> а sql им зачем?

Чтобы самим не писать вручную алгоритмы доступа к данным, включая миллионную в мире кривую реализацию Hash Merge.

А оный Merge возникнет рано или поздно при сопоставении разных групп наблюдений.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #58

57. Сообщение от нах. (?), 19-Апр-20, 22:41   –2 +/
ну просто намек, что очевидный алгоритм "в лоб" будет неверным - "съест" резкие отклонения, которые мы как раз, наверное, хотим увидеть, можно неточными.

На мой взгляд правильного ответа в рамках sql и единственной таблицы timestamp,value - не существует в принципе.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

58. Сообщение от нах. (?), 19-Апр-20, 22:54   +/
> А оный Merge возникнет рано или поздно при сопоставении разных групп наблюдений.

хренассе... а точно-точно timescale это то, что подходит для подобных данных?

(просто вроде принято считать, что если в sql запросе возникает hash merge, это чаще всего признак неправильной структуры базы, и даже "прямая" реализация тут плохо помогает - все равно это худший вариант)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #61

59. Сообщение от нах. (?), 19-Апр-20, 22:56   –1 +/
а где тут "изменение данных" ? Просто добавление не синхронное же.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

60. Сообщение от нах. (?), 19-Апр-20, 22:58   +/
это если хочется именно sql.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

61. Сообщение от DeadMustdieemail (??), 19-Апр-20, 23:35   +/
> хренассе... а точно-точно timescale это то, что подходит для подобных данных?

Агрегировать и фильтровать умеет, результат в виде таблицы выдаёт. Дальше вопрос уже к постгресу.

> (просто вроде принято считать, что если в sql запросе возникает hash merge,
> это чаще всего признак неправильной структуры базы, и даже "прямая" реализация
> тут плохо помогает - все равно это худший вариант)

Это верно лишь для трансакционных систем. Аналитические хранилища строят по другим принципам, и там сканирование таблиц (в поколоночном варианте - столбцов) скорее правило, чем исключение.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

62. Сообщение от Анончик (?), 20-Апр-20, 06:01   +/
Наверное путаете, в цене судя по докаладам оракл во все поля за редким исключением.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #64

63. Сообщение от Аноним (-), 20-Апр-20, 10:56   +/
отсутствие транзакций никогда не является плюсом, это всегда компромис во имя чего-то другого
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

64. Сообщение от DeadMustdieemail (??), 20-Апр-20, 11:31   +1 +/
> Наверное путаете, в цене судя по докаладам оракл во все поля за редким исключением.

Не путаю, у Оракла встроенный "шардинг" лишь относительно недавно появился, и до сих пор довольно кривенький.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

65. Сообщение от Аноним (65), 20-Апр-20, 13:17   +/
> одобрят

Вы им не говорите, что данные менять нельзя, а то не одобрят.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

66. Сообщение от qsdgemail (ok), 21-Апр-20, 17:35   +/
Victoriametrics же выше сказали. Отключай автоматический ретеншн, и будут твои данные "историческими".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

67. Сообщение от qsdgemail (ok), 21-Апр-20, 17:39   +/
В коллайдере у них там несколько уровней предобработки данных перед записью, на каждом уровне по 99% данных выбрасываются за ненужностью. И только потом записываются. Иначе в мире дисков не хватит чтобы сырые данные с одного эксперимента записать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

68. Сообщение от qsdgemail (ok), 21-Апр-20, 17:45   +/
> А если мне нужно не для метрик, а для исторических данных на
> десятки терабайт?

В подходящей базе десятки терабайт превращаются в просто терабайты, а если повезёт, то и в гигабайты, за счёт data-aware компрессии.

Для olap -- кликхаус. Для метрик -- victoriametrics.

У таймскейла вообще никакая компрессия, всё время тормозит из-за IO.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23


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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру