The OpenNET Project / Index page

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

Выпуск VictoriaMetrics 1.94, СУБД для построения систем мониторинга

05.10.2023 12:05

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

В тестах производительности VictoriaMetrics опережает InfluxDB и TimescaleDB при выполнение операций вставки и выборки данных до 20 раз, потребляя при этом в 10 раз меньше ОЗУ, чем InfluxDB и в 7 раз меньше, чем Prometheus, Thanos и Cortex при обработке миллионов уникальных временных рядов. Хранение данных в сжатом виде позволяет уместить в том же объёме хранилища в 7 раз больше записей по сравнению с Prometheus, Thanos и Cortex, и в 70 раз - по сравнению с TimescaleDB. Имеются специфичные оптимизации для хранилищ с большими задержками и низкой интенсивностью операций ввода/вывода (например, жёсткие диски и облачные хранилища AWS, Google Cloud и Microsoft Azure).

СУБД оформлена в виде одного исполняемого файла с минимальными настройками, передающимися через командную строку при запуске. Все данные хранятся в одном каталоге, заданном при запуске при помощи флага "-storageDataPath". В качестве языка запросов используется MetricsQL, расширенный вариант языка PromQL, применяемого в системе мониторинга Prometheus. Кроме непрерывной обработки поступающих данных в VictoriaMetrics также предусмотрена возможность загрузки ранее собранных исторических данных.

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

Среди добавленных в новом выпуске новшеств:

  • В MetricsQL для наглядности разрешено разделение чисел подчёркиванием (например, можно указывать 1_234_567_890 и 1.234_567_890 вместо 1234567890 и 1.234567890).
  • В vmbackup добавлена поддержка оставления на сервере копий созданных бэкапов.
  • В интерфейсе vmui добавлена опция для показа 25 последних запросов. На страницу "Explore cardinality" добавлена поддержка экспорта данных в Prometheus. Добавлена кнопка для автоматического форматирования запросов PromQL/MetricsQL. Повышена наглядность диаграмм. В localStorage добавлено хранилище истории запросов.
  • В vmagent расширены возможности управления узлами кластера, улучшена обработка ошибок и снижена нагрузка на управляющую панель Kubernetes при начальном обнаружении сервиса.
  • В кластере с 60 до 3 секунд сокращено максимально допустимое время восстановления при выполнении операций vmselect и vminsert, в ситуации, когда недоступны некоторые узлы vmstorage.

Отдельно можно отметить проведение сегодня в 19 часов по московскому времени виртуальной конференции, на которой разработчики VictoriaMetrics познакомят с новыми возможностями проекта и планами по развитию, расскажут об управлении платформой и выявлении аномалий, а также поделятся сведениями о развитии открытой СУБД для ведения логов VictoriaLogs. В завершении на мероприятии будет секция ответов на вопросы.



  1. Главная ссылка к новости (https://github.com/VictoriaMet...)
  2. OpenNews: Выпуск системы мониторинга Zabbix 6.0 LTS
  3. OpenNews: Открыт код VictoriaMetrics, СУБД для временных рядов, совместимой с Prometheus
  4. OpenNews: Представлена СУБД InfluxDB 1.0
  5. OpenNews: Релиз системы сбора и визуализации метрик Graphite 1.0.0
  6. OpenNews: Выпуск СУБД TimescaleDB 2.0
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/59875-victoriametrics
Ключевые слова: victoriametrics
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (94) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, InuYasha (??), 12:31, 05/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –15 +/
    > СУБД
    > Код написан на языке Go

    Меня чувство некоторого диссонанса.

     
     
  • 2.4, Массоны Рептилоиды (?), 13:08, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +12 +/
    И что? Прометей тоже на Go.
    Если это у тебя вызывает диссонанс, то почитай про Datomic или Neo4j, впадёшь в глубокую депрессию
     
     
  • 3.20, InuYasha (??), 16:43, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • –11 +/
    > И что? Прометей тоже на Go.

    Аргумент Поехавшего #3: "ну, свиньи же жрут своё говно - ну а что?".

    Так что, я не впадаю в депрессию, я пополняю список ненужного. Хотя, уже проще содержать список нужного.

     
     
  • 4.26, Аноним (26), 17:12, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +8 +/
    У вас какая-то нездоровая зацикленность на фекалиях и их поедании.
     
  • 4.27, OpenEcho (?), 17:17, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >...Хотя, уже проще содержать список нужного.

    Вот это "правильное" решение, только святой Бейсик, хотя нет, добавь еще в список нужного https://scratch.mit.edu/


     
  • 4.53, лютый арчешкольник... (?), 09:43, 06/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >ну, свиньи же жрут своё говно

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

     
  • 3.34, Аноним (34), 18:55, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Только rrdtool, только хардкор.

     
  • 2.5, OpenEcho (?), 13:14, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +5 +/
    >> СУБД
    >> Код написан на языке Go
    >
    >  Меня чувство некоторого диссонанса.

    Интервью профессиального водителя:

    Работодатель: Вы можете ездить на грузовых и легковых автомобилях?
    Кандидат: Грузовые у меня вызывают чувство диссонанса...

     
     
  • 3.6, kusb (?), 13:58, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Инструмент или его использование может вызывать диссонанс. Язык программирования, это аналог не классов машин, а какой-то конкретной марки, наверное.
     
  • 3.7, Tron is Whistling (?), 14:03, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Автомобили с квадратными колёсами и у меня вызывают чувство глубокого диссонанса.
     
     
  • 4.9, Любитель треугольных колёс (?), 14:20, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Автомобили с квадратными колёсами и у меня вызывают чувство глубокого диссонанса.

    То ли дело треугольные!
    https://etudes.ru/etudes/wheel-inventing/

     
     
  • 5.10, Tron is Whistling (?), 14:24, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Угу. Сферическая потуга академиков в вакууме от математики. Физика им не нужна.
     
  • 3.22, InuYasha (??), 16:52, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Интервью профессиального водителя:

    Работодатель: Вы можете ездить на грузовых автомобилях, сделанных из Lego?
    Кандидат: ... не, ну, в шлеме и мотоэкипе можно, но если только грузовик пустой.

    - так точнее будет.

     
     
  • 4.25, OpenEcho (?), 17:11, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > ...сделанных из Lego?
    > - так точнее будет.

    Ну очень увесиситый аргумент...

    :)

     
  • 2.14, Аноним (14), 15:53, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • –10 +/
    А на чём ещё БД писать? На Rust долго, на Java получится медленно.
    Унылое древнее типа С и С++ не беру, т.к. на этом писать в 2023 БД уже моветон. Тупо по историческим соображениями postgres на них, замена для PG - CockroachDB на Go написан. Больше не на чем писать кароч.
     
     
  • 3.19, Аноним (26), 16:37, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Clickhouse на крестах написан. Между прочим, лучший в классе column family.
     
     
  • 4.21, InuYasha (??), 16:48, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Postgres, MongoDB, MS SQL, SQLite... - да всё дохипстерское сишно-плюсовое и, ЧСХ, работало, и даже быстро, и масштабировалось. Но нет, толпы адептов выученного вчера языка завалили мир пруф-концептами и завертелось...
     
     
  • 5.24, Аноним (26), 17:10, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Postgres, MongoDB, MS SQL, SQLite...
    > и масштабировалось.

    Остроумно.

    Как и назвать монгу (влажная мечта любого JS-хипстора) дедовской, кстати.

     
  • 5.31, User (??), 18:20, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Масштабирующийся postgres/mssql? Воу, sqlite!
    Мужики-то не знали, ёлки!
     
  • 3.30, User (??), 18:18, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Cassandra смотрит на вас с недоумением
     
     
  • 4.75, Заноним (?), 04:15, 07/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Fixed:
    Cassandra смотрит на вас с недоумением javающего ленивца.
    Тогда как ScyllaDB уже и прожевала и переварила.
     
     
  • 5.76, User (??), 10:11, 07/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Fixed:
    > Cassandra смотрит на вас с недоумением javающего ленивца.
    > Тогда как ScyllaDB уже и прожевала и переварила.

    А вот с ней как раз не работал, но отзывы от работавших - гм, противоречивые. Вплоть до того, что на реальных задачах трехлетней давности - была _медленней_

     
  • 5.78, лютый арчешкольник... (?), 10:42, 07/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >ScyllaDB уже и прожевала и переварила.

    признайся, что ты только презку в паверпоинте посмотрел про сцыклу, а кассандру даже не использовал

     
     
  • 6.103, Заноним (?), 02:20, 25/11/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >>ScyllaDB уже и прожевала и переварила.
    > признайся, что ты только презку в паверпоинте посмотрел про сцыклу, а кассандру
    > даже не использовал

    ip -s l show eth0 кажет по ~154T принятых в каждую ноду кластера scylla в проде. А кассандру я похоронил вместе с jvm в 2013.

    В общем - держи свои галлюцинации при себе.


     
  • 3.77, лютый арчешкольник... (?), 10:40, 07/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >на Java получится медленно.

    весь хайлоад стек написан на жабе. маня-мирок, порвись )

    кассандра, neo4j, elasticsearch.... не, не слышали )

     
     
  • 4.79, Аноним (79), 12:28, 07/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Если нет жёстких требований к SLA, то действительно пишут на языках со сборкой мусора. А вот если есть, как в биржевой торговле и алготрейдинге, то только кресты/rust или извращения с написанием кода в garbage-free стиле на ЯП с GC. А если речь просто о хайлоаде, то всякие выстрелившие стартапы любят делиться историями успеха, как они 500К RPS держат на микросервисах на каком-нибудь Ruby, так как запихали все в кубер и поднимают под нагрузку десятки инстансов.
     
     
  • 5.84, лютый арчешкольник... (?), 19:48, 07/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >в биржевой торговле и алготрейдинге,

    маргинальщина. это надо 0.01% от всего ИТ...

    >языках со сборкой мусора

    для обычного применения уже несколько ЛЕТ как нет GC с заметными не под микроскопом паузами

     
     
  • 6.90, ptr (??), 02:50, 09/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > для обычного применения уже несколько ЛЕТ как нет GC с заметными не под микроскопом паузами

    Странно. Последний раз буквально пару лет нарывался на проблемы с С#.
    Суть проблемы была в том, что при пиковой загрузке GC не успевал освобождать память. Что ни пробовали - это приводило к заметным провалам в производительности. После переписывания на C++ на пиковой нагрузке сервис просто упирался в 100% загрузку всех ядер CPU, но не устраивал явный провал пропускной способности через миллисекунды после этого, как на C#.

     
     
  • 7.92, лютый арчешкольник... (?), 18:51, 09/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >буквально пару лет нарывался на проблемы с С#.

    с# тут каким боком?

    вообще, ты кажись не понимаешь, что чудес не бывает. маленькие паузы == меньшая ПСП. для задач где паузы не мешают, с ними никто не борется. но при желании есть платные ГЦ вообще без пауз.

    ну а плюсы твои с колхозным самописным ГЦ вообще не обязательно что даже жабу с шанондой догонят.

     
     
  • 8.100, ptr (??), 17:56, 10/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Тем, что в нем нет никаких средств явно и в нужный момент освободить память зани... текст свёрнут, показать
     
  • 5.104, qsdg (ok), 04:55, 27/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Как раз в биржах алготрейдинге и HFT jvm достаточно популярна Хотя практики у... большой текст свёрнут, показать
     
  • 3.89, ptr (??), 02:39, 09/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Смотря какую БД. Как только начинается страничная организация хранения данных, так сразу Go потребует лишних копирований память-память, которых можно избежать на C/C++. Что при достаточно большом кеше становится очень болезненным.
     
     
  • 4.105, qsdg (ok), 04:57, 27/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    В VictoriaMetrics все буферы стараются быть привязанными к потоку, чтобы между кешами CPU не переезжать. Это не столько к языку, сколько к тому как на нём писать.
     

  • 1.8, Аноним VictoriaMetrics (?), 14:15, 05/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > В тестах производительности VictoriaMetrics опережает InfluxDB
    > и TimescaleDB при выполнение операций вставки и выборки данных
    > до 20 раз, потребляя при этом в 10 раз меньше ОЗУ, чем InfluxDB
    > и в 7 раз меньше, чем Prometheus, Thanos и Cortex при обработке
    > миллионов уникальных временных рядов

    Сильное заявление. Но в сравнении с TimescaleDB, например, разрабы VictoriaMetrics подобос*ались с конфигами оппонента , используя устаревшие данные (себя настроили как надо, кстати), затем не ответили на вопросы касательно тестирования. И так во всех трёх сравнениях. При этом называют самописный DSL преимуществом перед SQL-совместимым синтаксисом.

    Подозреваю, сравнение с другими СУБД такая же проблема, раз они в своих тестах три года подряд придерживались одной стратегии, не исправляя при этом косяки за всё время. Да и оставив без ответа конструктивную критику по поводу методов тестирования. Сейчас, 3 годя спустя после последнего такого сравнения (без исправлений своих косяков) они могли ещё сильнее отстать от оппонентов, но при этом всё ещё ссылаются на устаревшие (ноябрь 2018, с тех пор было много новых релизов и VM, и оппонентов) предвзятые (только своих сотрудников) неверное построенные (обозначенные косяки не поправили) сравнения.

     
     
  • 2.17, Аноним (26), 16:34, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Сильное заявление. Но в сравнении с TimescaleDB, например, разрабы VictoriaMetrics подобос*ались с конфигами оппонента , используя устаревшие данные (себя настроили как надо, кстати), затем не ответили на вопросы касательно тестирования.

    В данном случае вообще пофиг, в 20 или в 18.9 раз. Один фиг, timescale является настройкой над постгресом, который является типичным RDBMS и будет всасывать у любой более-менее нормальной TSDB со свистом.

    > При этом называют самописный DSL преимуществом перед SQL-совместимым синтаксисом.

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

     
     
  • 3.45, Стандарт (?), 23:15, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Вы, видимо, с миром разработки ПО не знакомы, Мониторинг - не единственное, где ... большой текст свёрнут, показать
     
     
  • 4.54, лютый арчешкольник... (?), 09:47, 06/10/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >если Вы чисто девопс, который по какой-то нелепой причине никогда не имеете дело с РСУБД

    ну я техлид ) уже лет 10 не писал SQL, потому что выкинул все реляционки, потому что они тормозные.  в целом, считаю притягивание SQL к NOSQL лютым бредом, потому что оно всё равно обрастает какими-то нестандартными командочками и перестает быть им. хотя SQL даже для КРУДа неудобный! talk to my hand!

     
     
  • 5.81, NoSQL (?), 19:19, 07/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > уже лет 10 не писал SQL, потому что выкинул все реляционки, потому что они тормозные
    > хотя SQL даже для КРУДа неудобный

    А где же вы храните данные? В текстовых файлах? В Mongo? Redis? Кликхаус? В словарях в памяти приложения?
    А, стоп, может Вы техлид статического сайта с 5 посетителями в год, уточнений же не было.

     
     
  • 6.85, лютый арчешкольник... (?), 19:51, 07/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    и как это к делу относится? храню терабайты в монге, сотни гигабайт в neo4j (cypher пакость, но альтернатив нет)... то что в монге нет SQL это её огромный плюс (хоть и не единственный)
     
     
  • 7.86, лютый арчешкольник... (?), 20:06, 07/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    + терабайты в эластике.... всё сразу и не вспомнишь ) там тоже sql как козе баян
     
  • 4.91, ptr (??), 12:39, 09/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Мониторинг он воообще то разный Например, имеем данные трекинга 100 тыс вагоно... большой текст свёрнут, показать
     
     
  • 5.106, qsdg (ok), 05:04, 27/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Да, PromQL (как и VictoriaMetrics) он больше для мониторинга IT инфраструктуры. Там обычно данные через неделю уже очень-то и нужны. Зато очень нужны алёрты, дашборды и большие объёмы.

    Теоретически конечно можно сделать, но у каждой тулсы своя фокус-ниша. А так -- любая БД конкурирует с Excel вообще-то.

     
  • 2.32, User (??), 18:23, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, я с timescale'ом лично сравнивал. В дефолтах разница примерно на порядок, после чего желание тюнить само собой отпало.
     
     
  • 3.46, дефолт (?), 23:16, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > я с timescale'ом лично сравнивал

    В 2018?

     
     
  • 4.48, Аноним (48), 00:09, 06/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Я сравнивал в 2022 / 2023.
    Разница всё так же на порядок
     
  • 4.62, User (??), 12:06, 06/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> я с timescale'ом лично сравнивал
    > В 2018?

    В 22ом. Затащил timescale\tobs - вышло вполне адекватно проекту, но по сравнению с соседями на victoriametrics разница на порядок и есть.

     
  • 2.47, Аноним (48), 00:09, 06/10/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    У нас на работе используется Вика.
    И да, мы сравнивали производительность и потребление ресурсов VictoriaMetrics vs Postgres + TimescaleDB на одном и том же сервере / профиле нагрузки.
    Я изначально был за PG, но связка Postgres + TimescaleDB настолько сильно тупила и жрала ресурсы, что это было даже не смешно.
    Собственно, аргументы на этом у меня закончились, потому Вика )
     
     
  • 3.58, ыы (?), 10:02, 06/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А вот чтобы это небыло рекламой, покажите параметры обрудования, конфиги, размер данных и NVPS ?
     
  • 3.72, asand3r (ok), 22:22, 06/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Я легко верю, что VM производительней в виду заточенности под профиль нагрузки.
    Однако, всё же когда приводят цифры, хочется понимать как тестировали, адекватно ли настроили оппонента. PostgreSQL сам по себе довольно непросто настраивается и требует определенных компетенций как в области самого ПО так и настройки ОС.
    VM же, по факту, даже настраивать не нужно - просто заваливаешь её процессором, памятью, быстрым диском и всё работает. Моё любимое - зайдите в гугл и попробуйте поискать "victoriametrics performance tuning".
     
     
  • 4.73, Аноним (48), 23:40, 06/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Как писал парень выше - тут всё просто:
    Ставишь Victoria Metrics, просто запускаешь и просто всё работает.
    Ставишь PG & Timescale, для начала прогоняешь минимальный тюнинг при помощи pgtune & timescaledb-tune. Получаешь отвратительный результат (работает на порядок медленнее конкурента, при этом ресурсов жрёт конкретно больше и самое печальное, даже со сжатием, потребляет катастрофически много дискового пространства) и осознаёшь, что дальнейший тюнинг возможен (точно можно сделать несколько лучше), но нецелесообразен (догнать даже незатюненную Victoria Metrics - в принципе нереально).

    Сносишь PG & Timescale в баню и радуешься жизни :)

     
     
  • 5.74, asand3r (ok), 23:43, 06/10/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Как писал парень выше - тут всё просто:
    > Ставишь Victoria Metrics, просто запускаешь и просто всё работает.
    > Ставишь PG & Timescale, для начала прогоняешь минимальный тюнинг при помощи pgtune
    > & timescaledb-tune. Получаешь отвратительный результат (работает на порядок медленнее
    > конкурента, при этом ресурсов жрёт конкретно больше и самое печальное, даже
    > со сжатием, потребляет катастрофически много дискового пространства) и осознаёшь, что
    > дальнейший тюнинг возможен (точно можно сделать несколько лучше), но нецелесообразен (догнать
    > даже незатюненную Victoria Metrics - в принципе нереально).
    > Сносишь PG & Timescale в баню и ...

    ... деградируешь. =)

     
  • 3.87, ptr (??), 02:09, 09/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А дальше то как? Что с ACID? Через какой FDW к ней ходить? TimeScaleDB ставят когда нужно работать с временными сериями в реляционной БД.
     
     
  • 4.107, qsdg (ok), 05:08, 27/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    ACID -- это не про мониторинг, а про транзакции. В мониторинг тулзах никому ни разу ещё не понадобился ACID. Там нету как транзакций, так и вообще UPDATE в принципе.
     

  • 1.11, Аноним (11), 14:31, 05/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кто такая Виктория?
     
     
  • 2.13, Аноним (13), 15:03, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    И где она живет?
    (Наверное в той же общаге, что и Элис)
     
     
  • 3.49, Аноним (48), 00:11, 06/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А вдруг она не курит, и в $&)@# не даёт...

    Извините (картинка со слоником из "38 попугаев".jpg) :)

     

  • 1.12, Tron is Whistling (?), 14:34, 05/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Downsampling только в энтерпрайзе.
    Прелесть. Не, я уж лучше дальше в rrdtool.
     
     
  • 2.108, qsdg (ok), 05:09, 27/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Downsampling только в энтерпрайзе.
    > Прелесть. Не, я уж лучше дальше в rrdtool.

    На Perl пишете небось?

     
     
  • 3.115, Tron is Whistling (?), 09:46, 27/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    PHP брал, C брал, Pascal брал...
    Perl не брал.
     

  • 1.29, Аноним (29), 18:07, 05/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Тоже как то пытались перейти на это игровое решение с самоделки на тараниуле и упёрлись в то что нет даунсемплинга, который был в подделке. Вопрос закрыли после трёх недель работы.

    Потом переехали на редис плюс постгрес, ну понятно что с пострадавшей гибкостью.

     
     
  • 2.41, Tron is Whistling (?), 21:48, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Я для графиков живу на MySQL в коротком отрезке - 7 дней, там сотня с фигом гигабайт получается, далее непрерывно выгружаю то, что требуется, в RRD - для быстрой отрисовки и истории.
     
     
  • 3.42, Tron is Whistling (?), 21:53, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Но у меня кейс специфичный - мне графики нужны в промышленном масштабе...
     

  • 1.35, Легивон (?), 20:15, 05/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Когда она только появилась быстро отметил её как проект занимающийся восновном балобольством, сказками про большую в 9000 раз производительность.
    Ничего не изменилось, вот и сейчас они снова "положили" thanos на лопатки в 7 раз одновременно и по памяти и по сжатию.
    Сжатие в семь раз относительно проектов которые так же использую сжатие - это просто сказки для маленьких детей. Удивительно, как эта система каким-то образом обрасла совершенно упоротыми фанатиками сектантами, расказывающими такие же небылицы. Видимо лозунги специально заточены на аудиторию психических.
    Пруфы то будут? Как воспроизвести ваши "эксперименты"? Выкладывайте семплы и скрипты как залить их в ващу ненужную поделку и в прометей? Вместо пруфов - только победы в интернете, да?
    Вангую на танос в тестах всегда подается белый шум в метриках и лейблах, а в викторию постоянка. Иного варианта про 700% сжатия от сжатого и быть не может.
    Еще прочитал описание... даунсемплинга нет, лол. Для чего оно тогда вообще нужно?
    Еще одна система мониторинга косплеющая прометей с киллер фитчей - официально ни для чего не нужна?
     
     
  • 2.80, x (?), 15:43, 07/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Удивительно, как эта система каким-то образом обрасла совершенно упоротыми фанатиками сектантами, расказывающими такие же небылицы

    ыкспэрты опеннета против фанатиков из CERN

    https://www.theregister.com/2023/09/18/lhc_infrastructure_monitoring/

     
     
  • 3.82, Легивон (?), 19:38, 07/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Что ты хотел сказать?
    Ты читал эту статью?
    Где пруфы: графики, методика воспроизведения?
     
     
  • 4.98, Roman (??), 16:23, 10/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Посмотрите бенчмарки с примерами воспроизведения здесь https://docs.victoriametrics.com/Articles.html#benchmarks

    Например https://victoriametrics.com/blog/mimir-benchmark содержит абсолютно всё для воспроизведения. Даже полные снапшоты дашбордов во время выполнения бенчмарка.

     
     
  • 5.99, Мимир (?), 16:40, 10/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Посмотрите бенчмарки с примерами воспроизведения здесь
    > https://docs.victoriametrics.com/Articles.html#benchmarks

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

    > Например https://victoriametrics.com/blog/mimir-benchmark

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

     
     
  • 6.109, qsdg (ok), 05:14, 27/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >> Например https://victoriametrics.com/blog/mimir-benchmark
    > Разве что это хоть как-то похоже на сравнение. Но опять же -
    > ни комментариев от разрабов Mimir, ни тестовых данных. И сама статья
    > "сравнения" расположена внезапно на сайте виктории, что вообще ни разу не
    > предвзято, ага.

    Разрабы Мимира участвовали в бенчмарке, там же написано. И они бы у себя откомментировали быстро, если бы было что сказать. Но они понимают что это fight that you cannot win, поэтому молчат.

     
  • 3.83, ыы (?), 19:46, 07/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    вас ничего не смутило в этой статье?
     
  • 2.93, Балабол (?), 21:02, 09/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Вот тут ребята с вами не согласны - https://docs.victoriametrics.com/CaseStudies.html
     

  • 1.36, Имя (?), 20:41, 05/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А что у них там с ACID?
     
     
  • 2.110, qsdg (ok), 05:16, 27/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > А что у них там с ACID?

    А его нету :)

    Нет UPDATE -- значит нет транзакций вообще. В мониторинге никому не нужен ACID.

     

  • 1.40, Аноним (40), 21:37, 05/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Переехали на неё в прошлом году. Имели 80 нод кубера, прометеус умирал при таком количестве нод, а при подключении виктории все проблемы исчезли.
     
     
  • 2.43, Аноним (43), 23:00, 05/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Сколько у нас нод не скажу, но аналогично девопсы заменили Прометеус на Викторию и ситуация существенно улучшилась.
     
  • 2.55, Tron is Whistling (?), 09:50, 06/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Лучше расскажите, сколько у вас MVPS на это количество нод, а мы посмеёмся.
     
     
  • 3.56, Tron is Whistling (?), 09:50, 06/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    // NVPS
     
  • 3.94, Балабол (?), 21:04, 09/10/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вот тут у ребят из Roblox 120 миллионов NVPS - https://www.datanami.com/2023/05/30/why-roblox-picked-victoriametrics-for-obse
     
     
  • 4.97, Roblox (?), 23:53, 09/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > 120 миллионов NVPS

    И ни слова о точности, потерях. Наверное 99,9% потерь, точность 4 знака до запятой и 0 после, раз не указали. А лейбл однобуквенный от ascii-таблицы. Только дата с временем, и та - с точностью только до секунд, миллисекунды отбрасываются, коллизии теряются. При таких условиях - вполне можно поверить, что у VictoriaMetrics наберётся 120 миллионов NVPS.

     
     
  • 5.111, qsdg (ok), 05:29, 27/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >> 120 миллионов NVPS
    > И ни слова о точности, потерях. Наверное 99,9% потерь, точность 4 знака
    > до запятой и 0 после, раз не указали. А лейбл однобуквенный
    > от ascii-таблицы. Только дата с временем, и та - с точностью
    > только до секунд, миллисекунды отбрасываются, коллизии теряются. При таких условиях -
    > вполне можно поверить, что у VictoriaMetrics наберётся 120 миллионов NVPS.

    Наверное нет. Наверное длина лейблов вообще не важна, миллисекунды есть, точность норм. Наверное в Роблоксе не лаптем щи хлебают.

     
  • 3.95, Tron is Whistling (?), 21:10, 09/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Лучше расскажите, сколько у вас MVPS на это количество нод, а мы
    > посмеёмся.

    Вы про себя расскажите.

     
  • 2.57, ыы (?), 09:59, 06/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Как вы полагаете, за счет чего достигается такой прорыв в производительности? Законы физики полагаю разработчики этого ПО не переделывали?
     
     
  • 3.65, Аноним (43), 13:18, 06/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну никого же не смущает, что, например, ms sql быстрее чем postgresql работает.
    Вполне могут быть разные подходы к одинаковым задачам.
    Я точно не помню уже, но мне казалось что они просто взяли архитектуру кликхауса и на его основе сделали свою таймсериас дб. Но могу и врать, давно уже интересовался этим.
     
     
  • 4.70, ыы (?), 19:05, 06/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Когда производительность на схожих задачах отличается разительно - смущает. Возникает вопрос- за счет чего достигнут такой эффект. И начинаются оговорки...
     
     
  • 5.96, Балабол (?), 21:11, 09/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Почему ClickHouse быстрее Postgres'а в 1000 раз, а сохраненные в ClickHouse данные занимают в 10-100 раз меньше места на диске по сравнению с ClickHouse? Наверное, разработчики ClickHouse балаболы...
     
  • 4.112, qsdg (ok), 05:31, 27/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну никого же не смущает, что, например, ms sql быстрее чем postgresql
    > работает.
    > Вполне могут быть разные подходы к одинаковым задачам.
    > Я точно не помню уже, но мне казалось что они просто взяли
    > архитектуру кликхауса и на его основе сделали свою таймсериас дб. Но
    > могу и врать, давно уже интересовался этим.

    Нет, из архитектуры Кликхауса там только LSM tree. Но оно сейчас у всех есть.

     

  • 1.59, ыы (?), 10:16, 06/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >в 70 раз - по сравнению с TimescaleDB

    а говорят что в Постгрес есть сжатие... Вы сжатые данные в 70 раз сжали? А не п.здишь ли мил человек?

     
     
  • 2.66, Аноним (43), 13:24, 06/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну можно видео сжать zip'ом, а можно H265... Это не означает, что можно zip сжать повторно сверху с помощью H265.
    А вообще перед тем как у себя внедрять - бизнес/девопсы приносили кучу статей со сравнительными тестированиями этих БД и все были в пользу Виктории. Я правда потыкал носом в то, что имена авторов статей подозрительно с сотрудниками Виктории совпадали...)) В общем, авторы Виктории - те еще любители маркетинговых сказок...
     
     
  • 3.69, ыы (?), 18:30, 06/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Речь идет не о сжатии видео. Речь идет о такого рода данных которые нельзя сжимать с потерями. А количество алгоритмов для таких преобразований не так много.
     
     
  • 4.71, Аноним (43), 20:00, 06/10/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Кроме всего прочего, time-series БД оперируют именно настройкой степени потерь, от потерь в точности хранения вещественных чисел и разрешения DateTime, до потерь во временной области, когда несколько последовательных отсчетов сэмплируются в один отсчет с той или иной агрегацией.
    Аналогия с видео подразумевала, что ваш посыл с повторным сжатием в N раз уже сжатых данных - не верен. Сжимают исходные несжатые данные в таких системах.
     
     
  • 5.88, ptr (??), 02:28, 09/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > от потерь в точности хранения вещественных чисел и разрешения DateTime,

    А вот это должно решаться клиентом, а не БД. Например, для GPS данных мы фиксируем точность в отдельном поле. И какие либо потери там могут сильно искажать картину.

    > до потерь во временной области, когда несколько последовательных отсчетов
    > сэмплируются в один отсчет с той или иной агрегацией

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

     
     
  • 6.101, Легивон (?), 21:39, 10/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Дядя, ты не шаришь. Иди гугли "теорему CAP".
    В прометее и деревативах осознано дропнули "C", потому что для его назначения - мониторинг, оно не нужно. А его наличие только вредит. Когда ты выбираешь "consistency", ты должен париться насчет распределенных коммитов, дожидаться синхронного подтверждения записи, должен в целом синхронизовать процессы протекающие в распределенной системе. Это вообще никак не вяжется с необходимостью ворочать миллионами семплов, для чего он и создавался и то почему он так адцки выстрелил.
    Зато отказ от "C" приносит кучу плюсов. К примеру попробуй угадать с 1 попытки как проще всего (и это вполне адекватно) сделать отказоустойчивый прометей? За счет этого прометей имеет огромный потенциал по простому маштабированию.
     
     
  • 7.102, ptr (??), 17:33, 13/10/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Какое отношение конситенция имеет к потере точности данных или нарушению их последовательности? Когда данные искажаются БД - это уже ни в какие ворота не лезет. Причем для большинства видов мониторинга. Даже ПИД-регулирование на искаженных данных или без сохранения их оригинальной последовательности просто не сможет нормально работать.
     
     
  • 8.114, qsdg (ok), 05:36, 27/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Точность не теряется То что вы говорите -- это семплирование, и оно используетс... текст свёрнут, показать
     
  • 7.113, qsdg (ok), 05:33, 27/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Дядя, ты не шаришь. Иди гугли "теорему CAP".
    > В прометее и деревативах осознано дропнули "C", потому что для его назначения - мониторинг, оно не нужно.

    Не совсем так. CAP очень легко достигается, если просто не поддерживать UPDATE и DELETE :)
    Но да, в мониторинге оно никому не нужно.

     

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



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

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