Как MergeSet работает в VictoriaMetrics?

Я встретил исследовательскую работу, рекомендованную MergeSet от VictoriaMetrics.

Там написано

MergeSet — это упрощенное одноуровневое LSM-дерево, реализованное VictoriaMetrics [6], который объединяет тег и идентификатор публикации. вместе в ключе, и список сообщений естественным образом формируется из-за отсортированный порядок, поддерживаемый LSM-деревом.

Хотя я пытался прочитать исходный код с виртуальной машины, но не совсем понял, что такое MergeSet.

Для обычного LSM-дерева каждый элемент представляет собой пару ключ-значение, отсортированную по ключу. Если MergeSet следует этой парадигме, то мои вопросы следующие:

  1. Объединяет ли MergeSet каждую пару ключ-значение тега с соответствующим TSID и сохраняет ее как ключ кортежа в MergeSet.table?
  2. Если пара «ключ-значение» тега и TSID встроены в ключи, что представляет собой значение MergeSet.table?

Если нет, следует ли мне рассматривать MergeSet как (частично) отсортированный набор строк, вдохновленный LSM-деревом, использующий емкость диска?

ReactJs | Supabase | Добавление данных в базу данных
ReactJs | Supabase | Добавление данных в базу данных
Это и есть ваш редактор таблиц в supabase.👇
1
0
64
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Пакет github.com/VictoriaMetrics/VictoriaMetrics/lib/mergeset реализует LSM-подобную структуру данных со следующими свойствами:

  • Он хранит непрозрачные фрагменты байтов в отсортированном порядке с помощью метода Table.AddItems.
  • Он обрабатывает сохраненные байтовые фрагменты в блоках размером до 64 КБ. Каждый блок сжимается перед сохранением на диск. Это уменьшает количество операций ввода-вывода на диске и использование дискового пространства.
  • Он объединяет части одинакового размера в более крупные в фоновом режиме, чтобы держать количество частей под контролем. Это улучшает степень сжатия и скорость запросов.
  • Он обеспечивает O(log(N)) поиск и O(1) префиксное сканирование по отсортированным байтовым фрагментам с помощью структуры TableSearch.
  • Он позволяет делать мгновенные снимки, как описано в этой статье.

mergeset используется VictoriaMetrics для хранения различных индексов, которые имеют общее название indexdb. Эти индексы включают следующие записи:

  • metricName -> metricID, что позволяет найти внутренний идентификатор временного ряда (он же metricID) по каноническому имени временного ряда (он же meteicName) при сохранении загруженных необработанных образцов в VictoriaMetrics. Каноническое имя временного ряда включает имя метрики, а также все метки временного ряда, отсортированные в определенном порядке.

  • metricID -> metricName, который позволяет найти имена метрик, а также все метки для временных рядов с заданным внутренним идентификатором.

  • label=value -> metricID, что позволяет найти временной ряд с заданной меткой label=value. Эти записи известны как инвертированный индекс и используются для быстрого поиска временных рядов с помощью заданных фильтров меток .

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

Спасибо! Но я все еще в замешательстве: если AddItems принимает несколько непрозрачных байтовых фрагментов, как массив фрагментов может служить парами ключ-значение, как записи в индексе? Например, для mergeset внутри индекса metricName->metricID объединен ли срез байтов metricName и metricID?

Xavier Z 17.04.2024 04:18

Каждый фрагмент байта, передаваемый в AddItems, содержит одну закодированную запись, например metricName->metricID.

valyala 17.04.2024 22:47

Другие вопросы по теме