【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 
写在最前面
看了timescaledb官方的测试文章TimescaleDB比拼InfluxDB：如何选择合适的时序数据库？，发现差异较大的只在存储， 就准备用timescaledb，因为公司有专门的数据库小组，可以对pg进行维护。但测试发现openstack监控一天的写入数据空间在150G左右，面对服务器那可怜的600G存储，明显是不够的。因此才有了influxdb和timescaledb的对比测试，结果发现在我司环境，timescaledb各方面均被influxdb超越。
背景
目前prometheus的监控数据存储使用自带的tsdb时序数据库，将数据存储在本地磁盘；没有接口对存储的数据进行管理，只能按存储块删除；由于抓取量大、频率高，占用的磁盘空间高，无法满足长时间存储的需求。
poc项目
对比目前流行的tsdb：timescaledb、influxdb，通过对接我司测试云环境openstack监控。一台物理机通过docker部署influxdb(1.7.6)，一台物理机通过docker部署prometheus-postgresql-adapter(0.4.1)、pg_prometheus(0.2.1,timescaledb:1.2.0)
并从以下几方面进行对比：
1、性能
(1)Cpu、内存、磁盘使用情况
(2)写入效率
(3)查询效率
2、功能
(1)高可用|集群
(2)写入与查询
(3)能删除指定指标和时间范围的数据点
(4)数据上卷。能进行周期缩短，以node_exporter 30s抓取一次为例；30s数据存储7天，7天后每10分钟保留一个点；15天后每小时保留一个点；30天后每一天保留一个点；
POC详情
性能
cpu
通过获取docker使用的cpu时间来进行对比。Timescaledb包含pg_prometheus及adapter的cpu时间，单位为秒。
结果：timescaledb两个组件所有的cpu时间在influxdb的4倍以上
内存
内存上不太能看出优劣，timescaledb用的shared mem比较多，我看了pg_prometheus启动后使用了timescale-tune工具自动优化后配置的shared memory为32GB，因此即使timescaledb占了89GB之多，其实通过free -g查看主机内存并没有增加实际的used消耗。
磁盘
差异最大的地方，timescaledb可以说是被influxdb秒杀；每天相同的数据量，influxdb占用在5G左右，而timescaledb占用在150G左右，而且并不是如timescaledb官方测试所说的随着数据量增大，存储倍数差异减少的情况。
写入效率
两个db每天写入11亿8千万的监控数据，均没有出现写入丢失；
查询效率
influxdb与prometheus查询效率相当，timescaledb相同场景返回相同数据量差不多消耗至少4倍的时间，其中标红色的是超过1m查询时间的情况。
功能
高可用|集群
Influxdb开源版不支持集群，社区采用率高的是influxdb-proxy，后端连接多个influxdb；
Timescaledb底层使用的pg支持集群，主从流复制；
这一项对于高可用的监控数据存储来讲，timescaledb占优。
写入与查询
1、Influxdb
Influxdb1.7版本已经自带prometheus remote write和read
2、timescaledb
通过timescaledb提供的pg_prometheus_adapter实现prometheus remote write和read
数据删除
1、Influxdb
Influxdb为不同的metric创建不同的measurement，删除无用metric直接truncate或drop表即可
2、Timescaledb
通过标准sql，执行delete操作对数据进行删除
数据上卷
以node_exporter 30s抓取一次为例；30s数据存储7天，7天后每10分钟保留一个点；15天后每小时保留一个点；30天后每一天保留一个点；
Timescaledb和influxdb均提供Continuous Query的功能，可按不同的频率进行统计
结论
如果存储可用量少同时对高可用监控数据存储没有要求的，选influxdb；
反之，用TimescaleDB。
来源：oschina
链接：https://my.oschina.net/u/2305466/blog/3072922