背景
随着移动互联网、物联网、大数据等行业的高速发展，数据在持续的以指数级的速度增长，比如我们使用手机访问互网络时的行为数据，各种可穿戴设备上报的状态数据，工厂中设备传感器采集的指标数据，传统互联网公司的监控数据等。实际上，这些按照时间顺序记录系统、设备状态变化的数据都是时序数据(Time Series)，它普遍存在于互联网、物联网、IT基础设施中。
得益于软硬件技术的快速发展，处理如此庞大的时序数据集的成本在持续降低，更多公司开始持续收集、分析数据，用于异常处理、趋势预测、精准营销、风险控制等场景，希望利用数据的潜在价值，提高公司盈利能力和竞争力。这里举两个例子：
1.下图为某共享单车在旧金山某热门区域的车辆借还情况。通过分析该区域车辆的历史借还数据，单车公司可优化热点时间段的车辆补给。
传统的时序数据解决方案及问题如下：
1. MySQL等关系型数据库：
· 写入吞吐低：单机写入吞吐低，很难满足时序数据千万级的写入压力;
· 存储成本大：对于时序数据压缩不佳，需占用大量机器资源;
· 维护成本高：单机系统，需要在上层人工的分库分表，维护成本高;
· 查询性能差：适用于交易处理，海量数据的聚合分析性能差。
2. Hadoop、Spark等批处理系统
· 数据延迟高：离线批处理系统，数据从产生到可分析，耗时数小时、甚至天级;
· 查询性能差：不能很好的利用索引，依赖批处理任务，查询耗时一般在分钟级以上。
3. HBase
· 多维分析能力差：HBase可以较好的满足写入压力，但对于非RowKey前缀的查询性能较差;
· 维护成本：使用HBase需要同时维护HBase和Hadoop等系统，且HBase的稳定性会进一步加大维护成本。
写入、存储、查询多环节优化，时序数据库优势明显
1. 时序数据模型及特点
在引入时序数据库之前，先要了解【时序数据】的模型及特点。
1.1 时序数据的数学模型
前面介绍了时序数据的场景，也说明了分析时序数据的意义及传统方案。那么时序数据该怎样存储呢?数据的存储要考虑其数学模型和特点，时序数据当然也不例外。这里以一段时序数据为例，介绍下时序数据的数学模型。
下列数据记录了一段时间内某集群里各机器上各端口的出入流量，每半小时记录一个观测值：
· point： 一个时序数据点，类似于关系型数据库中的 row;
· timestamp： 时间戳，表征时序数据产生的时间点;
· tag： 维度列，用于描述设备/系统的属性，表明是哪个设备/模块产生的，一般不随着时间变化;
· field： 指标列，用于描述设备/系统状态的变化，随时间平滑波动。
1.2 时序数据特点
· 数据模式： 时序数据随时间增长，相同设备/系统的维度信息不变，指标平滑变化，这点从上面的Network表的数据变化可以看出。
· 写入： 持续高并发写入，无更新操作：时序数据库面对的往往是百万甚至千万数量级终端设备的实时数据写入(如摩拜单车2017年全国车辆数为千万级)，但数据大多表征设备状态，写入后不会更新。
· 查询： 按不同维度对指标进行统计分析，且存在明显的冷热数据，一般只会频繁查询近期数据。
2. 时序数据库
2.1 时序数据库
时序数据库是管理时序数据的专业化数据库，并针对时序数据的特点对写入、存储、查询等流程进行了优化，从而解决时序数据处理难题：
· 存储成本：
o 利用维度重复、时间递增、指标平滑变化等特性，合理选择编码压缩算法，提高数据压缩比;
o 通过预降精度，对历史数据做聚合，节省存储空间。
· 高并发写入：
o 数据批量写入，降低网络开销;
o 数据先写入内存，再周期性的dump为不可变的文件存储，提高写入速度。
· 低查询延时，高查询并发：
o 优化常见的查询模式，通过索引等技术降低查询延时;
o 通过缓存、routing等技术提高查询并发。
2.2 开源时序数据库对比
目前行业内比较流行的开源时序数据库产品有 InfluxDB、OpenTSDB、Prometheus、Graphite等，其产品特性对比如下图所示：
· 没有free、易用的分布式版本(OpenTSDB支持分布式部署，但依赖系统过多，维护成本高);
· 聚合能力普遍较弱，而时序数据大多需要来做统计分析;
· 没有free的权限管理;
· 没有针对时间序列的多维度对比分析工具。
历经每日万亿写入吞吐，腾讯云CTSDB技术架构
腾讯CTSDB(Cloud Time Series Database)是一种分布式、高性能的时序数据库，针对时序数据的高并发写入、存在明显的冷热数据、IoT用户场景等做了大量优化，同时也支持各行业的日志解析和存储。在腾讯内部支撑腾讯云等每日万亿写入吞吐的场景，经过严苛的压力打磨。其架构如下图所示：
· 高性能：(具体性能数据参考后文测试部分)
o 支持批量写入、高并发查询，以及强大的分析聚合能力;
o 通过横向扩展，线性提升系统性能;
o 支持sharding、routing，加速查询。
· 高可靠：
o 分布式系统，支持多副本;
o 机架感知，自动错开机架分配主从副本。
· 易使用：
o 丰富的数据类型，REST接口，数据写入查询均使用json格式;
o 原生分布式，弹性可伸缩，数据自动均衡;
o 权限系统：支持用户名密码、机器白名单的权限系统。
· 低成本：
o 支持列存储，高压缩比(0.1左右)，降低存储成本;
o 支持数据预降精度：降低存储成本的同时，提高查询性能。
o 副本数可按需调整。
· 兼容开源生态：
o 兼容Kibana/Logstash/Beat等组件，方便数据采集及可视化分析;
o 支持从MySQL、Kafka等开源生态同步数据，方便迁移。
2. 竞品性能对比测试
这里选用业界较为流行的InfluxDB来与CTSDB做性能对比测试。
2.1 写入性能测试
(1) CTSDB单节点集群与InfluxDB单机版写入性能对比
结论: CTSDB单节点写入性能最高在19w，InfluxDB在15w。
(2) CTSDB单节点集群与CTSDB双节点集群写入性能对比
结论：CTSDB单节点集群写入最高可达20w，双节点集群写入性能34w。
2.2 查询性能测试
(1) CTSDB单节点集群与InfluxDB单机版查询性能对比
结论：
· CTSDB查询性能整体比InfluxDB好很多，当并发数较高时(40)，CTSDB查询性能比InfluxDB高出近4倍，在2w左右。
· 在并发线程数达到50时，InfluxDB出现链接错误，拒绝查询请求;此时，CTSDB可正常查询。
(2) CTSDB单节点集群与双节点集群查询性能对比
结论
在并发数较高的情况下，双节点集群查询性能较单节点集群有了大幅度提升，呈现了查询性能线性扩展的趋势。
关于我们
1. 我们的现状
作为腾讯唯一的时序数据库，CTSDB支撑了腾讯内部20多个核心业务(微信彩票、财付通、云监控、云数据库、云负载等)。其中，云监控系统记录了腾讯内部各种软硬件系统的实时状态，CTSDB承载了它所有的数据存储，在每秒千万级数据点的写入压力、每天20TB+数据量的写入场景下稳定运行，足以证明CTSDB可以稳定支撑物联网的海量数据场景。
2. 我们的未来
