近期，在 YMatrix 5.0 发布会上，四维纵横创始人 & CEO 姚延栋分享了《返璞归真，以简驭繁 —— YMatrix 超融合数据库 5.0 发布》的主题演讲。在本次演讲中，介绍 YMatrix 超融合数据库的发展历程及现阶段的技术痛点，深入阐释了万物智联时代数据库的最佳形态。本文根据现场演讲内容整理而成。
⚠️ 四维纵横创始人姚延栋的精彩演讲可以通过“YMatrix 超融合数据库” 视频号 & B站 上观看啦！
“返璞归真，以简驭繁” - 超融合数据库 YMatrix 5.0 新品发布会
这十来年，我们见证很多大数据和数据库产品的潮起潮落、兴衰变迁，我们开始反思数据库的本质是什么，特别是万物智联和数字化转型时代，数据库的形态应该是什么样的？这些反思催生了 YMatrix，目标是打造为万物智联和数字化转型时代而生的数据库。
万物智联时代，时序是最重要的新变量。为此我们选择了时序数据库切入，然而和其他时序数据库明显不同，我们是超融合时序数据库，不单支持时序，还可以支持关系、JSON、GIS、文本等。
经过两年多对产品的打磨，YMatrix 已经在全球最大的 IoT 时序场景落地，在该企业每天写入的数据超过十万亿个数据点，同时还有高并发的查询。大家试想一下，一方面有数据的疯狂写入，同时还要支持高并发查询，在有限的资源下，相互之间会竞争 CPU、IO 等资源，非常有挑战。
通过我们优秀的工程师团队不懈地努力，大幅优化了写入以及资源使用率后，我们搞定了这个场景，客户非常满意。现在我们可以自信地说 YMatrix 已经穿透了时序场景，而 5.0 将更多的研发重心放在了“超融合”。
因为我们相信超融合是万物智联时代的最佳数据库形态。
过去 20 多年出现过很多优秀的产品，他们或者是性能卓越，或者是功能强大，或者是易用性极佳。即便是到了今天，用户仍在选择数据库时，不得不在功能、性能、易用，这三者之间进行权衡和取舍。
有的数据库性能卓越，但是易用性欠佳；有的数据库支持关系数据，但是不支持时序；有的数据库支持时序，但是不支持分析和 Machine Learning 等等，而我们认为应该是更多的融合，而不是权衡和取舍。举例来说，智能手机成功地将电话 MP3、GPS、照相机以及存算能力融合在一起，这种融合不单开创一个全新的消费电子领域，也改变了人们的工作和生活方式。
与此类似，超融合数据库也是 N 合一，把多种不同数据库品类的常用功能整合在一起。这里的 N 是指场景的不同，可以是 1、2 或 3，甚至更多。这种融合不是简单功能上的堆砌，而是真正提供一个数据基座的基础设施级别的数据库。当然，这样的融合本身不会带来产业的巨变，它更像是催化剂，能够催化和加速各行各业的数字化革新。
谈到融合，最主要的是功能上的融合，各种不同的数据库产品和品类，区别最大的就是功能。
按照不同的标准有不同的划分方式
这里我们以数据模型及处理模型来分类，按照数据模型有关系数据库、时序数据库、图数据库等，而处理模型又可以进一步细分，如处理类型有 OLTP 和 OLAP，时效性有批处理系统和流处理系统，这两大分类最早常见于大数据领域。近几年随着流和数据库更多的整合，流数据库也受到越来越多人的关注。按照处理模式是否已知可以分为数据仓库和数据湖。
可以看到数据库的品类非常的多，这一方面说明了数据库是丰富多彩的，同时也给用户带来了选择困惑。
现在工业 4.0 和智能制造备受关注。以工业场景为例，在工业场景里有很多重要的信息化系统，譬如有制造执行系统 MES、仓储管理系统 WMS、质量管理系统 QMS，这些信息化系统大多使用关系型数据库，常见的有 SQLServer、MySQL 和 Oracle。这些数据库很多都是跟随着信息化系统进入企业的。
随着智能制造的发展，企业希望构建设备的智能管理和运维，为此需要耗时数月选型时序数据库，引入时序数据库，以解决时序数据的采集、存储和监控等问题。常见的时序数据库产品有 OpenTSDB、 InfluxDB 等。
时间的推移下，数据会不断地积累，形成历史数据，这些历史数据中蕴含着丰富的价值。为了挖掘这些价值，促进企业的数据驱动实现决策支持，我们需要搭建 BI 和选型数据仓库，常见的数据仓库和分析型数据库有Greenplum、Clickhouse 和 Hadoop 等。机器学习在工业里面使用了很长时间，近年来随着大数据的发展，基于大数据模型的机器学习算法，精度更高，因此企业希望引入基于大数据的机器学习模型，叠加工业激励模型去实现企业的降本增效。
为此需要引入 Spark、TensorFlow 机器学习平台， 这一趋势会随着需求不断发展而继续。譬如，当需要解决文本检索的时候，引入 Elasticsearch 或 Solr；当需要解决地理位置数据处理，需要引入 ArcGIS；当需要解决文档数据时，引入 MongoDB。
每一次的选型，少则需要耗时一两个月，多则耗时半年甚至一年以上。很多时候还会发生选型时测试是好的，一旦上生产却问题频出，很多企业被迫放弃选型或者是重新选型。
这一现象也称为试点困境，甚至有人称之为试点炼狱。
选型的结束并不是工作的结束，而是更多工作的开始，每一种产品都需要运维、监控、报警、导入、导出、备份、恢复、高可用、权限管理等。诸多产品的叠加，运维的复杂度就会更高。一旦出现问题，就会造成生产和交付出现问题，并且每一种产品都有学习成本，诸多产品的学习成本叠加在一起就会更高，而使用不当是很多问题的关键。
这么多的数据库，数据库的本质是什么？如果我们抛除掉所有的概念以及技术细节，数据库的本质就三件事情：接数据、存数据和用数据。
过去很多不同的数据库都是在使用不同的方式去解决这三个最本质的问题。所谓天下大事，合久必分，分久必合。上世纪八九十年代，数据库趋势以和为主，而 21 世纪的头十几年，数据库以分为主要趋势，面向细分场景去开发数据库，以解决该场景下的问题，所以形成了很多的数据库品类。
当时有一点卖方市场的意思，重要的是要看数据库的开发人员能够开发出什么样的产品来给业界使用，而用户更多的是组合不同的产品来去解决自己全场景的问题。
为什么会这样？主要还是由于事物发展到不同阶段造成的。不管是硬件技术、分布式数据库技术还是开源软件，相对都比较早期，积累和沉淀比较薄弱，在面向细分场景可以有效地降低复杂度，提升成功的概率。
近几年，数据库领域融合趋势渐显，出现了诸如 HTAP、湖仓一体等热词。我们不禁要问，融合的尽头是什么？作为数据库人，是继续一个问题、一个问题的解决当下，还是以终为始，思考终局？更重要的是，用户想要的到底是什么样的数据库。
用户其实并不关心 TP、AP、批流、湖仓，用户想要的是一款强大的数据库，可以解决最根本的数据问题。有数据就可以往里面写，想用可以随时用。用户更希望把精力放在数据自身的价值和业务价值上，而不是数据库的价值。所谓批流之分，湖仓之分只是阶段性的产物。
采用 YMatrix 超融合数据库，只需要选型一次，也只需要运维一个产品，选型成本和用户运维成本会大幅地降低。一旦完成选型后，当新需求出现时，无需再耗费数月去选型一个专用数据库，只需要研究在 YMatrix 中如何实现该功能。
主要涉及到三个方面，建模、写入和查询。
同样以工厂场景为例，我们来看使用 YMatrix 数据库的客户旅程感受。首先是工厂的信息化系统，信息化系统使用的是关系型数据库，而 YMatrix 本身是一个严格意义上的关系型数据库，和 PostgreSQL 的接口完全兼容，可以使用标准的 SQL 进行建模、写入和查询。熟悉 SQL 的人一看便知。
在关系数据或者 OLTP 场景下， YMatrix 推荐使用 Heap 存储引擎，怎么做也是非常简单，只需要在建表时使用 using heap 即可，其他的所有工作会由数据库来自动实现。一旦建模完成，查询和写入都可以使用标准 SQL 实现。
当需要建设设备智能运维系统时，无需再去选型专用时序数据库，只需看如何在 YMatrix 实现，方法和前面一样，使用标准 SQL 进行建模、写入和查询。
只有一点区别，建模时使用 MARS2 存储引擎。MARS2 是我们专门为时序场景打造的存储引擎，性能非常的好。当需要构建报表或者建设 BI 系统时，也无需耗时再去选型专用的分析型数据库，只需使用 YMatrix 提供的强大数据分析能力。
如上图所示，该 SQL 使用了窗口函数来计算跳变差值。经常用于安全和报警等场景下，可以看到，短短 10 几行 SQL 就可以实现强大的业务价值。
上图是另外一个例子，大概 20 行左右的 SQL，用于计算所有车辆的全天驾驶循环，通常会用在高级分析和机器学习模型训练中。
这两个 SQL 主要想演示 YMatrix 强大数据分析能力，寥寥几行 SQL 就可以快速提供业务价值。如果和 BI 软件的集成，可以让业务人员直接挖掘数据价值。
YMatrix 提供了库内机器学习，也就是 In-Database Machine Learning，这也是一个非常强大的能力。
我们看一下上图，是用户自定义函数，类似于存储过程，可以直接在数据库内执行。函数体是用 Python 来实现，在里面可以调用任意 Python 代码。例子中可见，使用了 pandas 流数据库，同时也调用了用户自己编写的 metric，最后一行调用了 metric.forecast 函数，以实现模型的训练和预测。
这意味着你可以在数据库内执行任意的 Python 代码来去实现原地数据分析，也意味着整个 Python 生态为你开放，更意味着无限的数据分析可能，功能强大，感兴趣的朋友可以好好地研究一下。
YMatrix 还支持其他数据库功能，譬如文本检索、JSON 和 GIS 等，使用方法非常简单。使用标准 SQL 建模、写入、查询，只需要在建模的时候使用正确的数据类型即可。
此外，YMatrix 还提供了强大的索引能力来去加速不同场景下的查询性能。
下图，我们展示了一个 SQL 示例，用于计算过去 24 小时内，在某个点周边两公里的所有 ATM 机，提款超过 2000 元的所有交易。
这是一个非常复杂的业务需求，但是我们使用了 6 条 SQL 在 YMatrix 里即可完成这个业务场景。
我们可以对比一下两种不同的客户体验，一种需要试点、选型、学习、适配，耗时数月以上；另外一种使用 YMatrix 当下立即开发，并且全部使用标准 SQL，学习曲线很低，可以带来超过 10 倍，甚至 100 倍以上的效率提升。
YMatrix 超融合数据库 + 现代 SQL 可以实现无限可能。YMatrix 强大功能远不至此，随着使用的深入，经常会惊喜地发现原来这样的功能已经实现。这里列举几个常用的，譬如：用户透明分区，无需用户再去手动分库分表，冷热分级存储、物化视图、索引、压缩等。
值得强调的是，YMatrix 还支持 ACID，确保数据不丢、不错、不重。很多时序数据库和分析型数据库都不支持 ACID，无法确保数据的正确性。
最后，我们用两张图来对比两种不同的技术栈和体验。
采用超融合架构，可以有效地节省设施成本及运维成本，提升开发效率并降低人才门槛。我们知道在数字化转型时代，最稀缺的人才是复合型人才，教育和培训很难快速地满足业内对于复合型人才的需求。通过降低人才门槛可以有效地缓解这一问题，所以使用 YMatrix 超融合解决方案可以大幅地降低行业专家驾驭数字技术的难度，真正的为行业转型赋能。
过去两年来，我们和很多客户及同行进行交流，大家都认可超融合数据库的价值，但是也有两点顾虑，一是能不能实现，二是即使实现了，性能会怎么样？
前面我们回答了第一个问题，现在我们来回答第二个问题 —— 性能。
性能可以说是数据库领域永远具有吸引力的话题，因为性能数字清晰直观，孰优孰劣，孰强孰弱，一目了然。特别是近来很多厂商去参加性能的打榜、打擂，有一点大跃进的意思。
但这也是好事，说明技术是在不断地进步。然而我们也注意到，绝大多数的厂商仍然是在打单榜、打细分的场景。现在数据库竞争已经到了深水区，单靠某个细分场景上，20-30% 性能优势甚至是一倍的优势，已经难以再获得用户的青睐，而需要铁人三项甚至是十项全能。
YMatrix 非常看重在用户全场景之下的性能表现，包括写入、时序查询、单表分析、多表分析、 Machine Learning、OLTP 等，有了性能的支撑，超融合才有意义。
我们来看下面 6 个数字。
第一个数字：1.52 亿数据点/秒。
这是一个真实客户场景写入的性能表现，单看这个数字可能没什么感觉，我们来做一个对比，工业大数据是一个典型的时序场景，而一般工厂的数据规模在 10 万点左右。现在我们解决了 1.52 亿规模场景，可以说是工厂场景的 1500 倍以上，从侧面说明了 YMatrix 的强大写入能力。
这个客户是理想汽车，我们使用 10 台 x86 服务器，实现了 1.52 亿数据点/秒的写入能力，同时还可以支撑高并发的查询。
创业两年来，我们也接触过数百家大大小小企业，包括我们也看到国内外友商很多场景案例分享，理想汽车是我们目前了解到最大的时序场景，可以说是时序的珠穆朗玛峰。感谢我们优秀的团队，我们已经登顶，如果你有更大的场景，我们非常期待交流。
为什么写入性能我们使用时序场景，因为时序场景 99% 的操作是写入，对写入的性能要求最高。如果我们能搞定这个场景之下对高并发、低延迟写入的要求，我们就可以相对比较容易的搞定其他场景的写入性能诉求。
第二个数字：5.1 倍。
这是 YMatrix 和 TimescaleDB 在时序场景下查询的性能对 比，用的是 TSBS 标准 Benchmark，TimescaleDB 耗时是 YMatrix 的 5.1 倍。
TimescaleDB 是一款优秀的时序数据库，创立于 2015 年，现在估值超过 10 亿美金，是一家独角兽企业，客户也很多，包括像苹果这样的全球知名企业。TSBS 是 TimescaleDB 官网推荐的一个 Benchmark，我们采用其企业 CPU only 测试集，用的是 10 万设备规模 ，TimescaleDB 耗时是 YMatrix 5.1倍。
这里我们使用的是 MARS2 存储引擎，TimescaleDB 使用 Heap，而 YMatrix 也有 Heap 存储引擎。如果两个产品都使用 Heap 存储引擎的话， YMatrix 性能比 TimescaleDB 快一倍以上。
顺带一提，YMatrix 和 TimescaleDB 都是基于 PostgreSQL，所以在创业早期我们也借鉴了一些 TimescaleDB 的做法，比如说 TimescaleDB 会使用 Heap 去承接时序场景下的热数据，7 天之后会自动转换成冷数据，把 1000 行压成一行以去实现类似于列存，提高压缩比。
我们当时认为这种方法应该是可行的，因为 TimescaleDB 已经获得了广泛的接受，但是当我们实现之后，到国内客户现场去 POC 时，才发现这种方法根本不工作。
原因有三点：第一，在转表时，资源消耗非常重，会造成大量数据积压；第二，一单转表，冷数据不能更新，但在很多场景下，更新是一个常规操作；第三，明细查询和聚合查询比较慢。
吸取了这些教训之后，我们重新设计了存储引擎 MARS2，解决高并发、低延迟的数据写入性能问题，同时也不再分冷、热，而是都可以 Update，最后就是明细查询和聚合查询性能有了大幅地提升。
第三个数字：27 %。
这是 YMatrix 和 Clickhouse 在 SSB 1000上面的性能对比数字 ，Clickhouse 耗时比 YMatrix 多 27%。众所周知，Clickhouse 是一款卓越的分析型数据库，主打单表的性能， 因其性能卓越，所以很多厂商都去找 Clickhouse 打擂，我们也不免俗。
Clickhouse 性能非常好，主要来源于两个点，一是存储的有序化，二是执行向量化，然后就是大量其他细节的长期打磨。在实现了有序存储和向量化执行器之后，YMatrix 和 Clickhouse 性能在同一个数量级。随后我们在 SSB 场景之下投入了大量的资源去进行细化。
很多时候我们的工程师为了几个百分点的提升而鏖战，最终我们在微批动态执行等方面取得突破之后，得到了今天的数字，可以说实属不易。
第四个数字是 X。
这里我们卖一个关子，是和 Greenplum 的性能对比，用的是 TPC-H Benchmark，Greenplum 是一款卓越的 MPP 数据仓库，自 2015 年开源以来，受到了业内的广泛关注。
Greenplum 由于其在功能、性能、稳定性方面的综合表现出色，在国内外有大量的商业用户和免费用户，也有多家互联网厂商采用开源的 Greenplum 构建了其 MPP 数据仓库，譬如说阿里的 ADB。我们后续会通过公众号发布详细的评测文章，敬请各位朋友关注。
第五个数字是 8 倍。
YMatrix 和 Spark 在 Machine Learning 场景之下性能对比，也是我们客户的实测数据。这个客户使用 Spark + Hive，耗时是 YMatrix + Python 的 8 倍以上。
Spark 是全球知名的开源大数据平台，而 Spark ML 是全球知名的 Machine Learning Library，我们也见到很多用户使用 Spark + Hadoop 技术栈，这个技术栈有一个非常明确的特点就是数据贴近计算。当需要进行模型训练时， Spark 去数据源拉取数据到 Spark 集群。这样一来，数据量大性能损耗非常明显。
YMatrix 提供了强大的库内机器学习能力，可以把任意的 Python 或 R 的机器学习算法下推到数据库里面，也就是说计算贴近存储。这样避免移动海量的数据，同时借助于 YMatrix 强大的并行执行能力，性能优势很明显。
第六个数字：160 万。
YMatrix 和 Intel 实验室联合测试的结果，用的是 TPC-B 国际标准测试集。英特尔提供 5 台服务器，每台是 128 个 core，256GB 内存。在 TPC-B 标准 Benchmark 之下，主键查询 TPS 高达 160 万，而 Update 和 Insert 的 TPS 也超过 20 万以上，包含增、删、改、查，4条 SQL 的事务， TPS 高达 6.7 万。
虽然 YMatrix 主打场景不是极致的 OLTP，但是可以看到性能数据依然非常卓越，可以满足很多企业的 OLTP 以及 HTAP 场景，绝大多数企业的 TPS 在 10 万以下。
我们用了 6 个数字，分别从写入性能、时序查询、单表 OLAP、多表 OLAP、Machine Learning 及 OLTP 等方面展示了 YMatrix 强大综合性能能力，可以说非常亮眼。一款数据库不但融合了很多功能，而且性能也很卓越，特别是在时序、分析和 Machine Learning 等主打场景之上，可以做到比专用的数据库还要快。
YMatrix 5.0 中包含了多达 138 项性能优化，特别是数据写入、分析等方面，我们进行了指令集的优化。很多时候我们的性能团队都拿着汇编代码在研究“时间去了哪里”，通过和时间赛跑，我们确实追回了很多“时间”，最终取得现在的结果。
功能丰富，性能卓越还不够。我们认为万物智联时代，数字化转型时代的数据库还要做到简单易用，只有足够的简洁才能够降低门槛，才能够真正的赋能各行各业数字化转型。
使用数据库的第一步是安装，然而由于分布式数据库的复杂度，繁琐的安装步骤让很多的初学者望而却步。为了解决这个问题，我们提供了体验极佳的图形化 installer 在 10 分钟左右就可以完成一个分布式集群的搭建。
更进一步，为了降低初学者的学习曲线，我们还提供了 onboarding 特性，让用户可以在 3 分钟之内，体验一个完整的 IoT 场景，包括数据的写入、查询及分析。
安装好数据库之后，下一步就是数据入库。Kafka 是目前业内事实上的工业标准，有大量用户在使用 Kafka 来实现数据的分发。为了降低数据入库的复杂度，实现实时数据入库，我们提供一个图形化的 Kafka 链接器，可以 6 步零代码实现 Kafka 的秒级入库，大幅降低了数据入库的复杂度。
没有监控的数据库可以说就像是一个盲盒，充满着不确定性和惊奇。YMatrix 非常看重可观测性，5.0 里面提供了超过 100 项核心指标，运维人员通过指标可以了解整个集群的运行全局和细节。
这些指标时时刻刻在为集群做 X 光，确保数据库的健康平稳地运行。一旦发生问题，通过相关指标，可以快速定位原因，快速地解决问题。
YMatrix 4.0 如果发生 master 故障，还需要人工的干预才能恢复。在 5.0 中，我们对故障的监测和高可用进行了全新的设计。基于 Qurom 技术，我们现在无需人工干预，可以全程实现任意节点自动 failover，这样一来大幅提升了集群的鲁棒性，让 DBA 也可以睡个好觉。
扩容在很多场景下是一个低频操作，对于大多数企业来说，两三年扩容一次就不错了。在物联网场景之下，时序生产的速度非常的快，扩容成为了常规操作。
YMatrix 5.0 中，我们对扩容进行了重新设计，基于 segment set 特性，可以确保扩容的过程中业务零中断，并且不影响读写。这样一来可以保证在扩容的过程之中业务正常运行，让 DBA 的工作更为容易。
超融合数据库是一个全新的尝试。和以往不同，超融合是站在用户的视角来思考用户的全场景，全场景需要什么样的数据库。
苹果公司早期的交互设计师泰斯勒提出复杂度守恒定律，定律指出一个系统的一些复杂度是没有办法被降低的，这种内在的复杂度只能通过产品设计的方式去平衡和转移。数据库就是一个非常复杂的系统，整个数据库界过去 20 年一直在努力降低或转移复杂度，而不同的数据库产品和品类都是这种努力的尝试。
回归根本，用户最想要的就是一款强大的数据库，可以解决所有数据的最根本问题，接数据、存数据和用数据。YMatrix 4.0 发布以来，受到了很多创业公司到大型企业的认可，其中还包括市值超过万亿的公司，譬如宁德时代、比亚迪，也有世界 500 强企业，譬如三一重工、小米等。作为一家创业两年左右的基础软件企业，能为这些伟大的企业服务是我们的骄傲。
每个时代都有不同的时代需求，也有不同的时代诉求，每个时代也有其最主要的玩家，因此需要为时代而生的产品服务。我们已经走过了信息化时代和大数据时代，进入了数智化和万物智联的时代。
YMatrix 致力为数智化和万物智联的时代打造为这个时代而生的数据库。今天，我们一起深耕数据库领域十多年的数据库人定义了一个数据库的新品类，走在了世界的前列，也走到了已知和未知的边界。前方可见之路是越来越少，却也充满着无限的可能，我们一方面心怀忐忑，同时也满怀期待，也热忱的期望，对数据库有极大热忱的工程师可以加入我们团队，一起玩一个无限的游戏。
今天我们发布 YMatrix 5.0，其中包含众多新特性，特别是在性能和易用性方面，希望 YMatrix 能够为更多的用户带来价值，也期待着更多的用户给予我们反馈，让我们可以在超融合的路上越走越好。
自创业做时序数据库以来，我就对时间的本质非常感兴趣。关于时间，最新的物理学形成了很多颠覆认知的新共识。时间的本质是什么？尚未定论。古希腊人早就用了两个词来表示时间，一个是 Chronos，一个是 Kairos。Chronos 是定量的、机械式的时间，Kairos 是定性的，具有特定意义的时间，也是组成我们人生故事和记忆的时刻。
希望本次 YMatrix 5.0 发布会可以带给诸位 Kairos 时光。最后感谢大家观看本次的发布会，谢谢。
本文为 YMatrix 原创内容，未经允许不得转载。
欲了解更多超融合时序数据库相关信息，请访问 “YMatrix 超融合数据库” 官方网站
