直播回顾 ｜ MatrixDB 定义下一代时序架构（内附 PPT 下载）

由 CSDN 主办的在线峰会 —— 新数据库时代视频回放终于来了！

在物联网技术的快速发展下，衍生出一种功能更强大，使用更简单的新的数据库 —— “超融合时序数据库”。本次线上峰会聚焦于技术干货，从开发者关注的技术痛点出发，分享性能优化、架构设计、系统实现等技术层面的方法论及实战经验。

北京四维纵横数据有限公司创始人姚延栋此次发表题为《超融合时序数据库：下一代时序数据库架构解析》的主题演讲。演讲内容见下文：

01 产品介绍

MatrixDB，全球首款超融合时序数据库。基于开源 Greenplum，实现海量时空数据的快速采集、高效存储、实时分析以及深度学习(ML+AL)，比传统的时序数据库 InfluxDB、OpenTSDB 性能快 50 倍，空间节省 60% 以上，比传统的 MPP 数据库快 3-100 倍。

MatrixDB 广泛应用于能源、航空航天、汽车和车联网、智能制造和工业互联网、金融、保险、证券、5G 通信、雷达和气象、智慧农业、生物医疗研发、智慧城市、智能家居等各行各业，覆盖智能监控、实时控制、设备溯源、用户画像、行为分析和预测分析等多种应用场景，为物联网、车联网、工业互联网和智慧生活提供坚实、简洁的数据基座。

02 当前的时序架构是痛点也是机遇

物联网技术的不断发展并在各个行业场景快速普及应用，随之而来的海量时序数据也为时序数据库的快速写入、高效存储、快速查询提出了更高的要求。时序场景主要包含主数据（关系数据）和时序数据（带时间戳）。当前时序架构使用各种方式采集时序数据并发送到 Kafka 里，再用不同的数据库来处理不同的业务查询需求。例如：使用 Redis 解决设备最新值的查询，譬如某个智能电表的最新度数、剩余多少度电等，使用 OpenTSDB/HBase 实现明细查询，譬如某辆新能源车某个时间段内发动机的指标数据，使用 ElasticSearch 实现多维查询，譬如通过某些标签值查询到某个或者某些设备，然后通过 OpenTSDB 获取其明细或者聚集数据，使用 Hive 实现 OLAP 分析。

当前时序架构痛点：DIY 技术线，慢且复杂！

可以看出，目前整个数据架构基本上都是 DIY 搭建出来的架构栈，这样的架构栈通常会出现“2 个特点”：1、慢；2、复杂。

专用的数据库来解决专用的问题，为什么还会慢 ？

专业产品来解决专用问题看似是快，但是端到端组合在一起会慢。比如：多维查询，一些带有维度、标签的信息去 Elasticsearch 查询，再根据 Elasticsearch 返回的 ID 去 OpenTSDB 里查明细，在不同的数据库之间一来一回的查询，还需要在应用中通过代码关联其他业务数据进行处理，这样的开销反而更大，所以端到端的性能并非是最好的。

DIY 的技术栈，能有多复杂 ？

技术栈复杂，开发运维成本，软硬件成本高，性能较低，并且运维复杂的技术栈也是需要考虑人才的稀缺性。

这就是当前数据架构所遇到的痛点和挑战。

 “超融合时序数据库” 定义下一代时序架构！

时序数据直接通过类似 Kafka 的组件写入到超融合时序数据库，支持各种各样的查询，不管是设备的最新值、聚集查询、多维查询、明细查询、OLAP 的分析及将来的流处理等，都可以在一个数据库里搞定。

总的来说，超融合数据库把“极简”、“极速”留给用户！

想要用户“简单”，首先需要考虑用户对时序场景的需求。时序场景以读写多样性为主，场景的多样性，导致技术栈的复杂性。

在时序场景里面，基本 95% 以上的操作都是以“写”为主，如何支持平稳、高效、实时显得尤为重要；时序场景写入模式也很突出，设备的时序数据通常按顺序写入，缺省模式需要很好的支持这种特点，除此之外也有很多其他真实场景需求，包括延迟写入、分批写入、异频写入、更新删除等。

过去的数据库基本就在 B+树及 LSM 树之间做选择，如何能把各种数据库结构的优势整合在一个数据库里？这就是我们做超融合数据库架构的由来。

从存储引擎来看，不管是行存、列存、内存还是 LSM 引擎，使得数据库内部可以实现不同的存储引擎，不同的存储引擎又可以针对不同的应用场景去优化，对于用户而言，一个数据库通过不同存储引擎支持不同的业务场景，简单高效。比如，用行存去增删改查，用列存做分析型查询，这样一来，数据库可以做比以前单个数据库功能更强的事情，实现几个数据库的超集。

超融合架构解决数据复杂度的问题：读、写、查询的处理，用户使用 SQL 轻松搞定，把“极简”、“极速”留个用户，把复杂度留给数据库实现者和数据库本身，而数据库本身该如何处理复杂性？需要在数据库内部分工合作，并且实现每个点都可插拔，使数据库本身的复杂度是可控的，同时实现高灵活性，这是超融合架构的核心。

03 “超融合时序数据库” 到底是什么？

从开发和运维的角度来说，超融合时序数据库可以这么理解：

过去我们需要使用 “多个” 数据库来解决一个问题，但现在只需要一个“超融合时序数据库”就可以轻松搞定！

关系型数据为什么没有成为时序数据库的主流？

B+ 树是为读而优化的，而 LSM 树是为写而优化的。很多人认为，关系型数据库用了 B+ 树就不太适合再去做时序场景的缺省数据库，因为时序场景 95%-99% 都是“写”的操作，而大多的时序数据库底层都是使用类似 LSM 树的方式。

事实上，基于 B+ 树的 MatrixDB 写入性能是 InfluxDB 的几十倍，是国内友商的十几倍，可以参考 PostgreSQL 中文社区的第三方评测：时序数据库InfluxDB和MatrixDB加载性能实测

超融合时序架构不足及改进？

超融合时序数据库支持窄表和宽表两种模式，宽表性能好，建议使用宽表模式，然而宽表的 schema 不够灵活，每次增加新品类的设备，就需要在数据库里修改 schema，创建新字段，为了改进这一问题，超融合时序数据库引入 “MXKV” 技术，可以在字段类型加入任意多的 key 和 value 值，弥补了宽表的不足。

04 时序场景的三大趋势

第 1 大趋势：从监控走向分析

过去时序场景主要用于服务器监控，服务器不过几万台，存储 7 天到 30 天的数据，数据量小且主要目的是监控；但随着物联网、工业物联网、车联网的崛起下，数据量大且主要目的是分析，通过分析挖掘海量时序数据的价值。

譬如在车联网场景下，时序数据库存储着庞大的车辆指标时序数据，结合车辆维保时间、故障部件及维修方式等关系数据，可以实现驾驶员画像、驾驶习惯画像、车辆画像等，极大的提升驾驶安全和体验。

第 2 大趋势：数据模型从窄表走向宽表

“窄表”，方便扩展，能适应各种复杂的数据结构（树形等），无论有多少配置都不需要修改表结构。简单来说，灵活，性能差，适合数据量少及简单场景。

“宽表”，业务相关的测点、维度和属性信息放在一张或者几张数据库表中，存储效率高，速度快，适合大数据量及复杂业务场景。

在物联网、工业物联网、车联网的场景的崛起，时序数据库越来越重视分析，宽表模型越来越多，近几年出现的新时序数据库也都是以宽表模型为主。

第 3 大趋势：技术栈走向超融合时序数据库

从各种开源软件拼搭起来走向 ONE FOR ALL 的架构方式。借鉴奧卡姆剃刀原理：“如无必要，勿增实体”。一个数据库可以完成的事情，就不需要太多的数据库来处理。最终，我们的目标是把“极简”、“极速”留给用户，把复杂留给数据库开发人员。

超融合时序数据库，One for ALL！

更多详细内容，欢迎下载 PPT～

PPT 下载

超融合时序数据库：下一代时序数据库架构解析

原文链接

本文为 yMatrix 原创内容，未经允许不得转载。