其他
VictorialMetrics存储原理之索引
前文我们介绍了 VictorialMetrics 中是如何接收和传输数据的，接下来我们来分析下当 vmstorage 接收到数据后是如何保存监控指标的。
现在我们使用 csv 来导入一行指标数据，直接使用下面的请求即可：
curl -d "GOOG,1.23,4.56,NYSE" 'http://127.0.0.1:8480/insert/0/prometheus/api/v1/import/csv?format=2:metric:ask,3:metric:bid,1:label:ticker,4:label:market'
执行上面的请求后，在 vmstorage 组件下面会收到如下所示的一些日志信息：
同时在数据目录 vmstorage-data 下面也多了一个 cache 目录，而且 data 下面的 small 目录和 indexdb 目录下面也生成了一些文件，这些文件就是用来存储指标数据的。
接下来我们就来仔细分析下这些文件是干什么的，以及这些文件的存储格式是怎样的。
要想弄明白 vmstorage 是如何去存储数据的，首先我们要先弄明白几个概念。
存储格式
下图是 VictoriaMetrics 支持的 Prometheus 协议的一个写入示例。
VM 在收到写入请求时，会对请求中包含的时序数据做转换处理。首先根据包含 metric 和 labels 的 MetricName 生成一个唯一标识 TSID，然后 metric(指标名称__name__) + labels + TSID 作为索引 index，TSID + timestamp + value 作为数据 data，最后索引 index 和数据 data 分别进行存储和检索。
因此 VM 的数据整体上分成索引和数据两个部分，因此文件格式整体上会有两个部分，其中索引部分主要是用于支持按照 label 或者 tag 进行多维检索，数据存储时，先将数据按 TSID 进行分组，然后每个 TSID 包含的数据点各自使用列式压缩存储。
TSID
VictoriaMetrics 的 MetricName 的结构如下所示，包含 MetricGroup（指标名称 __name__） 和 Tag 数组，其中，Tags 是可选的，每个 Tag 由 Key 和 Value 等字节数组构成。
为了规范，Tags 必须按标签 Key 排序，使用 sortTags 方法。
VictoriaMetrics 的 TSID 的结构如下所示，包含 MetricGroupID、JobID、InstanceID、MetricID 等几个字段，其中除了 MetricID 外，其他字段都是可选的。这个几个 ID 的生成方法如下：
MetricGroupID是根据MetricName中的MetricGroup使用xxhash的 sum64 算法生成。JobID和InstanceID分别由MetricName中的第一个 tag 和第二个 tag 使用xxhash的 sum64 算法生成。为什么使用第一个 tag 和第二个 tag？这是因为 VictoriaMetrics 在写入时，将写入请求中的 JobID 和 InstanceID 放在了 Tag 数组的第一个和第二个位置。MetricID，使用 VictoriaMetrics 进程启动时的系统纳秒时间戳自增生成。
// lib/storage/tsid.go
// TSID 是一个时间序列的唯一 ID，实际上就是唯一标识一个时间序列的结构体。
//
// 时间序列会根据 TSID 进行排序。
//
// 除了 MetricID 之外其他属性都是可选的。 它们的存在仅仅是为了更好地对相关指标进行分组。
// 如果它们的含义与它们的命名不同，那也没关系。
type TSID struct {
AccountID uint32
ProjectID uint32 // 下面分析的时候可以暂时忽略这两个属性，用于多租户标识的属性
// MetricGroupID（指标组ID）对于指定的(AccountID, ProjectID)必须是唯一的。
//
// Metric Group 包含具有相同名称的指标，例如 “memory_usage”、“http_requests”，但具有不同的标签。
// 例如，下面的这些指标属于 memory_usage 这个指标组:
//
// memory_usage{datacenter="foo1", job="bar1", instance="baz1:1234"}
// memory_usage{datacenter="foo1", job="bar1", instance="baz2:1234"}
// memory_usage{datacenter="foo1", job="bar2", instance="baz1:1234"}
// memory_usage{datacenter="foo2", job="bar1", instance="baz2:1234"}
MetricGroupID uint64
// JobID 是给定项目的单个作业（又名服务）的 ID。
//
// JobID 对于指定的(AccountID, ProjectID)必须是唯一的。
//
// 一个 Job 任务可能由多个实例组成。
// See https://prometheus.io/docs/concepts/jobs_instances/ for details.
JobID uint32
// InstanceID 是实例（进程）ID，对于特定的(AccountID, ProjectID)必须是唯一的。
InstanceID uint32
// MetricID 是指标（时间序列）的唯一ID。
//
// 其他所有的 TSID 字段都可以通过 MetricID 获取。
MetricID uint64
}
因为 TSID 中除了 MetricID 外，其他字段都是可选的，因此 TSID 中可以始终作为有效信息的只有 MetricID，因此 VictoriaMetrics 的在构建 tag 到 TSID 的字典过程中，是直接存储的 tag 到 MetricID 的字典。
以写入 http_requests_total{status="200", method="GET"} 为例，则 MetricName 为 http_requests_total{status="200", method="GET"}，假设生成的 TSID 为 {metricGroupID=0, jobID=0, instanceID=0, metricID=51106185174286}，则 VictoriaMetrics 在写入时就构建了如下几种类型的索引 item，其他类型的索引 item 是在后台或者查询时构建的。
metricName -> TSID, 即http_requests_total{status="200", method="GET"} -> {metricGroupID=0, jobID=0, instanceID=0, metricID=51106185174286}metricID -> metricName，即51106185174286 -> http_requests_total{status="200", method="GET"}metricID -> TSID，即51106185174286 -> {metricGroupID=0, jobID=0, instanceID=0, metricID=51106185174286}tag -> metricID，即status="200" -> 51106185174286、method="GET" -> 51106185174286、"__name__" = http_requests_total -> 51106185174286（其实还有一个联合索引）
有了这些索引的 item 后，就可以支持基于 tag 的多维检索了，在当给定查询条件 http_requests_total{status="200"} 时，VictoriaMetrics 先根据给定的 tag 条件，找出每个 tag 的 metricID 列表，然后计算所有 tag 的 metricID 列表的交集，然后根据交集中的 metricID，再到索引文件中检索出 TSID，根据 TSID 就可以到数据文件中查询数据了，在返回结果之前，再根据 TSID 中的 metricID，到索引文件中检索出对应的写入时的原始 MetircName。
但是由于 VictoriaMetrics 的 tag 到 metricID 的字典，没有将相同 tag 的所有 metricID 放在一起存储，在检索时，一个 tag 可能需要查询多次才能得到完整的 metricID 列表。另外查询出 metricID 后，还要再到索引文件中去检索 TSID 才能去数据文件查询数据，又增加了一次 IO 开销。这样来看的话，VictoriaMetrics 的索引文件在检索时，如果命中的时间线比较多的情况下，其 IO 开销会比较大，查询延迟也会比较高。
这里我们了解了 TSID 这个非常重要的概念，还有几个结构体需要我们了解下，比如 rawRow 表示一个原始的时间序列行，MetricRow 表示插入到存储中的指标数据：
// lib/storage/raw_row.go
// rawRow 表示一个原始的时间序列行
type rawRow struct {
TSID TSID // 时间序列ID
Timestamp int64 // 时间戳
Value float64 // 给定时间戳的时间序列值
// PrecisionBits是要存储的值中的有效位数，可能值为 [1..64]
// 1 表示最大. 50% error, 2 - 25%, 3 - 12.5%, 64 没有错误, i.e.
// 存储的值不会丢失精度
PrecisionBits uint8
}
// libe/storage/storage.go
// MetricRow 插入到存储中的指标
type MetricRow struct {
// MetricNameRaw 包含原始的指标名称，必须使用 metricne.UnmarshalRaw 对其进行解码。
MetricNameRaw []byte
Timestamp int64
Value float64
}
插入指标
有了上面几个概念的认识，现在我们回过头再去看下 vmstorage 中对 vminsert 请求的处理：
// app/vmstorage/transport/server.go
func (s *Server) processVMInsertConn(bc *handshake.BufferedConn) error {
return clusternative.ParseStream(bc, func(rows []storage.MetricRow) error {
vminsertMetricsRead.Add(len(rows))
return s.storage.AddRows(rows, uint8(*precisionBits))
}, s.storage.IsReadOnly)
}
当 vmstorage 节点接收到数据后，最后会通过回调执行 s.storage.AddRows(rows, uint8(*precisionBits))，该函数将数据添加到底层存储去：
// lib/storage/storage.go
// AddRows 添加 mrs 集合到存储 s
func (s *Storage) AddRows(mrs []MetricRow, precisionBits uint8) error {
if len(mrs) == 0 {
return nil
}
// 限制可能向存储添加行的并发 goroutine 数量
// 当太多的 goroutine 调用 AddRows 时，这应该可以防止内存不足错误和 CPU 抖动。
select {
// 如果写入 channel 成功，说明并发小于 CPU 最大核数，然后就可以走插入逻辑
// 如果没写入成功（也就是满了），则执行default case
case addRowsConcurrencyCh <- struct{}{}:
default: // 如果插入 channel 失败，说明某个 insert 操作的协程被阻塞，这时需要通知 select 协程去让出。
atomic.AddUint64(&s.addRowsConcurrencyLimitReached, 1)
t := timerpool.Get(addRowsTimeout) // 获取一个30s超时的timer
// 数据摄取优先级高于并发搜索
// pacelimiter（步长限制器）中有个原子累加的变量，表示有多少个 insert 操作在等待
// 走到这里证明有一个 insert 操作被阻塞了，调用 Inc，表示需要（Search操作）等待
storagepacelimiter.Search.Inc()
select { // 写入不成功或者还未超时就会阻塞在这里了
// 在超时的30s时间内，尝试去写入 channel 队列
case addRowsConcurrencyCh <- struct{}{}:
timerpool.Put(t) // 把 timer 放回对象池，减少 GC
// 可以成功写入 channel 了，那么可以执行 insert 操作了，则执行限制器的 Dec 操作，减一
storagepacelimiter.Search.Dec()
// 当限制器的等待数量为0的时候，会调用 cond.Broadcast() 去通知 select 协程开始工作。
case <-t.C: // 到30s超时时间了
// 把 timer 放回对象池，减少 GC timerpool.Put(t)
// 超时了那么当前的 insert 就报错了，等待的数量就可以减一了
storagepacelimiter.Search.Dec()
atomic.AddUint64(&s.addRowsConcurrencyLimitTimeout, 1) // 记录下超时次数
atomic.AddUint64(&s.addRowsConcurrencyDroppedRows, uint64(len(mrs))) // 记录没有被插入成功的 mr 数量
// 等待了30秒仍然没有CPU资源，只能报错
return fmt.Errorf("cannot add %d rows to storage in %s, since it is overloaded with %d concurrent writers; add more CPUs or reduce load",
len(mrs), addRowsTimeout, cap(addRowsConcurrencyCh))
}
}
// 下面是插入逻辑
// 一次插入不要太大
var firstErr error
ic := getMetricRowsInsertCtx()
maxBlockLen := len(ic.rrs)
for len(mrs) > 0 {
mrsBlock := mrs
// 如果要插入的 mrs 超过了最大长度
if len(mrs) > maxBlockLen {
// 则先插入最大长度的 mrs mrsBlock = mrs[:maxBlockLen]
// 剩下的 mrs 下次循环去处理
mrs = mrs[maxBlockLen:]
} else {
mrs = nil
}
// 执行真正的 add 操作
if err := s.add(ic.rrs, ic.tmpMrs, mrsBlock, precisionBits); err != nil {
if firstErr == nil {
firstErr = err
}
continue
}
// 记录下插入成功的 mrs 数量
atomic.AddUint64(&rowsAddedTotal, uint64(len(mrsBlock)))
}
// 放回对象池
putMetricRowsInsertCtx(ic)
<-addRowsConcurrencyCh // insert 逻辑执行完成后，出队
return firstErr
}
该函数的实现非常经典，会限制可能向存储添加数据的并发 goroutine 数量，当太多的 goroutine 调用 AddRows 时，可以防止内存不足错误和 CPU 抖动。这里实现了插入比查询更高的优先级，当资源不足时，查询操作会挂起让出资源给到插入操作使用。
获取 TSID
真正实现添加数据是下面的 add 函数，其中 rawRow 是原始的时序数据行，MetricRow 是要插入到存储中的行数据，该函数的核心就是要生成指标序列的 TSID 数据，如下所示：
// lib/storage/storage.go
func (s *Storage) add(rows []rawRow, dstMrs []*MetricRow, mrs []MetricRow, precisionBits uint8) error {
// 当前使用的索引
idb := s.idb()
j := 0
var (
// 这些变量用于加速同一 metricName 的多个相邻行的批量导入。
prevTSID TSID
prevMetricNameRaw []byte
)
var pmrs *pendingMetricRows
// 获取该数据块的最小时间和最大时间
minTimestamp, maxTimestamp := s.tb.getMinMaxTimestamps()
// 带有第几代索引信息的 TSID 对象
var genTSID generationTSID
// 只返回第一个错误，因为它返回所有错误没有意义
var firstWarn error
// 循环数据行，其实就是填充 rawRow 中的 TSID 数据
for i := range mrs {
mr := &mrs[i]
if math.IsNaN(mr.Value) { // 值为 NaN
if !decimal.IsStaleNaN(mr.Value) {
// 跳过 Prometheus staleness 标记以外的 NaN
// 因为底层编码不知道如何使用它们。
continue
}
}
// 如果指标的时间戳小于最小的时间戳
// 则跳过保留期外时间戳过小的行
if mr.Timestamp < minTimestamp {
......
continue
}
// 同样跳过超过最大时间戳的数据
if mr.Timestamp > maxTimestamp {
......
continue
}
dstMrs[j] = mr
r := &rows[j]
j++
r.Timestamp = mr.Timestamp
r.Value = mr.Value
r.PrecisionBits = precisionBits
// 快速路径 - 当前 mr 包含与前一 mr 相同的指标名称，因此它包含相同的 TSID。
if string(mr.MetricNameRaw) == string(prevMetricNameRaw) {
// 当许多行包含相同的 MetricNameRaw 时，应在批量导入时触发此路径。
r.TSID = prevTSID
continue
}
// 判断 TSID 是否在缓存中（命中缓存）
if s.getTSIDFromCache(&genTSID, mr.MetricNameRaw) {
r.TSID = genTSID.TSID
// 跳过该行，因为已超出唯一序列数的限制。
if s.isSeriesCardinalityExceeded(r.TSID.MetricID, mr.MetricNameRaw) {
j--
continue
}
// 快速路径 - 给定 MetricNameRaw 的 TSID 已在缓存中找到，并且未删除。
// 不需要检查 r.TSID.MetricID 是否已删除，因为 tsidCache 不包含已删除时间序列的 MetricName -> TSID 条目，可以查看 Storage.DeleteMetrics 的代码
prevTSID = r.TSID // 设置前一个 TSID 的值
prevMetricNameRaw = mr.MetricNameRaw // 设置前一个 MetricNameRaw 的值
// 找到的TSID不是当前代的索引（来自上一代缓存下来的索引）
if genTSID.generation != idb.generation {
// 索引需要尝试使用该 TSID 重新填充当前代的索引数据
// https://github.com/VictoriaMetrics/VictoriaMetrics/issues/1401
created, err := idb.maybeCreateIndexes(&genTSID.TSID, mr.MetricNameRaw)
if err != nil {
return fmt.Errorf("cannot create indexes in the current indexdb: %w", err)
}
if created {
// 如果填充成功，则将当前的 TSID 设置为当前代索引
genTSID.generation = idb.generation
// 重新将该 TSID -> MetricNameRaw 数据放回缓存，方便后面的序列处理
s.putTSIDToCache(&genTSID, mr.MetricNameRaw)
}
}
continue
}
// 慢速路径 - 缓存中缺少TSID
// 在下面的循环中推迟搜索
j--
if pmrs == nil {
// 初始化 pendingMetricRows
pmrs = getPendingMetricRows()
}
// 将 mr 数据添加到 pendingMetricRows 中去待处理
if err := pmrs.addRow(mr); err != nil {
// 错误时不要停止添加数据 - 只需跳过无效行即可。
// 这保证了无效行不会阻止将有效行添加到存储中去。
if firstWarn == nil {
firstWarn = err
}
continue
}
}
// 有指标的 TSID 没有在缓存中（上面的慢速路径）
if pmrs != nil {
// 按指标名称对 pendingMetricRows 进行排序，以便通过下面循环中的 “is” 加快搜索速度。
pendingMetricRows := pmrs.pmrs
sort.Slice(pendingMetricRows, func(i, j int) bool {
return string(pendingMetricRows[i].MetricName) < string(pendingMetricRows[j].MetricName)
})
//
is := idb.getIndexSearch(0, 0, noDeadline)
prevMetricNameRaw = nil // 接收前一个 MetricNameRaw
var slowInsertsCount uint64
for i := range pendingMetricRows {
pmr := &pendingMetricRows[i]
mr := pmr.mr // MetricRaw
dstMrs[j] = mr
r := &rows[j]
j++
r.Timestamp = mr.Timestamp
r.Value = mr.Value
r.PrecisionBits = precisionBits
// 快速路径 - 当前 mr 包含与前一个 mr 相同的指标名称，因此它包含相同的 TSID。
if string(mr.MetricNameRaw) == string(prevMetricNameRaw) {
// 当许多行包含相同的 MetricNameRaw 时，在批量导入时会触发该路径。
r.TSID = prevTSID
if s.isSeriesCardinalityExceeded(r.TSID.MetricID, mr.MetricNameRaw) {
// 跳过该行，因为已超出唯一序列数的限制
j--
continue
}
continue
}
// 慢速路径
slowInsertsCount++ // 记录慢插入次数
// 通过 MetricName 去获取（没有就创建）TSID 数据
if err := is.GetOrCreateTSIDByName(&r.TSID, pmr.MetricName); err != nil {
if firstWarn == nil {
firstWarn = fmt.Errorf("cannot obtain or create TSID for MetricName %q: %w", pmr.MetricName, err)
}
j--
continue
}
// 设置 genTSID 为当前生成的 TSID
genTSID.generation = idb.generation
genTSID.TSID = r.TSID
// 返回缓存
s.putTSIDToCache(&genTSID, mr.MetricNameRaw)
// 缓存当前的 TSID 和 MetricNameRaw，方便下一条序列快速处理
prevTSID = r.TSID
prevMetricNameRaw = mr.MetricNameRaw
if s.isSeriesCardinalityExceeded(r.TSID.MetricID, mr.MetricNameRaw) {
// 跳过该行，因为已超出唯一序列数的限制
j--
continue
}
}
// 回收对象
idb.putIndexSearch(is)
putPendingMetricRows(pmrs)
atomic.AddUint64(&s.slowRowInserts, slowInsertsCount)
}
// 提示错误信息
if firstWarn != nil {
logger.WithThrottler("storageAddRows", 5*time.Second).Warnf("warn occurred during rows addition: %s", firstWarn)
}
dstMrs = dstMrs[:j]
rows = rows[:j]
// TSID 填充完成，可以插入数据了
var firstError error
if err := s.tb.AddRows(rows); err != nil {
firstError = fmt.Errorf("cannot add rows to table: %w", err)
}
if err := s.updatePerDateData(rows, dstMrs); err != nil && firstError == nil {
firstError = fmt.Errorf("cannot update per-date data: %w", err)
}
if firstError != nil {
return fmt.Errorf("error occurred during rows addition: %w", firstError)
}
return nil
}
首先循环数据，把时间戳过小或过大的都过滤掉，然后就是想办法尽可能快地获取到指标的 TSID：
快速路径 - 当前 MetricRow 包含与前一 MetricRow 相同的指标名称，因此它们具有相同的 TSID，所以直接将当前对象的 TSID 设置成前一个 TSID，这是最快的方式。 如果和前一个指标名称不一样，则去查看 genTSID 是否在缓存中（命中缓存） 如果命中缓存则 genTSID 中的 TSID 就是我们需要的，同时也将其设置为前一个 prevTSID。如果该 TSID 不是当代的索引（来自上一代缓存下来的索引），则需要尝试使用该 TSID 重新填充当代的索引数据，这和索引轮换有关，后面会详细说明。 如果没有命中缓存，则属于慢速路径，将当前数据添加到 pendingMetricRows中去待处理循环了所有指标数据后，接下来需要处理 pendingMetricRows中的数据，也就是缓存中没有对应的 TSID，此时就需要我们去生成对应的 TSID 数据。快速路径 - 同样是当前 MetricRow 与前一个 MetricRow 的指标名称相同，因此它包含相同的 TSID，直接设置成前一个 TSID 即可。 慢速路径 - 走到这个分支则只能去创建 TSID 了，通过 MetricName 去获取（没有就创建）TSID 数据，也就是上面的 GetOrCreateTSIDByName函数。获取后记得放到缓存中去。
上面费了很大的功夫就是为了获取时间序列对应的 TSID 数据的，这也是插入数据过程中最可能出现慢插入的地方，因为该过程涉及到索引，比较耗时间，如果你插入的数据出现大量的高基数序列（比如包含一些随机生成的 ID 作为标签），则会大大降低 vmstorage 的插入性能。
我们可以去查看下 GetOrCreateTSIDByName 函数的实现。
// lib/storage/index_db.go
// GetOrCreateTSIDByName 使用指定 metricName 的 TSID 填充 dst。
func (is *indexSearch) GetOrCreateTSIDByName(dst *TSID, metricName []byte) error {
// hack：在多次连续未命中后跳过 TSID 的搜索
// 这将提高大批量新时间序列的插入性能。
if is.tsidByNameMisses < 100 {
err := is.getTSIDByMetricName(dst, metricName)
if err == nil {
is.tsidByNameMisses = 0
return nil
}
if err != io.EOF {
return fmt.Errorf("cannot search TSID by MetricName %q: %w", metricName, err)
}
is.tsidByNameMisses++
} else {
is.tsidByNameSkips++
if is.tsidByNameSkips > 10000 {
is.tsidByNameSkips = 0
is.tsidByNameMisses = 0
}
}
// 找不到给定名称的 TSID，创建它。
// 如果 mn 的重复 TSID 是由并发 goroutines 创建的，那么这也是可以的。
// 指标结果将在表搜索 TableSearch 后由 mn 合并。
if err := is.db.createTSIDByName(dst, metricName); err != nil {
return fmt.Errorf("cannot create TSID by MetricName %q: %w", metricName, err)
}
return nil
}
// 根据 metricName 去搜索 TSID
func (is *indexSearch) getTSIDByMetricName(dst *TSID, metricName []byte) error {
dmis := is.db.s.getDeletedMetricIDs()
ts := &is.ts // TableSearch
kb := &is.kb
kb.B = append(kb.B[:0], nsPrefixMetricNameToTSID) // MetricName -> TSID 的前缀
kb.B = append(kb.B, metricName...)
kb.B = append(kb.B, kvSeparatorChar)
ts.Seek(kb.B) // Seek 查找 ts 中大于或等于 k 的第一项
for ts.NextItem() { // 循环查找
if !bytes.HasPrefix(ts.Item, kb.B) { // ts.Item 不是以 kb.B 为前缀
// 没找到
return io.EOF
}
v := ts.Item[len(kb.B):] // 获得尾部的值
tail, err := dst.Unmarshal(v) // 填充dst
if err != nil {
return fmt.Errorf("cannot unmarshal TSID: %w", err)
}
if len(tail) > 0 { // 尾部还有值
return fmt.Errorf("unexpected non-empty tail left after unmarshaling TSID: %X", tail)
}
if dmis.Len() > 0 { // 有标记删除的 MetricID 列表
// 验证 dst 是否标记为已删除。
if dmis.Has(dst.MetricID) {
// dst 被删除了，继续搜索。
continue
}
}
// 找到了有效的 dst
return nil
}
if err := ts.Error(); err != nil {
return fmt.Errorf("error when searching TSID by metricName; searchPrefix %q: %w", kb.B, err)
}
// 什么都没发现
return io.EOF
}
该函数会获取 metricName 对应的 TSID，但是可能会出现多次连续未命中的情况，为了提高性能，这里做了一点 hack，如果连续未查询到 TSID 100 次则跳过搜索，就只能去创建 TSID 了，如果跳过了 10000 次则又重置可以重新去搜索。
搜索 TSID 是通过下面的 getTSIDByMetricName 函数来实现的，创建 TSID 是通过 createTSIDByName 函数实现的。
TSID 的生成方法如下所示：
// lib/storage/index_db.go
// 根据指定的 metricName 创建 TSID
func (db *indexDB) createTSIDByName(dst *TSID, metricName []byte) error {
mn := GetMetricName()
defer PutMetricName(mn)
if err := mn.Unmarshal(metricName); err != nil {
return fmt.Errorf("cannot unmarshal metricName %q: %w", metricName, err)
}
// 创建 TSID
created, err := db.getOrCreateTSID(dst, metricName, mn)
if err != nil {
return fmt.Errorf("cannot generate TSID: %w", err)
}
// TSID 创建后要创建索引，这一步是最耗时的
if err := db.createIndexes(dst, mn); err != nil {
return fmt.Errorf("cannot create indexes: %w", err)
}
// 不需要使 tag 缓存无效，因为它在 db 上无效，tb 通过传递给 OpenTable 的invalidateTagFiltersCache flushCallback 刷新。
if created {
// 仅当 indexDB 中未找到 tsid 时，才增加 newTimeseriesCreated 计数器
atomic.AddUint64(&db.newTimeseriesCreated, 1)
if logNewSeries {
logger.Infof("new series created: %s", mn.String())
}
}
return nil
}
// getOrCreateTSID 在 db.extDB 中查找指定 metricName 的 TSID
// 如果找不到任何内容，则创建新的 TSID
//
// 如果 TSID 已创建，则返回 true；如果 TSID 在 extDB 中，则返回 false
func (db *indexDB) getOrCreateTSID(dst *TSID, metricName []byte, mn *MetricName) (bool, error) {
// 在外部存储中搜索 TSID
// 这个 db 通常来自上一个时期
var err error
// 相当于去上一个索引 db 中查找 TSID
if db.doExtDB(func(extDB *indexDB) {
err = extDB.getTSIDByNameNoCreate(dst, metricName)
}) {
if err == nil {
// 已在外部存储中找到 TSID
return false, nil
}
if err != io.EOF {
return false, fmt.Errorf("external search failed: %w", err)
}
}
// 在外部存储中找不到 TSID，在本地生成。
generateTSID(dst, mn)
return true, nil
}
// 生成 TSID 数据
func generateTSID(dst *TSID, mn *MetricName) {
dst.AccountID = mn.AccountID
dst.ProjectID = mn.ProjectID
// 根据 MetricName 中的 MetricGroup 使用 xxhash 的 sum64 算法生成。
dst.MetricGroupID = xxhash.Sum64(mn.MetricGroup)
// 假设 job-like metric 放在 mn.Tags[0]，而 instance-like metric 放在 mn.Tags[1]
// 这个假设是正确的，因为 mn.Tags 必须在调用 generateTSID() 函数之前使用 mn.sortTags() 进行排序。
// 这允许对磁盘上彼此靠近的相同（job、instance）的数据块进行分组。
// 当从磁盘读取相同 job 和/或 instance 的数据块时，这会减少磁盘寻道和磁盘读取 IO。
// 例如，与 `process_resident_memory_bytes{job="vmstorage"}` 匹配的时间序列的数据块在磁盘上是物理相邻的。
if len(mn.Tags) > 0 {
dst.JobID = uint32(xxhash.Sum64(mn.Tags[0].Value)) // 第一个Tag规定为 JobID
}
if len(mn.Tags) > 1 {
dst.InstanceID = uint32(xxhash.Sum64(mn.Tags[1].Value)) // 第二个Tag规定为 InstanceID
}
dst.MetricID = generateUniqueMetricID() // 生成唯一的指标ID
}
MetricID 通过 generateUniqueMetricID() 生成, 在重启时, nextUniqueMetricID 被赋值为当时的时间戳, 随后每次新的 TSID 的创建都会在此基础之上+1。
// lib/storage/index_db.go
// 生成唯一的 MetricID
func generateUniqueMetricID() uint64 {
// 期望的是从此函数返回的 metricID 必须是密集的。
// 如果它们是稀疏的，那么这可能会损害 metric_ids 与 uint64set.Set 的交集性能。
return atomic.AddUint64(&nextUniqueMetricID, 1)
}
// 该数在重新启动时不能倒退，否则可能会发生 metricID 冲突。
// 所以不要在 VictoriaMetrics 重新启动期间更改服务器上的时间。
var nextUniqueMetricID = uint64(time.Now().UnixNano())
但是我们可能在这里看不懂 TSID 是如何去搜索或者创建的，这就需要我们去了解下 VM 中的倒排索引了。
倒排索引
当创建完 TSID 后, 需要建立一系列的索引供查找时使用。在 VM 中不同类型的索引都是通过 KV 关系来描述，在代码中称为 Item , Item 的结构如下:
在 VM 中 Item 的整体上是一个 KV 结构的字节数组，共计有 7 种类型，每种类型的 Item 通过固定前缀来区分，前缀类型如下图所示。
在 storage/index_db.go: createIndexes 函数中，去分别建立了各个索引，生成 Items，代码如下所示：
// lib/storage/index_db.go
// 创建索引
func (db *indexDB) createIndexes(tsid *TSID, mn *MetricName) error {
// 索引 items 的顺序很重要，它保证了索引的一致性。
ii := getIndexItems()
defer putIndexItems(ii)
// 创建 MetricName -> TSID 的索引。
ii.B = append(ii.B, nsPrefixMetricNameToTSID) // 前缀
ii.B = mn.Marshal(ii.B)
ii.B = append(ii.B, kvSeparatorChar) // 分隔符
ii.B = tsid.Marshal(ii.B)
ii.Next()
// 创建 MetricID -> MetricName 索引。
ii.B = marshalCommonPrefix(ii.B, nsPrefixMetricIDToMetricName, mn.AccountID, mn.ProjectID)
ii.B = encoding.MarshalUint64(ii.B, tsid.MetricID)
ii.B = mn.Marshal(ii.B)
ii.Next()
// 创建 MetricID -> TSID 索引
ii.B = marshalCommonPrefix(ii.B, nsPrefixMetricIDToTSID, mn.AccountID, mn.ProjectID)
ii.B = encoding.MarshalUint64(ii.B, tsid.MetricID)
ii.B = tsid.Marshal(ii.B)
ii.Next()
// 创建 Tag -> MetricID 索引
prefix := kbPool.Get()
prefix.B = marshalCommonPrefix(prefix.B[:0], nsPrefixTagToMetricIDs, mn.AccountID, mn.ProjectID)
ii.registerTagIndexes(prefix.B, mn, tsid.MetricID)
kbPool.Put(prefix)
// 将 Items 添加到 Table 中去
return db.tb.AddItems(ii.Items)
}
对于 ask{market="NYSE",ticker="GOOG"} 1.23 的时序指标，对应的 MetricName 为 AccountID=0, ProjectID=0, ask{market="NYSE",ticker="GOOG"}，假设生成的 TSID 为：
{
AccountID: 0
ProjectID: 0
MetricGroupID: 6661248876682682060
JobID: 3817370224
InstanceID: 4166188337
MetricID: 1654132102944898001
}
则生成的索引 Item 逻辑结构如下图所示：
上图为构建的 MetricName -> TSID 的索引，前缀为 nsPrefixMetricNameToTSID=0，整个索引项就是一个 key: value 的形式，key 为 MetricName 编码后的值，value 为 TSID 编码后的值，中间通过一个 kvSeparator 的分隔符进行连接，当然这些值真正的存储形式都是 []byte。除了上图的这个索引之外还有几个其他的索引：MetricID -> MetricName、MetricID -> TSID、Tag -> MetricID，方式都是一样的，只是要注意每种索引的前缀是不一样的。最后得到的索引就是上面构建的几种索引的集合数组。
索引构建完成后又是如何去持久化数据的呢？保存的数据又是怎样的格式呢？未完待续吧......