时序数据库系列
时序数据库-05-TDengine 是一款开源、高性能、云原生的时序数据库 (Time-Series Database, TSDB)
时序数据库-05-TDengine Time-Series Database, TSDB
时序数据库-05-TDengine windows11 WSL 安装实战笔记 docker
时序数据库-06-01-vm VictoriaMetrics 快速、经济高效的监控解决方案和时间序列数据库
时序数据库-06-02-vm VictoriaMetrics install on docker 安装 vm
时序数据库-06-03-vm VictoriaMetrics java 整合
时序数据库-06-04-vm VictoriaMetrics storage 存储原理简介
时序数据库-06-05-vm VictoriaMetrics cluster 集群原理
时序数据库-06-06-vm VictoriaMetrics cluster 集群访问方式
3.基本特点
时序业务和普通业务在很多方面都有巨大的区别，归纳起来主要有如下几个方面：
3.1 持续产生海量数据，没有波峰波谷
举几个简单的例子，比如类似哨兵的监控系统，假如现在系统监控1w台服务器的各类指标，每台服务器每秒采集100种metrics，这样每秒钟将会有100w的TPS。再比如说，现在比较流行的运动手环，假如当前有100w人佩戴，每个手环一秒只采集3种metrcis(心跳、脉搏、步数)，这样每秒钟也会产生300w的TPS。
3.2 数据都是插入操作，基本没有更新删除操作
时序业务产生的数据很少有更新删除的操作，基于这样的事实，在时序数据库架构设计上会有很大的简化。
3.3 近期数据关注度更高，未来会更关注流式处理这个环节，时间久远的数据极少被访问，甚至可以丢弃
这个很容易理解，哨兵系统我们通常最关心最近一小时的数据，最多看看最近3天的数据，很少去看3天以前的数据。随着流式计算的到来，时序数据在以后的发展中必然会更关注即时数据的价值，这部分数据的价值毫无疑问也是最大的。数据产生之后就可以根据某些规则进行报警是一个非常常见并重要的场景，报警时效性越高，对业务越有利。
3.4 数据存在多个维度的标签，往往需要多维度联合查询以及统计查询。
时序数据另一个非常重要的功能是多维度聚合统计查询，比如业务需要统计最近一小时广告主google发布在USA地区的广告点击率和总收入分别是多少，这是一个典型的多维度聚合统计查询需求。这个需求通常对实效性要求不高，但对查询聚合性能有比较高的要求。
4.TSDB核心特性
总结起来TSDB需要关注的技术点主要有这么几个：
4.1 高吞吐量写入能力
这是针对时序业务持续产生海量数据这么一个特点量身定做的，当前要实现系统高吞吐量写入，必须要满足两个基本技术点要求：系统具有水平扩展性和单机LSM体系结构。系统具有水平扩展性很容易理解，单机肯定是扛不住的，系统必须是集群式的，而且要容易加节点扩展，说到底，就是扩容的时候对业务无感知，目前Hadoop生态系统基本上都可以做到这一点；而LSM体系结构是用来保证单台机器的高吞吐量写入，LSM结构下数据写入只需要写入内存以及追加写入日志，这样就不再需要随机将数据写入磁盘，HBase、Kudu以及Druid等对写入性能有要求的系统目前都采用的这种结构。
4.2 数据分级存储/TTL
这是针对时序数据冷热性质定制的技术特性。数据分级存储要求能够将最近小时级别的数据放到内存中，将最近天级别的数据放到SSD，更久远的数据放到更加廉价的HDD或者直接使用TTL过期淘汰掉。
4.3 高压缩率
提供高压缩率有两个方面的考虑，一方面是节省成本，这很容易理解，将1T数据压缩到100G就可以减少900G的硬盘开销，这对业务来说是有很大的诱惑的。另一个方面是压缩后的数据可以更容易保证存储到内存中，比如最近3小时的数据是1T，我现在只有100G的内存，如果不压缩，就会有900G的数据被迫放到硬盘上，这样的话查询开销会非常之大，而使用压缩会将这1T数据都放入内存，查询性能会非常之好。
4.4 多维度查询能力
时序数据通常会有多个维度的标签来刻画一条数据，就是上文中提到的维度列。如何根据随机几个维度进行高效查询就是必须要解决的一个问题，这个问题通常需要考虑位图索引或者倒排索引技术。
4.5 高效聚合能力
时序业务一个通用的需求是聚合统计报表查询，比如哨兵系统中需要查看最近一天某个接口出现异常的总次数，或者某个接口执行的最大耗时时间。这样的聚合实际上就是简单的count以及max，问题是如何能高效的在那么大的数据量的基础上将满足条件的原始数据查询出来并聚合，要知道统计的原始值可能因为时间比较久远而不在内存中哈，因此这可能是一个非常耗时的操作。目前业界比较成熟的方案是使用预聚合，就是在数据写进来的时候就完成基本的聚合操作。
未来技术点：异常实时检测、未来预测等等。
5.传统关系型数据库存储时序数据的问题
很多人可能认为在传统关系型数据库上加上时间戳一列就能作为时序数据库。数据量少的时候确实也没问题。但时序数据往往是由百万级甚至千万级终端设备产生的，写入并发量比较高，属于海量数据场景。
5.1 MySQL在海量的时序数据场景下存在如下问题：
存储成本大：对于时序数据压缩不佳，需占用大量机器资源；
维护成本高：单机系统，需要在上层人工的分库分表，维护成本高；
写入吞吐低：单机写入吞吐低，很难满足时序数据千万级的写入压力；
查询性能差：适用于交易处理，海量数据的聚合分析性能差。
5.2 使用Hadoop生态(Hadoop、Spark等)存储时序数据会有以下问题：
数据延迟高：离线批处理系统，数据从产生到可分析，耗时数小时、甚至天级；
查询性能差：不能很好的利用索引，依赖MapReduce任务，查询耗时一般在分钟级。
5.3 时序数据库需要解决以下几个问题：
时序数据的写入：如何支持每秒钟上千万上亿数据点的写入。
时序数据的读取：如何支持在秒级对上亿数据的分组聚合运算。
成本敏感：由海量数据存储带来的是成本问题。如何更低成本的存储这些数据，将成为时序数据库需要解决的重中之重。
网友评论