浅谈国产数据库的现状及发展，有代表性的国产数据库
【CSDN编者按】近年来，除国产数据库刷新各种排行榜纪录外，混合HTAP数据库也迎来了发展的春天。
建立既可在线交易又可数据分析的混合数据库，是国产数据库紧跟潮流、引领时代的重要一步。
作者|雷涛
出品| 《新程序员》
直到21世纪初，我国数据库产业发展还很缓慢，基本处于西方数据库博览会的状态，能买到的国产数据库产品很少。
1989年，甲骨文决定进入中国，恰逢中国电信建设“九七工程”的风口浪尖，顺利获得东北三省邮电管理局的大订单后，甲骨文在中国市场站稳脚跟。
此后，Sybase于1991年进入大陆，IBM随后也带着Db2、Informix等数据库产品进入中国。
在接下来的十几年里，我国数据库市场格局逐渐形成，金融业以Db2、Sybase为主，电信、电力行业Oracle基本一统江湖。
然而，风云起，时代变迁，一切局势都在默契中开始扭曲。
例如，在10年前愉快的农场偷菜的场景中，由于C端的顾客急剧增加，中国的IT员工在以往的西方的IOE(IBM小型飞机、Orcale数据库、EMC存储)技术架构中会同时执行这样大量的操作
在这样的大背景下，核心技术的自主管理成为业界共识，建立自己的数据库成为中国程序员们的梦想。
雷涛对HTAP数据库的深度解读
近十年来，我国在数据库领域真正实现了厚积薄发。
从单节点到分布式、单一用途的TP、从AP库到混合HTAP、独立的数据仓库、从数据湖到湖仓一体、SQL、NoSQL、以及NewSQL……数据库的各个方面都迎来了划时代的进展
以下，本文对HTAP数据库进行深入解读。
Google File System、Google BigTable、Google MapReduce——三驾马车是当今大数据平台Hadoop技术的基础，不仅支撑着新一代的分布式架构体系，而且海量数据的高效
2012年，谷歌发表了3354 spanner:Google’sglobally-distributed database的论文，提取了同时支持大数据量交易的数据库，在TP操作的基础上
在谷歌提出Spanner架构的基础上，2014年，Gartner正式定义了HTAP，这是混合数据库诞生的开始。
目前，数据库基本上可分为两大流派，一个是无关型( NoSQL )数据库，一般使用KV技术，主要用于用户图像、业务报告等海量数据挖掘的AP场景。
另一种是关系数据库( SQL )，它添加、删除、修改和调查单个记录速度快，一般用于在线交易的TP场景。
也就是说，TP库的处理速度快，AP库的处理数据量高。
此前，作为AP和TP应用场景的井水并不侵犯河水，彼此交流甚少，但随着数字化的发展，直播自带商品的新场景层出不穷。 直播需要处理在线交易，为客户提供实时图像，但传统的单一TP或AP数据库很难应对这种混合场景。
近年来，一些国产混合负荷数据库采用矩阵混合的方式，打破了AP和TP两种场景之间的鸿沟。
数据不可思议的旅行
梳理数据存储模型的演进历史，不难发现这是一个随着数据量水平的不断扩大，数据模型不断变化的过程。
目前我们提到的数据库一般是指关系数据库，从关系的角度来看，数据库被定义为工厂的工厂，数据是原材料。
工厂为了进行原材料的加工，配置了大量的操作设备，原材料也随时被重建修正。 从建模原理可以看出TP数据库的数据加工厂适合快速零件加工，但不适合大量材料的储存。
另一方面，关系TP数据库在海量数据存储方面的短板直接催生了Hadoop等大数据技术的革命。
从大数据的角度看，AP数据库本身就是仓库，数据是已经加工完毕的成品，没有重构、修改等更新需求。
例如，Hadoop技术堆栈中HDFS存储的实现是所有的数据只写入一次，不能修改。 这实际上是一种牺牲写入和更新数据特性以换取海量数据存储和查询性能的方法。
随着大数据APP应用的进一步扩大，业界知道还需要存储和挖掘价值密度较低的非结构化数据。
例如，客服的对话方式可能是语音、文字，甚至是图像、视频。 这不是传统意义上的数据库、数据仓库可以处理的结构化数据。 因此，出现了用于存储非结构化数据的湖泊，数据湖泊中数据的标准化、结构化特性也退化了。
从关系数据库到数据湖，各种大数据技术堆栈是相互独立的，但随着移动互联网时代的到来，这种情况已经改变。
在线性能和实时分析真的是“鱼和熊掌不可兼得”吗？
权威咨询公司IDC对大数据的定义是，满足种类多( Variety )、流量大(容量大)、价值高(价值高)等指标的数据称为大数据。
从历史上看，谷歌提交大数据三驾马车的论文时，当时的关系型数据库技术很难处理大数据。
在当前各行各业不断迈向云的大背景下，数据量级必然会创新高。
据我所知，整个IT行业存储的数据量级别正以每年80%左右的速度增长，传统的SQL数据库很难处理这些数据量。
许多用户在实际工作中也会将大型表相关的查询任务放在传统的TP数据库中进行。 虽然此类查询效率不高，但考虑到从TP数据库导入AP数据仓库所需的超长时间，直接在TP数据库上执行查询是可以理解的。
其实，这个例子深刻说明了当前大数据技术堆栈面临的困境，各TP和AP数据库就像数据孤岛，要打破孤岛之间的边界比登天还难。
如上所述，作为SQL和NoSQL这两个产品基础的构建模型不同，相互之间的互换性不好。
为了确保在线交易处理的时效，必须牺牲数据分析的性能，而实时数据分析不能依赖传统的技术堆栈来快速完成用户图像。
处理时间和实时用户图像之间的平衡可能是数据库工程师和产品经理之间永远无法达成的协议。
目前，大多数商业银行都使用以Oracle为代表的TP数据库作为核心系统，但Oracle只能处理流程交易数据，无法进行数据挖掘。
要二次表达数据的价值，需要每天做ETL，批处理工作，并存储在数据仓库中。
然后在数据仓库中进行建模、挖掘、数据集市、ODS，逐个构建数据仓库报告。
如果仍然不能回答更详细、隐含的问题，例如非线性的问题，可以将数据复制到SAS进行机器学习，建立统计指标体系，进一步深入。
数据必须在这里移动三次，复制三个冗馀并管理数据的完整性，每天在数据中心运送的大量工作都在进行数据迁移。
在这种低效的运输转移过程中，数据的许多价值都被白白消耗掉了。 此外，如上所述，TP和AP两个系统的组件不兼容，联合这两个系统已很难实现，考虑到灾难恢复的高可用性需求，这一点变得更加困难。
混合矩阵-负载的正确打开方式
如今，所有行业的数据中心都需要堆栈解决方案，通过阻止大数据技术的底层组件之间的差异来寻找“All Data In One”解决方案。 只有这样才能减少插件。
TP和AP之间的主要区别在于原始存储和列在不同使用场景下的性能。
在计算机世界里，数据吞吐速度往往受数据访问局部原理的支配。
现代硬盘、存储器的结构是，当用户读取某个区域的数据时，其相邻的数据也被取入上位的高速缓存，读取1KB的数据和连续读取64MB的数据的代价大致相同，用户可以通过连续的磁盘或笔记
因此，原始存储经常用于SQL的TP场景，而列存储基本上用于NoSQL的AP场景。
这背后的原因也很简单，还是以银行业为例，在网络交易的TP场景中，比如客户取钱时，会检查用户、账号、密码、余额等信息。 所有这些信息都以“行”为单位进行存储，在线交易中的数据总是以“行”为单位进行访问，将数据放在一行中具有访问速度的优点。
但对于汇总、分析销售报表、数据挖掘等AP场景，只需关注少量维度信息，如交易额、账户余额等，不需要用户、账号、密码等数据。 在这样的场景中，将相同维度的信息集中在一起的列存储计划将带来巨大的速度优势。
行、列混合，综合两者优势的尝试在业界也进行了很多，但往往没有成功，最大的问题还是性能。
在在线TP事务方案中，列存储器的写入性能太低。
因此，一般来说，传统方案还是退化为线性存储TP数据库，在交易量较少的日终结算时点，将数据提取到列型存储AP数据库进行数据挖掘。
如图1所示，商务场景主要分为在线交易OLTP和数据分析OLAP两种。
HTAP数据库不仅支持使用SQL计算传统关系模型，还可以将图计算和AI建模纳入逻辑规划中，以实现高阶计算。
在数据存储层次中，通过以矩阵混合方式按需支持OLAP和OLTP场景，存储体系结构可以支持所有场景。
图1 HTAP数据库体系结构图
该逻辑规划和存储器的融合，也称为“All Data In One”，是对数据库基础的重新定义。
在资源调度层，采用AI-Native方式探查所需的调度引擎，在实际计算时进行资源隔离。
该架构能更好地支持数据计算，最终实现一个数据库综合所有场景的终极目标。
相信未来国产HTAP数据库将继续走“All Data In One”之路，发展特色不断创新，降低系统运维成本，发挥数据最大价值。
本文出自《新程序员002：新数据库时代软件定义汽车》，由60多位专家倾力创作。
本书附带《2021数据库全景图V1.0》和《2021汽车技术与产业生态全景图V1.0》，包括《2021年度数据库发展研究报告》和《2021年度软件定义汽车研究报告》，以及文字和视频多媒体演示。
数据库作为核心技术的三大项之一，我们从新型数据库的普及、数据库开源趋势、数字化转型的实现以及资本辅助产业等角度，邀请了27位数据库行业的专家，对无关型数据库、文档型数据共享混合数据库、时序数据库、图数据库等理论技术和行业实践，快速提升了数据库开发人员。
《新数据库时代》目录
智能驾驶作为人工智能的制高点，我们以技术和商业融合创新为主线，邀请23位汽车领域专家，从开源系统、道路合作、数字孪生等不同视角探讨云计算、人工智能、物联网等技术在汽车行业
《软件定义汽车》目录
本书对高屋建瓴的产业分析和趋势预判适用于中高级员工的参考决策。
同时，众多专家体验过的入门和实践之旅也为初学者提供了可借鉴的专业途径。