Я встретил исследовательскую работу, рекомендованную MergeSet
от VictoriaMetrics.
Там написано
MergeSet — это упрощенное одноуровневое LSM-дерево, реализованное VictoriaMetrics [6], который объединяет тег и идентификатор публикации. вместе в ключе, и список сообщений естественным образом формируется из-за отсортированный порядок, поддерживаемый LSM-деревом.
Хотя я пытался прочитать исходный код с виртуальной машины, но не совсем понял, что такое MergeSet
.
Для обычного LSM-дерева каждый элемент представляет собой пару ключ-значение, отсортированную по ключу. Если MergeSet
следует этой парадигме, то мои вопросы следующие:
MergeSet
каждую пару ключ-значение тега с соответствующим TSID и сохраняет ее как ключ кортежа в MergeSet.table
?MergeSet.table
?Если нет, следует ли мне рассматривать MergeSet
как (частично) отсортированный набор строк, вдохновленный LSM-деревом, использующий емкость диска?
Пакет github.com/VictoriaMetrics/VictoriaMetrics/lib/mergeset реализует LSM-подобную структуру данных со следующими свойствами:
O(log(N))
поиск и O(1)
префиксное сканирование по отсортированным байтовым фрагментам с помощью структуры TableSearch.mergeset
используется VictoriaMetrics для хранения различных индексов, которые имеют общее название indexdb
. Эти индексы включают следующие записи:
metricName -> metricID
, что позволяет найти внутренний идентификатор временного ряда (он же metricID
) по каноническому имени временного ряда (он же meteicName
) при сохранении загруженных необработанных образцов в VictoriaMetrics. Каноническое имя временного ряда включает имя метрики, а также все метки временного ряда, отсортированные в определенном порядке.
metricID -> metricName
, который позволяет найти имена метрик, а также все метки для временных рядов с заданным внутренним идентификатором.
label=value -> metricID
, что позволяет найти временной ряд с заданной меткой label=value
. Эти записи известны как инвертированный индекс и используются для быстрого поиска временных рядов с помощью заданных фильтров меток .
Как VictoriaMetrics сохраняет эти записи в файле mergeset
, который работает только с отсортированными фрагментами байтов? Он сортирует записи в байтовые фрагменты таким образом, чтобы их можно было искать с помощью сканирования префиксов. Он также добавляет к каждому типу записи байтовые фрагменты с индивидуальным префиксом, чтобы они не конфликтовали друг с другом. См. поддерживаемые в настоящее время префиксы.
Каждый фрагмент байта, передаваемый в AddItems
, содержит одну закодированную запись, например metricName->metricID
.
Спасибо! Но я все еще в замешательстве: если
AddItems
принимает несколько непрозрачных байтовых фрагментов, как массив фрагментов может служить парами ключ-значение, как записи в индексе? Например, дляmergeset
внутри индексаmetricName->metricID
объединен ли срез байтовmetricName
иmetricID
?