创意电子

标题: 超融合时序数据库定义将来影象 -- MatrixDB4.0发布会实录 [打印本页]

作者: 一刻talks 时间: 2021-8-10 15:28
标题: 超融合时序数据库定义将来影象 -- MatrixDB4.0发布会实录
MatrixDB 4.0于2021年7月5日在线发布，本文是图文内容。

大家好，我是四维纵横创始人姚延栋。感谢大家观看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、从无到有。那为了回答这个问题，我们不妨回到上世纪70年代，当时还没有数据库，开辟人员使用文件来去存储和管理数据。我们可以假想一个场景，一个企业有三个系统：一个是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等等；支持自界说范例、自界说函数、自界说聚集；支持持续聚集，物化视图，子查询等等。所以我们可以看到MatrixDB4.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发布会。谢谢。

欢迎光临创意电子 (https://wxcydz.cc/)