Как VictoriaLogs хранит логи: колоночная структура и внутреннее устройство

VictoriaLogs — это система управления логами, которая кардинально отличается от традиционных решений вроде Elasticsearch. Вместо инвертированного индекса она использует колоночное хранение, что позволяет выполнять запросы в разы быстрее и экономить ресурсы. В этой статье мы разберём, как устроена её внутренняя архитектура, проследив путь лога от момента отправки до размещения на диске. Вы узнаете, почему запросы выполняются так быстро, откуда берётся множество файлов в директориях и какие настройки и метрики важны для стабильной работы. Материал будет полезен как администраторам, так и разработчикам, даже если вы никогда не работали с подобными системами.

Как устроен путь лога от приёма до диска

Когда вы отправляете лог в VictoriaLogs через HTTP API, он не записывается сразу на диск. Вместо этого данные попадают в буфер в памяти, который называется "pending rows". Этот буфер накапливает записи до определённого момента, после чего они сбрасываются на диск в виде сегмента. Такой подход позволяет группировать операции записи, что значительно повышает производительность при высокой нагрузке.

Сегмент — это директория, содержащая файлы для каждой колонки. Например, файл timestamps содержит все временные метки записей в этом сегменте, файл message — содержимое сообщений, а для каждого уникального поля создаётся отдельный файл со значениями. Такая структура называется колоночной, и именно она обеспечивает высокую скорость запросов. Когда вы ищете логи за определённый период, система читает только файл с временными метками, а не весь документ целиком, как это происходит в построчных СУБД.

Сегменты неизменяемы: после записи они не модифицируются. Это упрощает конкурентный доступ и гарантирует целостность данных. Если вы удаляете старые логи, система просто удаляет целые сегменты, что очень эффективно. Каждый сегмент имеет временную метку начала и конца, что позволяет быстро отсекать ненужные данные при запросах.

Предыстория и контекст: почему VictoriaLogs появился

VictoriaLogs разработан компанией VictoriaMetrics, известной своей СУБД для метрик. Логи и метрики — две стороны наблюдаемости, и VictoriaLogs призван закрыть пробел в этой области. Традиционные системы, такие как Elasticsearch, используют инвертированный индекс, который отлично подходит для полнотекстового поиска, но требует значительных ресурсов для хранения и обслуживания. VictoriaLogs предлагает колоночный подход, заимствованный из аналитических СУБД (например, ClickHouse), но адаптированный специально для логов.

Компания VictoriaMetrics — российская, что делает продукт особенно привлекательным для пользователей в России и СНГ. Это open-source проект с активным сообществом, и он может стать надёжной альтернативой западным системам, которые могут быть недоступны из-за санкций. VictoriaLogs полностью совместим с протоколами Elasticsearch, что упрощает миграцию, но при этом использует собственный язык запросов LogsQL, который более гибок и удобен для анализа логов.

Чем колоночная структура отличается от традиционной?

В традиционных системах, таких как Elasticsearch, данные хранятся построчно: каждая запись — это документ, содержащий все поля. При запросе по временному диапазону системе приходится читать весь документ, даже если вам нужна только временная метка. В колоночной структуре, наоборот, данные хранятся по колонкам: все временные метки в одном файле, все сообщения в другом. Поэтому запрос по временному диапазону считывает только файл с временными метками, что в разы быстрее и экономит дисковые операции.

Кроме того, колоночное хранение обеспечивает лучшую сжимаемость. Однотипные данные (например, временные метки) сжимаются эффективнее, чем разнородные записи. Это снижает занимаемое место на диске и ускоряет передачу данных при чтении. В VictoriaLogs используются современные алгоритмы сжатия, такие как LZ4, что дополнительно повышает эффективность.

Технические детали: файлы, флаги и метрики

Если заглянуть в директорию с данными VictoriaLogs, вы увидите множество папок с именами вроде 202401011200. Каждая такая папка — это сегмент, содержащий файлы для каждой колонки. Например, для поля message будет файл message.blp, для временных меток — timestamps.blp. Расширение .blp означает "block of log records" — блок записей. Внутри каждого файла данные организованы блоками, которые сжимаются с помощью алгоритма LZ4 или других кодеков.

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

Среди флагов, которые важны для настройки, стоит выделить -retentionPeriod — срок хранения данных. Когда сегмент становится старше этого периода, он удаляется целиком. Также есть флаги для контроля размера сегментов, например -segmentSize, который определяет, когда активный сегмент должен быть сброшен на диск. Метрики, такие как vmvictorialogssegmentcount, показывают количество активных сегментов, что помогает отслеживать здоровье системы.

Кого затронет и как: практические советы

Новое понимание внутреннего устройства VictoriaLogs полезно прежде всего администраторам и инженерам, которые эксплуатируют эту систему. Зная, как устроено хранение, легче диагностировать проблемы: если на диске много файлов, это нормально — это сегменты. Если запросы выполняются медленно, возможно, стоит проверить, какие колонки читаются, и оптимизировать запросы.

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

Для пользователей в России и СНГ VictoriaLogs особенно интересен, так как это open-source проект с активным сообществом, и он может стать альтернативой западным системам, которые могут быть недоступны из-за санкций. VictoriaMetrics — российская компания, что добавляет уверенности в поддержке и развитии.

Что будет дальше: развитие VictoriaLogs

VictoriaLogs активно развивается. В планах — улучшение интеграции с экосистемой Grafana, расширение языка LogsQL, а также оптимизация производительности. Ожидается, что проект достигнет стабильного релиза в ближайшее время, и тогда он станет полноценной заменой Elasticsearch для многих сценариев.

Следите за обновлениями на GitHub и в официальном блоге VictoriaMetrics. Если вы ещё не пробовали VictoriaLogs, сейчас хорошее время для эксперимента: установите его, отправьте тестовые логи и посмотрите, как быстро выполняются запросы.

Итог

VictoriaLogs — это современная система управления логами с колоночной структурой хранения, которая обеспечивает высокую производительность и экономию ресурсов. Понимание её внутреннего устройства помогает эффективно эксплуатировать систему и избегать типичных ошибок. Если вы ищете альтернативу Elasticsearch с меньшими требованиями к железу и более простой настройкой, VictoriaLogs — отличный кандидат.