编者按： 以下为发布会的图文回顾内容，发布会完整视频回放可参见：https://www.bilibili.com/video/BV1164y1b73U?spm_id_from=333.337.search-card.all.click
大家好，我是四维纵横创始人姚延栋。感谢大家观看 MatrixDB4.0 发布会直播。今天和大家分享的题目是：“超融合时序数据库 定义未来记忆”。
首先做一下自我介绍，从几个故事开始吧。我是出生自山东德州一个农村家庭，小时候手表是奢侈品，所以很久以来没有很好的时间观念。在我小学二年级的时候，一觉醒来发现天已经大亮，赶紧穿上衣服背着书包去学校。，到了学校一看，空无一人，所以就坐在教室的门口等着老师和同学们。等了很久，没有一个人来。这个时候一个晚上干活的长辈经过，问我：“大半夜的，你在这儿干嘛呀？”。我说：“我来上学”。他说：“你看现在也就是两三点钟，赶紧回家睡觉去”。我不信，就没有动。他没办法，就去了我家找了我的父母。后来我妈过来，硬把我拉了回去。就这样，我们家在当天就有了挂钟，这个挂钟到现在还在我们老家的墙上，想来的话有三十来年了。这是我小时候有关于时间，比较早、比较深刻的一个记忆。从此以后，对于时间有了一个模糊的记忆。就像古罗马的哲学家奥古斯丁曾经说过：“时间是什么，如果你不问我，我是知道的。如果你问我，我就不知道该如何回答了”。
后来 2002 年，我考入了中科院软件所，师从称为中国 Linux 第一人的孙玉芳孙老师，专业是数据库和网络。现在想来，其实这就是 MPP 数据库。只可惜，当我第一次和孙老师一对一单独交流的时候，他告诉我这个方向已经没有了，换一个方向吧。就这样，我和数据库擦肩而过。从软件所毕业之后，我去了 SunMicrosystem 工作了三年，做了三年 Solaris 相关的工作。后面去了 Symantec，做了两年半存储相关的工作。在 2010 年，加入了当时 EMC 的 Greenplum 部门。我在当时就有一个小想法，希望能够在 EMC 工作五年以上。因为在 Sun 的时候，如果你工作满五年，就可以得到一个大概这么大的一个天文望远镜。如果你工作满十年，就可以得到一个更长的天文望远镜。如果你能够工作满十五年，就可以得到一个超长的天文望远镜。当时看到日本的同事，展示三个天文望远镜摆在一起的时候，非常的羡慕。所以我想在这家新公司，我一定要待满五年以上，也得到天文望远镜。这一待就是十年，整整从 2010 年到 2020 年，十个年头。不过可惜的是，并没有得到望远镜，因为 EMC 没有这样的福利。不过这十年，和数据库就结下了不解之缘。也许冥冥之中自有定数，在和数据库第一次擦肩而过的几年之后，和数据库结下了不解之缘。2019年，Gartner 发布了一个全球数据库排名的报告，在数据分析领域，Greenplum 世界排名第三。这也是我从事的所有事情中，包括吃饭睡觉甚至是打游戏，第一次排名和世界第一如此之近。
2020 年我和几个小伙伴出来创业，选择的方向是时序数据库。和当时主流的专用的时序数据库，技术路线不同的是，我们采用的是超融合时序数据库。超融合数据库是我们公司提出的一个理念，我们也在全球范围内，开创了超融合时序数据库，这样一个全新的数据库品类。我们公司叫四维纵横，希望在四维之内，纵横驰骋，走一条不一样的技术人生。我们是一家创业公司，也是一个玩游戏的创业公司。我们玩的是一个无限的游戏。游戏分两类：一类是有限的游戏，一类是无限的游戏。有限的游戏是在边界以内玩，有固定的规则，争的是输赢。而无限的游戏是在边界上玩，没有固定的规则，玩的是规则本身。目的是为了让游戏不断的延续，拓展边界。我们把创业这个无限的游戏分了三个层次，分别对应着我们的三个产品：第一个产品是产品本身，也就是我们的 MatrixDB 数据库；第二个产品是我们这家公司；而第三个产品是我们每个人自己。我们希望在创业的这个游戏之内，可以不断的迭代这三个产品，探求每个产品的边界，最终希望提升我们每一个人的认知，我们的判断力、格局和视野。
我们也是一家用数学公式来运营的公司，公式非常简单，是 y=f(x)。“y” 是输出，是结果；“x” 是输入，是信息；“f” 是函数，是逻辑。我们用这样一个简单的公式，来运营公司。比如我们经常会发生分歧，这个时候就是大家的 y 不一致了。我们并不会争论 y 对错本身，而是会后退一步，来去看大家的 f 是什么、x 是什么、你的逻辑是什么、你的输入是什么。这个时候我们经常发现是大家的 x 不同，也就是说大家对同一件事情的认知不同、见解不同、解读不同。那这种情况之下，我们会递归调用 y=f(x)，来分析大家为什么会对同一件事情产生不同的解读。通常情况下，不出几个回合我们就可以解决，原始的、在 y 上的分歧，达到我们在当时的认知水平的一致。
我们创业的一个初衷是看到很多人，在大数据技术发展了十几年之后，仍然觉得大数据很难、很复杂。以至于很多人习惯性地认为，大数据理应如此复杂，对此我们并不认同。我们认为大数据应该像水、像电、像气一样简单易用。毫无疑问，大数据技术本身是非常复杂的，但是大数据的应用应该非常简单。就像电，电本身包括发电和输电都是非常复杂的。但是电走进千家万户，简单易用。几年之前，有一个词叫做大数据平民化、大数据民主化，但是相关的工作并没有取得很好的成功。原因是方向没有问题，但是技术路线遇到了挑战。为此我们提出了超融合时序数据库，通过把数据存储和处理的复杂度封装到数据库内部。使得万物互联的新时代再无数据之忧，使得人们可以像用水、电、气一样使用数据，使数据成为生产要素。
提到数据库我们难免就会考虑，数据库的本质是什么，为什么会有数据库，是什么原因催生了数据库的从 0到 1，从无到有。那为了回答这个问题，我们不妨回到上世纪 7 0年代，当时还没有数据库，开发人员使用文件来去存储和管理数据。我们可以假想一个场景，一个企业有三个系统：一个是 HR 人力系统、一个是财务系统、一个是请假系统。每个月，我们将要从三个系统里面抽取数据，来计算每个人休了多少假，应该发多少薪水。我们可以看到这个操作效率是非常低的，因为我们没有办法很好地实现数据的共享。所以说数据库出现的第一个推动力是消除数据孤岛，实现数据的共享。那第二个推动力是数据独立性，也就是说业务逻辑和底层的数据逻辑，应该解耦合。上层业务发生变化，不用改底层的数据；底层数据发生变化，不用动上层的业务。但是如果你直接操作文件是做不到的。比如我们把数据的存储从数组变成链表，这个时候你上层的业务逻辑就要相应的进行修改。所以为了实现数据的独立性，为了实现业务逻辑和数据逻辑的解耦，催升了数据库一个技术，叫做数据子语言，也就是后来的 SQL。那第三是可靠性，包括故障机制、安全机制、ACID 等等。我们可以看到，共享独立性和可靠是推动数据库从 0 到 1 的主要推动力，我们再抽象一层的话，这三个其实都是为了解决效率问题，也就是说是解决从 1 到 N 的问题。因为没有数据库，你仍然可以做这些事情，但是你的效率会大幅降低。通过数据库我们可以实现数据的共享，消除数据孤岛，实现数据的独立性，实现业务逻辑和底层数据逻辑的解耦，实现可靠性。那是不是数据库从0到1的过程中，就没有遇到困难和挑战。肯定不是的，古人云：刚柔并济而难生。实际上数据库在出现的时候，也遇到了很多的困难，其中之一就是性能。在上世纪 70 年代 CPU 的算力和存储的能力都是非常弱的，当时磁盘也才刚刚出现。所以在有限的计算资源和存储资源的情况之下，还要分出一个单独的进程来处理数据库的这样的通用的数据处理任务，对性能的消耗是显而易见的。因此当时用不用数据库，是一个严肃的问题。当然了，多年以后，这不再是一个问题了。
那提到数据自然而然就会提到大数据，提到大数据就会想到 Hadoop。那 Hadoop 为什么会产生，Hadoop又是怎么样从 0 到 1，从无到有出现的，我们也来分析一下 Hadoop 的前生今世。Hadoop 的作者叫 Doug Cutting，他在 2004 年左右开发了一个项目叫做 Apache Nutch。Nutch 是一个网络爬虫，他其实想做谷歌抓取网页这样一件事情。他开发完了之后，就开始在公网上抓取网页。当抓取到一亿个页面左右的时候，那台服务器撑不住了，因为存储空间不够了，怎么办？这个时候有两种方式，第一种方式，是使用我老东家EMC的磁盘阵列，但是磁盘阵列这个东西非常昂贵，Doug Cutting 没有办法负担用磁盘阵列去来存储网页这样的数据。所以他就选择了另一条路线，加机器，从 1台变成 2台，从 2台变成 4台。当用了 4台机器，索引了大概 4亿个页面的时候，他就发现，为了维护这 4台机器之间数据的正确性、一致性，他花出了大量的时间，那这是不经济的。所以他停下来，考虑应该怎么样解决。正在这个时候，他看到了谷歌的一篇论文叫 GFS，受 GFS 的启发，Doug Cutting 开发了 Nutch Distributed File System，也就是 NDFS，后来改名为 HDFS。HDFS 解决了什么问题呢，实际上 HDFS 解决了一个高可用、廉价存储的问题。那存储问题解决了，我们可以把数据存在很多节点上，但计算怎么办？还需要把数据从远端拉到一个节点上进行计算。毫无疑问，这是一个单点瓶颈。怎么办，当时学术界的一个主要方式是 Open MPI，但是 Open MPI 非常复杂难用，所以 Doug Cutting 没有采取。而这个时候他又看到了谷歌的另一篇论文叫做 MapReduce，受该论文的启发他很快实现了 MapReduce 这个开源项目，这就解决了并行计算的问题。如此一来，HDFS 解决了高可用、廉价存储的问题，而 MapReduce 解决了分布式并行计算的问题，这就形成了Hadoop的核心组件。开源之后，Hadoop 受到当时大型互联网公司的热捧，因为当时主要的大型互联网公司都遇到了大数据的问题，而不知所措。所以各大互联网公司，包括 LinkedIn、Twitter、Facebook 在 Hadoop 上面大举投入。
但是人们很快发现 MapReduce 的逻辑非常简单，它就是两个函数：一个是 Mapper，一个是 Reducer。但是如果想写出正确的 MapReduce 代码来非常有挑战，写出高性能的 MapReduce 代码来挑战更大。而当MapReduce 代码出现错误的时候，去进行调试更是难上加难。为此，Facebook 开发了一个新的项目叫做Hive。Hive 的初衷是，大家就不要再去写 MapReduce了，而是去写 Hive Query Language。我会把你的查询自动翻译成 MapReduce 去执行。这样你就不用再去手写 MapReduce，可以释放你的这个效率。从此之后，Facebook 内部 95% 的人就不用再写 MapReduce 代码了。还有 5% 的人，他们是 Hive 的开发者。那Hive 解决了交互查询的问题，但是熟悉数据库的人，看到 Hive Query Language 翻译成 MapReduce 这样一个动作的时候，很自然的就会想到数据库的优化器，把 SQL 翻译成查询计划。因此就会拿着 Hive 来和数据库进行对比。一比就会发现 Hive 的效率比较低，并且不支持标准 SQL。那为了解决这个问题，Hadoop 的三驾马车之一，也是最主要的 Hadoop 发行商 Cloudera 在 2013 年开源了一个全新的项目叫做 Impala。Impala 在开源之初，就放弃了 MapReduce，而是采用了数据库领域里的经典技术优化器和执行器。当然了一开始，它还使用的是 HDFS。但是我们刚才看到 HDFS 是为了解决像爬虫这样的批处理业务而设计的，它不能很好的支撑像数据库这样的交互查询。为了解决这个效率的问题，Cloudera 后来开源了一个新的项目叫做 Apache Kudu。那这样我们可以看到，Impala 加 Kudu 其实就是一款 MPP 数据库，它和 HDFS 和MapReduce 没有任何关系。那沿着这条主线，我们可以看到 Hadoop 从批处理系统，慢慢的演进最终成了一个 MPP 数据库。当然了，Hadoop 还有很多其他的主线。那我们为什么会对这条主线比较感兴趣，是因为这是 Hadoop 最赚钱的主线。根据 Cloudera 前 CEO 一些数据，Cloudera 的主要营收超过 75% 都是来自于它的 SQL 产品，也就是说来自于这条主线。现在我们再来看一看，Hadoop 为什么会从无到有产生，推动它的动力是什么，其实是大数据处理的能力。是大数据处理的性能，也就是说 Hadoop 使得大数据成为可能，使得大数据从 0 到 1 成为可能。那前面我们分析了，数据库的推动力和 Hadoop 的推动力。现在我们再放到一个更长的时间范围之内，来看一看数据处理平台的进化。
在过去的 50 年里，数据处理平台大概经历了四个主要的阶段。第一个阶段是上世纪 80 年代、90 年代，这个阶段非常简单，上层是应用底下是关系型数据库。应用通过 SQL 进行交互完美的解决了数据共享的问题和独立性的问题。到了二零零几年，互联网公司涌现，数据量暴涨，数据增长的速度远远超过了数据库技术的增长速度，因此很多公司面临着能不能的挑战。为了解决这个问题，很多专用的数据库开始出现，包括像 Hadoop、Cassandra、kv 数据库、document 数据库、宽列数据库、时序数据库等等等等。这些专用的数据库解决了当时大数据带来的性能挑战的问题，使得业务成为可能。但是它也破坏了推动数据库出现的两个因素，第一个是数据共享。我们可以看到，这么多独立的数据产品，其实每一个都是数据孤岛，无法实现数据的统一共享。第二个，应用需要去各个数据库抓取数据，到应用的内存里面，再进行数据的关联聚集合并计算等等。也就是说应用里面要承担部分查询引擎的任务，这样一来就破坏了数据的独立性。人们慢慢的发现了，这种模式效率比较低，所以在思考该如何解决。大概在 2013 年的时候，Facebook 开发了 Presto，那其实 Presto 就是一个查询引擎。它可以把应用里面的一些数据相关的操作封装起来，下推到数据库这一层面。但是 Presto 并不自己管理数据，它仍然需要各种各样的专用数据库，各种各样的数据源来获取数据。Presto 本身是一个查询引擎，由于它自己不管理数据，所以它的性能没有办法做到极致。那沿着这个方向，后来又出现了数据中台。到目前为止，其实数据中台的核心技术也就是说数据的存储和计算，都是用了这样的一个架构。如果我们拨开一些数据中台的外衣，就会看到里面封装了很多很多开源的数据产品，然后再在上面包一层薄薄的查询引擎，为上层的应用提供查询服务。那这种方式到目前为止，没有很成功的产品，没有成为主流。究其原因是如果沿着这个思路做下去，就需要把查询引擎，做成一个强大的数据库。所以出现了第四个阶段，也就是超融合数据库的阶段。这个阶段和上一个阶段不同，上一个阶段是独立的查询引擎，底层会有不同的独立的单独的数据库。而在超融合数据库阶段是一个数据库，我们内部封装不同的存储引擎，并配以相应的执行器引擎和优化器引擎，最终暴露 SQL 给应用。
这样一来，我们就解决了前面提到的两个问题。第一，数据共享的问题。大家都是在一个数据库里面，可以进行关联，可以进行直接的查询处理。第二，解决了独立性的问题。应用通过现代 SQL 直接和数据库进行交互。当然了，现在毕竟是 2021年，和上世纪 80 年代已经有了很大的不同，数据量要大了很多，业务的复杂度也大了很多，所以也没有办法回到像上世纪 80 年代那么简洁。因此在整个数据平台里面，还需要像消息队列、复杂流处理等等的产品组合在一起，形成一个数据平台。但是这种数据平台的架构，比上一个时代要大幅简化。
那如果我们再反过来看一下，这四个时代到底是谁在起着主要的推动力，就会发现性能和效率是两个关键的因素。它们分别在不同的时代，不同的场景之下，起着不同的作用。在上世纪 80 年代，是因为效率的推动，使得关系数据库出现。而到了 2000 年是因为性能的推动，出现了很多专用的数据库。那再往后，又是因为效率的推动，出现了像 Presto 这样的查询引擎，去试图封装底层大量的离散的单独的数据库。那到了第四个阶段，其实又是性能的推动。当然了，它很好的结合了性能和效率，因为毕竟数据库技术也好，分布式技术也好，包括硬件技术也好，经历了几十年的发展，实际上现在的技术已经和以前完全不同。我们可以在一个系统之内，同时兼顾到性能和效率。这一点和生物界的进化非常相似，生物界都是沿着从简单到复杂有机体的一个方向去进化。而超融合数据库，其实也是这样的一个思路，从关系数据库到各种各样的专用数据库，又到封装跨数据库的查询引擎，最终发展成了一个复杂的数据库的新物种超融合数据库。超融合数据库会在内部封装不同的存储引擎和计算引擎，并对外暴露一个标准 SQL 接口。
我们提到超融合数据库，什么是超融合？融合的是什么？我们可以从两个层面来分析，第一个层面是融合数据类型。在超融合数据库出现之前，每一种数据类型都对应着一种处理该数据类型的数据库，比如说：kv、document、column families。那超融合数据库，可以在一个数据库内部处理不同的数据类型，包括关系型数据、时序数据、GIS 数据、包括类似于 json 这样的半结构化数据和 text 这样的非结构化数据。第二个融合是融合处理场景，包括 TP 型场景、AP 型场景和Streaming以及 Machine Learning之类的场景。这就是超融合数据库的融合所在，超融合技术也是技术发展的一个自然走向。
如果我们再回过头来分析，从上世纪 70 年代到现在这 50 年的技术发展路径，我们可以看到数据处理平台有三个主线。第一个主线是交易型数据库，诞生自上世纪 70 年代；第二个主线是分析型数据库，诞生自于上世纪 80 年代；第三个主线是大数据数据湖，诞生是 2000 年左右。从 2010 年到 2020 年，这 10年的时间之内，这三个主线发生过三次两两融合。第一次是 2011 年，451 Research称之为 NewSQL，实际上就是交易型数据库和大数据技术的融合。第二次是 2015 年，Gartner 称之为 HTAP，实际上是交易型数据库和分析型数据库的融合。第三次是 2020 年，Spark 背后的公司叫 DataBricks，称之为 Lake-House，实际上是 Data-Lake 和 Data-Warehouse 的融合。如果三个大员已经出现过两两融合，我们自然可以想到最中心的地方，就是超融合。
前面我们提到超融合数据库是技术演进的自然趋势。但是，超融合数据库也面临着很多的挑战。不过超融合数据库的一个特殊类型，超融合时序数据库，已经出现并且实现产品化。那什么是超融合时序数据库？很简单，超融合时序数据库就是关系库加时序库再加分析库。时序数据库有三个要素，分别是插入、存储和查询。那插入操作最频繁，大概有 95% 到 99% 的操作是插入操作。而且时序场景下，没有波峰波谷，要求比较平稳，持续高吞吐。并且实时数据能够插入，那存储时序数据量非常大，对效率非常敏感，因此要求比较高的压缩比，而且需要冷热分级存储。因为时序数据本身它的量很大，而不同时间点，不同时间段的时序数据其价值密度是不一样的。所以，用户希望可以使用不同价格的存储介质来去存储不同价值的时序数据。时序场景的查询非常多样化，包括单设备的最新值查询、明细查询和聚集查询；还包括多设备的最新值查询、聚集查询和明细查询，多维度的维度查询；还包括预测、模式识别、数据挖掘等等各种各样的查询。所以时序场景的查询是非常多样化的。那是不是解决了插入存储和查询之后时序数据库就OK了呢？其实远远不是。
现在我们来可以看一下，根据 DB-Engines 在时序数据库这个细分领域流行度排名第一的 InfluxDB 对未来时序数据库功能的一个概述。去年 InfluxDB 在其官网公布了它的下一代产品，叫做 IOx。在文章里面，它也提出了下一代时序数据库设计的 13 个目标，我们称之为时序 13 条。我们可以简单的看一下，第一条是说要支持海量的设备，大量的指标和标签。用过 InfluxDB 的朋友可能知道，InfluxDB 建议标签数不要超过3-5个。而它的性能也会随着设备数的增加和指标数的增加，加速的下落。所以它的下一代时序数据库产品，第一个设计目标就是要解决海量设备、大量指标和标签的支持问题。第二条是说不但要很好地支持Metrics 这种 query，还要实现一流的分析能力。第三点是要支持多态存储、支持多机存储、支持存算分离，再往下是要灵活的内存控制。大家都知道做一个数据库经常会出现两类问题：第一类是查询很慢，第二类是 Out Of Memory。所以 InfluxDB 也希望能够在下一代产品，对内存实现更灵活的控制，再下面是灵活的副本控制、灵活的分区机制，能够支持很强大的执行器、支持容器化，可以做到并行的导入导出，能够支持数据订阅，能够兼容生态，特别是一些新的生态，可以做到云边一体，能够支持数据联邦，并且支持内嵌脚本，使得用户可以使用类似于 Python，Java, R 这样的语言，在数据库内对它的数据进行分析处理。这是行业排名第一 InfluxDB，在时序数据库领域摸爬滚打了七年之后，在接触了大量的场景之后，总结的下一代时序数据库应该具备的功能，我们对此非常认可。除了其中的一条就是灵活的赋能控制，我们认为这一条可以放宽。
那这是不是就是时序数据库的终局呢？我们对此并不这样认为。我们把时序数据库划分了三个代际：第一代是专用的时序数据库，典型的代表就是 InfluxDB、OpenTSDB 这样的数据库产品。这种时序数据库只能支持时序场景、只能支持时序数据，因而很多时候都需要关系型数据库的配合。其次它只能解决偏监控类的问题，支持一些小查询。第二代是关系型时序数据库，它把关系数据和时序数据整合在一起，把时序当做是关系型数据库里面的一个数据类型或者是说数据场景，典型的代表就是 Timescale。但是 Timescale 不能很好地处理分析性查询，它的分布式能力也是比较薄弱。为此我们提出了第三代时序数据库，也就是超融合时序数据库。超融合时序数据库，可以在一个数据库内解决时序的全场景问题，不需要再去引入额外的第三方的数据库，一库搞定时序全场景，我们认为这是时序数据库的最终形态。
那第一代时序数据库和第三代数据库它的核心区别是什么？我们可以分析一下，第一代时序数据库的典型代表 InfluxDB，InfluxDB 实际上做了大量的工作都是在把存储引擎做成数据库。其实很多 NoSQL 都是核心做了一个存储引擎，然后上面包一个比较薄的执行器，没有优化器，对用户进行服务。这些 NoSQL，包括InfluxDB，其实是类似于把存储引擎做成数据库。我们可以看一看 InfluxDB 在存储引擎领域做的一些迭代，大概在 13、14 年的时候 InfluxDB 0.8 的版本使用的是 levelDB、RocksDB 和 lmDB。但是这三个存储，都有各种各样的问题。比如说不支持热备份、不能高效地支持删除或者是说会造成文件描述符的暴涨。所以到了 0.9 的版本，InfluxDB 引入了BoltDB，但是BoltDB又遇到了写吞吐的问题。到了 0.9.5，InfluxDB开始引入它自研的存储引擎，基于 WAL 加 TSM 加 TSI，这个存储引擎一直用到现在。比较有意思的是 2020 年，InfluxDB 宣布要做下一代产品 IOx，而这次它又换了存储引擎，它将使用 Arrow 做 IOx 的存储引擎。
那么我们不免要问 InfluxDB，用了五六年的自研存储引擎，WAL +TSM +TSI，到底遇到了哪些问题。其实如果我们回想一下，刚才说的时序 13 条里面就比较容易回答。第一条的话就是支持海量的设备、大量的指标和标签；第二条的话就是支持分析型查询，而它的自研存储引擎，不能很好的解决这两个场景的问题。我们前面提到 InfluxDB，目前不支持分析型查询，同时它的性能在指标数增多，设备数增多的时候衰减得非常严重。所以它才要在下一代产品里面，再换一次存储引擎。我们可以看到 InfluxDB，在过去的七八年的时间换了这么多的存储引擎，这也说明存储对于像 InfluxDB 这样的 NoSQL 数据库来说是多么的重要。
那么第三代时序数据库，也就是超融合时序数据库，是怎么做的呢？譬如 MatrixDB，我们是把存储引擎做进数据库，而不是把存储引擎做成数据库。MatrixDB 在一个关系型数据库内部，可以插拔不同的存储引擎，比如说关系数据引擎、时序数据引擎、空间数据引擎、Json数据的引擎等等。而且，可以实现这些数据引擎之间进行关联，并且可以确保ACID。这是第一代时序数据库和第三代时序数据库的核心区别，一个是把存储引擎做成数据库，一个是把存储引擎做进数据库。
那超融合时序数据库有什么好处呢？其实是一目了然的。左边我们可以看到是关系库、时序库和分析库支撑上层的一个应用，而使用了超融合时序数据库就可以用一个数据库来代替过去的三个数据库，一个顶三，技术栈大幅简化。而开发运维的效率也会大幅地提升，我们可以用一个具象的画面来感受一下。
这是我们过去在接触用户的时候，经常碰到的一个场景。很多用户，都是用了左边这样的一些架构。它们首先有主数据，主数据会存在 MySQL、PostgreSQL 这样的关系型数据库里面去，而设备的时序数据会被采集丢到 Kafka 里面去。Kafka 会有很多消费者，包括 Redis、Elasticsearch、HBase、Flink、Hive 等等。那这些产品，每一个都来解决一个特定的查询场景。比如说 Redis，Redis 主要用来解决设备最新值这样一个查询，比如某一个电表它的最新读数是多少。HBase 主要用来解决明细查询，我可以通过主键查到一个设备一段时间之内它的明细数据，或者是聚集数据。Elasticsearch 主要用来做维度查询。而 Flink 主要做实时查询。Hive 主要做 OLAP 的数据分析。那右边这个图是用 MatrixDB 之后的架构图，我们可以看到整个架构技术栈大为简化，它的开发和运维的效率也大幅提升，并且出错的概率也大幅减少。这是真真正正地做到了一个顶多个。
MatrixDB 是国内唯一一个通过了工信部两项权威认证的产品。一个认证是分布式分析型数据库，它包含了 27 个必选项、24 个可选项一共 51 个测试项，MatrixDB 全部通过。目前国内只有两个产品，通过 51 个选项，MatrixDB 是其中之一。第二个认证是时序数据库的认证，包括 26 个必选项和 7 个可选项，MatrixDB 同样也是全部通过了 33 个测试。
除了功能非常丰富非常强大之外，MatrixDB 的性能也是非常卓越。我们做了三个场景的性能测试，前面我们提到时序数据库 95% 到 99% 的操作，都是数据的插入，所以我们对各种各样的场景进行了测试。这里我们列举了其中之一，感兴趣的朋友可以到我们官网去查看完整的性能测试报告。这个场景是 10万个设备，指标数从10、50、100 到 400 不等。我们可以看到在各个场景之下，MatrixDB 的性能都是具有明显的优势。而且随着指标数增多，MatrixDB的性能优势越来越明显，大概在 400 个指标的时候，MatrixDB 就是 InfluxDB 的 50 倍左右。这是插入，第二个评测是查询的延迟。我们选择的是 TSBS Benchmark，对比 TSBS Benchmark 的主要的维护者之一 Timescale。我们可以看到在评测结果里面，大查询对 Timescale 具有明显的优势；而对于小查询，我们是处于在同一个量级上，大家都是在毫秒级左右。第三个测试是吞吐，也就是 throughput。这个是我们一个用户测试的场景，他发现 MatrixDB 和国内的一个竞品相比，吞吐量要高 80 倍左右。所以我们可以看到，不管是插入、查询的延迟、高吞吐还是 throughput，MatrixDB 都是性能卓越。当然了，性能只是诸多考虑的因素之一，在生产环境，除了性能用户还会关注诸多的因素。
前面我们提到时序数据库细分领域的行业排名第一InfluxDB对未来时序数据库设计目标的一个解读，在这我想分享给大家的是 MatrixDB 4.0 已经实现了这 13条中的 11条。除了容器化和灵活的副本控制，其他的我们已经做到很好的支持。而且还不止如此，MatrixDB 还有更多的功能，是一个真真正正企业级 ready 的超融合时序数据库产品。它可以很好的支持线性扩展，既可以单节点部署，也可以分布式部署。能够支持资源管理，有完善的监控报警系统；能够做在线扩容，不用停机、不用停业务；具备分布式备份恢复的能力，完善的支持事务，支持 ACID；还有 360 度的安全访问机制，包括认证、权限控制、加密、审计；支持多种压缩算法，包括列式压缩算法和通用压缩算法；支持多种索引，还支持多表关联；支持复合数据类型，包括数组、Json、KV 等等；支持自定义类型、自定义函数、自定义聚集；支持持续聚集，物化视图，子查询等等。所以我们可以看到 MatrixDB 4.0非常强大，它不但性能卓越，而且功能非常非常完善，是一个真真正正的 production ready 的一个企业级产品。它可以让您和您的客户省心省力，省时省钱。
下面我们看几个场景和案例，第一个是工业互联网。工业互联网是智能制造的重点，也是我们国家十四五规划的重中之重。这张图我们可以看到左边是工业里面的工业设备、生产设备，也就是说是生产域，是 OT 域的设备。通过数据采集，我们可以把这些数据插入到 MatrixDB 里面。而同时 MatrixDB 还可以对接 IT 域像 ERP、CRM 这类数据，可以实现在 MatrixDB 内部做到 IT 域和 OT 域数据的融合。在一个公司内部全量数据的基础之上提供支撑包括流程优化、智能分析等等。所以 MatrixDB 可以是工业互联网的数据基座，它可以从数据层首先实现两化融合，为智能制造打下数据基础。
这是一个车联网的例子，这个用户之前用了像 OpenTSDB 这样的时序数据库，然后搭配 Hive 这样的多维分析的产品。采用了 MatrixDB 之后，它可以用一套数据库，来解决过去两个分布式系统。当然了大家知道 OpenTSDB 底层是基于 HBase，那 HBase 呢又用了 ZooKeeper 和 HDFS 等等一堆的分布式产品，所以底层其实是很多套分布式系统。现在的话用一套分布式系统，一个超融合时序数据库可以解决过去很多产品组合才能解决的场景。这样一来的话整个技术栈大幅简化，开发和运维的效率也有了明显的提升，整个技术栈大幅简化，性能也是原来架构的 10倍以上，开发运维效率大幅提升。
这是一个物联网智慧城市的案例，随着万物开始互联，各种各样的数据开始被采集到，包括天气的数据，空气的数据、栅格数据；包括交通里面道路数据、车流数据、人流数据、人群的各种各样的数据。这些数据通过各种各样的传感器收集起来实时上传到 MatrixDB，然后支撑上面的各种各样的业务，包括风险预测、事故的预测、时空的大数据分析、事件流分析、交通分析等等，各种应用的场景。
下面我们再看一个云边一体的案例，这是一个能源相关的场景。在场站侧我们部署了一套单节点的 MatrixDB 数据库，在集控侧部署了四个节点的 MatrixDB 数据库，在数据中心部署了一个十几个节点的大集群。这样就可以使用一套数据库，无缝地实现数据在各个层次的对接，真正的达到了云边一体。
时序数据是物联网、车联网、工业互联网和智慧城市的基础数据，而时间是时序数据的最重要的属性。时间的本质是什么，目前尚无定论，不过哲学家黑格尔说的一句话非常具有参考价值。他说时间是人们对过去的回忆，事物本身没有记忆，所以我们没有办法对过去的事物形成回忆。但是超融合时序数据库，将会为未来的事物赋予记忆，进而拥有智能。超融合时序数据库，为万物互联的时代提供一站式的数据平台。让您和您的客户省心省力、省时省钱。感谢大家观看MatrixDB 4.0 发布会。谢谢。
