forum.opennet.ru - "Выпуск СУБД TimescaleDB 1.7" (52)

"Выпуск СУБД TimescaleDB 1.7"

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

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

Оглавление

Годнота, Аноним (1), 10:48 , 18-Апр-20, (1) –2

и чем же оно годнота тем что поверх pgsql - а на кой ляд во временных рядах воз, анонимчик (?), 12:38 , 18-Апр-20, (10) +1

Подскажи тогда годноту, если ты такой эксперт, Аноним (1), 13:44 , 18-Апр-20, (16) –2

Victoriametrics , Аноним (17), 14:01 , 18-Апр-20, (17) +2

А если мне нужно не для метрик, а для исторических данных на десятки терабайт , Аноним (1), 16:24 , 18-Апр-20, (23)

а sql им зачем , нах. (?), 18:22 , 18-Апр-20, (27)

Для запросов, Аноним (31), 20:40 , 18-Апр-20, (31)

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

Скрытый экстремум сам придумал , Аноним (46), 19:51 , 19-Апр-20, (46) +3

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

Чтобы самим не писать вручную алгоритмы доступа к данным, включая миллионную в м, DeadMustdie (??), 21:04 , 19-Апр-20, (56) +1

хренассе а точно-точно timescale это то, что подходит для подобных данных пр, нах. (?), 22:54 , 19-Апр-20, (58)

Агрегировать и фильтровать умеет, результат в виде таблицы выдаёт Дальше вопрос, DeadMustdie (??), 23:35 , 19-Апр-20, (61)

8220 и чем же оно годнота тем что поверх pgsql - а на кой ляд во временных р, Lex (??), 20:25 , 18-Апр-20, (29) +2

Не вопрос Подскажи что-нибудь для хранения исторических данных и разнообразных , funny.falcon (?), 09:24 , 19-Апр-20, (37)

Victoriametrics же выше сказали Отключай автоматический ретеншн, и будут твои д, qsdg (ok), 17:35 , 21-Апр-20, (66)

А друшой момент бывают данные не срвсем исторические, но скорость изменения кот, funny.falcon (?), 09:26 , 19-Апр-20, (38)
Не мы такие, жись такая Вот идет поток, скажем, от GPS-трекера И все бы хорошо,, Алексей Морозов (ok), 16:36 , 19-Апр-20, (42) +4

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

В подходящей базе десятки терабайт превращаются в просто терабайты, а если повез, qsdg (ok), 17:45 , 21-Апр-20, (68)

кликхаус, анонимчик (?), 19:15 , 18-Апр-20, (28) +1

Таки либо облако, либо ковыряй сам - поддержки не будет даже за деньги , DeadMustdie (??), 20:47 , 19-Апр-20, (48)

Скажите мне непросвещённому, чем оно лучше того же MySQL , Аноним (3), 10:57 , 18-Апр-20, (3) –8

mysql не поддерживает time series , Catwoolfii (ok), 13:24 , 18-Апр-20, (15) +2

А разве на СУБД без подобных расширений нельзя хранить выборки через заданные пр, Аноним (34), 21:38 , 18-Апр-20, (34) –1

Можно, но mysql вряд ли сможет нормально работать с таблицей с триллионами запис, Аноним (36), 02:23 , 19-Апр-20, (36) +2

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

В каких-то пределах являются Разумной альтернативой является разве что Informix , DeadMustdie (??), 20:50 , 19-Апр-20, (49)

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

Тем же, чем и блокчейн т е ничем, но хомяки одобрят , Lex (??), 20:27 , 18-Апр-20, (30) –3

Вы им не говорите, что данные менять нельзя, а то не одобрят , Аноним (65), 13:17 , 20-Апр-20, (65)

чем оно лучше кликхаус , анонимчик (?), 12:39 , 18-Апр-20, (11) –5

чем анонимчик отличается от дегенерата , Аноним (-), 15:19 , 18-Апр-20, (20) +7

Ничем, duh Аргументы пожалуйста, КО (?), 16:10 , 18-Апр-20, (21)

тем что тормознутее, ибо pq не колоночная DB , Аноним (22), 16:14 , 18-Апр-20, (22) +2

В subj для хранения временных рядов используются специфические структуры данных , DeadMustdie (??), 20:54 , 19-Апр-20, (51)

А чем сабж лучше чем DB2 , Аноним (24), 18:08 , 18-Апр-20, (24)

Не совсем сравнимо Скорее аналог - Informix Time Series, который проработан сущ, DeadMustdie (??), 20:52 , 19-Апр-20, (50)

В clickhouse нет транзакций например , Аноним (31), 20:43 , 18-Апр-20, (32)

то плюс для таймсериес, анонимчик (?), 21:41 , 18-Апр-20, (35) +1

А вот не факт Приложения разные бывают , DeadMustdie (??), 20:55 , 19-Апр-20, (52)
отсутствие транзакций никогда не является плюсом, это всегда компромис во имя че, Аноним (-), 10:56 , 20-Апр-20, (63)

Интересно, насколько хорошо timescaledb работает с триллионами строк Victoriame, Аноним (36), 21:35 , 18-Апр-20, (33)

Представьте себе хранить нужно не только метртки , funny.falcon (?), 09:27 , 19-Апр-20, (39) –1

Если timeseries, то victoriametrics Если OLAP, то ClickHouse , anonymous (??), 18:21 , 19-Апр-20, (44) –1

Расскажите об этом коллегам из Teradata, Microsoft, IBM, Oracle, SAP и Vertica , DeadMustdie (??), 20:56 , 19-Апр-20, (53) +2
В целом - жизнь немножко шире любых представлений о ней , DeadMustdie (??), 20:57 , 19-Апр-20, (54)

вот она база данных для научных вычислений и экспериментов вопрос только в том , анонимуслинус (?), 16:44 , 19-Апр-20, (43)

Интересный вопрос Когда я последний раз интересовался довольно давно , самая зд, DeadMustdie (??), 21:02 , 19-Апр-20, (55)

Наверное путаете, в цене судя по докаладам оракл во все поля за редким исключени, Анончик (?), 06:01 , 20-Апр-20, (62)

Не путаю, у Оракла встроенный шардинг лишь относительно недавно появился, и до, DeadMustdie (??), 11:31 , 20-Апр-20, (64) +1

В коллайдере у них там несколько уровней предобработки данных перед записью, на , qsdg (ok), 17:39 , 21-Апр-20, (67)

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

1. "Выпуск СУБД TimescaleDB 1.7" –2 +/–

Сообщение от Аноним (1), 18-Апр-20, 10:48

Годнота

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

10. "Выпуск СУБД TimescaleDB 1.7" +1 +/–

Сообщение от анонимчик (?), 18-Апр-20, 12:38

и чем же оно годнота? тем что поверх pgsql - а на кой ляд во временных рядах возможность изменения данных.

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

16. "Выпуск СУБД TimescaleDB 1.7" –2 +/–

Сообщение от Аноним (1), 18-Апр-20, 13:44

Подскажи тогда годноту, если ты такой эксперт

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

17. "Выпуск СУБД TimescaleDB 1.7" +2 +/–

Сообщение от Аноним (17), 18-Апр-20, 14:01

Victoriametrics.

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

23. "Выпуск СУБД TimescaleDB 1.7" +/–

Сообщение от Аноним (1), 18-Апр-20, 16:24

А если мне нужно не для метрик, а для исторических данных на десятки терабайт?

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

27. "Выпуск СУБД TimescaleDB 1.7" +/–

Сообщение от нах. (?), 18-Апр-20, 18:22

> А если мне нужно не для метрик, а для исторических данных на
> десятки терабайт?
а sql им зачем?

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

31. "Выпуск СУБД TimescaleDB 1.7" +/–

Сообщение от Аноним (31), 18-Апр-20, 20:40

Для запросов

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

41. "Выпуск СУБД TimescaleDB 1.7" –3 +/–

Сообщение от нах. (?), 19-Апр-20, 10:00

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

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

46. "Выпуск СУБД TimescaleDB 1.7" +3 +/–

Сообщение от Аноним (46), 19-Апр-20, 19:51

Скрытый экстремум сам придумал?

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

57. "Выпуск СУБД TimescaleDB 1.7" –2 +/–

Сообщение от нах. (?), 19-Апр-20, 22:41

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

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

56. "Выпуск СУБД TimescaleDB 1.7" +1 +/–

Сообщение от DeadMustdie (??), 19-Апр-20, 21:04

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

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

58. "Выпуск СУБД TimescaleDB 1.7" +/–

Сообщение от нах. (?), 19-Апр-20, 22:54

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

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

61. "Выпуск СУБД TimescaleDB 1.7" +/–

Сообщение от DeadMustdie (??), 19-Апр-20, 23:35

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

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

29. "Выпуск СУБД TimescaleDB 1.7" +2 +/–

Сообщение от Lex (??), 18-Апр-20, 20:25

“ и чем же оно годнота? тем что поверх pgsql - а на кой ляд во временных рядах возможность изменения данных.“ ?
Ви таки собрались изменять «исторические данные» задним числом ?

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

37. "Выпуск СУБД TimescaleDB 1.7" +/–

Сообщение от funny.falcon (?), 19-Апр-20, 09:24

Не вопрос. Подскажи что-нибудь для хранения исторических данных и разнообразных запросов к ним без возможности изменения.

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

66. "Выпуск СУБД TimescaleDB 1.7" +/–

Сообщение от qsdg (ok), 21-Апр-20, 17:35

Victoriametrics же выше сказали. Отключай автоматический ретеншн, и будут твои данные "историческими".

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

38. "Выпуск СУБД TimescaleDB 1.7" +/–

Сообщение от funny.falcon (?), 19-Апр-20, 09:26

А друшой момент: бывают данные не срвсем исторические, но скорость изменения которых падает пропорционально их возрасту.

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

42. "Выпуск СУБД TimescaleDB 1.7" +4 +/–

Сообщение от Алексей Морозов (ok), 19-Апр-20, 16:36

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

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

59. "Выпуск СУБД TimescaleDB 1.7" –1 +/–

Сообщение от нах. (?), 19-Апр-20, 22:56

а где тут "изменение данных" ? Просто добавление не синхронное же.

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

68. "Выпуск СУБД TimescaleDB 1.7" +/–

Сообщение от qsdg (ok), 21-Апр-20, 17:45

> А если мне нужно не для метрик, а для исторических данных на
> десятки терабайт?
В подходящей базе десятки терабайт превращаются в просто терабайты, а если повезёт, то и в гигабайты, за счёт data-aware компрессии.
Для olap -- кликхаус. Для метрик -- victoriametrics.
У таймскейла вообще никакая компрессия, всё время тормозит из-за IO.

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

28. "Выпуск СУБД TimescaleDB 1.7" +1 +/–

Сообщение от анонимчик (?), 18-Апр-20, 19:15

> Подскажи тогда годноту, если ты такой эксперт
кликхаус

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

48. "Выпуск СУБД TimescaleDB 1.7" +/–

Сообщение от DeadMustdie (??), 19-Апр-20, 20:47

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

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

3. "Выпуск СУБД TimescaleDB 1.7" –8 +/–

Сообщение от Аноним (3), 18-Апр-20, 10:57

Скажите мне непросвещённому, чем оно лучше того же MySQL?

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

15. "Выпуск СУБД TimescaleDB 1.7" +2 +/–

Сообщение от Catwoolfii (ok), 18-Апр-20, 13:24

mysql не поддерживает time series?

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

34. "Выпуск СУБД TimescaleDB 1.7" –1 +/–

Сообщение от Аноним (34), 18-Апр-20, 21:38

А разве на СУБД без подобных расширений нельзя хранить выборки через заданные промежутки времени? А то разработчики всяких там АИИС КУЭ и не знают.

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

36. "Выпуск СУБД TimescaleDB 1.7" +2 +/–

Сообщение от Аноним (36), 19-Апр-20, 02:23

Можно, но mysql вряд ли сможет нормально работать с таблицей с триллионами записей на одном сервере, в то время как для специализированных БД для временных рядов - это детская нагрузка. https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/Case...

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

40. "Выпуск СУБД TimescaleDB 1.7" –1 +/–

Сообщение от нах. (?), 19-Апр-20, 09:52

осталось понять, являются ли сопли и клей поверх postgres "специализированной бд для временных рядов", и насколько быстро тот постгрез лопнет.

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

49. "Выпуск СУБД TimescaleDB 1.7" +/–

Сообщение от DeadMustdie (??), 19-Апр-20, 20:50

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

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

60. "Выпуск СУБД TimescaleDB 1.7" +/–

Сообщение от нах. (?), 19-Апр-20, 22:58

это если хочется именно sql.

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

30. "Выпуск СУБД TimescaleDB 1.7" –3 +/–

Сообщение от Lex (??), 18-Апр-20, 20:27

Тем же, чем и блокчейн[ т.е ничем, но хомяки одобрят ]

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

65. "Выпуск СУБД TimescaleDB 1.7" +/–

Сообщение от Аноним (65), 20-Апр-20, 13:17

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

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

11. "Выпуск СУБД TimescaleDB 1.7" –5 +/–

Сообщение от анонимчик (?), 18-Апр-20, 12:39

чем оно лучше кликхаус?

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

20. "Выпуск СУБД TimescaleDB 1.7" +7 +/–

Сообщение от Аноним (-), 18-Апр-20, 15:19

чем анонимчик отличается от дегенерата?

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

21. "Выпуск СУБД TimescaleDB 1.7" +/–

Сообщение от КО (?), 18-Апр-20, 16:10

Ничем, duh...
Аргументы пожалуйста

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

22. "Выпуск СУБД TimescaleDB 1.7" +2 +/–

Сообщение от Аноним (22), 18-Апр-20, 16:14

тем что тормознутее, ибо pq не колоночная DB.

Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

51. "Выпуск СУБД TimescaleDB 1.7" +/–

Сообщение от DeadMustdie (??), 19-Апр-20, 20:54

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

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

24. "Выпуск СУБД TimescaleDB 1.7" +/–

Сообщение от Аноним (24), 18-Апр-20, 18:08

А чем сабж лучше чем DB2?

Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

50. "Выпуск СУБД TimescaleDB 1.7" +/–

Сообщение от DeadMustdie (??), 19-Апр-20, 20:52

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

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

32. "Выпуск СУБД TimescaleDB 1.7" +/–

Сообщение от Аноним (31), 18-Апр-20, 20:43

В clickhouse нет транзакций например.

Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

35. "Выпуск СУБД TimescaleDB 1.7" +1 +/–

Сообщение от анонимчик (?), 18-Апр-20, 21:41

то плюс для таймсериес

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

52. "Выпуск СУБД TimescaleDB 1.7" +/–

Сообщение от DeadMustdie (??), 19-Апр-20, 20:55

> тем что тормознутее, ибо pq не колоночная DB.
А вот не факт.
Приложения разные бывают.

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

63. "Выпуск СУБД TimescaleDB 1.7" +/–

Сообщение от Аноним (-), 20-Апр-20, 10:56

отсутствие транзакций никогда не является плюсом, это всегда компромис во имя чего-то другого

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

33. "Выпуск СУБД TimescaleDB 1.7" +/–

Сообщение от Аноним (36), 18-Апр-20, 21:35

Интересно, насколько хорошо timescaledb работает с триллионами строк? Victoriametrics нормально работает, судя по https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/Case...

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

39. "Выпуск СУБД TimescaleDB 1.7" –1 +/–

Сообщение от funny.falcon (?), 19-Апр-20, 09:27

Представьте себе: хранить нужно не только метртки.

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

44. "Выпуск СУБД TimescaleDB 1.7" –1 +/–

Сообщение от anonymous (??), 19-Апр-20, 18:21

Если timeseries, то victoriametrics. Если OLAP, то ClickHouse.

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

53. "Выпуск СУБД TimescaleDB 1.7" +2 +/–

Сообщение от DeadMustdie (??), 19-Апр-20, 20:56

> Если timeseries, то victoriametrics. Если OLAP, то ClickHouse.
Расскажите об этом коллегам из Teradata, Microsoft, IBM, Oracle, SAP и Vertica.

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

54. "Выпуск СУБД TimescaleDB 1.7" +/–

Сообщение от DeadMustdie (??), 19-Апр-20, 20:57

В целом - жизнь немножко шире любых представлений о ней ;)

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

43. "Выпуск СУБД TimescaleDB 1.7" +/–

Сообщение от анонимуслинус (?), 19-Апр-20, 16:44

вот она база данных для научных вычислений и экспериментов. вопрос только в том выдержит она скажем записи данных с одронного коллайдера или других физических экспериментов с миллионами мелких датчиков?))

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

55. "Выпуск СУБД TimescaleDB 1.7" +/–

Сообщение от DeadMustdie (??), 19-Апр-20, 21:02

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

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

62. "Выпуск СУБД TimescaleDB 1.7" +/–

Сообщение от Анончик (?), 20-Апр-20, 06:01

Наверное путаете, в цене судя по докаладам оракл во все поля за редким исключением.

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

64. "Выпуск СУБД TimescaleDB 1.7" +1 +/–

Сообщение от DeadMustdie (??), 20-Апр-20, 11:31

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

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

67. "Выпуск СУБД TimescaleDB 1.7" +/–

Сообщение от qsdg (ok), 21-Апр-20, 17:39

В коллайдере у них там несколько уровней предобработки данных перед записью, на каждом уровне по 99% данных выбрасываются за ненужностью. И только потом записываются. Иначе в мире дисков не хватит чтобы сырые данные с одного эксперимента записать.

Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

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


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


	16. "Выпуск СУБД TimescaleDB 1.7"	–2 +/–
	Сообщение от Аноним (1), 18-Апр-20, 13:44
	Подскажи тогда годноту, если ты такой эксперт
	Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "Выпуск СУБД TimescaleDB 1.7"	+2 +/–
	Сообщение от Аноним (17), 18-Апр-20, 14:01
	Victoriametrics.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	23. "Выпуск СУБД TimescaleDB 1.7"	+/–
	Сообщение от Аноним (1), 18-Апр-20, 16:24
	А если мне нужно не для метрик, а для исторических данных на десятки терабайт?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	27. "Выпуск СУБД TimescaleDB 1.7"	+/–
	Сообщение от нах. (?), 18-Апр-20, 18:22
	> А если мне нужно не для метрик, а для исторических данных на > десятки терабайт? а sql им зачем?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	31. "Выпуск СУБД TimescaleDB 1.7"	+/–
	Сообщение от Аноним (31), 18-Апр-20, 20:40
	Для запросов
	Ответить \| Правка \| Наверх \| Cообщить модератору


	41. "Выпуск СУБД TimescaleDB 1.7"	–3 +/–
	Сообщение от нах. (?), 19-Апр-20, 10:00
	а теперь расскажи нам, как выглядит запрос к бд с метрикой, снимающеся раз в, допустим, пять минут, чтобы нарисовать график ее изменения за год. Если ты хотя бы немножко умеешь кодить - ты поймешь, почему sql для этой цели абсолютно неудачный выбор. Если еще и математику в школе учил - вспомни что такое "скрытый экстремум", выкинь мысленно уже написанный тобой гуанокод и начинай заново. Если в школе ты учил только основы религиозных культур, а кодить умеешь только в .md, то можешь не морщить лобик.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	46. "Выпуск СУБД TimescaleDB 1.7"	+3 +/–
	Сообщение от Аноним (46), 19-Апр-20, 19:51
	Скрытый экстремум сам придумал?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	57. "Выпуск СУБД TimescaleDB 1.7"	–2 +/–
	Сообщение от нах. (?), 19-Апр-20, 22:41
	ну просто намек, что очевидный алгоритм "в лоб" будет неверным - "съест" резкие отклонения, которые мы как раз, наверное, хотим увидеть, можно неточными. На мой взгляд правильного ответа в рамках sql и единственной таблицы timestamp,value - не существует в принципе.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	56. "Выпуск СУБД TimescaleDB 1.7"	+1 +/–
	Сообщение от DeadMustdie (??), 19-Апр-20, 21:04
	> а sql им зачем? Чтобы самим не писать вручную алгоритмы доступа к данным, включая миллионную в мире кривую реализацию Hash Merge. А оный Merge возникнет рано или поздно при сопоставении разных групп наблюдений.
	Ответить \| Правка \| К родителю #27 \| Наверх \| Cообщить модератору


	58. "Выпуск СУБД TimescaleDB 1.7"	+/–
	Сообщение от нах. (?), 19-Апр-20, 22:54
	> А оный Merge возникнет рано или поздно при сопоставении разных групп наблюдений. хренассе... а точно-точно timescale это то, что подходит для подобных данных? (просто вроде принято считать, что если в sql запросе возникает hash merge, это чаще всего признак неправильной структуры базы, и даже "прямая" реализация тут плохо помогает - все равно это худший вариант)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	61. "Выпуск СУБД TimescaleDB 1.7"	+/–
	Сообщение от DeadMustdie (??), 19-Апр-20, 23:35
	> хренассе... а точно-точно timescale это то, что подходит для подобных данных? Агрегировать и фильтровать умеет, результат в виде таблицы выдаёт. Дальше вопрос уже к постгресу. > (просто вроде принято считать, что если в sql запросе возникает hash merge, > это чаще всего признак неправильной структуры базы, и даже "прямая" реализация > тут плохо помогает - все равно это худший вариант) Это верно лишь для трансакционных систем. Аналитические хранилища строят по другим принципам, и там сканирование таблиц (в поколоночном варианте - столбцов) скорее правило, чем исключение.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	29. "Выпуск СУБД TimescaleDB 1.7"	+2 +/–
	Сообщение от Lex (??), 18-Апр-20, 20:25
	“ и чем же оно годнота? тем что поверх pgsql - а на кой ляд во временных рядах возможность изменения данных.“ ? Ви таки собрались изменять «исторические данные» задним числом ?
	Ответить \| Правка \| К родителю #23 \| Наверх \| Cообщить модератору


	37. "Выпуск СУБД TimescaleDB 1.7"	+/–
	Сообщение от funny.falcon (?), 19-Апр-20, 09:24
	Не вопрос. Подскажи что-нибудь для хранения исторических данных и разнообразных запросов к ним без возможности изменения.
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


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


	42. "Выпуск СУБД TimescaleDB 1.7"	+4 +/–
	Сообщение от Алексей Морозов (ok), 19-Апр-20, 16:36
	Не мы такие, жись такая. Вот идет поток, скажем, от GPS-трекера. И все бы хорошо, но время от времени этот чертов трекер начинает досылать данные, накопленные в своем черном ящике,
	Ответить \| Правка \| К родителю #29 \| Наверх \| Cообщить модератору


	59. "Выпуск СУБД TimescaleDB 1.7"	–1 +/–
	Сообщение от нах. (?), 19-Апр-20, 22:56
	а где тут "изменение данных" ? Просто добавление не синхронное же.
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


	28. "Выпуск СУБД TimescaleDB 1.7"	+1 +/–
	Сообщение от анонимчик (?), 18-Апр-20, 19:15
	> Подскажи тогда годноту, если ты такой эксперт кликхаус
	Ответить \| Правка \| К родителю #16 \| Наверх \| Cообщить модератору


	48. "Выпуск СУБД TimescaleDB 1.7"	+/–
	Сообщение от DeadMustdie (??), 19-Апр-20, 20:47
	> кликхаус Таки либо облако, либо ковыряй сам - поддержки не будет даже за деньги.
	Ответить \| Правка \| Наверх \| Cообщить модератору

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


	15. "Выпуск СУБД TimescaleDB 1.7"	+2 +/–
	Сообщение от Catwoolfii (ok), 18-Апр-20, 13:24
	mysql не поддерживает time series?
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


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


	40. "Выпуск СУБД TimescaleDB 1.7"	–1 +/–
	Сообщение от нах. (?), 19-Апр-20, 09:52
	осталось понять, являются ли сопли и клей поверх postgres "специализированной бд для временных рядов", и насколько быстро тот постгрез лопнет.
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


	60. "Выпуск СУБД TimescaleDB 1.7"	+/–
	Сообщение от нах. (?), 19-Апр-20, 22:58
	это если хочется именно sql.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	30. "Выпуск СУБД TimescaleDB 1.7"	–3 +/–
	Сообщение от Lex (??), 18-Апр-20, 20:27
	Тем же, чем и блокчейн[ т.е ничем, но хомяки одобрят ]
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору