时序数据库（TSDB）

 用搜索引擎搜索下 “tsdb”或者 “时序数据库”，你可以看到各种开源的时序数据库，我没有对各种开源时序数据库进行过详细对比，只是大致上看了下别人的评论。从评论来看InfluxDB应该是目前综合性能最好的，但是它的集群版是闭源的商业产品。OpenTSDB用的人也挺多，但是性能上比较差，写入速度波动幅度比较大。假如你的物联网系统需要保存历史数据的测点数量不超过5万，那么用InfluxDB应该是没问题的。

 

假如你想对各种TSDB做一个测试，并根据测试结果来选择，我的建议如下：

 

1、测试其写入速度，并关注写入速度的波动性。所有的TSDB在实现的时候肯定都用来内存来缓存写入速度的，它们需要在特定时机把缓存的数据写入到磁盘进行归档。所以，在考察写入速度的时候，一定要关注它在对内存数据进行归档化处理时候的写入速度。

 

2、在写入的同时测试其查询速度。因为物联网系统中设备时刻都在产生数据，你的每个查询都是和大量的写入操作同时执行的。

 

3、测试其数据完整性，前面我们提到tsdb在执行写操作时都是先写内存的，然后在特定时候归档到磁盘。 这样一来就存在"tsdb数据库正常关闭或者异常关闭时候 丢失数据"的可能性。作为tsdb的使用者，当然希望它关闭重启的时候尽可能少丢失已经写入的数据。

 

4、测试其在时序错位情况下的数据完整性，时序错位有两种情况：采样数据的时间和tsdb服务器当前时间有较大偏差；两个不同测点之间，几乎同时写入的数据，但被标记为不同的采样时间（有较大的时差）；在这两种情况下，重启服务器后，测试其数据丢失情况。

 

5、测试其磁盘占用率，假如你的系统中连接了1000的设备，每个设备有10个测点，每个测点没秒钟持久化一次，那么你每天需要持久化的时序数据有864兆，每份数据最少包含一下内容：一个测点Id、一个时间戳、一个值。测点算它4个字节、时间戳8个字节、值4个字节。在不压缩的情况下至少需要13G磁盘空间。所以压缩性能是tsdb的一项关键指标。

 

6、了解其查询接口是否丰富，既然把这么多历史数据都保存下来，那当然是希望这些数据能发挥出其价值。一个强大的查询接口是这些数据发挥价值的前提条件。除了普通的按照时间和标签查询某些测点在某个时间段的所有值之外，我觉得tsdb还应该包括：降频查询（在时间轴上分组聚合），聚合查询（把一些测点按照某个算法计算相同采样时间点的值，可以在查询时聚合或者写入时聚合）。