The OpenNET Project / Index page

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

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

25.05.2019 17:52

Открыты исходные тексты VictoriaMetrics - быстрой и масштабируемой СУБД для хранения и обработки данных в форме временного ряда (запись образует время и набор соответствующих этому времени значений, например, полученных через периодический опрос состояния датчиков или сбор метрик). Проект конкурирует с такими решениями, как InfluxDB, TimescaleDB, Thanos, Cortex и Uber M3. Код написан на языке Go и распространяется под лицензией Apache 2.0.

Преимущества и особенности VictoriaMetrics:

  • Простота эксплуатации. СУБД представляет из себя один исполняемый файл с минимальными настройками, передающимися через командную строку при запуске. Все данные хранятся в одном каталоге, заданном при запуске при помощи флага "-storageDataPath";
  • Поддержка языка запросов PromQL, используемого в системе мониторинга Prometheus. Поддерживаются подзапросы и некоторые расширенные возможности, такие как выражение "offset", шаблоны внутри "WIDTH", операторы "if" и "default", дополнительные функции и возможность включения комментариев;
  • Возможность использования в качестве долговременного хранилища данных, подключенного к Prometheus и Grafana.
  • Наличие режима обратного заполнения для загрузки исторических данных;
  • Поддержка различных протоколов передачи данных, включая Prometheus API, Influx, Graphite и OpenTSDB. В том числе VictoriaMetrics может применяться в качестве прозрачной замены InfluxDB и может работать с совместимыми с InfluxDB коллекторами, такими как Telegraf;
  • Высокая производительность и низкое потребление ресурсов по сравнению с конкурирующими системами. В некоторых тестах VictoriaMetrics опережает InfluxDB и TimescaleDB при выполнение операций вставки и выборки данных до 20 раз. При выполнении аналитических запросов выигрыш по сравнению с реляционными СУБД PostgreSQL и MySQL может составлять от 10 до 1000 раз.



  • Имеется возможность обработки очень большого числа уникальных временных рядов. При обработке миллионов разных временных рядов VictoriaMetrics потребляет до 10 раз меньше ОЗУ, чем InfluxDB.
  • Высокая степень сжатия данных в дисковом хранилище. VictoriaMetrics по сравнению с TimescaleDB может уместить в том же объёме хранилища до 70 раз больше записей;
  • Наличие оптимизаций для хранилищ с большими задержками и низкой интенсивностью операций ввода/вывода (например, жёсткие диски и облачные хранилища AWS, Google Cloud и Microsoft Azure);
  • Простая система резервного копирования на основе снапшотов;
  • Наличие средств для защиты целостности хранилища от повреждений данных, например, при экстренном отключении питания (хранилище имеет форму журнально-структурированного дерева со слиянием);
  • Реализация на языке Go, что обеспечивает компромисс между производительностью и сложностью кода по сравнению с Rust и C++.
  • Предоставляются исходные коды кластерной версий, которая поддерживает горизонтальное масштабирование на несколько серверов и демонстрирует низкие накладные расходы. Имеются средства обеспечения высокой доступности.


  1. Главная ссылка к новости (https://blog.usejournal.com/op...)
  2. OpenNews: Выпуск СУБД TimescaleDB 1.2
  3. OpenNews: Выпуск распределённой СУБД TiDB 2.0
  4. OpenNews: Стабильный релиз СУБД FoundationDB 6.0, развиваемой компанией Apple
  5. OpenNews: Выпуск PipelineDB 1.0.0, надстройки к PostgreSQL для непрерывной обработки потоков
  6. OpenNews: Доступна СУБД InfluxDB 1.1
Автор новости: valyala
Тип: Программы
Ключевые слова: prometheus, victoriametrics, database
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (72) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Груст (?), 21:23, 25/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –14 +/
    Я тупой. В чем прикол таких баз данных? Чем простая таблица в постгресе или мускуле не угодила?
     
     
  • 2.3, anonymous (??), 21:34, 25/05/2019 [^] [^^] [^^^] [ответить]  
  • +10 +/
    Скоростью.

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

     
     
  • 3.4, anonymous (??), 21:35, 25/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    P.S.:

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

     
  • 3.11, Аноним (11), 23:51, 25/05/2019 [^] [^^] [^^^] [ответить]  
  • –8 +/
    То есть, вы даже не пробовали, а сразу вкорячили стильно-модно-молодежное?
     
     
  • 4.12, anonymous (??), 00:24, 26/05/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Кто вам такое сказал? Уже начинают надоедать вопросы про эти "стильно-модно-молодёжно" от людей, кто, видимо, вообще не занимается high load (иначе откуда такие вопросы?).

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

     
     
  • 5.14, anonymous (??), 00:38, 26/05/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    P.S.: Но даже если бы и не пробовали, то это не повод отказываться от хорошего решения (такого как Prometheus или VictoriaMetrics). Просто изучите как что работает, изучите задачу, которую решайте, и исходя из этого выбирайте инструменты.
     
  • 5.18, Ordu (ok), 04:42, 26/05/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > VictoriaMetrics работает ещё лучше (жрёт сильно ресурсов).

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

     
     
  • 6.19, Какаянахренразница (ok), 06:02, 26/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    жрёт сильно меньше ресурсов, не?
     
  • 6.23, anonymous (??), 11:10, 26/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    "Жрёт сильно меньше ресурсов", прошу прощения.
     
     
  • 7.28, Аноним (28), 13:02, 26/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    надо было просто сказать: "архи-высочайше меньше" - тогда бы все сразу поняли
     
     
  • 8.36, Аноним (36), 16:12, 26/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Если сравнивать с прометеусом, то мимо ресурсов cpu memory, есть ли выигрыш по d... текст свёрнут, показать
     
     
  • 9.57, valyala (?), 14:14, 29/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    VictoriaMetrics хорошо жмет данные перед сохранением на диск Например, в 70 раз... текст свёрнут, показать
     
     
  • 10.64, Andrey Mitrofanov_N0 (?), 15:25, 29/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ойспадя, lha против pkarc-а детство, дос, велосипедики-паровозики ... текст свёрнут, показать
     
     
  • 11.66, пох. (?), 17:36, 29/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    это, чувак, не lha Это примерно zip против rll compression ... текст свёрнут, показать
     
     
  • 12.71, Andrey Mitrofanov_N0 (?), 10:59, 30/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Я т-тя умоляю Чтоб 10ха получить, надо не писать данные на диск часок-другой,... текст свёрнут, показать
     
     
  • 13.73, valyala (?), 14:07, 30/05/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    VictoriaMetrics скидывает данные на диск раз в секунду См https medium com ... текст свёрнут, показать
     
     
  • 14.76, Andrey Mitrofanov_N0 (?), 11:42, 31/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Аминь Я уже почти готов хотеть в Zabbix , как тот Аноним Но мне, пожалуйста,... текст свёрнут, показать
     
  • 4.13, пох (?), 00:35, 26/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    чего там пробовать - количество известно, скорость поступления тоже.
    Помножить одно на другое и на пару недель хранения - получаем размер базы, вызывающий вопросы, в своем ли уме тот, кто ее такую завел в sql. Причем в нее идут запросы весьма специфического характера - нужны либо все данные за интервал от-до, либо средние на отрезке такой-то длинны от и до, либо не средние, а, например, 90%. И никогда-никогда не понадобится конкретное значение вот в такой вот момент (к тому же его весьма вероятно и вообще нет в базе - есть значение на пол-секунды до, и на пол-секунды после, и какой у них точный тамйстемп - угадать нельзя)

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

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


     
     
  • 5.20, qsdg (ok), 07:37, 26/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > И никогда-никогда не понадобится конкретное значение вот в такой вот момент

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

     
     
  • 6.21, DeadLoco (ok), 07:55, 26/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это потому, что 95% не слыхивали о теореме Котельникова.
     
     
  • 7.40, А (??), 23:32, 26/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А можно подробнее, в применении к системам мониторинга?
     
  • 6.24, пох (?), 11:54, 26/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    речь была не об этом - речь о том что select .. where timestamp=чемубытонибыло - под что хорошо оптимизированы sql-базы - вообще не может использоваться с tsdb (даже имитируемой sql'ем) - потому что никто не обещал что такой вообще в базе будет, и когда юзер просит "покажи мне счетчик в момент X", он на самом деле имеет в виду - "покажи мне среднее между наиболее близкими к моменту X отсчетами".

    хранение сырых данных тут не очень поможет, если только они не снабжены метками сами по себе - что нынче немодно-немолодежно. Да и смысла особенного не имеет - приезжает у тебя разом 300 метрик, все выплюнуты приложением по какому-то конкретному поводу, нафига 300 времен сохранять, когда оно одно ровно на всех.
    Виктория, конечно, упакует, так что лишнего места не сожрется, но смысла в этом нет. Опять таки нормализованные формы хранения для tsdb не нужны - поскольку у данных из разных метрик ровно одна общая точка - тот самый тамймстемп.

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

     
  • 6.58, valyala (?), 14:17, 29/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    VictoriaMetrics поддерживает возможность получить сырые данные - см. https://medium.com/@valyala/analyzing-prometheus-data-with-external-tools
     
  • 5.65, Andrey Mitrofanov_N0 (?), 15:41, 29/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Кому не хватает умишка - ну, судьба громадных инстансов zabbix (который как
    > раз mysql

    Чего там у них с Судьбой-то?  Яндекс со слоникомвдоме замучали насмерть?....

    >использует вместо tsdb, точнее, до последней версии использовал, сейчас
    > вроде научился, правда, как обычно у авторов, чему-то странному) служит последним
    > предупреждением. Или первым факапом, кому как повезет.

    А конкретнее?

    Апокалипс -- сегодня и каждый вечер на арене?

    > Да, они там напихали огромное количество костылей и подпорок, чтобы оно вообще
    > как-то у кого-то работало, но за прошедшие десять лет уже даже
    > его авторам понятно, что идея "компьютеры стали достаточно быстрыми, чтобы обойтись
    > sql'ем" была неудачной (а выбор mysql/postgres с неосиляторством sqlite - неудачным
    > вдвойне).

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

    "" Мускул умер, посгре умер, сиквел умер...  Всех их задавил пох своей жирной #zabbix. ""  Продолжай про "...бороздят просторы Большого Театра".

    ///"" -- А вдоль дорог мёртвые с косами -- стоять!  -- Б----я-а. ""

     
     
  • 6.67, пох. (?), 17:41, 29/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Ага, Вы я вижу знакомы с Авторами.

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



     
     
  • 7.72, Andrey Mitrofanov_N0 (?), 11:05, 30/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Ага, Вы я вижу знакомы с Авторами.
    > я, в отличие от некоторых, слишком хорошо знаком с их поделкой -

    То есть про авторов -

    "" но за прошедшие десять лет уже даже его авторам понятно, что идея "компьютеры стали достаточно быстрыми, чтобы обойтись sql'ем" была неудачной (а выбор ""

    - этт Вы разговаривали за других?

    > (прекрасный веб-интерфейс, который этого не умеет, и прекрасная структура базы данных,
    > не документированная в принципе)

    Это прекрасно.  Да-да, конечно.  Продолжайте бороздить посторы Большого.


     
     
  • 8.74, пох. (?), 22:23, 30/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    это очевидный вывод из их не особо удачной попытки таки добавить tsdb в послед... текст свёрнут, показать
     
     
  • 9.77, Andrey Mitrofanov_N0 (?), 11:54, 31/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Автоаночо А то же я подумал, что у тебя мускулы в докерах взрываются тм , а ... текст свёрнут, показать
     
  • 3.38, Онаним (?), 17:58, 26/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У меня по сути только один вопрос: сколько человек смотрят ежедневно ваши миллионы метрик, и сколько метрик они успевают посмотреть за год? :D Не троллю, просто интересна нужность всего этого.
     
     
  • 4.44, Аноним (44), 11:12, 27/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Так это может не для человека нужно. Для ИИ или каких-то процессов моделирования или "алармических" алгоритмов. А человек уже выжимку после этого "чего-то" получает - "пока все нормально" или "срочно подними графитовые стержни или сиди я сам подниму, у нас возникла неприятная тенденция" или "скидывай срочно эти поганые биткоины!"
     
  • 4.48, пох (?), 14:04, 27/05/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    например - ноль. Но если что-то начинает вести себя странно - открывают связанный с проблемным местом набор (где далеко не миллионы)  и сравнивает состояние на сейчас с состоянием на прошлый понедельник.
    Это много проще, чем пытаться такую оценку состояния системы автоматизировать.

     
  • 2.6, Грустный Ёжик (?), 21:38, 25/05/2019 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Это специфический тип данных. Хранить его в обычном sql крайне неэффективно.
    Хороший пример временного ряда-- оцифрованный звук. Представьте, что кто-то решил хранить 16 бит 44100 Гц стерео без сжатия в базе postgres/mysql. И что нужно сделать, чтобы проиграть участок с 12 часа по 14ый.
     
  • 2.7, Тупой Груст (?), 21:38, 25/05/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Тем, что в таких базах обычно сам временной ряд оптимизирован, как по объёму информации о дате и времени, так и по скорости доступа к последовательным данным (отрезку времени).

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

     

  • 1.2, Аноним (2), 21:31, 25/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –11 +/
    > Реализация на языке Go, что обеспечивает компромисс между производительностью и сложностью кода по сравнению с Rust и C++.

    Какой-то феерический бред.

     
     
  • 2.5, anonymous (??), 21:37, 25/05/2019 [^] [^^] [^^^] [ответить]  
  • +12 +/
    Какие-то аргументы будут?

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

     
     
  • 3.33, InuYasha (?), 13:48, 26/05/2019 [^] [^^] [^^^] [ответить]  
  • –6 +/
    "Сложность кода" (фактор, важный для разработчиков) следует читать как "лень разработчиков". Т.е. "компромисс между ленью и производительностью.

    В общем, спасибо автору за список конкурентов.

     
     
  • 4.39, anonymous (??), 22:02, 26/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > "Сложность кода" (фактор, важный для разработчиков) следует читать как "лень разработчиков"

    Нет, "сложность кода" -- это именно "сложность кода".

     
  • 2.30, Аноним (28), 13:08, 26/05/2019 [^] [^^] [^^^] [ответить]  
  • +7 +/
    > Какой-то феерический бред.

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

     
     
  • 3.32, пох (?), 13:23, 26/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    но что характерно - через следующие пять лет никто уже не помнит никакое игого и все увлечены чем-то новым и прекрасным, и все так же скачут по поляне.
    А танк стоит себе...

     
     
  • 4.37, derfenix (ok), 17:19, 26/05/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > А танк стоит себе...

    А должен ехать...

     
     
  • 5.45, GentooBoy (ok), 11:49, 27/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    И куда ему ехать?
     

  • 1.8, Аноним (8), 23:05, 25/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Странно что с RRDTool не сравнивают или они в разных нишах?
     
     
  • 2.10, Аноним (10), 23:11, 25/05/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    В разных. В RRD не хранятся сырые значения, а утрамбовываются (аггрегацией и интерполяцией) в заранее отведённые слоты. Да и сотни тысяч—миллионы серий ты с RRD не пособираешь.
     

  • 1.9, vitalif (ok), 23:09, 25/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хрен с ним с RRDTool. Где с прометеусом сравнение?
     
     
  • 2.17, qsdg (ok), 04:39, 26/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Хрен с ним с RRDTool. Где с прометеусом сравнение?

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

    Плюс поддерживает push, а не только pull как Пром.

    Но и я так понимаю никто не мешает оставить Пром для скрэпинга, recording rules, alerts итп, а уже хранить/запрашивать данные из VictoriaMetrics. То есь это не замена Прому, а дополнение.

     
  • 2.22, Hagen (??), 10:18, 26/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Прометеус не поддерживает API на запись данных, что не позволяет "положить" в него идентичный по размеру, природе и кардинальности датасет. Поэтому нельзя добиться честного сравнения.
    Кроме того, в Прометеус нельзя писать из нескольких источников, а значит его нельзя использовать в качестве удаленного хранилища.
     

  • 1.16, anonymous (??), 00:56, 26/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Статья вроде написана автором продукта, но очень скромно (сильно занижая важность продукта), IMHO :)
     
     
  • 2.25, пох (?), 11:55, 26/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Статья вроде написана автором продукта, но очень скромно (сильно занижая важность продукта),
    > IMHO :)

    это если еще и работает. Кто смелый?

     
     
  • 3.27, x3who (?), 12:49, 26/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Выглядит настолько вкусно, что хочется попробовать. Есть у нас одна приблуда для статистики на MySQL со всеми выше описанными проблемами - медленно, трудно маинтейнить и т.д. Правда мне от неё ещё надо кастомные SQL-запросы увязывающие несколько потоков данных, а с этим в VictoriaMetrics вроде сложно. Хотя если есть есть способ быстро дёрнуть данные, например в Постгрес и там анализировать - то тоже сойдет.
     
     
  • 4.59, valyala (?), 14:23, 29/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Если под несколькими потоками данных понимаются несколько временных рядов, то PromQL, поддерживаемый VictoriaMetrics, легко позволяет производить вычисления над такими рядами и над группами рядов. См. https://medium.com/@valyala/promql-tutorial-for-beginners-9ab455142085
     

  • 1.26, Аноним_number_X (?), 12:15, 26/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    TimescaleDB - надстройка (extension) над постгресом (MVCC и др., чего отродясь не нужно в timeline DB), дайте угадаю, автор данной статьи объем базы вместе с WAL считал? Но сам его реализовывать не стал? Да на дефолтных настройках, позволяющих мускуль и постгре на калькуляторах запускать? Хех, сравнивать это с реляционками - сильный ход.
     
     
  • 2.29, x3who (?), 13:05, 26/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В чем суть претензии - вы хотите сказать, что на самом деле Постгрес лучше подходит для работы с таймлайнами? Или что?
     

  • 1.31, Аноним_number_X (?), 13:21, 26/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Суть претензии в попытках манипуляции. Автобус лучше Белаза или Белаз лучше автобуса? Или велосипед - лучший выбор?
     
     
  • 2.60, valyala (?), 14:26, 29/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Все сравниваемые решения - TimescaleDB, InfluxDB и VictoriaMetrics - позиционируют себя как базы данных для работы с временными рядами (time series databases), так что если тут и присутствует манипуляция, то только со стороны разработчиков конкурирующих решений, выбравших некорректное позиционирование.
     

  • 1.34, x3who (?), 14:57, 26/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Но задача-то сформулирована - эффективная работа с тайм-сериями. Там важно сколько эти данные занимают на диске и как быстро работает эта система, при этом последнее зависит и от первого тоже.

    Т.е., используя вашу аналоги, сравнение идёт что лучше для перевозки больших групп живых людей - Белазы, автобусы или кластеры велосипедов.

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

     
     
  • 2.35, Аноним_number_X (?), 16:06, 26/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вот манипуляция и заключается в том, что белаз перевозит 1 водителя, а сколько он соляры жрет!!! Я не утверждаю, что инструмент плох или хорош, констатирую наличие манипуляции. Безвредной, в принципе, но манипуляции, что само по себе должно насторожить. За кластер велосипедов спасибо, от души поржал.
     

  • 1.41, x3who (?), 00:18, 27/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Так всё зависит от условий - в 40х годах Белаз бы был идеальным средством перемещения пехоты и военнопленных по пересеченной местности. Сегодня даже ОМОН перемещается автобусами, а завтра, когда кончится нефть - потребуются велосипеды для перемещения войск для завоёвывания урановых и литиевых месторождений. Для военных применений машины на литиевых батарейках не очень подходят - ведь литий хорошо воспламеняется и плохо тушится, а вот кластер на велорикшах с горячей заменой вышедших из строя велосипедистов обеспечит оптимальное соотношение производительности к стоимости, к тому же он более устойчив к поражающим факторам ядерных взрывов и систем РЭБ.
     
     
  • 2.69, Аноним_number_X (?), 23:59, 29/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    "Так всё зависит от условий" - дык, я спорю? Кластер велосипедистов (С) для ядрен батона нужен геораспределенный :), а полуглобус на 4 гусеницах (в Кубинке стоит, кстати) через эпицентр тактического через 30 минут может(ну, должен, по крайней мере) идти. Все от задач зависит, да, опять таки, я не говорю что Х - это плохо или хорошо, не нужно за меня додумывать и переубеждать меня :)
     

  • 1.42, Аноним (42), 01:42, 27/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Ещё бы к Заббиксу привинтили поддержку этой СУБД в качестве бэкенда… Эх, мечты.
     
     
  • 2.46, Andrey Mitrofanov (?), 11:58, 27/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Ещё бы к Заббиксу привинтили поддержку этой СУБД в качестве бэкенда… Эх,
    > мечты.

    Зачем?  Поделитесь подробностями.

     
     
  • 3.49, пох (?), 14:14, 27/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Зачем?  Поделитесь подробностями.

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

     
     
  • 4.52, Andrey Mitrofanov_N1 (?), 16:58, 27/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Зачем?  Поделитесь подробностями.
    > затем что лопнуть он норовит - именно из-за использования sql для задачи,
    > ему не слишком подходящей

    А-а-ага.  Ну-да, ну-да.

    whistler на пайтоне и субж на го-шечке -- не з-з-здуются?!

    А ты, я погляжу, Профессионал.
      Наверное, и RRD-ешечки клиентам торгуешь?
        Слайлики дай списать, дяденька.

     
  • 2.51, пох (?), 14:27, 27/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    поддержку какой-то tsdb к 4.2 приделали - поддержку прометеуса тоже приделали, но, естественно, только чтения, поскольку другого внешнего апи в нем и не предусмотрено.

    насколько оно работоспособное - вот вы нам и рассказывайте.

     
  • 2.61, valyala (?), 14:29, 29/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Никто не мешает прикрутить VictoriaMetrics в качестве бэкенда к Zabbix - исходники открыты :)
     
     
  • 3.68, пох. (?), 17:45, 29/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    видели бы вы те исходники (жабикса, в смысле)...

     
     
  • 4.70, Аноним_number_X (?), 00:05, 30/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вот, честно, сам не смотрел, но с удовольствием от нах/пох (кстати, а лох есть? не в обиду, юмор) почитал бы пару строк про как?чество сей СУБД
     
     
  • 5.75, пох. (?), 22:41, 30/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вот, честно, сам не смотрел, но с удовольствием от нах/пох (кстати, а
    > лох есть? не в обиду, юмор) почитал бы пару строк про
    > как?чество сей СУБД

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

     

  • 1.43, Аноним (43), 07:04, 27/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    перед тем как что то мониторить надо понять а на куя это мониторить...
    та же история с видеослежением - кто на все это смотрит и принимает решение...
    один бред (мониторинг всея и всего) порождает второй бред (виктория бреда)
     
     
  • 2.50, пох (?), 14:15, 27/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > та же история с видеослежением - кто на все это смотрит и принимает решение...

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

     

  • 1.47, GentooBoy (ok), 12:04, 27/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    С Clickhouse сравнивать не стали по очевидным причинам?
     
     
  • 2.53, anonymous (??), 17:57, 27/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ClickHouse -- это для другого рода метрик.
     
     
  • 3.56, Аноним (56), 16:28, 28/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    можно поподробнее ну или линки
     
  • 2.62, valyala (?), 14:38, 29/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Кликхаус - аналитическая СУБД. Ее можно приспособить для хранения метрик, но это требует некоторых усилий:

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

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

     

  • 1.54, Аноним (54), 22:34, 27/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Господа, а чем собственно смотреть метрики в Influx есть пусть и подтормаживающий, но работающий в общем случае Chronograf, а здесь мне не понятно совершенно чем залезать в это изделеие и инвестигировать ситуацию.
     
     
  • 2.55, anonymous (??), 00:51, 28/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Смотря что нужно. Однако стоит особо отметить grafana -- весьма популярный сервис для визуализации метрик и настройки alert-ов.
     
  • 2.63, valyala (?), 14:45, 29/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Есть следующие способы просмотра метрик, сохраненных в VictoriaMetrics:

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

     

  • 1.78, Аноним (78), 15:00, 01/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно, почему с graphite это дело сравнивается так, как будто graphite бесконечно устаревшая и неюзабельная штуковина?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    MIRhosting
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

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