influxDb是一个高性能的时序数据库，主要特性：

 

• 专为时序数据设计的高性能数据仓储，TSM引擎可以实现高吞吐速度与数据压缩率；
• 完全使用go编写并且被编译为一个独立的二进制文件，没有任何其它外部依赖；
• 简单、性能优良的http API；
• 通过插件可以实现对其它数据库协议的接入，如Graphite, collectd, and OpenTSDB；
• 为方便数据聚合查询而定制设计的类似于SQL的查询语言；
• Tags使得series能够被迅速而高效地检索；
• 可以高效地淘汰过期数据的保留策略；
• 连续查询（continuous queries）功能可以自动定时聚合数据，使得需要频繁执行的检索更加高效。

一、数据库设计trade-off

influxdb作为时序数据库，其优异的性能表现是以损失部分功能性作为代价的，具体如下：

 

 1. 基于时序数据库的特点，如果多次收到同一条数据，influxdb会把它当作一条数据处理。

提升：简化了冲突处理，提高了写入性能；

缺陷：不能存储相同的数据，某些极端情况下会发生数据覆盖。

 

 2. 删除数据是极少发生的，一旦发生，通常发生在较大范围的时间尺度内，而且一般都是比较老的、不需要继续写入的数据中。

提升：禁止删除操作，从而提高读写性能；

缺陷：删除功能被直接禁止。

 

 3. 对时序数据的更新很少发生，因为更新造成的冲突也不会出现。基于时序的数据大都是新的数据，并不需要更新。

提升：禁用更新提高了读写性能；

缺陷：更新功能被直接禁止。

 

 4. 大量的主要写入都是来自最近时间截的数据并且以升序添加至数据库中。

提升：以升序存入数据性能会很好；

缺陷：如果数据以随机顺序或者不是升序存入，会导致性能损失。

 

 5. 数据规模是很重要的指标，数据库必须能够处理大数据量的读写。

提升：数据库可以处理大数据量的读写；

缺陷：在各类权衡中，开发团队被要求必须提高性能。

 

 6. 写数据和检索数据比强一致性的视图更重要。

提升：来自多个客户端的大数据量的读写可以被很好地支持；

缺陷：如果数据库处于高负载情况下，客户端取得到数据可能不是最新的。

 

 7. 有一些series可能是暂时的，比如某些series在几个小时内出现了，然后又消失了。

提升：influxdb善于处理不连续的数据；

缺陷：无schema的设计意味着一些数据库操作不被支持，比如跨表join是不被支持的。

 

 8. 所有数据行都是平等的，没有任何数据会被特殊对待。

提升：influxdb可以很高效地聚合数据和处理大量数据；

缺陷：数据单纯地以时间截划分，不会有数据被单独地特殊地对待。

 

二、表设计原则

作为一款schema-less的数据库，influxdb有着不同于mysql的表设计原则。

 

建议的原则

把元数据（meta data）设计进tag中

tags会被索引，但是fields不会，因此基于tags的检索会比基于fields的检索会更快。

这里有几条通用的用来判断是使用tag还是field来存储数据的方法：

 

• 如果字段是经常被作为检索条件的元数据，设计为tag；
• 如果字段经常要作为group by的参数，设计为tag；
• 如果字段需要被用来放在influxQL的函数的参数，设计为field；
• 如果出于某些考虑，字段不方便作为string类型保存，则应该使用field，因为tags总是以string类型来存储。

 

避免使用influxQL的关键字作为字段名

这个并不是必须的，但是这样做会简化你写influxQL的过程，你可以不必给字段加上双引号，就能检索。

 

不建议的原则

不要有太多的series

跟mysql的索引一样，series不能太多，否则会造成大量的内存占用以及io负载。

 

不要在measurement的名字里携带数据

涉及数据分类的时候，分类的数据最好做为一个字段，编入一个measurement中，而不要通过给measurement加后缀的方式，编入多个measurements中。

 

不要在一个tag字段里存放多于一条信息

为了方便检索，一个tag里只存放单一的、纯粹的数据，如果存放多于一个数据点，在做检索的时候还需要手动解析tag再分类，这样会极大地削弱tags的索引作用。

 

三、分片组持续时间

influxdb把数据存储在分片组中，分片组使用retention policy(RP)进行管理。处于一定时间段内的数据将会被存储，这个时间段被称为“shard group duration”。

 

分片组持续时间trade-off

在设计retention policies的时候，需要在以下两点中找到平衡：

 

• 长的分片时间意味着更好的整体性能；
• 短的分片时间意味着更大的灵活性。

 

建议的分片组持续时间

RP Duration	Shard Group Duration
<= 1 day	6 hours
> 1 day and <= 7 days	1 day
> 7 days and <= 3 months	7 days
> 3 months	30 days
infinite	52 weeks or longer

 

在设计分片组时间时，还有以下因素需要考量：

 

• 分组时间应该是所有查询中最常执行查询中最长的时长范围的两倍；
• 每个分组应可以容纳至少10000points；
• 每个分组中每个series中应至少包含1000points.