04.InfluxDB系统化学习-TSDBStore

本文主要是介绍04.InfluxDB系统化学习-TSDBStore，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

概述

在《02.InfluxDB系统化学习-InfluxDB初始化》讲述了influxdb数据启动过程中加载的服务，其中在

cmd/influxdb/run/server.go中创建tsdb.NewStore对象时有以下代码：

    // 初始化存储结构--NewServer(c *Config, buildInfo *BuildInfo)
    s.TSDBStore = tsdb.NewStore(c.Data.Dir)
    s.TSDBStore.EngineOptions.Config = c.Data    // Open TSDB store.--初始化tsdb数据文件--func (s *Server) Open()
    if err := s.TSDBStore.Open(); err != nil {
        return fmt.Errorf("open tsdb store: %s", err)
    }

来自官网的说明：

The storage engine ties a number of components together and provides the external interface for storing and querying series data. It is composed of a number of components that each serve a particular role:

• In-Memory Index - The in-memory index is a shared index across shards that provides the quick access to measurements, tags, and series. The index is used by the engine, but is not specific to the storage engine itself.
• WAL - The WAL is a write-optimized storage format that allows for writes to be durable, but not easily queryable. Writes to the WAL are appended to segments of a fixed size.
• Cache - The Cache is an in-memory representation of the data stored in the WAL. It is queried at runtime and merged with the data stored in TSM files.
• TSM Files - TSM files store compressed series data in a columnar format.
• FileStore - The FileStore mediates access to all TSM files on disk. It ensures that TSM files are installed atomically when existing ones are replaced as well as removing TSM files that are no longer used.
• Compactor - The Compactor is responsible for converting less optimized Cache and TSM data into more read-optimized formats. It does this by compressing series, removing deleted data, optimizing indices and combining smaller files into larger ones.
• Compaction Planner - The Compaction Planner determines which TSM files are ready for a compaction and ensures that multiple concurrent compactions do not interfere with each other.
• Compression - Compression is handled by various Encoders and Decoders for specific data types. Some encoders are fairly static and always encode the same type the same way; others switch their compression strategy based on the shape of the data.
• Writers/Readers - Each file type (WAL segment, TSM files, tombstones, etc..) has Writers and Readers for working with the formats.

翻译如下：

一个TSM存储引擎包含：

In-Memory Index 在shard之间共享，提供measurements，tags，和series的索引

WAL 同其他database的binlog一样，当WAL的大小达到一定大小后，会重启开启一个WAL文件。

Cache 内存中缓存的WAL，加速查找

TSM Files 压缩后的series数据

FileStore TSM Files的封装

Compactor 存储数据的比较器

Compaction Planner 用来确定哪些TSM文件需要compaction，同时避免并发compaction之间的相互干扰

Compression 用于压缩持久化文件

Writers/Readers 用于访问文件

该代码主要是完成tsdb相关的创建和初始化，本节主要是针对tsdb做详细的介绍。

整体架构

当一个point写入时，influxdb根据其所属的database、measurements和timestamp选取一个对应的shard。每个 shard对应一个TSM存储引擎。每个shard对应一段时间范围的存储。

shard通过CreateShard 来创建。可以看出其依次创建了所需的文件目录，然后创建Index 和Shard 数据结构。

DataBase

数据库名，在 InfluxDB 中可以创建多个数据库，不同数据库中的数据文件是隔离存放的，存放在磁盘上的不同目录。

语法如下

CREATE DATABASE <database_name> [WITH [DURATION <duration>] [REPLICATION <n>] [SHARD DURATION <duration>] [NAME <retention-policy-name>]]

Retention Policy（RP）

存储策略，用于设置数据保留的时间，每个数据库刚开始会自动创建一个默认的存储策略 autogen，数据保留时间为永久，之后用户可以自己设置。插入和查询数据时如果不指定存储策略，则使用默认存储策略，且默认存储策略可以修改。InfluxDB 会定期清除过期的数据。核心作用有3个：指定数据的过期时间，指定数据副本数量以及指定ShardGroup Duration。

语法如下

CREATE RETENTION POLICY <retention_policy_name> ON <database_name> DURATION <duration> REPLICATION <n> [SHARD DURATION <duration>] [DEFAULT]

DURATION子句确定InfluxDB保留数据的时间。 <duration>是持续时间字符串或INF（无限）。 保留策略的最短持续时间为1小时，最大持续时间为INF。

REPLICATION子句确定每个点的多少独立副本存储在集群中，其中n是数据节点的数量。该子句不能用于单节点实例。

SHARD DURATION子句确定shard group覆盖的时间范围。 <duration>是一个持续时间字符串，不支持INF（无限）持续时间。此设置是可选的。 默认情况下，shard group持续时间由保留策略的DURATION决定：

Retention Policy’s DURATION	Shard Group Duration
< 2 days	1 hour
>= 2 days and <= 6 months	1 day
> 6 months	7 days

// shardGroupDuration returns the default duration for a shard group based on a policy duration.
func shardGroupDuration(d time.Duration) time.Duration {
    if d >= 180*24*time.Hour || d == 0 { // 6 months or 0
        return 7 * 24 * time.Hour
    } else if d >= 2*24*time.Hour { // 2 days
        return 1 * 24 * time.Hour
    }
    return 1 * time.Hour
}
// normalisedShardDuration returns normalised shard duration based on a policy duration.
func normalisedShardDuration(sgd, d time.Duration) time.Duration {
    // If it is zero, it likely wasn't specified, so we default to the shard group duration
    if sgd == 0 {
        return shardGroupDuration(d)
    }
    // If it was specified, but it's less than the MinRetentionPolicyDuration, then normalize
    // to the MinRetentionPolicyDuration
    if sgd < MinRetentionPolicyDuration {
        return shardGroupDuration(MinRetentionPolicyDuration)
    }
    return sgd
}

最小允许SHARD GROUP DURATION为1小时。 如果CREATE RETENTION POLICY查询尝试将SHARD GROUP DURATION设置为小于1小时且大于0，则InfluxDB会自动将SHARD GROUP DURATION设置为1h。 如果CREATE RETENTION POLICY查询尝试将SHARD GROUP DURATION设置为0，InfluxDB会根据上面列出的默认设置自动设置SHARD GROUP DURATION。

DEFAULT将新的保留策略设置为数据库的默认保留策略。此设置是可选的。

特点如下

1. RP是数据库级别而不是表级别的属性。这和很多数据库都不同。

2. 每个数据库可以有多个数据保留策略，但只能有一个默认策略。

3. 不同表可以根据保留策略规划在写入数据的时候指定RP进行写入，下面语句就指定six_mouth_rollup的rp进行写入：

curl -X POST 'http://localhost:8086/write?db=mydb&rp=six_month_rollup' --data-binary 'disk_free,hostname=server01 value=442221834240i 1435362189575692182'

4. 如果没有指定任何RP，则使用默认的RP。

Shard Group

Shard Group是InfluxDB中一个重要的逻辑概念，从字面意思来看Shard Group会包含多个Shard，每个Shard Group只存储指定时间段的数据，不同Shard Group对应的时间段不会重合。每个Shard Group对应多长时间是通过Retention Policy中字段”SHARD DURATION”指定的，如果没有指定，也可以通过Retention Duration（数据过期时间）计算出来。

设计Shard Group的目的

1. 将数据按照时间分割成小的粒度会使得数据过期实现非常简单，InfluxDB中数据过期删除的执行粒度就是Shard Group，系统会对每一个Shard Group判断是否过期，而不是一条一条记录判断。

2. 实现了将数据按照时间分区的特性。将时序数据按照时间分区是时序数据库一个非常重要的特性，基本上所有时序数据查询操作都会带有时间的过滤条件，比如查询最近一小时或最近一天，数据分区可以有效根据时间维度选择部分目标分区，淘汰部分分区。

Shard

         Shard Group实现了数据分区，但是Shard Group只是一个逻辑概念，在它里面包含了大量Shard，Shard才是InfluxDB中真正存储数据以及提供读写服务的概念，类似于HBase中Region，Kudu中Tablet的概念。在 InfluxDB 中按照数据的时间戳所在的范围，会去创建不同的 shard，每一个 shard 都有自己的 cache、wal、tsm file 以及 compactor，这样做的目的就是为了可以通过时间来快速定位到要查询数据的相关资源，加速查询的过程，并且也让之后的批量删除数据的操作变得非常简单且高效。

       删除：在 LSM Tree 中删除数据是通过给指定 key 插入一个删除标记的方式，数据并不立即删除，需要等之后对文件进行压缩合并时才会真正地将数据删除，所以删除大量数据在 LSM Tree 中是一个非常低效的操作。而在 InfluxDB 中，通过 retention policy 设置数据的保留时间，当检测到一个 shard 中的数据过期后，只需要将这个 shard 的资源释放，相关文件删除即可，这样的做法使得删除过期数据变得非常高效。

1. Shard是InfluxDB的存储引擎实现，具体称之为TSM(Time Sort Merge Tree) Engine，负责数据的编码存储、读写服务等。TSM类似于LSM，因此Shard和HBase Region一样包含Cache、WAL以及Data File等各个组件，也会有flush、compaction等这类数据操作。

2. InfluxDB采用了Hash分区的方法将落到同一个Shard Group中的数据再次进行了一次分区。这里特别需要注意的是ÿ

这篇关于04.InfluxDB系统化学习-TSDBStore的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---