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

"Выпуск СУБД TimescaleDB 1.7"	+/–
Сообщение от opennews (??), 18-Апр-20, 10:48
Опубликован   выпуск СУБД TimescaleDB 1.7, предназначенной для хранения и обработки данных в форме временного ряда (срезы значений параметров через заданные промежутки времени, запись образует время и набор соответствующих этому времени значений). Подобная форма хранения оптимальна для таких применений как системы мониторинга, торговые платформы, системы сбора метрик и состояний датчиков. Предоставляются средства для интеграции с проектом Grafana и Prometheus... Подробнее: https://www.opennet.dev/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. Сообщение от Catwoolfii (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. Сообщение от DeadMustdie (??), 19-Апр-20, 20:47	+/–
> кликхаус Таки либо облако, либо ковыряй сам - поддержки не будет даже за деньги.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

49. Сообщение от DeadMustdie (??), 19-Апр-20, 20:50	+/–
> являются ли сопли и клей поверх postgres В каких-то пределах являются. Разумной альтернативой является разве что Informix с его Time Series, концептуально история аналогично. И да, там только за деньги (не очень большие, правда), и ни разу не open source.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #60

50. Сообщение от DeadMustdie (??), 19-Апр-20, 20:52	+/–
> А чем сабж лучше чем DB2? Не совсем сравнимо. Скорее аналог - Informix Time Series, который проработан существенно лучше, но реализует ту же самую идею.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

51. Сообщение от DeadMustdie (??), 19-Апр-20, 20:54	+/–
> тем что тормознутее, ибо pq не колоночная DB. В subj для хранения временных рядов используются специфические структуры данных. Построчное хранение идентификационной информации по рядам не обязательно плохо влияет на производительность, там данных обычно на 3 копейки, особенно на фоне самих рядов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

52. Сообщение от DeadMustdie (??), 19-Апр-20, 20:55	+/–
> тем что тормознутее, ибо pq не колоночная DB. А вот не факт. Приложения разные бывают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

53. Сообщение от DeadMustdie (??), 19-Апр-20, 20:56	+2 +/–
> Если timeseries, то victoriametrics. Если OLAP, то ClickHouse. Расскажите об этом коллегам из Teradata, Microsoft, IBM, Oracle, SAP и Vertica.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

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

55. Сообщение от DeadMustdie (??), 19-Апр-20, 21:02	+/–
> вопрос только в том выдержит она скажем записи данных с одронного коллайдера или других физических экспериментов с миллионами мелких датчиков?)) Интересный вопрос. Когда я последний раз интересовался (довольно давно), самая здоровая единая реляционная БД в мире как раз обслуживала вроде бы ЦЕРН-овский, если не путаю, ускоритель. И сделана она была на DB2 в горизонтально масштабируемой конфигурации (Database Partitioning Feature = DPF, если быть точным). Но воды с тех пор немало утекло, так что рекордсмен наверное поменялся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #62

56. Сообщение от DeadMustdie (??), 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. Сообщение от DeadMustdie (??), 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. Сообщение от DeadMustdie (??), 20-Апр-20, 11:31	+1 +/–
> Наверное путаете, в цене судя по докаладам оракл во все поля за редким исключением. Не путаю, у Оракла встроенный "шардинг" лишь относительно недавно появился, и до сих пор довольно кривенький.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

65. Сообщение от Аноним (65), 20-Апр-20, 13:17	+/–
> одобрят Вы им не говорите, что данные менять нельзя, а то не одобрят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

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

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

68. Сообщение от qsdg (ok), 21-Апр-20, 17:45	+/–
> А если мне нужно не для метрик, а для исторических данных на > десятки терабайт? В подходящей базе десятки терабайт превращаются в просто терабайты, а если повезёт, то и в гигабайты, за счёт data-aware компрессии. Для olap -- кликхаус. Для метрик -- victoriametrics. У таймскейла вообще никакая компрессия, всё время тормозит из-за IO.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

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

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