数据库技术及应用基础教程-视频教程autocad2004基础应用 候旭东

1. 匹配自身业务场景：时序服务可以根据设备规模、指标数量、采集频率等细分为多个场景。 目前大部分时序数据库都可以应用于中小规模场景，但是对于千万级设备、单台设备上百个指标、秒级采集等大规模场景，有很好的挑战。

2、图形化工具：是否有简单易用的图形化工具，包括图形化接入工具和图形化监控、运维管理工具。 图形化工具可以大大降低使用门槛，提高开发运维效率。

3、生态和社区：数据库主要解决数据存储和计算的问题，端到端的业务解决方案也需要依赖生态的完善。 另外，数据库是复杂的软件，尤其是分布式数据库，开发和维护都有一定的门槛，所以社区活跃度是一个重要的考虑因素。 一个活跃的社区可以帮助我们在遇到问题时更快地找到解决方案。

4、写性能，乱序写：时序数据库95%以上的操作都是数据写，需要稳定的性能，所以写性能是一个重要的考虑因素。 另外，是否支持乱序写入也是一个选择因素，因为时序数据经常会出现数据错误和重传的情况。

5、更新和删除：在很多业务场景中，最近的数据往往伴随着乱序、错误的数据。 这时候就需要对这些数据进行更新和删除。

6. 降采样：时间序列数据的值密度随着时间的推移而衰减，因此需要对采集到的指标数据进行频繁的降采样。 例如，如果原始数据采集频率为 10 秒，则数据将同时降采样为 1 小时。 一分，甚至一天一分。 在这种业务场景下，需要考虑数据库是否自动支持降采样。

7、压缩率：当设备数据量大，指标多，采集频率高时，时序数据量会变得非常大，对存储空间要求高。 一种常用的方法是只保留最近的数据，删除历史数据。 ; 但是业务希望数据量尽可能大，对尽可能多的数据进行分析和模型训练，所以压缩率就成了一个重要的指标。 通常时序数据库支持列式编码压缩和分块压缩。

8、查询性能：时序场景查询非常多样，包括简单的索引查询和分析查询； 单设备/多设备最新值、聚合值查询、多维度查询； 插值和阈值计算、模式识别和其他查询。 根据业务场景，对数据库进行实际评估是一个很好的方法。 此外，使用更通用的基准测试，如tsbs benchmarks，也可以全面验证数据库的查询能力。

9、冷热分层存储：时序数据的价值密度随时间衰减，因此不同时间段的数据使用不同价格的存储介质和存储服务是普遍需求。 冷热分层存储可以很好地解决这个问题，通常与分区结合使用。

10. 分区支持：时序场景通常会根据时间属性进行分区，有时也会根据其他属性进行二次分区，以更好地支持插入和查询。

11、连续聚合：时序场景经常使用时间窗口查询，频繁获取该时间窗口内数据点的聚合值，比如过去10秒的最大CPU利用率。 传统的方法是每10秒向数据库发送一次查询请求。 数据库收到查询后，计算过去10秒内CPU指标的最大值。 这种方法是可行的，但是开销比较大，延迟高。 连续聚合可以连续计算10秒窗口的索引聚合值，这样在收到相应查询时可以直接返回结果。 通过订阅机制，可以进一步避免轮询查询，直接将结果发送给感兴趣的订阅者。

12、时序函数：时序场景中有很多特定的函数，比如first、last、gapfill、variance、standard deviation、ARIMA等，这些常用函数是否原生支持也是模型选择的一个因素。

13. 云边融合：由于时序数据量大、频率高，通常采用边缘计算架构，在边缘侧部署单节点时序数据库或小型数据库集群，在同时将边缘侧的数据经过初步处理后发送到云端/数据中心的大型数据库集群，此时需要考虑产品是否能够支持云边融合。

14、安全机制：安全机制是选型时经常被忽视的一个因素，因为它主要贯穿在业务的最开始，所以对安全的关注度较低。 但是能源、电力、工业互联网等很多时序场景都非常重视安全。 是否有完整的安全控制，包括认证、访问控制、加密和审计，是判断时序数据库是否安全的重要考虑因素。

15、嵌入式脚本能力：除了标准的SQL，应用开发者往往对数据进行更复杂的处理。 一种方法是使用JDBC将数据读入内存，使用编程语言提供的数据处理函数来处理数据。 这种方式比较适合数据量比较小的场景。 如果数据量很大，将数据读入内存进行转换和转换效率很低。 因此，能否在数据库中使用通用的编程语言（Python、R等）处理数据是一个重要的考虑因素。

16、运维管理：包括安装部署、监控告警、故障恢复、备份恢复、扩容升级等。

04 时序数据库和关系数据库的纠葛是什么？

当你对时序数据库有了一定的了解后，你可能会疑惑，虽然时序数据是非常好的结构化数据，但是关系数据库从1980年代就开始支持时间戳数据类型了，那为什么不用关系数据库来处理时序数据呢，但是开发一个专门的时间序列数据库？

这要从关系型数据库的存储引擎说起。 传统关系型数据库使用行存储引擎存储数据，使用B+树来提高查询性能。 B+树是一种为读取而优化的数据结构。 写入数据时，会引起B+树的分页，分页会引起随机磁盘IO。 随机磁盘IO会大大降低数据写入的性能。 另外，B+树的压缩比也低。

正是因为关系数据库的这些特点数据库技术及应用基础教程，不适合时序数据库。 时序数据库中绝大多数操作都是写操作，因此希望针对数据写入进行优化； 时序数据量比较大，需要达到较好的压缩比，这是传统关系型数据库不具备的条件。

大多数时间序列数据库不使用 B+ 树，而是使用 LSM（Log Structured Merge）树或其变体。 LSM树是一种为写入而优化的数据结构，具有优秀的写入性能。 因此，很多时序数据库选择LSM或LSM变体作为核心存储引擎，例如InfluxDB、OpenTSDB（OpenTSDB基于HBase，HBase基于LSM树）。

那么LSM树能否满足时序数据库的所有特性需求呢？ 不完全的。 LSM 树虽然写性能优秀，但不能很好地支持读操作。 为此，时序数据库引入了不同的机制来提高查询性能。 例如，InfluxDB使用B树索引、倒排索引、Bloomfilter等技术来提高查询性能。 这样一方面提高了读操作的查询性能，写数据的时候需要维护。 这些不同类型的索引也增加了写操作的开销。 由此可见，时序数据库需要在读操作和写操作之间取得平衡，而不是简单地追求其中之一。

近年来，一些产品开始挑战关系型数据库不适合处理时序数据的假设，开发了基于行存储和B+树的性能优异的关系型时序数据库。 代表产品是TimescaleDB。 TimescaleDB 基于时间序列数据，天然具有时间戳属性。 时序数据表是按照时间进行分区的。 当前分区使用行存储和B+树。 类似于列存的效果）。

那么TimescaleDB的写入性能如何呢？ 一些在线测评发现其写入性能优于时序专用数据库InfluxDB。 为什么？ B+树没有读优化，写性能不如LSM树吗？ 理论上B+树确实会造成随机磁盘IO，但是在数据库项目实现的时候，会采用WAL日志+buffer的方式，尽量避免随机IO：WAL总是顺序读写，而page of B+树修改的时候不会直接写。 相反，先写入 WAL 日志，然后再更新内存缓冲区。 只有当内存缓冲区满了，才会刷新到磁盘。 这样，随机磁盘IO在很大程度上优化为顺序磁盘IO。 为了提高写入性能，LSM树引入了各种索引，一定程度上增加了写入开销。

时间序列数据多为指标数据，通常是一系列数字串。 为了将这些数字串转化为有价值的信息，通常需要引入时间序列数据的上下文信息，其中大部分是关系数据。 因此，时序场景通常需要关系数据库和时序数据库的配合，才能赋予数据意义，最大化数据的价值。 关系型时序数据库支持关系型数据库中的时序数据，这个问题只能通过数据库替代关系型数据库+时序型数据库来解决。 可以大大简化技术栈，提高开发和运维效率。

TimescaleDB使用hack的方式在关系型数据库中实现时序数据库，性能优异。 按照这种思路，一个新的数据库类别开始出现：超融合时序数据库。 超融合时序数据库在关系数据库内部实现了多个存储引擎，以支持不同的数据类型和业务场景。 例如，关系存储引擎存储结构化数据，时序存储引擎存储时序数据，GIS存储引擎存储地理信息数据。 配合优化器和执行器实现HTAP和流数据处理。 这方面的代表产品是MatrixDB。 MatrixDB是一个关系型数据库，内置了关系型存储引擎、列式存储引擎和时序存储引擎。 它可以同时处理结构化数据和物联网/工业物联网时间序列数据，性能卓越。

当关系数据库可以很好地支持时间序列数据时，专用时间序列数据库有什么意义？ 这是一个值得思考的问题。 时序数据库的最终结果可能是没有时序数据库。 这并不意味着时序数据库是不必要的，但时序数据库作为数据库子类别可能不是必需的。 这不仅是时序数据库的终结，也是时序数据库的重生。

正如“NoSQL”这个词在很多年前很流行，现在很少有人提起，但是一些流行的NoSQL产品，比如Elasticsearch和MongoDB，仍然很受欢迎。 只是自从大多数NoSQL产品开始支持关系型数据库的特性，如ACID、SQL等，“NoSQL”作为数据库范畴的说法意义不大。

05 时序数据库的未来方向

不管专用时序数据库的未来如何，随着物联网、车联网、工业互联网、以及智慧城市发展。 有几个方向值得我们关注。

1. 超融合时序数据库

融合是未来几年数据库发展的主旋律之一。 数据库的界限越来越模糊。 就像生物世界从简单到复杂的进化一样，数据库将在组织上显得更加复杂，在功能上更加强大，但也更加便于用户使用。 简单的“新物种”：超融合数据库。 如下图所示，数据库和数据处理平台从诞生到现在已经演进了大约50年，可以分为四个阶段：

在超融合数据库的趋势下数据库技术及应用基础教程，超融合时序数据库是时序数据库的一个重要发展方向。 由于超融合时序数据库的实现难度低于通用超融合数据库，超融合时序数据库最早出现并商业化。

2、云原生时序数据库

云原生数据库是商业模式的重要创新，正在对数据库技术产生深远的影响。 Snowflake等国外云原生数据库取得了巨大的商业成功，对数据库技术也起到了重要的推动作用。

在这么大的情况下，如何实现云原生时序数据库是一个重要的研究方向。 云原生时序数据库和目前的云原生数仓如Snowflake有很多区别。 例如数据仓库主要是批量加载数据和OLAP查询，而时序数据库需要支持频繁的高吞吐数据写入、乱序数据写入和更新删除、高并发时序查询、持续聚合query等。在设计和实现云原生时序数据库时需要考虑这些时序场景的具体问题。

3、智能数据库

数据库运维管理是一项极具挑战性的工作。 随着数据库集群越来越大，软硬件故障将成为常态，这将进一步增加分布式数据库运维的难度。 在这种情况下，智能运维正成为热点。 通过收集数据库运行过程中的各种指标数据，利用时序数据库分析时序数据库本身，提高数据库的智能化，降低运维的复杂度。

06 总结

随着物联网、车联网、工业互联网的快速发展，时序数据库再次走在时代的前沿，受到业界的高度关注。 专用时序数据库和超融合（关系型）时序数据库这两条技术路线，成为了业内人士关注的话题。 时序数据库未来的发展方向是什么，是架构选择的重要考虑因素。

本文介绍了时序数据、时序数据库和时序数据建模，回顾了时序数据库的发展简史，阐述了时序数据库选型的注意事项，进而指出在分析了时序数据库的两种技术路线的基础上，分析了时序数据库的优缺点。 最终的结果可能是没有时序数据库。 当然，这并不是说不需要时序数据库，而是可能不需要专门的时序数据库，超融合的时序数据库将成为未来重要的发展趋势。 这不仅是时序数据库的终结，也是时序数据库的重生。