forum.opennet.ru - "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." (78)

"Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."

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

"Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	+/–
Сообщение от opennews (?), 25-Май-19, 21:23
Открыты (https://blog.usejournal.com/open-sourcing-victoriametrics-f3... исходные тексты VictoriaMetrics (https://victoriametrics.com/) - быстрой и масштабируемой СУБД для хранения и обработки данных в форме временного ряда (запись образует время и набор соответствующих этому времени значений, например, полученных через периодический опрос состояния датчиков или сбор метрик). Проект конкурирует с такими решениями, как InfluxDB (https://influxdata.com), TimescaleDB (https://www.timescale.com/), Thanos (https://github.com/improbable-eng/thanos), Cortex (https://github.com/cortexproject/cortex) и Uber M3 (https://eng.uber.com/m3/). Код написан на языке Go и распространяется (https://github.com/VictoriaMetrics/VictoriaMetrics) под лицензией Apache 2.0. Преимущества и особенности VictoriaMetrics: - Проста в эксплуатации. Представляет из себя один исполняемый файл с минимальными настройками, передающимися через командную строку при запуске. - Поддержка языка запросов PromQL (https://prometheus.io/docs/prometheus/latest/querying/basics/), используемого в системе мониторинга Prometheus (https://prometheus.io/). Поддерживаются подзапросы PromQL и некоторые расширенные возможности (https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/Exte... такие как выражение "offset", шаблоны внутри "WIDTH", операторы "if" и "default", дополнительные функции и возможность включения комментариев; - Возможность использования в качестве долговременного хранилища данных (https://prometheus.io/docs/prometheus/latest/storage/#remote... подключенного к Prometheus и Grafana (https://grafana.com/). - Наличие режима обратного заполнения для загрузки исторических данных; - Поддержка различных протоколов передачи данных, включая Prometheus API, Influx, Graphite и OpenTSDB. В том числе VictoriaMetrics может применяться в качестве прозрачной замены InfluxDB и может работать с совместимыми с InfluxDB коллекторами, такими как Telegraf; - Высокая производительность и низкое потребление ресурсов по сравнению (https://medium.com/@valyala/measuring-vertical-scalabil... с конкурирующими системами. Возможность (https://medium.com/@valyala/insert-benchmarks-with-inch... обработки очень большого числа уникальных временных рядов; - Реализация на языке Go, что обеспечивает компромисс между производительностью и сложностью кода по сравнению с Rust и C++. - Предоставляются исходные коды кластерной версий (https://github.com/VictoriaMetrics/VictoriaMetrics/tree/clus... которая поддерживает горизонтальное масштабирование на несколько серверов и демонстрирует низкие накладные расходы. Имеются средства обеспечения высокой доступности. URL: https://blog.usejournal.com/open-sourcing-victoriametrics-f3... Новость: https://www.opennet.dev/opennews/art.shtml?num=50745
Ответить \| Правка \| Cообщить модератору

Оглавление

Я тупой В чем прикол таких баз данных Чем простая таблица в постгресе или муск, Груст (?), 21:23 , 25-Май-19, (1) –15

Скоростью У нас несколько миллионов метрик под постоянным мониторингом то есть , anonymous (??), 21:34 , 25-Май-19, (3) +10

P S К тому же для Prometheus, например есть куча написанного ПО для работы с ме, anonymous (??), 21:35 , 25-Май-19, (4) +1
То есть, вы даже не пробовали, а сразу вкорячили стильно-модно-молодежное , Аноним (11), 23:51 , 25-Май-19, (11) –9

Кто вам такое сказал Уже начинают надоедать вопросы про эти стильно-модно-моло, anonymous (??), 00:24 , 26-Май-19, (12) +6

P S Но даже если бы и не пробовали, то это не повод отказываться от хорошего р, anonymous (??), 00:38 , 26-Май-19, (14) +2
Не могли бы вы пояснить эту фразу Она как-то не укладывается в моей голове -- ж, Ordu (ok), 04:42 , 26-Май-19, (18) +2

жрёт сильно меньше ресурсов, не , Какаянахренразница (ok), 06:02 , 26-Май-19, (19)
Жрёт сильно меньше ресурсов , прошу прощения , anonymous (??), 11:10 , 26-Май-19, (23) +1

надо было просто сказать архи-высочайше меньше - тогда бы все сразу поняли, Аноним (28), 13:02 , 26-Май-19, (28) –1

Если сравнивать с прометеусом, то мимо ресурсов cpu memory, есть ли выигрыш по d, Аноним (36), 16:12 , 26-Май-19, (36) –1

VictoriaMetrics хорошо жмет данные перед сохранением на диск Например, в 70 раз, valyala (?), 14:14 , 29-Май-19, (57) +1

ойспадя, lha против pkarc-а детство, дос, велосипедики-паровозики , Andrey Mitrofanov_N0 (?), 15:25 , 29-Май-19, (64) –1

это, чувак, не lha Это примерно zip против rll compression , пох. (?), 17:36 , 29-Май-19, (66) –1

Я т-тя умоляю Чтоб 10ха получить, надо не писать данные на диск часок-другой,, Andrey Mitrofanov_N0 (?), 10:59 , 30-Май-19, (71)
VictoriaMetrics скидывает данные на диск раз в секунду См https medium com , valyala (?), 14:07 , 30-Май-19, (73) +2
Аминь Я уже почти готов хотеть в Zabbix , как тот Аноним Но мне, пожалуйста, , Andrey Mitrofanov_N0 (?), 11:42 , 31-Май-19, (76)

чего там пробовать - количество известно, скорость поступления тоже Помножить од, пох (?), 00:35 , 26-Май-19, (13)

Насколько я помню, создатели Victoria Metrics утверждали, что у них как раз можн, qsdg (ok), 07:37 , 26-Май-19, (20)

Это потому, что 95 не слыхивали о теореме Котельникова , DeadLoco (ok), 07:55 , 26-Май-19, (21)

А можно подробнее, в применении к системам мониторинга , А (??), 23:32 , 26-Май-19, (40)

речь была не об этом - речь о том что select where timestamp чемубытонибыло -, пох (?), 11:54 , 26-Май-19, (24)
VictoriaMetrics поддерживает возможность получить сырые данные - см https med, valyala (?), 14:17 , 29-Май-19, (58)

Чего там у них с Судьбой-то Яндекс со слоникомвдоме замучали насмерть А ко, Andrey Mitrofanov_N0 (?), 15:41 , 29-Май-19, (65) –1

я, в отличие от некоторых, слишком хорошо знаком с их поделкой - включая поиски , пох. (?), 17:41 , 29-Май-19, (67)

То есть про авторов - но за прошедшие десять лет уже даже его авторам понятно,, Andrey Mitrofanov_N0 (?), 11:05 , 30-Май-19, (72) –1

это очевидный вывод из их не особо удачной попытки таки добавить tsdb в послед, пох. (?), 22:23 , 30-Май-19, (74) –1

Автоаночо А то же я подумал, что у тебя мускулы в докерах взрываются тм , а , Andrey Mitrofanov_N0 (?), 11:54 , 31-Май-19, (77) –2

У меня по сути только один вопрос сколько человек смотрят ежедневно ваши миллио, Онаним (?), 17:58 , 26-Май-19, (38) +1

Так это может не для человека нужно Для ИИ или каких-то процессов моделирования, Аноним (44), 11:12 , 27-Май-19, (44)
например - ноль Но если что-то начинает вести себя странно - открывают связанны, пох (?), 14:04 , 27-Май-19, (48) +2

Это специфический тип данных Хранить его в обычном sql крайне неэффективно Хоро, Грустный Ёжик (?), 21:38 , 25-Май-19, (6) +7
Тем, что в таких базах обычно сам временной ряд оптимизирован, как по объёму инф, Тупой Груст (?), 21:38 , 25-Май-19, (7) +3

Какой-то феерический бред , Аноним (2), 21:31 , 25-Май-19, (2) –9

Какие-то аргументы будут Go -- действительно более простой язык, чем C , имеющи, anonymous (??), 21:37 , 25-Май-19, (5) +12

Сложность кода фактор, важный для разработчиков следует читать как лень раз, InuYasha (?), 13:48 , 26-Май-19, (33) –6

Нет, сложность кода -- это именно сложность кода , anonymous (??), 22:02 , 26-Май-19, (39) +1

А не нагружать ГЦ автор этой ВикторияМятрикс умеет хорошо, его https github co, qsdg (ok), 03:05 , 20-Июл-19, (79) –1

Некоторые раз в пять лет вылезают из ржавого танка, видят как изменилась жизнь в, Аноним (28), 13:08 , 26-Май-19, (30) +6

но что характерно - через следующие пять лет никто уже не помнит никакое игого и, пох (?), 13:23 , 26-Май-19, (32) +1

А должен ехать , derfenix (ok), 17:19 , 26-Май-19, (37) +6

И куда ему ехать , GentooBoy (ok), 11:49 , 27-Май-19, (45)

Странно что с RRDTool не сравнивают или они в разных нишах , Аноним (8), 23:05 , 25-Май-19, (8)

В разных В RRD не хранятся сырые значения, а утрамбовываются аггрегацией и инт, Аноним (10), 23:11 , 25-Май-19, (10) +2

Хрен с ним с RRDTool Где с прометеусом сравнение , vitalif (ok), 23:09 , 25-Май-19, (9)

Прометей сам по себе только локально может, нода упала и каюк Поэтому к нему об, qsdg (ok), 04:39 , 26-Май-19, (17)
Прометеус не поддерживает API на запись данных, что не позволяет положить в не, Hagen (??), 10:18 , 26-Май-19, (22)

Статья вроде написана автором продукта, но очень скромно сильно занижая важност, anonymous (??), 00:56 , 26-Май-19, (16)

это если еще и работает Кто смелый , пох (?), 11:55 , 26-Май-19, (25)

Выглядит настолько вкусно, что хочется попробовать Есть у нас одна приблуда для, x3who (?), 12:49 , 26-Май-19, (27)

Если под несколькими потоками данных понимаются несколько временных рядов, то Pr, valyala (?), 14:23 , 29-Май-19, (59)

TimescaleDB - надстройка extension над постгресом MVCC и др , чего отродясь н, Аноним_number_X (?), 12:15 , 26-Май-19, (26)

В чем суть претензии - вы хотите сказать, что на самом деле Постгрес лучше подхо, x3who (?), 13:05 , 26-Май-19, (29)

Суть претензии в попытках манипуляции Автобус лучше Белаза или Белаз лучше авто, Аноним_number_X (?), 13:21 , 26-Май-19, (31)

Все сравниваемые решения - TimescaleDB, InfluxDB и VictoriaMetrics - позициониру, valyala (?), 14:26 , 29-Май-19, (60)

Но задача-то сформулирована - эффективная работа с тайм-сериями Там важно сколь, x3who (?), 14:57 , 26-Май-19, (34) +1

Вот манипуляция и заключается в том, что белаз перевозит 1 водителя, а сколько о, Аноним_number_X (?), 16:06 , 26-Май-19, (35)

Так всё зависит от условий - в 40х годах Белаз бы был идеальным средством переме, x3who (?), 00:18 , 27-Май-19, (41)

Так всё зависит от условий - дык, я спорю Кластер велосипедистов С для ядре, Аноним_number_X (?), 23:59 , 29-Май-19, (69)

Ещё бы к Заббиксу привинтили поддержку этой СУБД в качестве бэкенда 8230 Эх, м, Аноним (42), 01:42 , 27-Май-19, (42) –1

Зачем Поделитесь подробностями , Andrey Mitrofanov (?), 11:58 , 27-Май-19, (46)

затем что лопнуть он норовит - именно из-за использования sql для задачи, ему не, пох (?), 14:14 , 27-Май-19, (49)

А-а-ага Ну-да, ну-да whistler на пайтоне и субж на го-шечке -- не з-з-здуются , Andrey Mitrofanov_N1 (?), 16:58 , 27-Май-19, (52) –1

поддержку какой-то tsdb к 4 2 приделали - поддержку прометеуса тоже приделали, н, пох (?), 14:27 , 27-Май-19, (51) +1
Никто не мешает прикрутить VictoriaMetrics в качестве бэкенда к Zabbix - исходни, valyala (?), 14:29 , 29-Май-19, (61)

видели бы вы те исходники жабикса, в смысле , пох. (?), 17:45 , 29-Май-19, (68) +1

Вот, честно, сам не смотрел, но с удовольствием от нах пох кстати, а лох есть , Аноним_number_X (?), 00:05 , 30-Май-19, (70)

я не умею в игого, поэтому оценить именно качество кода не смогу А не глядя в ко, пох. (?), 22:41 , 30-Май-19, (75) +1

перед тем как что то мониторить надо понять а на куя это мониторить та же исто, Аноним (43), 07:04 , 27-Май-19, (43)

С разморозочкой ИИ в него давно уже смотрит И умеет тебя отличить из толпы, во, пох (?), 14:15 , 27-Май-19, (50)

С Clickhouse сравнивать не стали по очевидным причинам , GentooBoy (ok), 12:04 , 27-Май-19, (47) +1

ClickHouse -- это для другого рода метрик , anonymous (??), 17:57 , 27-Май-19, (53)

можно поподробнее ну или линки, Аноним (56), 16:28 , 28-Май-19, (56)

Кликхаус - аналитическая СУБД Ее можно приспособить для хранения метрик, но это, valyala (?), 14:38 , 29-Май-19, (62)

Господа, а чем собственно смотреть метрики в Influx есть пусть и подтормаживающи, Аноним (54), 22:34 , 27-Май-19, (54)

Смотря что нужно Однако стоит особо отметить grafana -- весьма популярный серви, anonymous (??), 00:51 , 28-Май-19, (55) +1
Есть следующие способы просмотра метрик, сохраненных в VictoriaMetrics - Строить, valyala (?), 14:45 , 29-Май-19, (63) +1

Интересно, почему с graphite это дело сравнивается так, как будто graphite беско, Аноним (78), 15:00 , 01-Июн-19, (78)

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

1. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." –15 +/–

Сообщение от Груст (?), 25-Май-19, 21:23

Я тупой. В чем прикол таких баз данных? Чем простая таблица в постгресе или мускуле не угодила?

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

3. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +10 +/–

Сообщение от anonymous (??), 25-Май-19, 21:34

Скоростью.
У нас несколько миллионов метрик под постоянным мониторингом (то есть снимаются новые значения и постоянно рисуются графики на произвольные временные интервалы). И эта штука справляется одним сервером.

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

4. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +1 +/–

Сообщение от anonymous (??), 25-Май-19, 21:35

P.S.:
К тому же для Prometheus, например есть куча написанного ПО для работы с метриками. Просто берёшь и используешь.

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

11. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." –9 +/–

Сообщение от Аноним (11), 25-Май-19, 23:51

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

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

12. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +6 +/–

Сообщение от anonymous (??), 26-Май-19, 00:24

Кто вам такое сказал? Уже начинают надоедать вопросы про эти "стильно-модно-молодёжно" от людей, кто, видимо, вообще не занимается high load (иначе откуда такие вопросы?).
Отвечая на вопрос: нет, мы пробовали. Вернее, за опыт подобных задач чего только не пробовали.  Пробовали и MySQL/PgSQL и нижеупомянутые RRD [которые конкретно тут вообще не к месту], и graphite, и InfluxDB и прочее и прочее, и уже лишь потом чистый Prometheus и VictoriaMetrics (как минимум потому, что Prometheus появился лишь несколько лет назад). Prometheus -- единственный, кто справился с нашими _текущими_ задачами, а VictoriaMetrics работает ещё лучше (жрёт сильно ресурсов).

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

14. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +2 +/–

Сообщение от anonymous (??), 26-Май-19, 00:38

P.S.: Но даже если бы и не пробовали, то это не повод отказываться от хорошего решения (такого как Prometheus или VictoriaMetrics). Просто изучите как что работает, изучите задачу, которую решайте, и исходя из этого выбирайте инструменты.

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

18. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +2 +/–

Сообщение от Ordu (ok), 26-Май-19, 04:42

> VictoriaMetrics работает ещё лучше (жрёт сильно ресурсов).
Не могли бы вы пояснить эту фразу? Она как-то не укладывается в моей голове -- жрёт сильно ресурсов, значит лучше? Может тут ошибка какая вкралась в формулировку? Или имеется в виду "работает ещё лучше, хоть и жрёт сильно ресурсов"?

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

19. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от Какаянахренразница (ok), 26-Май-19, 06:02

жрёт сильно меньше ресурсов, не?

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

23. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +1 +/–

Сообщение от anonymous (??), 26-Май-19, 11:10

"Жрёт сильно меньше ресурсов", прошу прощения.

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

28. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." –1 +/–

Сообщение от Аноним (28), 26-Май-19, 13:02

надо было просто сказать: "архи-высочайше меньше" - тогда бы все сразу поняли

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

36. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." –1 +/–

Сообщение от Аноним (36), 26-Май-19, 16:12

Если сравнивать с прометеусом, то мимо ресурсов cpu/memory, есть ли выигрыш по disk usage? Не проводили замеры?

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

57. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +1 +/–

Сообщение от valyala (?), 29-Май-19, 14:14

VictoriaMetrics хорошо жмет данные перед сохранением на диск. Например, в 70 раз лучше, чем TimescaleDB и примерно в 10 раз лучше, чем Prometheus. Вот тут можно почитать, почему так происходит - https://medium.com/@valyala/victoriametrics-achieving-b...

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

64. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." –1 +/–

Сообщение от Andrey Mitrofanov_N0 (?), 29-Май-19, 15:25

> VictoriaMetrics хорошо жмет данные перед сохранением на диск. Например, в 70 раз
> лучше, чем TimescaleDB и примерно в 10 раз лучше, чем Prometheus.
> Вот тут можно почитать, почему
ойспадя, lha против pkarc-а... детство, дос, велосипедики-паровозики...

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

66. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." –1 +/–

Сообщение от пох. (?), 29-Май-19, 17:36

> This is 10x times better than 4 bytes per data point for the same data in Prometheus
это, чувак, не lha. Это примерно zip против rll compression.

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

71. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от Andrey Mitrofanov_N0 (?), 30-Май-19, 10:59

>> This is 10x times better than 4 bytes per data point for the same data in Prometheus
> это, чувак, не lha. Это примерно zip против rll compression.
Я т-тя умоляю... Чтоб 10ха получить, надо не писать данные на диск часок-другой, или делать запись дважды - полнве несжатые, фактически данные каждую секунду или типа, и пере-сжимать их раз в час или сколько там.
Быстро не писать на диск все умеют https://duckduckgo.com/?q=postgresql+running+with+scissors&t...
И пересжиманием архивов другим, более модным архиватором, тоже все в детстве баловались.
А тут, вищь ты, новый маркетинговый булшит завезли -- time series DB.
Новый выпуск "академиков" со свежмим хрустящими дипломами.
Слайдики многоцветные, в глазах рябит. Инвестиции -- миллионами.
" А не прикрутить ли ОНО к Zabbix-у?  Будет же хоро-шоу!  Да-а?1 "- вопрошают стада непуганых детей.   ...и только мудрый пох знает: забикса уже не спасти, надо успеть продать RRD и 10хе, пока не сдулись.

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

73. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +2 +/–

Сообщение от valyala (?), 30-Май-19, 14:07

>>> This is 10x times better than 4 bytes per data point for the same data in Prometheus
>> это, чувак, не lha. Это примерно zip против rll compression.
> Я т-тя умоляю... Чтоб 10ха получить, надо не писать данные на диск
> часок-другой, или делать запись дважды - полнве несжатые, фактически данные каждую
> секунду или типа, и пере-сжимать их раз в час или сколько
> там.
VictoriaMetrics скидывает данные на диск раз в секунду. См. https://medium.com/@valyala/wal-usage-looks-broken-in-m... .
Что касается пересжатия, то вы правы - под капотом используются Log-structured merge tree, которая пережимает данные в более крупные блоки - https://medium.com/@valyala/how-victoriametrics-makes-i...

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

76. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от Andrey Mitrofanov_N0 (?), 31-Май-19, 11:42

> VictoriaMetrics скидывает данные на диск раз в секунду. См. https://medium.com/@valyala/wal-usage-looks-broken-in-m...
> .
> Что касается пересжатия, то вы правы - под капотом используются Log-structured merge
> tree, которая пережимает данные в более крупные блоки -
Аминь.
Я уже почти готов "хотеть в Zabbix", как тот Аноним.  Но мне, пожалуйста, cstore_fdw переместите куда поближе к основному стору и обычным wal-логам с чекпоинтами (вот, как в Виктории -- с 10икс)  --  в PostgreSQL.  Мож лет через 3-5 запилят плагины для стораджа, не для "источника данных"... молитвами TimescaleDB, под шумок и инветиции... вот тогда и поглядим.
А пока "взрывающийся sql"(c)пох  моё продакшен-всё.  Партишонинг уже вот-вот почти,  шардинг?  может быть.  TimescaleDB? с дубу рухнул я что ли...
И обязательно: на халяву, бесплатно и с поддержкой от _сообщетва_, а не молодых-ранних-проинвестированных single-апстримов.
(И да, пока не прибежал тот другой ушибленный -- "бери исходники и паччь" тоже не сюда. спасибо, сам пошёл.)

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

13. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от пох (?), 26-Май-19, 00:35

чего там пробовать - количество известно, скорость поступления тоже.
Помножить одно на другое и на пару недель хранения - получаем размер базы, вызывающий вопросы, в своем ли уме тот, кто ее такую завел в sql. Причем в нее идут запросы весьма специфического характера - нужны либо все данные за интервал от-до, либо средние на отрезке такой-то длинны от и до, либо не средние, а, например, 90%. И никогда-никогда не понадобится конкретное значение вот в такой вот момент (к тому же его весьма вероятно и вообще нет в базе - есть значение на пол-секунды до, и на пол-секунды после, и какой у них точный тамйстемп - угадать нельзя)
отдельно спроси себя, что происходит с такой базой во время housekeeping- то есть удаления ставших ненужными кусков данных - как в этот момент идут инсерты, что происходит с системой хранения и т д.
Кому не хватает умишка - ну, судьба громадных инстансов zabbix (который как раз mysql использует вместо tsdb, точнее, до последней версии использовал, сейчас вроде научился, правда, как обычно у авторов, чему-то странному) служит последним предупреждением. Или первым факапом, кому как повезет.
Да, они там напихали огромное количество костылей и подпорок, чтобы оно вообще как-то у кого-то работало, но за прошедшие десять лет уже даже его авторам понятно, что идея "компьютеры стали достаточно быстрыми, чтобы обойтись sql'ем" была неудачной (а выбор mysql/postgres с неосиляторством sqlite - неудачным вдвойне).

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

20. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от qsdg (ok), 26-Май-19, 07:37

> И никогда-никогда не понадобится конкретное значение вот в такой вот момент
Насколько я помню, создатели Victoria Metrics утверждали, что у них как раз можно будет вытянуть сырые данные, а не как у дефолтного Prometheus. Я когда его только поставил, никак не мог понять почему у меня метрики получаются "пилой", ибо я сделал стандартную ошибку новичков в Prometheus -- запрашивал данные с таким же resolution как и scrape_interval. Эти вроде обещали что такого не будет, хотя я ещё не пробовал.

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

21. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от DeadLoco (ok), 26-Май-19, 07:55

Это потому, что 95% не слыхивали о теореме Котельникова.

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

40. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от А (??), 26-Май-19, 23:32

А можно подробнее, в применении к системам мониторинга?

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

24. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от пох (?), 26-Май-19, 11:54

речь была не об этом - речь о том что select .. where timestamp=чемубытонибыло - под что хорошо оптимизированы sql-базы - вообще не может использоваться с tsdb (даже имитируемой sql'ем) - потому что никто не обещал что такой вообще в базе будет, и когда юзер просит "покажи мне счетчик в момент X", он на самом деле имеет в виду - "покажи мне среднее между наиболее близкими к моменту X отсчетами".
хранение сырых данных тут не очень поможет, если только они не снабжены метками сами по себе - что нынче немодно-немолодежно. Да и смысла особенного не имеет - приезжает у тебя разом 300 метрик, все выплюнуты приложением по какому-то конкретному поводу, нафига 300 времен сохранять, когда оно одно ровно на всех.
Виктория, конечно, упакует, так что лишнего места не сожрется, но смысла в этом нет. Опять таки нормализованные формы хранения для tsdb не нужны - поскольку у данных из разных метрик ровно одна общая точка - тот самый тамймстемп.
Короче, совсем на sql не похоже. Просто лет десять-пятнадцать назад некоторые авторы некоторых мониторилок напрасно решили что компьютеры уже достаточно мощные и можно обойтись sql'ем. Оказалось, компьютеры еще и генерят теперь на несколько порядков больше мусора, и обойтись по прежнему получается плохо.

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

58. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от valyala (?), 29-Май-19, 14:17

VictoriaMetrics поддерживает возможность получить сырые данные - см. https://medium.com/@valyala/analyzing-prometheus-data-w...

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

65. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." –1 +/–

Сообщение от Andrey Mitrofanov_N0 (?), 29-Май-19, 15:41

> Кому не хватает умишка - ну, судьба громадных инстансов zabbix (который как
> раз mysql
Чего там у них с Судьбой-то?  Яндекс со слоникомвдоме замучали насмерть?....
>использует вместо tsdb, точнее, до последней версии использовал, сейчас
> вроде научился, правда, как обычно у авторов, чему-то странному) служит последним
> предупреждением. Или первым факапом, кому как повезет.
А конкретнее?
Апокалипс -- сегодня и каждый вечер на арене?
> Да, они там напихали огромное количество костылей и подпорок, чтобы оно вообще
> как-то у кого-то работало, но за прошедшие десять лет уже даже
> его авторам понятно, что идея "компьютеры стали достаточно быстрыми, чтобы обойтись
> sql'ем" была неудачной (а выбор mysql/postgres с неосиляторством sqlite - неудачным
> вдвойне).
Ага, Вы я вижу знакомы с Авторами.   Пригласите их сюда, пусть сами за себя, ладно?
"" Мускул умер, посгре умер, сиквел умер...  Всех их задавил пох своей жирной #zabbix. ""  Продолжай про "...бороздят просторы Большого Театра".
///"" -- А вдоль дорог мёртвые с косами -- стоять!  -- Б----я-а. ""

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

67. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от пох. (?), 29-Май-19, 17:41

> Ага, Вы я вижу знакомы с Авторами.
я, в отличие от некоторых, слишком хорошо знаком с их поделкой - включая поиски "где ж эта тварь в очередной раз помножилась на ноль" (прекрасный сишный спагетти-код с миллиардом не проверяемых указателей-параметров - это они называют "оптимизацией") и "как перенести 600 автодискаверимых айтимов вместе с историей и автопоиском с одного хоста на другой - поскольку приложение, внезапно, переехало, кто бы мог подумать, что так бывает!" (прекрасный веб-интерфейс, который этого не умеет, и прекрасная структура базы данных, не документированная в принципе)

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

72. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." –1 +/–

Сообщение от Andrey Mitrofanov_N0 (?), 30-Май-19, 11:05

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

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

74. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." –1 +/–

Сообщение от пох. (?), 30-Май-19, 22:23

> То есть про авторов -
> "" но за прошедшие десять лет уже даже его авторам понятно, что
> - этт Вы разговаривали за других?
это очевидный вывод из их (не особо удачной) попытки таки добавить tsdb в последнюю версию.
>> (прекрасный веб-интерфейс, который этого не умеет, и прекрасная структура базы данных,
>> не документированная в принципе)
> Это прекрасно.  Да-да, конечно.  Продолжайте бороздить посторы Большого.
продолжайте извлекать информацию из астрала, ага. Главное. ни в коем случае не пытайтесь пользоваться - а то внезапно полученные знания реального мира могут ненароком разрушить ваш розовый мирок.

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

77. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." –2 +/–

Сообщение от Andrey Mitrofanov_N0 (?), 31-Май-19, 11:54

>> То есть про авторов -
>> "" но за прошедшие десять лет уже даже его авторам понятно, что
>> - этт Вы разговаривали за других?
> это очевидный вывод из их (не особо удачной) попытки таки добавить tsdb
> в последнюю версию.
Автоаночо.  А то же я подумал, что у тебя мускулы в докерах "взрываются"(тм), а это оказывается....
....неудачи авторов с тсдб -- твой сиквел порвали.
В клочья, да.   " Это забикс виноват "-частушка.

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

38. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +1 +/–

Сообщение от Онаним (?), 26-Май-19, 17:58

У меня по сути только один вопрос: сколько человек смотрят ежедневно ваши миллионы метрик, и сколько метрик они успевают посмотреть за год? :D Не троллю, просто интересна нужность всего этого.

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

44. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от Аноним (44), 27-Май-19, 11:12

Так это может не для человека нужно. Для ИИ или каких-то процессов моделирования или "алармических" алгоритмов. А человек уже выжимку после этого "чего-то" получает - "пока все нормально" или "срочно подними графитовые стержни или сиди я сам подниму, у нас возникла неприятная тенденция" или "скидывай срочно эти поганые биткоины!"

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

48. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +2 +/–

Сообщение от пох (?), 27-Май-19, 14:04

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

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

6. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +7 +/–

Сообщение от Грустный Ёжик (?), 25-Май-19, 21:38

Это специфический тип данных. Хранить его в обычном sql крайне неэффективно.
Хороший пример временного ряда-- оцифрованный звук. Представьте, что кто-то решил хранить 16 бит 44100 Гц стерео без сжатия в базе postgres/mysql. И что нужно сделать, чтобы проиграть участок с 12 часа по 14ый.

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

7. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +3 +/–

Сообщение от Тупой Груст (?), 25-Май-19, 21:38

Тем, что в таких базах обычно сам временной ряд оптимизирован, как по объёму информации о дате и времени, так и по скорости доступа к последовательным данным (отрезку времени).
Конечно, такое можно сделать и в любой другой базе данных, но проиграешь как по времени создания и интеграции такой базы, так и накладным расходам при эксплуатации таких БД.

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

2. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." –9 +/–

Сообщение от Аноним (2), 25-Май-19, 21:31

> Реализация на языке Go, что обеспечивает компромисс между производительностью и сложностью кода по сравнению с Rust и C++.
Какой-то феерический бред.

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

5. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +12 +/–

Сообщение от anonymous (??), 25-Май-19, 21:37

Какие-то аргументы будут?
Go -- действительно более простой язык, чем C++, имеющий уровень вхождения сильно ниже, чем у Rust, но позволяющий писать вполне производильные приложения, если не нагружать GC.

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

33. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." –6 +/–

Сообщение от InuYasha (?), 26-Май-19, 13:48

"Сложность кода" (фактор, важный для разработчиков) следует читать как "лень разработчиков". Т.е. "компромисс между ленью и производительностью.
В общем, спасибо автору за список конкурентов.

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

39. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +1 +/–

Сообщение от anonymous (??), 26-Май-19, 22:02

> "Сложность кода" (фактор, важный для разработчиков) следует читать как "лень разработчиков"
Нет, "сложность кода" -- это именно "сложность кода".

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

79. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." –1 +/–

Сообщение от qsdg (ok), 20-Июл-19, 03:05

> ... если не нагружать GC.
А не нагружать ГЦ автор этой ВикторияМятрикс умеет хорошо, его https://github.com/valyala/fasthttp не делает вообще аллокаций.

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

30. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +6 +/–

Сообщение от Аноним (28), 26-Май-19, 13:08

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

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

32. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +1 +/–

Сообщение от пох (?), 26-Май-19, 13:23

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

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

37. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +6 +/–

Сообщение от derfenix (ok), 26-Май-19, 17:19

> А танк стоит себе...
А должен ехать...

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

45. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от GentooBoy (ok), 27-Май-19, 11:49

И куда ему ехать?

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

8. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от Аноним (8), 25-Май-19, 23:05

Странно что с RRDTool не сравнивают или они в разных нишах?

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

10. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +2 +/–

Сообщение от Аноним (10), 25-Май-19, 23:11

В разных. В RRD не хранятся сырые значения, а утрамбовываются (аггрегацией и интерполяцией) в заранее отведённые слоты. Да и сотни тысяч—миллионы серий ты с RRD не пособираешь.

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

9. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от vitalif (ok), 25-Май-19, 23:09

Хрен с ним с RRDTool. Где с прометеусом сравнение?

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

17. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от qsdg (ok), 26-Май-19, 04:39

> Хрен с ним с RRDTool. Где с прометеусом сравнение?
Прометей сам по себе только локально может, нода упала и каюк. Поэтому к нему обычно серьёзные пацаны подключают нормальные базы через Remote Storage (я только Танос знаю, но его замахаешься настраивать).
Плюс поддерживает push, а не только pull как Пром.
Но и я так понимаю никто не мешает оставить Пром для скрэпинга, recording rules, alerts итп, а уже хранить/запрашивать данные из VictoriaMetrics. То есь это не замена Прому, а дополнение.

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

22. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от Hagen (??), 26-Май-19, 10:18

Прометеус не поддерживает API на запись данных, что не позволяет "положить" в него идентичный по размеру, природе и кардинальности датасет. Поэтому нельзя добиться честного сравнения.
Кроме того, в Прометеус нельзя писать из нескольких источников, а значит его нельзя использовать в качестве удаленного хранилища.

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

16. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от anonymous (??), 26-Май-19, 00:56

Статья вроде написана автором продукта, но очень скромно (сильно занижая важность продукта), IMHO :)

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

25. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от пох (?), 26-Май-19, 11:55

> Статья вроде написана автором продукта, но очень скромно (сильно занижая важность продукта),
> IMHO :)
это если еще и работает. Кто смелый?

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

27. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от x3who (?), 26-Май-19, 12:49

Выглядит настолько вкусно, что хочется попробовать. Есть у нас одна приблуда для статистики на MySQL со всеми выше описанными проблемами - медленно, трудно маинтейнить и т.д. Правда мне от неё ещё надо кастомные SQL-запросы увязывающие несколько потоков данных, а с этим в VictoriaMetrics вроде сложно. Хотя если есть есть способ быстро дёрнуть данные, например в Постгрес и там анализировать - то тоже сойдет.

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

59. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от valyala (?), 29-Май-19, 14:23

Если под несколькими потоками данных понимаются несколько временных рядов, то PromQL, поддерживаемый VictoriaMetrics, легко позволяет производить вычисления над такими рядами и над группами рядов. См. https://medium.com/@valyala/promql-tutorial-for-beginne...

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

26. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от Аноним_number_X (?), 26-Май-19, 12:15

TimescaleDB - надстройка (extension) над постгресом (MVCC и др., чего отродясь не нужно в timeline DB), дайте угадаю, автор данной статьи объем базы вместе с WAL считал? Но сам его реализовывать не стал? Да на дефолтных настройках, позволяющих мускуль и постгре на калькуляторах запускать? Хех, сравнивать это с реляционками - сильный ход.

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

29. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от x3who (?), 26-Май-19, 13:05

В чем суть претензии - вы хотите сказать, что на самом деле Постгрес лучше подходит для работы с таймлайнами? Или что?

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

31. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от Аноним_number_X (?), 26-Май-19, 13:21

Суть претензии в попытках манипуляции. Автобус лучше Белаза или Белаз лучше автобуса? Или велосипед - лучший выбор?

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

60. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от valyala (?), 29-Май-19, 14:26

Все сравниваемые решения - TimescaleDB, InfluxDB и VictoriaMetrics - позиционируют себя как базы данных для работы с временными рядами (time series databases), так что если тут и присутствует манипуляция, то только со стороны разработчиков конкурирующих решений, выбравших некорректное позиционирование.

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

34. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +1 +/–

Сообщение от x3who (?), 26-Май-19, 14:57

Но задача-то сформулирована - эффективная работа с тайм-сериями. Там важно сколько эти данные занимают на диске и как быстро работает эта система, при этом последнее зависит и от первого тоже.
Т.е., используя вашу аналоги, сравнение идёт что лучше для перевозки больших групп живых людей - Белазы, автобусы или кластеры велосипедов.
Люди загрузили и померяли сколько места на диске оно сожрало после загрузки данных, а мы получили примерное представление о возможных профитах от использования этой БД. По-моему вполне достаточно для общей оценки профитов.

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

35. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от Аноним_number_X (?), 26-Май-19, 16:06

Вот манипуляция и заключается в том, что белаз перевозит 1 водителя, а сколько он соляры жрет!!! Я не утверждаю, что инструмент плох или хорош, констатирую наличие манипуляции. Безвредной, в принципе, но манипуляции, что само по себе должно насторожить. За кластер велосипедов спасибо, от души поржал.

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

41. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от x3who (?), 27-Май-19, 00:18

Так всё зависит от условий - в 40х годах Белаз бы был идеальным средством перемещения пехоты и военнопленных по пересеченной местности. Сегодня даже ОМОН перемещается автобусами, а завтра, когда кончится нефть - потребуются велосипеды для перемещения войск для завоёвывания урановых и литиевых месторождений. Для военных применений машины на литиевых батарейках не очень подходят - ведь литий хорошо воспламеняется и плохо тушится, а вот кластер на велорикшах с горячей заменой вышедших из строя велосипедистов обеспечит оптимальное соотношение производительности к стоимости, к тому же он более устойчив к поражающим факторам ядерных взрывов и систем РЭБ.

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

69. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от Аноним_number_X (?), 29-Май-19, 23:59

"Так всё зависит от условий" - дык, я спорю? Кластер велосипедистов (С) для ядрен батона нужен геораспределенный :), а полуглобус на 4 гусеницах (в Кубинке стоит, кстати) через эпицентр тактического через 30 минут может(ну, должен, по крайней мере) идти. Все от задач зависит, да, опять таки, я не говорю что Х - это плохо или хорошо, не нужно за меня додумывать и переубеждать меня :)

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

42. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." –1 +/–

Сообщение от Аноним (42), 27-Май-19, 01:42

Ещё бы к Заббиксу привинтили поддержку этой СУБД в качестве бэкенда… Эх, мечты.

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

46. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от Andrey Mitrofanov (?), 27-Май-19, 11:58

> Ещё бы к Заббиксу привинтили поддержку этой СУБД в качестве бэкенда… Эх,
> мечты.
Зачем?  Поделитесь подробностями.

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

49. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от пох (?), 27-Май-19, 14:14

> Зачем?  Поделитесь подробностями.
затем что лопнуть он норовит - именно из-за использования sql для задачи, ему не слишком подходящей

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

52. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." –1 +/–

Сообщение от Andrey Mitrofanov_N1 (?), 27-Май-19, 16:58

>> Зачем?  Поделитесь подробностями.
> затем что лопнуть он норовит - именно из-за использования sql для задачи,
> ему не слишком подходящей
А-а-ага.  Ну-да, ну-да.
whistler на пайтоне и субж на го-шечке -- не з-з-здуются?!
А ты, я погляжу, Профессионал.
  Наверное, и RRD-ешечки клиентам торгуешь?
    Слайлики дай списать, дяденька.

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

51. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +1 +/–

Сообщение от пох (?), 27-Май-19, 14:27

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

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

61. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от valyala (?), 29-Май-19, 14:29

Никто не мешает прикрутить VictoriaMetrics в качестве бэкенда к Zabbix - исходники открыты :)

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

68. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +1 +/–

Сообщение от пох. (?), 29-Май-19, 17:45

видели бы вы те исходники (жабикса, в смысле)...

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

70. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от Аноним_number_X (?), 30-Май-19, 00:05

Вот, честно, сам не смотрел, но с удовольствием от нах/пох (кстати, а лох есть? не в обиду, юмор) почитал бы пару строк про как?чество сей СУБД

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

75. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +1 +/–

Сообщение от пох. (?), 30-Май-19, 22:41

> Вот, честно, сам не смотрел, но с удовольствием от нах/пох (кстати, а
> лох есть? не в обиду, юмор) почитал бы пару строк про
> как?чество сей СУБД
я не умею в игого, поэтому оценить именно качество кода не смогу.
А не глядя в код объективную оценку софту давать сложно - у автора любой программы всегда есть индульгенция вида "софта без глюков не бывает", и "подумаешь, ошибка, вот, уже исправили". Поди отличи дейсвительно случайную и трудноуловимую от последствий тяп-ляп кодинга и оптимизаций ценой отказа от проверок.

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

43. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от Аноним (43), 27-Май-19, 07:04

перед тем как что то мониторить надо понять а на куя это мониторить...
та же история с видеослежением - кто на все это смотрит и принимает решение...
один бред (мониторинг всея и всего) порождает второй бред (виктория бреда)

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

50. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от пох (?), 27-Май-19, 14:15

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

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

47. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +1 +/–

Сообщение от GentooBoy (ok), 27-Май-19, 12:04

С Clickhouse сравнивать не стали по очевидным причинам?

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

53. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от anonymous (??), 27-Май-19, 17:57

ClickHouse -- это для другого рода метрик.

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

56. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от Аноним (56), 28-Май-19, 16:28

можно поподробнее ну или линки

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

62. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от valyala (?), 29-Май-19, 14:38

Кликхаус - аналитическая СУБД. Ее можно приспособить для хранения метрик, но это требует некоторых усилий:
- Нужно выбрать оптимальную схему хранения данных.
- Нужно реализовать инвертированный индекс для быстрого поиска по тэгам временных рядов.
По следующей ссылке есть сравнительные тесты производительности ClickHouse в качестве хранилища метрик - https://medium.com/@AltinityDB/clickhouse-for-time-seri... . Если сравнивать производительность с VictoriaMetrics, то на легких запросах VictoriaMetrics работает быстрее, а на тяжелых, которые сканируют десятки миллионов строк, производительность примерно одинакова.

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

54. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от Аноним (54), 27-Май-19, 22:34

Господа, а чем собственно смотреть метрики в Influx есть пусть и подтормаживающий, но работающий в общем случае Chronograf, а здесь мне не понятно совершенно чем залезать в это изделеие и инвестигировать ситуацию.

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

55. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +1 +/–

Сообщение от anonymous (??), 28-Май-19, 00:51

Смотря что нужно. Однако стоит особо отметить grafana -- весьма популярный сервис для визуализации метрик и настройки alert-ов.

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

63. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +1 +/–

Сообщение от valyala (?), 29-Май-19, 14:45

Есть следующие способы просмотра метрик, сохраненных в VictoriaMetrics:
- Строить дашборды в Grafana с помощью датасорса к Prometheus, используя PromQL.
- Использовать Prometheus API, поддерживаемый VictoriaMetrics - https://prometheus.io/docs/prometheus/latest/querying/api/
- Выгружать нужные метрики в сыром виде и потом анализировать удобным для вас способом - https://medium.com/@valyala/analyzing-prometheus-data-w...

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

78. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..." +/–

Сообщение от Аноним (78), 01-Июн-19, 15:00

Интересно, почему с graphite это дело сравнивается так, как будто graphite бесконечно устаревшая и неюзабельная штуковина?

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

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

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

Партнёры:

Хостинг:

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

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

1. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	–15 +/–
Сообщение от Груст (?), 25-Май-19, 21:23
Я тупой. В чем прикол таких баз данных? Чем простая таблица в постгресе или мускуле не угодила?
Ответить \| Правка \| Наверх \| Cообщить модератору


	3. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	+10 +/–
	Сообщение от anonymous (??), 25-Май-19, 21:34
	Скоростью. У нас несколько миллионов метрик под постоянным мониторингом (то есть снимаются новые значения и постоянно рисуются графики на произвольные временные интервалы). И эта штука справляется одним сервером.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	+1 +/–
	Сообщение от anonymous (??), 25-Май-19, 21:35
	P.S.: К тому же для Prometheus, например есть куча написанного ПО для работы с метриками. Просто берёшь и используешь.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	11. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	–9 +/–
	Сообщение от Аноним (11), 25-Май-19, 23:51
	То есть, вы даже не пробовали, а сразу вкорячили стильно-модно-молодежное?
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	12. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	+6 +/–
	Сообщение от anonymous (??), 26-Май-19, 00:24
	Кто вам такое сказал? Уже начинают надоедать вопросы про эти "стильно-модно-молодёжно" от людей, кто, видимо, вообще не занимается high load (иначе откуда такие вопросы?). Отвечая на вопрос: нет, мы пробовали. Вернее, за опыт подобных задач чего только не пробовали. Пробовали и MySQL/PgSQL и нижеупомянутые RRD [которые конкретно тут вообще не к месту], и graphite, и InfluxDB и прочее и прочее, и уже лишь потом чистый Prometheus и VictoriaMetrics (как минимум потому, что Prometheus появился лишь несколько лет назад). Prometheus -- единственный, кто справился с нашими _текущими_ задачами, а VictoriaMetrics работает ещё лучше (жрёт сильно ресурсов).
	Ответить \| Правка \| Наверх \| Cообщить модератору


	14. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	+2 +/–
	Сообщение от anonymous (??), 26-Май-19, 00:38
	P.S.: Но даже если бы и не пробовали, то это не повод отказываться от хорошего решения (такого как Prometheus или VictoriaMetrics). Просто изучите как что работает, изучите задачу, которую решайте, и исходя из этого выбирайте инструменты.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	18. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	+2 +/–
	Сообщение от Ordu (ok), 26-Май-19, 04:42
	> VictoriaMetrics работает ещё лучше (жрёт сильно ресурсов). Не могли бы вы пояснить эту фразу? Она как-то не укладывается в моей голове -- жрёт сильно ресурсов, значит лучше? Может тут ошибка какая вкралась в формулировку? Или имеется в виду "работает ещё лучше, хоть и жрёт сильно ресурсов"?
	Ответить \| Правка \| К родителю #12 \| Наверх \| Cообщить модератору


	19. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	+/–
	Сообщение от Какаянахренразница (ok), 26-Май-19, 06:02
	жрёт сильно меньше ресурсов, не?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	23. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	+1 +/–
	Сообщение от anonymous (??), 26-Май-19, 11:10
	"Жрёт сильно меньше ресурсов", прошу прощения.
	Ответить \| Правка \| К родителю #18 \| Наверх \| Cообщить модератору


	28. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	–1 +/–
	Сообщение от Аноним (28), 26-Май-19, 13:02
	надо было просто сказать: "архи-высочайше меньше" - тогда бы все сразу поняли
	Ответить \| Правка \| Наверх \| Cообщить модератору


	36. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	–1 +/–
	Сообщение от Аноним (36), 26-Май-19, 16:12
	Если сравнивать с прометеусом, то мимо ресурсов cpu/memory, есть ли выигрыш по disk usage? Не проводили замеры?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	57. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	+1 +/–
	Сообщение от valyala (?), 29-Май-19, 14:14
	VictoriaMetrics хорошо жмет данные перед сохранением на диск. Например, в 70 раз лучше, чем TimescaleDB и примерно в 10 раз лучше, чем Prometheus. Вот тут можно почитать, почему так происходит - https://medium.com/@valyala/victoriametrics-achieving-b...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	64. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	–1 +/–
	Сообщение от Andrey Mitrofanov_N0 (?), 29-Май-19, 15:25
	> VictoriaMetrics хорошо жмет данные перед сохранением на диск. Например, в 70 раз > лучше, чем TimescaleDB и примерно в 10 раз лучше, чем Prometheus. > Вот тут можно почитать, почему ойспадя, lha против pkarc-а... детство, дос, велосипедики-паровозики...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	66. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	–1 +/–
	Сообщение от пох. (?), 29-Май-19, 17:36
	> This is 10x times better than 4 bytes per data point for the same data in Prometheus это, чувак, не lha. Это примерно zip против rll compression.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	71. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	+/–
	Сообщение от Andrey Mitrofanov_N0 (?), 30-Май-19, 10:59
	>> This is 10x times better than 4 bytes per data point for the same data in Prometheus > это, чувак, не lha. Это примерно zip против rll compression. Я т-тя умоляю... Чтоб 10ха получить, надо не писать данные на диск часок-другой, или делать запись дважды - полнве несжатые, фактически данные каждую секунду или типа, и пере-сжимать их раз в час или сколько там. Быстро не писать на диск все умеют https://duckduckgo.com/?q=postgresql+running+with+scissors&t... И пересжиманием архивов другим, более модным архиватором, тоже все в детстве баловались. А тут, вищь ты, новый маркетинговый булшит завезли -- time series DB. Новый выпуск "академиков" со свежмим хрустящими дипломами. Слайдики многоцветные, в глазах рябит. Инвестиции -- миллионами. " А не прикрутить ли ОНО к Zabbix-у? Будет же хоро-шоу! Да-а?1 "- вопрошают стада непуганых детей. ...и только мудрый пох знает: забикса уже не спасти, надо успеть продать RRD и 10хе, пока не сдулись.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	73. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	+2 +/–
	Сообщение от valyala (?), 30-Май-19, 14:07
	>>> This is 10x times better than 4 bytes per data point for the same data in Prometheus >> это, чувак, не lha. Это примерно zip против rll compression. > Я т-тя умоляю... Чтоб 10ха получить, надо не писать данные на диск > часок-другой, или делать запись дважды - полнве несжатые, фактически данные каждую > секунду или типа, и пере-сжимать их раз в час или сколько > там. VictoriaMetrics скидывает данные на диск раз в секунду. См. https://medium.com/@valyala/wal-usage-looks-broken-in-m... . Что касается пересжатия, то вы правы - под капотом используются Log-structured merge tree, которая пережимает данные в более крупные блоки - https://medium.com/@valyala/how-victoriametrics-makes-i...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	76. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	+/–
	Сообщение от Andrey Mitrofanov_N0 (?), 31-Май-19, 11:42
	> VictoriaMetrics скидывает данные на диск раз в секунду. См. https://medium.com/@valyala/wal-usage-looks-broken-in-m... > . > Что касается пересжатия, то вы правы - под капотом используются Log-structured merge > tree, которая пережимает данные в более крупные блоки - Аминь. Я уже почти готов "хотеть в Zabbix", как тот Аноним. Но мне, пожалуйста, cstore_fdw переместите куда поближе к основному стору и обычным wal-логам с чекпоинтами (вот, как в Виктории -- с 10икс) -- в PostgreSQL. Мож лет через 3-5 запилят плагины для стораджа, не для "источника данных"... молитвами TimescaleDB, под шумок и инветиции... вот тогда и поглядим. А пока "взрывающийся sql"(c)пох моё продакшен-всё. Партишонинг уже вот-вот почти, шардинг? может быть. TimescaleDB? с дубу рухнул я что ли... И обязательно: на халяву, бесплатно и с поддержкой от _сообщетва_, а не молодых-ранних-проинвестированных single-апстримов. (И да, пока не прибежал тот другой ушибленный -- "бери исходники и паччь" тоже не сюда. спасибо, сам пошёл.)
	Ответить \| Правка \| К родителю #73 \| Наверх \| Cообщить модератору


	13. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	+/–
	Сообщение от пох (?), 26-Май-19, 00:35
	чего там пробовать - количество известно, скорость поступления тоже. Помножить одно на другое и на пару недель хранения - получаем размер базы, вызывающий вопросы, в своем ли уме тот, кто ее такую завел в sql. Причем в нее идут запросы весьма специфического характера - нужны либо все данные за интервал от-до, либо средние на отрезке такой-то длинны от и до, либо не средние, а, например, 90%. И никогда-никогда не понадобится конкретное значение вот в такой вот момент (к тому же его весьма вероятно и вообще нет в базе - есть значение на пол-секунды до, и на пол-секунды после, и какой у них точный тамйстемп - угадать нельзя) отдельно спроси себя, что происходит с такой базой во время housekeeping- то есть удаления ставших ненужными кусков данных - как в этот момент идут инсерты, что происходит с системой хранения и т д. Кому не хватает умишка - ну, судьба громадных инстансов zabbix (который как раз mysql использует вместо tsdb, точнее, до последней версии использовал, сейчас вроде научился, правда, как обычно у авторов, чему-то странному) служит последним предупреждением. Или первым факапом, кому как повезет. Да, они там напихали огромное количество костылей и подпорок, чтобы оно вообще как-то у кого-то работало, но за прошедшие десять лет уже даже его авторам понятно, что идея "компьютеры стали достаточно быстрыми, чтобы обойтись sql'ем" была неудачной (а выбор mysql/postgres с неосиляторством sqlite - неудачным вдвойне).
	Ответить \| Правка \| К родителю #11 \| Наверх \| Cообщить модератору


	20. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	+/–
	Сообщение от qsdg (ok), 26-Май-19, 07:37
	> И никогда-никогда не понадобится конкретное значение вот в такой вот момент Насколько я помню, создатели Victoria Metrics утверждали, что у них как раз можно будет вытянуть сырые данные, а не как у дефолтного Prometheus. Я когда его только поставил, никак не мог понять почему у меня метрики получаются "пилой", ибо я сделал стандартную ошибку новичков в Prometheus -- запрашивал данные с таким же resolution как и scrape_interval. Эти вроде обещали что такого не будет, хотя я ещё не пробовал.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	21. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	+/–
	Сообщение от DeadLoco (ok), 26-Май-19, 07:55
	Это потому, что 95% не слыхивали о теореме Котельникова.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	40. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	+/–
	Сообщение от А (??), 26-Май-19, 23:32
	А можно подробнее, в применении к системам мониторинга?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	24. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	+/–
	Сообщение от пох (?), 26-Май-19, 11:54
	речь была не об этом - речь о том что select .. where timestamp=чемубытонибыло - под что хорошо оптимизированы sql-базы - вообще не может использоваться с tsdb (даже имитируемой sql'ем) - потому что никто не обещал что такой вообще в базе будет, и когда юзер просит "покажи мне счетчик в момент X", он на самом деле имеет в виду - "покажи мне среднее между наиболее близкими к моменту X отсчетами". хранение сырых данных тут не очень поможет, если только они не снабжены метками сами по себе - что нынче немодно-немолодежно. Да и смысла особенного не имеет - приезжает у тебя разом 300 метрик, все выплюнуты приложением по какому-то конкретному поводу, нафига 300 времен сохранять, когда оно одно ровно на всех. Виктория, конечно, упакует, так что лишнего места не сожрется, но смысла в этом нет. Опять таки нормализованные формы хранения для tsdb не нужны - поскольку у данных из разных метрик ровно одна общая точка - тот самый тамймстемп. Короче, совсем на sql не похоже. Просто лет десять-пятнадцать назад некоторые авторы некоторых мониторилок напрасно решили что компьютеры уже достаточно мощные и можно обойтись sql'ем. Оказалось, компьютеры еще и генерят теперь на несколько порядков больше мусора, и обойтись по прежнему получается плохо.
	Ответить \| Правка \| К родителю #20 \| Наверх \| Cообщить модератору


	58. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	+/–
	Сообщение от valyala (?), 29-Май-19, 14:17
	VictoriaMetrics поддерживает возможность получить сырые данные - см. https://medium.com/@valyala/analyzing-prometheus-data-w...
	Ответить \| Правка \| К родителю #20 \| Наверх \| Cообщить модератору


	65. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	–1 +/–
	Сообщение от Andrey Mitrofanov_N0 (?), 29-Май-19, 15:41
	> Кому не хватает умишка - ну, судьба громадных инстансов zabbix (который как > раз mysql Чего там у них с Судьбой-то? Яндекс со слоникомвдоме замучали насмерть?.... >использует вместо tsdb, точнее, до последней версии использовал, сейчас > вроде научился, правда, как обычно у авторов, чему-то странному) служит последним > предупреждением. Или первым факапом, кому как повезет. А конкретнее? Апокалипс -- сегодня и каждый вечер на арене? > Да, они там напихали огромное количество костылей и подпорок, чтобы оно вообще > как-то у кого-то работало, но за прошедшие десять лет уже даже > его авторам понятно, что идея "компьютеры стали достаточно быстрыми, чтобы обойтись > sql'ем" была неудачной (а выбор mysql/postgres с неосиляторством sqlite - неудачным > вдвойне). Ага, Вы я вижу знакомы с Авторами. Пригласите их сюда, пусть сами за себя, ладно? "" Мускул умер, посгре умер, сиквел умер... Всех их задавил пох своей жирной #zabbix. "" Продолжай про "...бороздят просторы Большого Театра". ///"" -- А вдоль дорог мёртвые с косами -- стоять! -- Б----я-а. ""
	Ответить \| Правка \| К родителю #13 \| Наверх \| Cообщить модератору


	67. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	+/–
	Сообщение от пох. (?), 29-Май-19, 17:41
	> Ага, Вы я вижу знакомы с Авторами. я, в отличие от некоторых, слишком хорошо знаком с их поделкой - включая поиски "где ж эта тварь в очередной раз помножилась на ноль" (прекрасный сишный спагетти-код с миллиардом не проверяемых указателей-параметров - это они называют "оптимизацией") и "как перенести 600 автодискаверимых айтимов вместе с историей и автопоиском с одного хоста на другой - поскольку приложение, внезапно, переехало, кто бы мог подумать, что так бывает!" (прекрасный веб-интерфейс, который этого не умеет, и прекрасная структура базы данных, не документированная в принципе)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	72. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	–1 +/–
	Сообщение от Andrey Mitrofanov_N0 (?), 30-Май-19, 11:05
	>> Ага, Вы я вижу знакомы с Авторами. > я, в отличие от некоторых, слишком хорошо знаком с их поделкой - То есть про авторов - "" но за прошедшие десять лет уже даже его авторам понятно, что идея "компьютеры стали достаточно быстрыми, чтобы обойтись sql'ем" была неудачной (а выбор "" - этт Вы разговаривали за других? > (прекрасный веб-интерфейс, который этого не умеет, и прекрасная структура базы данных, > не документированная в принципе) Это прекрасно. Да-да, конечно. Продолжайте бороздить посторы Большого.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	74. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	–1 +/–
	Сообщение от пох. (?), 30-Май-19, 22:23
	> То есть про авторов - > "" но за прошедшие десять лет уже даже его авторам понятно, что > - этт Вы разговаривали за других? это очевидный вывод из их (не особо удачной) попытки таки добавить tsdb в последнюю версию. >> (прекрасный веб-интерфейс, который этого не умеет, и прекрасная структура базы данных, >> не документированная в принципе) > Это прекрасно. Да-да, конечно. Продолжайте бороздить посторы Большого. продолжайте извлекать информацию из астрала, ага. Главное. ни в коем случае не пытайтесь пользоваться - а то внезапно полученные знания реального мира могут ненароком разрушить ваш розовый мирок.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	77. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	–2 +/–
	Сообщение от Andrey Mitrofanov_N0 (?), 31-Май-19, 11:54
	>> То есть про авторов - >> "" но за прошедшие десять лет уже даже его авторам понятно, что >> - этт Вы разговаривали за других? > это очевидный вывод из их (не особо удачной) попытки таки добавить tsdb > в последнюю версию. Автоаночо. А то же я подумал, что у тебя мускулы в докерах "взрываются"(тм), а это оказывается.... ....неудачи авторов с тсдб -- твой сиквел порвали. В клочья, да. " Это забикс виноват "-частушка.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	38. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	+1 +/–
	Сообщение от Онаним (?), 26-Май-19, 17:58
	У меня по сути только один вопрос: сколько человек смотрят ежедневно ваши миллионы метрик, и сколько метрик они успевают посмотреть за год? :D Не троллю, просто интересна нужность всего этого.
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	44. "Открыт код VictoriaMetrics, СУБД для временных рядов, совмес..."	+/–
	Сообщение от Аноним (44), 27-Май-19, 11:12
	Так это может не для человека нужно. Для ИИ или каких-то процессов моделирования или "алармических" алгоритмов. А человек уже выжимку после этого "чего-то" получает - "пока все нормально" или "срочно подними графитовые стержни или сиди я сам подниму, у нас возникла неприятная тенденция" или "скидывай срочно эти поганые биткоины!"
	Ответить \| Правка \| Наверх \| Cообщить модератору