一、设计原则
InfluxDB是一个时间序列数据库，其性能优化方向为大规模、高效的时间序列数据的插入及查询操作。经权衡，部分场景下需要以牺牲功能为代价来提高性能，以下列出了部分设计理念：
1、数据按时间戳顺序存储，不允许重复数据存在。
2、数据删除是低频操作，批量数据删除除外；
3、数据更新是低频操作，实际场景很少发生；对某一数据的持续更新，不应该发生；绝大多数的数据都是新产生的数据，而且不会发生变化；
4、数据写入的时间戳接近当前时间，数据写入顺序与数据时间戳顺序一致；
5、数据规模至关重要，数据库性能优化，主要针对大规模的写入和读取操作，而不是更新和删除操作；
6、数据库可用性高于强一致性；
7、很多时间序列都是短暂，而不是永恒的产生数据；
8、不需要特别关注某个时刻的数据，从整体分析数据趋势才更重要；
二、基本概念
时间序列数据库，有一些特有的概念。其实只需要正确理解measurement、tag、series和存储文件之间的关系就可以比较容易的理解整个系统了。
| 概念 | 解释 | 对应于SQL |
| 时间戳timestamp |
在InfluxDB里的所有时间都是UTC的，时间戳timestamp就是一个UTC时刻下，某一序列series在该时刻的全部数据的唯一标识。知道了时间戳timestamp就可以获取序列series下指定时间的数据点point，这也意味着同一series下时间戳不允许重复。 同一个序列series中，两个相同时间戳数据的写入，会触发数据更新及数据合并； |
类似于SQL中的自增主键，但是时间戳类型的 |
| 数据点point |
一个序列series中，具有相同timestamp的的field数据集合。也就是说在同一个series中同一个timestamp的数据点point只会出现一次（可以视为在series中数据点以时间戳timestamp为主键存储）。 数据点可以保存一个measurement的field的一个或多个，也可以随时增加新的field。但对于已存储的数据，不允许修改数据类型。 |
类似于SQL中的一行记录 |
| 数据库database | 一个包含schema、时序数据、数据保留策略、持续查询、用户、权限的逻辑集合。 | 类似于SQL中的数据库 |
| 模式schema | schema包含database，retention policy，series，measurement，tag key，tag value以及field keys，其确定了在InfluxDB里面如何组织数据。 | 对应于SQL的数据库模式+表模式 |
| 度量measurement |
用于描述数据如何保存的数据结构，包含了tag，field和时间序列数据。measurement是字符串。 一个度量measurement可以有不同的存续策略retention policy。 |
对用于SQL的表 |
| 序列series |
measurement中的逻辑的数据分组，也是实际的数据存储分组。由shared measurement，tag set和feild key组成，不包含field value。 换句话就是，在InfluxDB中，数据不是按measurement存的，而是按series存的。 |
类似于SQL中按某一列的值，进行分表操作 |
| 序列候选series cardinality |
在InfluxDB实例中，由database、measurement、tag set、field key确定的不重复的组合数量。 举例说明一下：比如记录一个人员信息的measurement，只有两个tag（性别和是否已就业），其中性别为2个可选值（M、F），是否已就业为2个可选值（Y、N），那么这个measurement下会存在2×2共4个series cardinality。而实际存储时，数据也会按每个series进行处理。 |
类似于SQL中按某一列的值，可以分表的数量 |
| field | InfluxDB数据中记录metadata和数据的键值对。field数量必须大于0，不支持无索引。 | 对应于SQL的无索引列 |
| field set | 数据点上field key和field value的集合。 | 对应于SQL的无索引列名称和数值的集合 |
| field key | 组成field的键值对里面的键的部分。field key是字符串且保存在metadata中。 | 对应于SQL的无索引列的名称 |
| field value |
组成field的键值对里面的值的部分。field value才是真正的数据，可以是字符串，浮点数，整数，布尔型数据。 一个field value总是和一个timestamp相关联。 field value不会被索引，如果要对field value做过滤话，那就必须遍历所选时间范围里面的所有数据点，这种方式对比与tag效率会差很多。 |
对应于SQL的无索引列的值 |
| tag | InfluxDB数据中记录metadata的键值对。tags用于存储常用的metadata，在InfluxDB的数据中是可选的。tags会被索引，因此tag上的查询是很高效的。 | 对应于SQL的索引列 |
| tag set | 数据点上tag key和tag value的集合。 | 对应于SQL的无索引列名称和数值的集合 |
| tag key | 组成tag的键值对中的键部分，tag key是字符串，存在metadata中。 | 对应于SQL的无索引列名称 |
| tag value | 组成tag的键值对中的值部分，tag value是字符串，存在metadata中。 | 对应于SQL的无索引列数值 |
| 分片shard | 在分布式部署的情况下，shard决定了数据要存几份以及存在哪里。shard中包含实际的编码和压缩数据，并由磁盘上的TSM文件表示。每个shard都属于唯一的一个shard group。一个shard group中可以有1到多个shard。每个shard包含一组特定的序列series。同一shard group中的同一series上的所有点将存储在磁盘上的相同shard（TSM文件）中。 | 和SQL不太一样，有些类似于kafka分布式存储partition的机制 |
| 分片存续期间shard duration |
shard duration决定了每个shard group跨越多少时间。具体间隔由retention policy中的SHARD DURATION决定。 例如，如果retention policy的SHARD DURATION设置为1w，则每个shard group将跨越一周，并包含时间戳在该周内的所有点。之前的数据将被删除。 |
和SQL不太一样，有些类似于kafka中日志保留时间log.retention.hours |
| 分片组shard group |
shard group是shard的逻辑组合。shard group由时间和retention policy组织。 包含数据的retention policy至少包含一个关联的shard group。 一个shard group包含shard group覆盖的间隔的数据的所有shard。 每个shard group跨越的间隔是shard的持续时间。 |
这个和kafka分组就差别很大了 |
| 存续策略retention policy |
描述了InfluxDB保存数据的长短(duration)，数据存在集群里面的副本数(replication factor)，以及shard group的时间范围(shard group duration)。 当新建database的时候，InfluxDB会自动创建一个叫做autogen的retention policy，其duration为永远，replication factor为1，shard group的duration设为的7天。 retention policy在每个database里面是唯一的，是series的重要组成部分。 |
|
| TSM(Time Structured Merge tree) | 一种InfluxDB的专用数据存储格式，比现有的B+或LSM树实现更大的压缩和更高的写入和读取吞吐量。 | 存储结果，类似于SQL中的B+树，或KV数据库中的LSM树。 |
| 每秒写入量values per second |
InfluxDB数据持久化速度的度量，等于将每秒写入的数据点数 乘以 每个数据点存储的值的数量。 例如，如果数据共有四个field，并且每秒处理10个batch，每个batch是5000个数据点。那么每秒10个batch x 每batch5000个数据点 x values per second是每数据点4个field =每秒200,000个值。 |
|
| 数据点缓存WAL(Write Ahead Log) |
为了TSM数据文件访问频率，InfluxDB将最新的数据点缓存在WAL中，直到其总大小或时间达到系统阈值，会触发将数据以batch的方式写入到TSM文件中。 WAL中的数据点是可以被查询的。 而且WAL中的树节点已经完成了持久化，系统重启后仍然会被保留。InfluxDB进程启动时，会确保WAL中的所有点都写入到TSM中，然后才会接受新的数据写入，。 |
WAL与TSM的关系，和SQL日志以及B+树关系有些相似。 |
| 持续查询Continuous Query(CQ) |
Continuous Query(CQ)是在数据库内部，自动的周期性运行的一个InfluxQL的查询。 Continuous Query(CQ)需要在SELECT语句中使用一个函数，并且一定包括一个GROUP BY time()语句。 |
有些类似于SQL中的存储过程+JOB |
| 桶bucket |
在InfluxDB 2.0中，桶是一个有命名的，时间序列数据存储位置。 在InfluxDB 1.8+版本中, 一个database和一个retention policy的组合就代表了一个桶bucket。 |
2.0新增概念 |
三、数据存储对比
我们以官方文档中的foodships表为例子：
包含了3个带索引里的列park_id，planet，and time；和一个不带索引的列#_foodships。
在SQL里，foodships表看起来是这个样子的：
+---------+---------+---------------------+--------------+ | park_id | planet | time | #_foodships | +---------+---------+---------------------+--------------+ | 1 | Earth | 1429185600000000000 | 0 | | 1 | Earth | 1429185601000000000 | 3 | | 1 | Earth | 1429185602000000000 | 15 | | 1 | Earth | 1429185603000000000 | 15 | | 2 | Saturn | 1429185600000000000 | 5 | | 2 | Saturn | 1429185601000000000 | 9 | | 2 | Saturn | 1429185602000000000 | 10 | | 2 | Saturn | 1429185603000000000 | 14 | | 3 | Jupiter | 1429185600000000000 | 20 | | 3 | Jupiter | 1429185601000000000 | 21 | | 3 | Jupiter | 1429185602000000000 | 21 | | 3 | Jupiter | 1429185603000000000 | 20 | | 4 | Saturn | 1429185600000000000 | 5 | | 4 | Saturn | 1429185601000000000 | 5 | | 4 | Saturn | 1429185602000000000 | 6 | | 4 | Saturn | 1429185603000000000 | 5 | +---------+---------+---------------------+--------------+
但在InfluxDB中，要按索引列也就是tag划分series，每个series要按时间存储，看起来是这样的：
name: foodships tags: park_id=1, planet=Earth time #_foodships ---- ------------ 2015-04-16T12:00:00Z 0 2015-04-16T12:00:01Z 3 2015-04-16T12:00:02Z 15 2015-04-16T12:00:03Z 15 name: foodships tags: park_id=2, planet=Saturn time #_foodships ---- ------------ 2015-04-16T12:00:00Z 5 2015-04-16T12:00:01Z 9 2015-04-16T12:00:02Z 10 2015-04-16T12:00:03Z 14 name: foodships tags: park_id=3, planet=Jupiter time #_foodships ---- ------------ 2015-04-16T12:00:00Z 20 2015-04-16T12:00:01Z 21 2015-04-16T12:00:02Z 21 2015-04-16T12:00:03Z 20 name: foodships tags: park_id=4, planet=Saturn time #_foodships ---- ------------ 2015-04-16T12:00:00Z 5 2015-04-16T12:00:01Z 5 2015-04-16T12:00:02Z 6 2015-04-16T12:00:03Z 5
四、schema设计原则
1、建议将meta data做成tag
2、建议不要用数据关键字作为tag或field的名称
3、不建议使用过多的series
4、不建议tag和field采用相同名称
5、不建议用measurement的名称作为区分数据的依据
6、不建议在一个tag中塞入多个分类的信息
五、小结
基于以上原则和概念，我们对时间序列数据库有了一个初步的认识：
1、InfluxDB是一个无模式(schemaless)的数据库，你可以在任意时间添加measurement，tags和fields，但对于已存储的数据，是不允许修改数据类型的
2、对比与SQL数据库，InfluxDB其实更接近与KV数据库，而且InfluxDB对列扩展的支持是十分好的
3、和SQL不同，不支持跨measurement的JOIN
4、measurement和series的关系，是通过tag来划分的，这是和SQL十分不一样的地方
5、InfluxDB中数据分两大类tag和field，其中：tag是用来划分series用的，只能是数量可控的字符串，而且支持索引；field是真正用于数据存储的
6、由于优先考虑数据插入及数据查询的性能，而不是数据更新和数据删除，InfluxDB不能算一个完整的CRUD数据库，更像是一个CR-ud数据库：
更新某个数据点时，只需要在同一个时间戳下重复insert一次数据；
删除某个数据点时，是无法根据field的值进行删除操作的，遇到这种情况就需要先进行一次查询，然后通过时间戳进行删除；
不允许更新或重命名tag，遇到这种情况需要新建一个tag，迁移数据后，drop原tag的series；
不允许通过tag key删除tag，但可以直接drop整个series；
7、单条数据的更新和删除操作，尽量少做，效率比较低
8、时间戳及其重要，数据的组织是按时间戳进行的
9、支持数据分片、数据保存时间、数据保存份数的设置
10、十分适合按时间为维度进行采样、生产和更新的系统