20222022 年中国数据库行业年中国数据库行业年度分析报告年度分析报告墨天轮数据社区2023 年 01 月目目录录前 言.-1-一、中国数据库发展现状.-2-1.中国数据库流行度.-2-2.数据库学术论文概况.-4-3.数据库开源现状.-5-4.国产数据库产业融资概述.-9-5.国产数据库上市厂商财务分析.-16-6.国产数据库项目签约及中标一览.-18-7.数据库国产化替代背景及相关政策.-27-8.国产数据库市场份额.-30-9.国内数据库存量和增量市场平衡.-33-二、数据库关键技术概览.-38-1.NewSQL.-38-2.分布式.-42-3.HTAP.-45-4.Serverless.-58-5.湖仓一体.-61-6.内存数据库.-62-7.超融合与流式数据处理.-64-8.云原生数据库“四化”.-69-9.多模数据库.-74-10.时序数据库.-76-11.实时数据库.-77-12.图数据库.-85-13.搜索引擎.-97-14.数据库安全.-99-15.数据库中间件.-102-16.数据库兼容性.-105-三、中国数据库标准现状.-108-1.国内数据库行业发展简述.-108-2.数据库标准概况.-109-3.国外数据库标准发展及现状.-109-4.国内数据库标准发展及现状.-110-5.国内数据库标准发展方向及建议.-112-四、数据库服务及智能运维.-113-1.数据库服务.-113-2.数据库智能运维.-115-五、中国数据库产业问题与思考.-118-1.问题与挑战.-118-2.应对策略.-120-总 结.-122-附件附件表格表格表 1：2022 年排行榜年度 TOP 10 趋势详情.-4-表 2：2022 年国产数据库开源情况统计表.-7-表 3：2022 年国产数据库融资一览表.-11-表 4：2022 年国产数据库相关厂商估值表.-18-表 5：2022 年国产数据库项目中标一览表.-23-表 6：第六届大数据“星河”案例数据库优秀、标杆案例.-26-表 7：2022 年国产数据库相关政策.-30-表 8：HTAP 数据库的关键能力对比.-52-表 9：2022 年中国重大数据安全事件一览表.-101-编委会成员编委会成员：韩锋、韩富晟、黄东旭、盖国强、李飞飞、李浩、李昆、李文杰、李轶楠、李战怀、明玉琢、潘巍、徐戟、于巍、姚羽、郑贵德、张桦、邹磊、周研、章芋文指导指导单位单位：阿里云、北京大学、创邻科技、DBAIOPS 社区、庚顿数据、基石数据、科蓝软件、OceanBase、PingCAP、SphereEx、石原子科技、途普科技、虚谷伟业、星环科技、云和恩墨、亚信科技、云尧科技（以上人物姓名和公司名称按首字母排序，排名不分先后）版权版权声明声明本报告著作权归墨天轮、各合作单位和个人共同享有，未经书面许可，任何机构或个人不得以任何形式翻版、复刻、发表或引用。若征得墨天轮、各合作单位和个人同意进行引用、转载的，需在允许的范围内使用，并注明出处为“墨天轮”，且不得对本报告进行任何有悖原意的引用、删节或修改。本报告所涉及的观点或信息仅供参考，不构成任何投资建议。本报告仅在相关法律许可的情况下发放，并仅为提供信息而发放，概不构成任何广告。在法律许可的情況下，墨天轮可能会为报告中提及的企业提供或争取提供投融资或咨询等相关服务。本报告所指的公司或投资标的的价值、价格及投资收入可升可跌。本报告中发布的调研数据采用样本调研方法，其数据结果受到样本的影响。由于调研方法及样本的限制，调查资料收集范围的限制，该数据仅代表调研时间和人群的基本状况，仅服务于当前的调研目的，为市场和客户提供基本参考。受研究方法和数据获取资源的限制，本报告只提供给用户作为市场参考资料，本公司对该报告的数据和观点不承担法律责任。本报告的部分信息来源于公开资料，墨天轮、各合作单位和个人对该等信息的准确性、完整性或可靠性不做任何保证。本文所载的资料、意见及推测仅反映墨天轮于发布本报告当日的判断，过往报告中的描述不应作为日后的表现依据。在不同时期，墨天轮、各合作单位和个人可发出与本文所载资料、意见及推测不一致的报告和文章。墨天轮、各合作单位和个人不保证本报告所含信息保持在最新状态。同时，墨天轮、各合作单位和个人对本报告所含信息可在不发出通知的情形下做出修改，读者应当自行关注相应的更新或修改。-1-前前 言言随着互联网、大数据、人工智能等新一代信息技术的创新聚变，数字化产业正在成为全球经济新的驱动引擎，以数据为核心生产要素的增长变革，成为面向网络化、智能化方向提质增效及重塑核心竞争力的基础。随着数字化转型深入推进和数据量的爆炸式增长，产业对数据库的需求发生了革命性变化。技术发展让数据创造无处不在，从企业应用到个人应用和万物互联，来自新时代的数据库挑战持续增长：数据存储从 TB 级别、PB 级别增至 EB 级别；海量并发从企业内部数百至数千并发到互联网模式下百万级至亿万级并发；新的应用场景要求数据库具备弹性伸缩能力；各行业在加速信息化基础设施的分布式建设；此外端边云协同、AI 融合、软硬结合、数据安全、隐私保护等都是重要挑战。当前数据库技术得到创新发展并发生着颠覆性变革，从结构化数据到非结构化数据，从关系型到非关系型，从集中式到分布式，从闭源到开源,“One size fits all”的时代已经过去。全球知名咨询公司 Gartner 2021 年企业软件全球市场报告显示，数据技术已成为企业软件中最大且增速最快的赛道，未来 5 年复合增长率将达到 17.5%；2022 年 5 月发布的市场报告显示，2021 年全球 DBMS（Database Management System，数据库管理系统）市场规模达到 800亿美元，同比增长 22.3%。在快速发展中，数据库领域的技术和市场也发生着巨大变革。中国的数据库市场是全球市场的重要组成部分，从技术到商业，中国数据库产业正在发生快速而深远的变化，为了记录时代变革、洞察技术趋势、传递产品价值，我们组织编写了本报告，希望能够为数据库产业的产学研用提供参考，为行业发展作出贡献。-2-一、一、中国中国数据库数据库发展发展现状现状伴随中国数据库领域的快速技术进步，国内数据库生态蓬勃发展，并不断涌现出极具创新力的产品，推动了数据库应用的遍地开花。墨天轮社区正是在这样的背景之下创立成长，以平台化持续汇聚产业界力量，反映和呈现中国数据库发展状态，为推动行业进步而持续贡献。1.1.中国数据库中国数据库流行度流行度1.1.1 1 榜单榜单收录持续增加，数据库收录持续增加，数据库产业产业蓬勃发展蓬勃发展墨天轮中国数据库流行度排行榜于 2019 年 6 月推出，2022 年全年新增收录 55 款数据库，每月排行榜收录数持续增加，截至 2022 年 12 月共收录 249 款产品。图 1：2022 年中国数据库流行度排行榜收录数据库数量截至 12 月，中国数据库排行榜关系型数据库依旧是主流。在 163 个关系型数据库中，OLTP数据库 109 个，占比 66.9%。HTAP 和 OLAP 分别有 27 个和 25 个。分布式数据库多出集中式数据库 6 个，达到 123 个，目前分布式技术已成为多数国产数据库的标配，让企业应用能在容量和负载上都能轻松横向扩展，满足了当今时代和市场的需求，也是替换 Oracle 等传统集中式数据库的重要突破口。云原生数据库 34 个，云数据库成为新的竞争力焦点，阿里云、华为云、腾讯云的市场份额有显著增长。中国数据库排行榜各模型、属性数据如下图所示。-3-图 2：2022 中国数据库流行度排行榜各模型、属性数据1.1.2 2 排行榜年度排行榜年度 TOPTOP 1010 趋势趋势2022 年排行榜前三有 TiDB、OceanBase、openGauss 以及达梦的身影交替出现。相比于 2021 年 TiDB 连续占据榜首 12 个月的情况，2022 年排行榜榜首多了一些悬念。排行榜年度TOP10 是：TiDB、OceanBase、openGauss、达梦、GaussDB、PolarDB、人大金仓、GBase、TDSQL、AnalyticDB，排行榜前十竞争激烈，常有名次变动。2022 年排行榜年度 TOP 10 流行度趋势详情见下表。排名排名数据库名称数据库名称主要趋势主要趋势1TiDBTiDB 2022 年可谓是在面对强势进攻中坚守阵地，全年共累计 10 次位居榜首。TiDB 与上/下一名的最小分差仅为 2.13 分，但是全年流行度趋势比较平稳。2OceanBaseOceanBase 12 月得分相比 1 月得分，分数上涨 132.6 分，涨幅达到了 27.3%。其以榜首位置收官 2022 年排行榜，给 2023 年全年的流行度趋势带来了悬念。3openGaussopenGauss 在 2022 年 5 月登顶榜首一次。全年来看，12 月得分和排名与 1 月相比，以 0.8 分的分数劣势，排名下降一位至第三，其全年的趋势相对平稳。4达梦全年的流行度排行波动较大，12 月的得分相比今年 1 月得分下降 41.4 分。7 月得分上涨了 54.7 分，系与 6 月正式递交招股书，申请上交所科创板上市引发关注相关。5GaussDB整个流行度趋势是稳步上行的，其 12 月得分相比于今年 1 月得分，分数涨幅达到了14.9%。GaussDB 在市场拓展、技术上都有了突破性进展。6PolarDB2022 年 1 月的流行度得分是近两年的最低点，由此起步，全年的流行度是稳中有升。在-4-2022 年 10 月，排名和得分都有所突破，以 436.3 分位列第五。7人大金仓2022 年 6 月、7 月获得了全年最靠前的排名，位列第六。其全年的发展趋势是先升后降。1-10 月，人大金仓流行度直线上升，并在 10 月以 431.37 分达到顶点。8GBase全年的流行度趋势是“先升后降”，在今年 5 月以 384.9 分达到得分最高值后，逐渐下降。其 12 月得分相比于 1 月得分，微增 9.21 分，全年排名基本在第 7-8 名徘徊。9TDSQL其作为腾讯云旗下的数据库品牌，一直在金融领域稳扎稳打。TDSQL 全年的流行度趋势是波动性下降，以全年最高分为起点，12 月得分较 1 月得分下降幅度达到了 19.5%。10AnalyticDB全年得分稳中有升，全年一直保持着第十名的排名优势。其 12 月得分较今年 1 月上涨28.34 分，在数仓建设上稳步推进。表 1：2022 年排行榜年度 TOP 10 趋势详情2.2.数据库学术论文概况数据库学术论文概况中国数据库自主创新能力显著增强。目前中国数据库论文数占全球总数 12%，并呈现发文数逐年递增的趋势。以下数据基于 Web of Science 核心合集，检索主题为 Database 的检索机构，检索日期为 2022 年 12 月。图 1：中国数据库论文数盘点国产数据库创新成果有所突破。数据库论文能够展现数据库行业最新研究成果，发文数量能够一定程度上体现各发文单位在数据库学术领域、技术钻研上的成就。2022 年 7 月 SIGMOD2022会议中共有 151 篇国内外论文入选。SIGMOD2022 收录的国内论文，发文单位主要来源于高等学府清华大学、香港中文大学、香港科技大学，此外国产数据库厂商（阿里巴巴、腾讯、华为等）也入选了。这体现了国产数据库的自研成果达到了世界先进水平，得到了业界的广泛认可。-5-图 2：中国在 SIGMOD2022 的论文盘点2022 年 9 月 VLDB 召开，VLDB2022 会议中共有 336 篇国内外论文入选，其中中国贡献115 篇，占比超过 1/3。图 3：中国在 VLDB2022 的论文盘点3.3.数据库开源数据库开源现状现状中国数据库逐渐实现开源是大势所趋也是谋求长期发展的重要路径，2022 年 TiDB、PolarDB、GaussDB 等也相继推出了开源版本。对于厂商而言，开源能吸引更多的用户来拓展自己的生态，是一条行之有效的路径。截止到 2022 年 12 月底，已有 48 款国产数据库产品开源，具体的国产数据库开源情况如下表所示。序号序号名称名称贡献者贡献者开源地址开源地址StarStar 数量数量 开源时间开源时间1TiDBPingCAP 年2TDengine涛思数据 年-6-3Milvus赜睿科技（Zilliz）年4TiKVPingCAP 年5NebulaGraph悦数科技 年6Apache Doris百度 年7OceanBaseOceanB 年8Databend数变科技 年9Pika奇虎 年10AliSQL阿里巴巴 年11StarRocks鼎石科技 年12Kylin易趣 年13IoTDB清华大学 年14PolarDB阿里云 年15Tendis腾讯 年16LinDB饿了么 年17HugeGraph百度 年18Greptime DB格睿云 年19Kvrocks美图 年20TerarkDB字节跳动 年21RadonDB青云 年22MatrixOne矩阵起源 年23CovenantSQL子午星辰(CovenantLabs)年24TDSQL腾讯云 年25TensorBase致大尽微 年-7-26OpenMLDB第四范式 年27CnosDB诺司时空 年28FlashDB阿明克 年29openGauss华为 年30BaikalDB百度 年31云树Shard爱可生 年32Apache HAWQ偶数科技 年33StoneDB石原子科技 年34gStore北京大学 年35IvorySQL瀚高 年36SequoiaDB巨杉科技 年37openGemini华为 年38TenDB Cluster腾讯 年39DingoDB九章云极 年40Claims华东师范大学 年41PinusDB巨松软件 年42开务数据库浪潮云溪 年43GreatSQL万里数据库 年44Palo百度 年45Yukon超图软件 年46He3DB移动云 年47OushuDB偶数科技 年48红象数据库RedElephant2020 团队 年表 2：2022 年国产数据库开源情况统计表-8-2022 年国产数据库行业陆续有 PingCAP、阿里云、华为云、蚂蚁集团、格睿云共五家厂商推出开源的产品，具体的开源产品详情如下：4 月 1 日，TiDB 分析引擎 TiFlash 正式开源，它是为 TiDB 提供 HTAP 能力的重要组成部分。图 4：TiDB 分析引擎 TiFlash 正式开源4月1日，阿里云PolarDB-X正式开源X-Paxos，基于原生MySQL存储节点，提供Paxos三副本共识协议，可以做到金融级数据库的高可用和容灾能力，做到 RPO=0 的生产级别可用性，可以满足同城三机房、两地三中心等容灾架构。6 月 15 日，华为云将 GaussDB 时序时空数据库内核开源，并命名为 openGemini。图 5：openGemini 数据库全景图7 月 23 日消息，蚂蚁集团时序数据库 CeresDB 正式开源，并发布开源版本 CeresDB0.2.0。11 月 15 日，格睿云 Greptime宣布旗下时序数据库 GreptimeDB 正式开源。开源后，GreptimeDB 连续三天在 GitHub Trending 榜上排名第一。-9-图 6：2023 GreptimeDB 路线图4.4.国产数据库国产数据库产业产业融资概述融资概述从融资环境上看，数据库产业受资本关注度较高，整体投融资环境向好从融资环境上看，数据库产业受资本关注度较高，整体投融资环境向好。2022 年至今已有17 家国产数据库厂商和数据库生态企业获得融资，其中 2014 年后成立的新兴企业有 12 家，占比 70.6%；单笔获得过亿元人民币融资的有 11 家，占比 64.7%。相比于 2021 全年融资次数，数据库企业融资次数增长 21.4%。根据披露金额，2022 年融资额度总计约为 80.92 亿元人民币，其中不乏高瓴创投、经纬中国、红杉资本等知名投资方。2022 年国产数据库厂商融资详情见下表。融资时间融资时间公司名称公司名称轮次轮次金额金额成立时间成立时间投资方投资方数据库名称数据库名称2022/3/22天云数据D 轮数亿元人民币2013/5/9融溢资本、绿地创极、京国创创辉投资Hubble2022/4/28飞轮科技天使轮超 3 亿人民币2021/12/23IDG 资本、红杉中国SelectDB2022/5/13渊亭科技B 轮亿级人民币2014/1/28达晨财智DataExa-Seraph2022/6/23拓数派战略融资数亿元2021/2/2元禾重元、东吴证券DB-10-2022/6/29天谋科技天使轮近亿人民币2021/10/20红杉中国、考拉基金、戈壁创投、云智慧时序数据库2022/6/30新数科技A 轮数千万元2014/6/13复星锐正资本、博彦科技ShinDB2022/8/18云尧科技（浙江）种子轮1000 万人民币2021/6/16未披露YaoBase2022/8/25赜睿科技（Zilliz）B 轮6000 万美元2017/5/9Prosperity7Ventures、PavilionCapital、高瓴创投、五源资本、云启资本Milvus2022/9/15杭州悦数科技A 轮数千万美元2018/8/16时代资本、经纬创投、红点中国、源码资本、华兴资本图数据库NebulaGraph2022/9/27格睿云Greptime天使轮数百万美元2022/4/7耀途资本、九合创投时序数据库Greptime DB2022/10/11瀚高软件战略融资数亿人民币2005/7/5浪潮集团HighGo DB2022/10/18成章数据天使轮数千万元2021/9/27线性资本MonoGraphDB2022/10/18星环科技IPO 上市14.3 亿人民币2013/6/5公开发行ArgoDB、KunDB-11-2022/10/24南大通用D 轮数亿元人民币2004/5/11君联资本、耀途资本、国投创合、宇信科技、信一创科技、宇新大数据基金、苏州国发创投、相城金控GBASE2022/11/7航天软件IPO 过会5.51 亿元2000/12/12公开发行神通数据库2022/12/22达梦数据IPO 过会23.51 亿元2000/11/13公开发行达梦数据库2022/12/23柏睿数据D 轮过亿人民币2014/8/14海创天成、合肥产投集团、上海国际资管、北科建、朝科创RapidsDB表 3：2022 年国产数据库融资一览表图 1：2022 年融资国产数据库厂商-12-20222022 年国产数据库年国产数据库融资事件融资事件3 月 22 日，Hubble 数据库厂商天云数据获得数亿元天云数据获得数亿元 D D 轮融资轮融资。本轮由多家国家队基金共同投资，包括：北京市国资部门旗下创新投资平台北创投管理、科技部和北京市科创基金共同支持的北京市首支央地联动科技成果转化子基金远京基金、上海市国资委旗下绿地创极管理的苏州吴江太湖新城母基金。2021 年，天云数据还曾获得上海国资旗下国鑫创投的投资。4 月 28 日，云原生实时数仓厂商飞轮科技完成超飞轮科技完成超 3 3 亿元天使轮和天使亿元天使轮和天使 轮融资轮融资，将研发基于 Doris 内核的云原生发行版 SelectDB。SelectDB 是运行在云上的实时数据仓库，为用户和客户提供开箱即用的能力。5 月 13 日，DataExa-Seraph 图数据库厂商渊亭科技完成了亿元人民币渊亭科技完成了亿元人民币 B B 轮融资轮融资。本轮融资由达晨财智独家投资，资金将主要用于核心 AI 产品升级、高端人才引进，以及在国防、政企、工业、金融等业务方向的市场扩展。6 月 23 日，国内云原生数据库公司拓数派（拓数派（OpenPieOpenPie）完成数亿元）完成数亿元 A A 轮战略融资轮战略融资。本轮融资由元禾重元领投，东吴证券跟投。据悉，此前拓数派已获得头部产业基金连续两笔天使轮投资，估值在成立时即达到准独角兽级别。、-13-6 月 29 日，工业物联网时序数据库厂商天谋科技天谋科技（TimechoTimecho）完成近亿元人民币天完成近亿元人民币天使轮融资使轮融资，本轮融资由红杉中国领投，考拉基金、戈壁创投、云智慧共同跟投。本轮资金将主要用于开源产品研发、开源社区建设，以及核心技术团队打造与扩充等。6 月 30 日，一体化数据库云管理平台软件厂商北京新数科技有限公司完成北京新数科技有限公司完成 A A 轮数轮数千万元融资千万元融资。新数科技于 2018 年在业界率先推出数据库管理平台理念，致力建设一体化的数据库云管理平台软件生态。新数科技 ShinDB 分布式数据库突破了传统单节点数据库在高负载和大数据量场景下的瓶颈，实现了高并发、高吞吐量、自动容灾、备份恢复、动态扩展、应用透明等特性，还提供统一的 DDL、DML 执行、自动运维、监测告警、性能分析等一站式数据库管理平台。8 月 18 日，YAOBASEYAOBASE 厂商厂商云尧科技云尧科技完成千万元种子轮融资完成千万元种子轮融资。据悉，浙江云尧科技成立于 2021 年 6 月，是一家数据库软件企业，核心技术团队从 80 年代初就从事数据存储与管理领域的科研工作，目前已自主研发出 YaoBase（尧）原生 NewSQL 分布式关系型数据库软件，兼容 Oracle/DB2/MySQL 等特性。8 月 25 日，向量数据库公司向量数据库公司 ZillizZilliz（上海赜睿信息科技上海赜睿信息科技）宣布完成宣布完成 60006000 万美元万美元的的B B 轮融资轮融资，成功将其 B 轮融资规模进一步扩大至 1.03 亿美元。该笔融资将用于进一步完善研发团队和市场团队建设，加速全托管云服务产品 Zilliz Cloud 的研发及商业化，以及持续推进全球市场的布局。-14-9 月 15 日，开源图数据库开源图数据库 NebulaGraphNebulaGraph 研发商研发商杭州悦数科技有限公司杭州悦数科技有限公司获得数千万获得数千万美元的美元的 A A 轮融资轮融资。本轮融资将被用来继续投入到分布式图数据库 NebulaGraph 的产品研发项目中，为更多企业打造更稳定高效的数据存储及图计算技术底座。9 月 27 日，时序数据库厂商 格睿云格睿云（GreptimeGreptime）宣布完成数百万美元天使轮融资宣布完成数百万美元天使轮融资，本轮由耀途资本领投，九合创投跟投。格睿云公司当前正在打磨时序数据库 Greptime DB，未来也计划推出基于 Greptime DB 的全托管数据库服务 Greptime Cloud。10 月 11 日，瀚高基础软件股份有限公司获得浪潮集团数亿元战略投资，浪潮集团瀚高基础软件股份有限公司获得浪潮集团数亿元战略投资，浪潮集团成为瀚高股份第一大股东成为瀚高股份第一大股东，瀚高亦正式成为一家国有数据库软件企业。浪潮战略投资瀚高，进一步完善了浪潮的生态体系，强化产业实力，助力自身产品综合解决方案构建。10 月 18 日，数据库初创企业成章数据（成章数据（MonoGraphDBMonoGraphDB）宣布完成数千万元天使）宣布完成数千万元天使轮融资轮融资，投资方为线性资本。本轮融资将用于产品开发和团队组建。成章数据基于数据基底 DataSubstrate 这一技术，打造一款具备模块化、云原生、高性能、多模态和可插拔多种计算和存储引擎的新一代关系型 OLTP 数据库。10 月 18 日，星环信息科技(上海)股份有限公司在科创板挂牌上市，成为“国产大数据基础软件第一股”，市值约为 88.12 亿元。星环科技此次发行价为 47.34 元，发行 3021.06万股，IPO 募资总额为 14.3 亿元，募资主要会用在加大技术研发投入和加大市场推广方面。-15-10 月 24 日，GBASE 南大通用宣布完成数亿元 D 轮融资。本轮融资由君联资本领投，国投创合、狮城资本联合宇信科技集团、耀途资本、信一创科技、苏国发、相城金控联合投资。通过本轮融资，GBASE 南大通用将加速产品的升级研发计划、加大市场拓展力度,作为国产数据库行业领军企业，在助力国产信息化建设的国家战略中继续发挥积极作用。11 月 7 日，神舟通用母公司航天软件科创板航天软件科创板 IPOIPO 过会过会。神舟软件本次发行股票后，拟投资 5.51 亿元用于以下五个方面：产品研制协同软件研发升级建设项目（1.8 亿元）、神通数据库系列产品研发升级建设项目（1.52 亿元）、航天产品多学科协同设计仿真(CAE)平台研发项目（0.41 亿元）、ASP 平台研发项目（1.11 亿元）、综合服务能力建设项目（0.67 亿元）。12 月 22 日，达梦数据达梦数据科创板科创板 IPOIPO 过会过会。此次 IPO，达梦数据计划募资 23.51 亿元，此次募集的资金将用于达梦集群数据库管理系统、高性能分布式关系数据库管理系统、新一代云数据库产品的优化升级，以及达梦中国数据库产业基地和达梦研究院建设等项目。12 月 23 日，柏睿数据完成过亿人民币柏睿数据完成过亿人民币 D D 轮融资轮融资。本轮融资由科技部、北京市、上海市、合肥市联合引导基金（海创天成、合肥产投集团、上海国际资管、北科建、朝科创）投入。据悉，未来的数月内，柏睿数据还会陆续完成相当规模的战略融资。-16-5.5.国产数据库上市厂商财务分析国产数据库上市厂商财务分析由于缺乏直接的国产数据库上市厂商信息，墨天轮整理了18家国产数据库相关上市厂商数据。截止 2022 年 12 月 29 日，获取到 16 家厂商的每股月度价格波动信息。5.15.1 自研数据库在国产数据库行业具有较强优势自研数据库在国产数据库行业具有较强优势近年来，国产自研数据库不断发展和突破，自研的国产数据库在中国数据库行业具有极大的优势，发展迅猛，主要的自研数据库代表产品有达梦。达梦数据联营企业中国软件每股营收最高，达到了 47.23 元。今年 6 月后，每股价格增长提速，与达梦递交招股书紧密相关。据中国软件 2022年第二季度财务报告，其自主软件产品收入同比增长 78.18%，旗下达梦业绩表现良好。在信创市场份额领先，为公司贡献投资收益 1.12 亿元。达梦 2022 年 1-6 月的营业收入和净利润也呈现着正增长趋势。图 1：国产数据库相关上市公司股价走势图5 5.2.2 营运投入增加，净利率亏损扩大营运投入增加，净利率亏损扩大根据 2022 年二、三季度各厂商公布的财务数据，八家厂商的亏损都有所扩大。根据 2022年 9 月 30 日各厂商公布的数据，2022 年三季度净利润负增长的厂商占比 42.1%，18 家厂商的亏损总资金达到了 32.54 亿。以下上市公司中，大多处于发展阶段，疫情、各项投入加大是导致亏损的主要原因。-17-5 5.3.3 收入规模效应逐渐显现收入规模效应逐渐显现在 18 家国产数据库相关上市厂商中，中兴通讯营业收入最高，2022 年三季度营业收入达到了 925.6 亿，相比于二季度涨幅达到 54.7%。其次，浪潮集团实现了 2022 年三季度营业收入达316.3 亿。各厂商相继研在研发产品、人才引进等方面加大投入，收入规模效应逐渐显现。2022年 18 家国产数据库相关厂商估值情况见下表。数据库厂商数据库厂商代表产品代表产品市值市值营业收入营业收入净利润净利润2022/92022/9/30/302022/62022/6/30/302022/32022/3/31/3120212021A A2022/92022/9/30/302022/6/2022/6/30302022/32022/3/31/3120212021A A星环科技ArgoDB、KunDB、StellarDB110 亿 1.71 亿9758 万/3.31亿-2.36亿-1.65 亿/-2.45亿亚信科技AntDB128.6亿/31.09亿/68.95 亿/1.92 亿/7.86亿海量数据AtlasDB、Vastbase58.30亿2.00 亿1.33 亿7886 万4.20亿-5875万-3865万-1075万1127万科蓝软件SUNDB60.68亿7.05 亿4.81 亿2.43 亿12.98 亿-1666万-993.3万595.7万3737万中国软件达梦383.6亿55.82亿36.11亿15.24亿103.5 亿-3.91亿-2.85 亿 1.03 亿7558万拓尔思TRS Hybase84.13亿6.37 亿4.25 亿1.90 亿10.29 亿1.04 亿7463 万2100万2.46亿创意信息GreatDB58.75亿10.67亿6.31 亿3.78 亿18.67 亿-3284万279.1万3303万-2173 万超图软件Yukon（禹贡）92.08亿10.05亿4.47 亿2.77 亿18.75 亿6222万-4962万1169万2.88亿恒生电子LightDB772.0亿37.37亿23.86亿9.73 亿54.97 亿1149万-9580万-4130万14.64 亿-18-太极股份KingBase162.9亿70.61亿49.22亿18.59亿105.0 亿1.17 亿3684 万1872万3.73亿东方国信CirroData91.96亿14.25亿8.93 亿4.70 亿24.70 亿1.08 亿5913 万4140万3.02亿天玑科技PBData23.73亿2.6 亿1.49 亿6862 万5.42亿-1962万-1922万-598.9万4007万东软集团OpenBASE122.6亿55.64亿33.83亿12.78亿87.35 亿1.29 亿8303 万-3012万11.73 亿浪潮信息K-DB、开务数据库316.2亿527.7亿348.5亿172.8亿670.5 亿15.46亿9.54 亿3.34 亿20.03 亿优刻得UTSDB56.82亿14.89亿10.46亿5.28 亿29.01 亿-3.5 亿-2.6 亿-1.41亿-6.33亿金山云（港股）DragonBase、KingDB80.29亿60.49亿40.80亿21.74亿90.61 亿-21.49亿-13.56亿-5.532亿-15.89 亿航天软件神通数据库20亿/中兴通讯GoldenDB、EBASE1220亿925.6亿98.2 亿279.3亿1145亿68.20亿45.66亿22.17亿68.13 亿达梦数据DM94.04亿/2.49 亿/7.43亿/0.79 亿/4.38亿表 4：2022 年国产数据库相关厂商估值表6.6.国产数据库项目签约及中标一览国产数据库项目签约及中标一览6 6.1.1 20222022 年国产数据库项目签约及中标情况年国产数据库项目签约及中标情况据信通院预测，中国数据库市场 2020-2025 年复合增长率高达 23.35%，2025 年市场规模有望达 688 亿元。根据各厂商公开发布的消息，据墨天轮不完全统计，2022 年国产数据库行业共收到 51 次中标喜讯（表 6）。其中金额最大是中兴通讯、OceanBase、亚信 AntDB、万里数据库 4 家联合中标移动 1.45888 亿元超级大单。单家中标金额最大的是阿里云，其中标广东移动-19-2022-2023 年主备式自主可控 OLTP 数据库，金额达到了 967.28 万。从采购单位性质分析，46%的采购单位集中在金融领域，其次是政府。图 1：2022 年国产数据库采购单位性质占比图2022 年国产数据库行业中标信息统计如下：公告时间公告时间采购单位采购单位中标数据库中标数据库中标金额（元）中标金额（元）项目名称项目名称1 月 5 日中国银行Hubble（HTAP）TiDB中国银行企业级架构相关项目组件1 月 7 日黑龙江省农村信用社巨杉数据库60 万黑龙江省农村信用社联合社项目1 月 19 日中国石化、中国石油、中国海油金仓数据库中国石化、中国石油、中国海油的数据库国产化采购项目1 月 27 日中国移动福建公司科蓝软件 SUNDB 数据库中国移动福建公司 2020 年企业级大数据四期内存数据库采购项目1 月江西银行科蓝软件 SUNDB 数据库江西银行新建企业网银及企业手机银行建设项目2 月 22 日吉林银行股份有限公司GBase 8a MPPCluste吉林银行股份有限公司 MPP 数据库采购项目-20-2 月贵阳农商银行科蓝软件 SUNDB 数据库贵阳农商银行“安心租”资金监管系统3 月 2 日武汉地铁达梦数据库武汉地铁 7 号线北延线工程自动售检票系统项目3 月 2 日河南移动优炫数据库河南移动业务支撑系统国产数据库采购项目3 月 17 日安徽省联社中兴通讯 GoldenDB安徽省农村信用联合社（简称：安徽省联社）“分布式在线交易查询平台”项目4 月 15 日广东移动阿里云967.28 万广东移动 2022-2023 年主备式自主可控 OLTP 数据库项目4 月 20 日北京市应急管理部优炫数据库/北京市应急管理部消防产品合格评定中心项目4 月五粮液集团财务有限公司科蓝软件 SUNDB 数据库/监管数据标准化报送平台5 月 31 日人力资源社会保障部科蓝软件 SUNDB 数据库人力资源社会保障部金保工程二期SOA 基础软件及工具软件采购项目5 月贵阳银行科蓝软件 SUNDB 数据库贵阳银行信用卡管理系统6 月 17 日中移信息技术有限公司万里数据库/中移信息技术有限公司自主可控OLTP 数据库（分布式）联合创新项目（一期）7 月国防科技大学科蓝软件 SUNDB 数据库/国防科技大学气象海洋学院海洋环境再分析数据库平台项目7 月 15 日福建移动达梦数据库/福建移动 2022 年国产通用型关系数据库软件项目-21-7 月 18 日中车信息技术有限公司Hubble 数据库/中车信息技术有限公司“TiDSMP规则引擎组件采购及集成项目”7 月 19 日南瑞集团南大通用 GBase/南瑞集团 2022 年应用软件、国产操作系统及数据库框架建设项目中的数据库框架部分8 月 2 日北京农商银行科蓝软件 SUNDB 数据库/2022 年信创数据库软件数据库国产化替换8 月 4 日新疆某综合医院亚信科技 AntDB 数据库/新疆某综合医院“医共体”项目9 月 19 日中原银行OceanBase627 万中原银行 2022 年信息技术应用创新-OceanBase数据库软件许可采购项目9 月 22 日四川移动GreatDB188.145 万中国移动四川公司 2021 年业务支撑BOSS扩容改造工程国产分布式数据库项目9 月 27 日泉州银行GBase 8a/9 月 29 日正数网络UXDB/正数网络 2022-2023 年数据库产品及技术支撑服务集中采购项目9 月 29 日中国邮政TDSQL/中国邮政技术中台国产关系型数据库和数据备份软件采购项目9 月 30 日国家自然科学基金委员会达梦数据库48 万/9 月自贡银行GBase 8s/自贡银行基础软件及服务采购项目。9 月成都农商行GBase 8s成都农商行智慧办公与新邮件系统基础软件项目。-22-10 月 8 日天津市市场监督管理委员会南大通用 GBase 8c/天津市市场监督管理委员会分布式交易型数据库集成项目10 月 13 日浦发银行人大金仓/信用卡中心邮件系统数据库项目10 月 13 日山西银行人大金仓/财资系统等集中式数据库业务系统10 月 13 日新疆农村信用社联合社人大金仓/ODS 数据仓库项目10 月 13 日正数网络图数据库 GDMBASE/正数网络数据库产品及技术支撑服务集中采购项目10 月 17 日中国人民银行清算总中心南大通用 GBase 8a/中国人民银行清算总中心 2022 年金融大数据分析与服务平台扩容建设数据库采购项目10 月兵器装备集团财务有限责任公司GBase 8a MPPCluster/兵器装备集团财务有限责任公司大数据平台及应用建设项目10 月深圳地铁 14 号线轨道交通GBase 8s 数据库管理系统/11 月 2 日国家电网有限公司达梦数据库/国家电网有限公司 2022 年第四十五批采购（数字化项目第三次设备招标采购）项目调度类软件-数据库软件11 月 5 日湖北银行启云数据库/湖北银行 2022 年系统设备采购项目数据库类11 月 10 日某市纪律检查委员会亚信科技 AntDB 数据库/某市纪律检查委员会大数据分析查询项目11 月 11 日国家电网省级电力公司RapidsDB/-23-11 月 15 日东营银行科蓝软件 SUNDB 数据库/东营银行网贷平台11 月 21 日龙江银行HotDB84.7（万元）龙江银行 2022 年至 2023 年HotDB 数据库服务采购项目11 月 30 日中国移动河南公司科蓝软件 SUNDB 数据库/中国移动通信集团河南有限公司与北京科蓝软件系统股份有限公司2021-2022 年框架研发采购项目12 月 22 日江汉油田达梦数据库/2022 年江汉油田(中国石油化工股份有限公司江汉油田分公司)非结构化数据管控体系建设项目12 月昆仑银行科蓝软件 SUNDB 数据库/昆仑银行股份有限公司 2022 年分布式数据库一年框架协议采购项目12 月上海上期商务有限公司MogDB/信创数据库及中间件采购项目12 月杭州银行TiDB/杭州银行核心系统数据库项目2022 年国家管网GBase 8s2022 年解放军某部队GBase 8c表 5：2022 年国产数据库项目中标一览表6.26.2 20222022 年大数据年大数据“星河星河”案例一览案例一览由中国信息通信研究院、中国通信标准化协会大数据技术标准推进委员会(CCSA TC601)共同组织的第六届大数据“星河”案例征集于 2022 年 12 月 12 日公示入选结果。本次案例征集包括行业数据应用、数据安全、隐私计算、数据资产管理、数据库五大方向，共收到申报项目 595 份，经过形式审查和专家评审，共有 209 个案例入选，其中数据库方向有标杆案例 10 个、优秀案例22 个。在国产数据库产品广泛应用的同时，用户对于数据库的全栈服务日益关注，包括成熟的运维体-24-系、智能的工具产品等。在 2022 年信通院评选的“大数据星河案例”中，一系列优秀项目体现了数据库的整体性和用户的关注方向，例如哈尔滨银行和云和恩墨联合打造的“一体化数据库服务体系建设”项目，就体现了国产数据库 MogDB 和数据库服务体系的完美重塑。2022 年具体的数据库标杆案例和优秀案例如下表所示。20222022 年数据库标杆案例年数据库标杆案例单位名称单位名称成果名称成果名称中国工商银行股份有限公司华为技术有限公司华为云 GaussDB 助力工商银行核心交易系统分布式改造,助推智慧银行建设中国移动通信集团浙江有限公司金篆信科有限责任公司基于 GoldenDB 的电信行业核心交易系统数据库应用创新中国联通软件研究院阿里云计算有限公司联通 BSS 集约化系统异地双活建设实践中国移动通信集团江苏有限公司北京奥星贝斯科技有限公司上海新炬网络信息技术股份有限公司CRM 系统核心数据库替代项目中国移动通信集团上海有限公司湖南亚信安慧科技有限公司业务支撑系统核心数据库迁移改造项目中国移动通信集团广东有限公司阿里云计算有限公司在离线一体云原生数据仓库技术研究和应用中国移动通信集团山东有限公司亚信科技(中国)有限公司天津南大通用数据技术股份有限公司湖仓一体大数据平台研究和实践威海市商业银行股份有限公司华为技术有限公司“湖仓一体”分布式分析型数据库平台中国移动通信集团河北有限公司云和恩墨(北京)信息技术有限公司数据库替换选型方法及智能分析工具-25-中国移动通信集团江西有限公司浙江创邻科技有限公司创意信息技术股份有限公司基于图数据库的新一代电信网络诈骗预防劝阻和溯源打击系统20222022 年数据库优秀案例年数据库优秀案例单位名称单位名称成果名称成果名称中国移动通信集团山东有限公司北京奥星贝斯科技有限公司核心 IT 系统全流程业务在新型分布式 OLTP 数据库中的应用中国移动通信集团四川有限公司天津南大通用数据技术股份有限公司混搭架构中构建逻辑数仓的应用与实践中国移动通信集团云南有限公司金篆信科有限责任公司云南移动营收稽核系统改造项目创新案例中国移动通信集团内蒙古有限公司北京柏睿数据技术股份有限公司全内存计算数据库“提速赋能内蒙古移动行业智能短信精准分析与高效运营”中国光大银行股份有限公司北京万里开源软件有限公司光大银行分布式数据库在重要业务系统中的应用江苏紫金农村商业银行股份有限公司星环信息科技(上海)股份有限公司紫金农商银行基于 ArgoDB 的湖仓集一体大数据平台中国移动通信集团河南有限公司北京人大金仓信息技术股份有限公司基于轩辕数据总线平台实现异构数据库混合组网的解决方案中国联通软件研究院北京奥星贝斯科技有限公司联通核心业务的分布式数据库创新实践江西金融发展集团股份有限公司星环信息科技(上海)股份有限公司基于分布式数据库的互联网金融业务系统云南公路联网收费管理有限公司湖南亚信安慧科技有限公司云南高速清分结算系统降本增效升级改造中国国际金融股份有限公司云和恩墨(北京)信息技术有限公司中金公司星汉数据库智能运维平台中国光大银行股份有限公司北京新数科技有限公司中国光大银行数据库平台云系统哈尔滨银行股份有限公司云和恩墨(北京)信息技术有限公司一体化数据库运维服务体系建设中国对外经济贸易信托有限公司上海爱可生信息技术股份有限公司多元数据库统一云管平台云树 DMP 在信托行业应用实践-26-深圳华大北斗科技股份有限公司厦门渊亭信息科技有限公司DataExa-Seraph 图数据库赋能企业知识中台应用成都市气象局成都虚谷伟业科技有限公司综合气象信息管理系统升级维沃移动通信有限公司深圳分公司KV 存储在互联网领域的应用实践维沃移动通信有限公司深圳分公司透明数据加解密在互联网领域的应用实践郑州银行股份有限公司智能 SOL 扫描工具四川省大数据技术服务中心北京飞轮数据科技有限公司基于 SelectDB 的超大规模核酸检测数据平台中国电信股份有限公司湖北分公司湖北省信产通信服务有限公司数字科技分公司建设高效稳定的数据调度平台中航信移动科技有限公司北京飞轮数据科技有限公司基于 SelectDB 的航旅纵横用户行为在线分析平台表 6：第六届大数据“星河”案例数据库优秀、标杆案例6 6.3 3 数据库出海成为国产厂商的全新增量逻辑数据库出海成为国产厂商的全新增量逻辑很多数据库创业公司，成立之初就定位国际化，比如分布式开源数据库 PingCAP、开源向量数据库系统 Zilliz、云原生流式数据库 Singularity 等。2022 年有些国产数据库厂商在“出海”方面取得了进展。蚂蚁集团的 OceanBase 先后服务过印度、印尼、菲律宾、巴基斯坦等国家的金融科技公司。8 月 10 日，OceanBase CEO 杨冰在 4.0 产品发布会上也首次公开提到了出海战略，作为OceanBase 的第三增长引擎。2022 年 11 月 22 日，腾讯云数据库 TDSQL“大展身手”助力印尼 BNC 银行完成新核心分布式迁移，告别昂贵的传统商业数据库，实现数字化转型。从 2019 年服务 Shopee 开始，PingCAP 走向了海外市场。目前海外市场的营收已经超过 PingCAP 国内营收，在不同的国家都有头部的客户，比如日本最大的在线支付公司 PayPay，美国的 Square，越南的独角兽 VNG,印度的 Zomato，东南亚最大的电商 Shopee，法国最大的在线视频公司 Dailymotion 等等。-27-7.7.数据库国产化替代数据库国产化替代背景及背景及相关政策相关政策7 7.1.1 国产化替代国产化替代背景背景从中兴、华为等一系列高科技企业被美国制裁，到俄乌冲突事件爆发后，西方各国相继宣布制裁俄罗斯，以 Oracle、IBM、微软、SAP 为代表的科技巨头暂停在俄服务，这一系列动作给我们敲响了加速国产化替代的警钟。数据库作为提供数据存储与处理能力的基础软件，是信息系统的基础，数据库自主可控和国产化替代已经成为现实要求。在国内市场，Oracle、MySQL、IBM DB2 等传统数据库发展较早，广泛应用、占据先机，一旦出现供应链风险，企业没有相应的替代方案，则可能导致企业运营管理等系统业务无法正常开展，这将带来不可估量的影响与损失。往更深层次得说，一旦这些国外数据库产品全面禁用，会对国家信息安全带来危害，严重影响国民经济的正常运行。国产数据库起步较晚，在信息、人才、技术、成本等多重困境之下，很多企业采用“拿来主义”的方式，在开源软件基础上或者从厂商购买源代码的方式进行封装和开发，从“表面”上缩短差距，造成一种技术“平齐”甚至赶超的“虚假繁荣”。这种方式虽然起点比较高，起步比较快，但产品架构几乎不可能调整，想掌握核心技术更是难上加难。以国内最受欢迎的 MySQL 为例，从授权协议看，MySQL 拥有两种授权协议，一种是 GPL授权协议：任何采用 MySQL 源代码，并且进行修改的衍生产品，其代码必须开源，不允许修改后和衍生的代码作为闭源商业软件进行发布和销售。另外一种是商业授权协议，允许修改开源代码进行商用，但需要购买商业授权，本质上与使用 Oracle 没有区别。而事实上，国内很多“拿”了 MySQL 的产品并没有遵循 GPL 协议。他们在 MySQL 产品基础之上进行封装处理，把业务数据映射到某个封装协议的净荷中，然后填充对应协议的包头，形成封装协议的数据包，并完成速率适配。使用 PostgreSQL 的情况也大抵如此。这几年 PostgreSQL 在国内掀起了一波热潮，越来越多厂商基于 PostgreSQL 进行封装，以 PostgreSQL 为代表的开源数据库信创生态正在完善。这本质上和使用 MySQL 的“拿来主义”没有差别，甚至可能更糟。就在前几年里，Elastic、MongoDB、Redis Lab、Neo4j 等均修改过开源协议，以 Elastic为例，2021 年初，Elastic 公司宣布再次修改开源协议：Elastic 公司决定将 Server Side PublicLicense 和 Elastic License 两款开源软件的 Apache License 2.0 变更为双授权许可。其核心条款是“如果将程序的功能或修改后的版本作为服务提供给第三方，那么必须免费公开提供服务源代码”。这意味着不法分子可以获得其源代码并研究其漏洞，给企业用户带来巨大的安全风险。-28-此外，Apache 软件基金会和 GitHub 官网都有公开说明，产品和技术受到美国的出口法律和法规限制，因此使用国外开源软件不能规避“被制裁”风险。受美国出口管制的俄罗斯在近期俄乌事件中将这方面风险彻底暴露。有外媒消息称，全球第一代代码托管平台 GitHub 考虑限制俄罗斯开发人员使用开源软件。尽管此类软件的使用是免费的，但它的许可协议仍然存在诸多限制，包括禁止受制裁的国家使用原本对公众免费开放的代码。从以上可以看出，“拿来主义”本质上并没有实现真正的自主可控，其后续架构演进、功能和性能等都受到一定的制约，同时还受到国外出口管制法律的限制，随意修改开源协议等操作，给国内用户带来了巨大的商业和安全风险。近年来，中央出台多项信创相关政策，大力支持信创产业持续发展，努力实现国产替代。数据库作为信息系统的核心和信创基础软件的重要部分，将迎来重大发展机遇。十四五规划和 2035年远景目标纲要也明确提出：“坚持自主可控、安全高效，推进产业基础高级化、产业链现代化。”党的二十大报告强调，加快实施创新驱动发展战略。加快实现高水平科技自立自强。以国家战略需求为导向，集聚力量进行原创性引领性科技攻关，坚决打赢关键核心技术攻坚战。据 Gartner 报告，2021 年全球数据库管理系统市场接近 800 亿美元，其中关系型数据库占比达到 80%，是全球数据库的主流。据中国信通院预测，我国数据库市场规模 2025 年将达到 688亿元，增长迅速。在信创热潮推动下，分析型数据库、交易型数据库、图数据库、搜索引擎、时序数据库、时空数据库等国产化替代，打造自主可控数据平台将成为中国数据库市场重要趋势。当前，国内数据库产业呈现出百花齐放、百家争鸣的局面，在关系型和非关系型数据库领域全面开花，如云厂商如阿里云、腾讯云、华为云，也有很多数据库厂商，如达梦、人大金仓等，也有大数据厂商如星环科技。星环科技是一家大数据基础软件厂商，于 2022 年 10 月 18 日在科创板上市，其致力于大数据基础软件的自主研发，并基于分布式技术、多模型统一技术、数据云技术等打造了一系列国产分布式数据库产品，覆盖主流的 10 条数据库赛道，并且能够基于星环科技创新的多模型统一架构实现多模型数据的统一存储管理，高效实现跨模型联合分析。目前星环国产数据库产品已在金融、政府、能源、医疗等行业拥有 1000 多家终端用户，帮助企业实现国外（开源）数据库的国产化替代，打造自主可控的数据库平台，并在架构、功能、性能、安全、运维、易用性等方面实现大幅提升。7 7.2.2 政策催化，替代化进程加速政策催化，替代化进程加速国产数据库作为信创的关键环节，随着国产化替代深入推进而受到重视。尤其当前数据库供应商国外厂商占比较大，国产信创产品研发迫在眉睫。2022 年，党的二十大胜利召开，提出加快建设制造强国、网络强国、数字中国，并对加快发展数字经济提出明确要求。回首 2022 年全年，政-29-府相继从高位部署、省级试点布局、地市重点深入三个维度，颁发了 9 项国产数据库利好政策。具体政策详情见下表。发布日期发布日期细分领域细分领域文件名文件名主要内容主要内容2022/1/6数字经济不断做强做优做大我国数字经济充分发挥海量数据和丰富应用场景优势，促进数字技术和实体经济深度融合，赋能传统产业转型升级，催生新产业新业态新模式，不断做强做优做大我国数字经济。2022/1/12数字经济“十四五”数字经济发展规划预计到 2025 年，数字经济核心产业增加值占 GDP 比重达到10%；大数据产业测算规模突破 3 万亿元；年均复合增长率保持在 25%左右。推进信息技术软硬件产品产业化、规模化应用，加快集成适配和迭代优化，提升关键软硬件技术创新和供给能力。2022/1/24数字金融银行业保险业数字化转型指导意见加快数据库、中间件等通用软件技术服务能力建设，支持大规模企业级技术应用。加强创新技术的前台应用，丰富智能金融场景，强化移动端金融服务系统建设。2022/3/5数字经济2022 国务院政府工作报告加快发展工业互联网，培育壮大集成电路、人工智能等数字产业，提升关键软硬件技术创新和供给能力。2022/6/23数字政府关于加强建设数字政府政策的指导意见加快数字政府建设领域关键核心技术攻关，强化安全可靠技术和产品的应用，切实提高自主可控水平。2022/8/25数字经济中央企业关键核心技术攻 关大会集中力量攻克一批关键核心技术产品，不断提升自主创新能力，聚焦卡脖子问题取得更多突破性成果2022/9/6信创关于健全社会主义市场经济条件下关键核心技术攻关新型举国体制的意见明确主攻方向和核心技术突破口，重点研发具有先发优势的关键技术和引领未来发展的基础前沿技术。-30-2022/9/28信创关于加快部分领域设备更新改造贷款财政贴息工作的通知设立设备更新改造专项再贷款，额度为 2000 亿元以上，具体支持领域包括卫生健康、教育等 10 个领域设备购置与更新改造，且将优先审核和支持符合采购国产自主品牌设备。2022/12/27信创扩大内需战略规划纲要（2022-2035）聚焦核心基础零部件及元器件、关键基础材料、关键基础软件、先进基础工艺和产业技术基础，引导产业链上下游联合攻关。表 7：2022 年国产数据库相关政策8.8.国产数据库市场份额国产数据库市场份额8.18.1 国产数据库市场规模增长迅速，三年内将达到国产数据库市场规模增长迅速，三年内将达到 688688 亿元亿元据信通院预测，中国数据库市场 2020-2025 年复合增长率高达 23.35%，2025 年市场规模有望达 688 亿元，国产数据库市场空间前景广阔。图 1：2020-2025e 数据库市场规模8.28.2 国产数据库市场份额向头部厂商聚集，数据库云化趋势显著加速国产数据库市场份额向头部厂商聚集，数据库云化趋势显著加速12 月 15 日消息，2022 年 Gartner 云数据库魔力象限公布，阿里云（Alibaba Cloud）依旧处于领导者象限，腾讯云（Tencent Cloud）重新入选并进入特定领域者象限且具有最高的执行力，是国内入选的仅有两家企业。而 2021 年位于特定领域者象限的华为云今年落选。-31-图 2：2022 年 Gartner 云数据库魔力象限12 月 16 日消息，IDC 发布2022 年上半年中国关系型数据库软件市场跟踪报告。报告显示，数据库云化趋势显著加速，公有云模式占比大幅提升至 61.2%。其中，阿里云以 42.4%的市场份额连续 3 年蝉联榜首，在传统部署 公有云模式下，阿里云也稳居第一，持续领跑国内关系型数据库市场。在本地部署模式市场中，华为云 GaussDB 以 16.59%的市场份额排名国内第一，自2020H1 以来，连续五次蝉联第一。图 3：IDC 2022 年上半年中国关系型数据库软件市场份额-32-8.38.3 中国在全球分析型和交易型数据库市场份额到中国在全球分析型和交易型数据库市场份额到 20252025 年将占据较高比例年将占据较高比例3 月 3 日，国际权威研究分析机构 Gartner 发布了中国数据库市场指南（Market Guide forDBMS,China）。Gartner 预测，“到 2025 年，中国分析型数据库市场来自海外厂商的将只剩下 30%，交易型数据库市场海外厂商市场也只会剩下 50%左右。”8.48.4 20222022 年云数据库营收数据将占据数据库整体市场的半数以上年云数据库营收数据将占据数据库整体市场的半数以上根据 Gartner2022 中国数据库市场指南报告显示，中国数据库行业将加速增长并逐步向云端迁移，未来四年，中国数据库行业向公有云迁移的速度将超过全球平均水平。2020 年数据显示，云数据库已占据整体数据库市场份额的 40%，据 Gartner 预测，2022 年云数据库营收数据将占据数据库整体市场的半数以上。8.58.5 三年内中国公有云数据库市场总规模有望达到超五百亿元三年内中国公有云数据库市场总规模有望达到超五百亿元，云原生数据库主云原生数据库主要应用于互联网行业要应用于互联网行业8 月 18 日，华为云与中国信通院云计算与大数据研究所共同发布了业界首个云原生数据库白皮书，据中国信通院统计分析，2021 年，中国公有云数据库市场规模为 144.59 亿元，较 2020年增速 34.3%，预计到 2025 年，中国公有云数据库市场总规模将达到 503.31 亿元。信通院对云数据库的使用者进行调研后发现，云原生数据库的使用者行业分布广泛，其中来自互联网行业的占比 55.4%，这里面包含了互联网电商、社交文娱、计算机软件、信息技术服务等多个细分行业。图 4：云数据库使用者行业分布图-33-8.68.6 关系型数据库在中国数据库总体市场中的占比超六成关系型数据库在中国数据库总体市场中的占比超六成，四家初创厂商评选为四家初创厂商评选为中国分布式关系型数据库创新者中国分布式关系型数据库创新者11 月 1 日，国际知名研究机构 IDC 发布 IDC Innovator：中国分布式关系型数据库，2022报告，根据 IDC 的最新数据，关系型数据库在中国数据库总体市场中的占比仍超过 60%。IDC 基于对分布式关系型数据库市场中各初创厂商的综合分析，评选出 4 家公司作为该领域的创新者（排名不分先后）：北京偶数科技有限公司（偶数科技）、北京万里开源软件有限公司（万里数据库）、广州巨杉软件开发有限公司（巨杉数据库）、天云融创数据科技（北京）有限公司（天云数据）。图 5：IDC Innovator:中国分布式关系型数据库，20229.9.国内数据库存量和增量市场平衡国内数据库存量和增量市场平衡9.19.1 国内数据库行业背景简述国内数据库行业背景简述从长期来看，国内数据库行业经过实验室自研阶段、引入国外产品借鉴吸收阶段发展到了在自主研发赛道“百花齐放”的阶段，各类型的数据库企业与其代表的技术路线都处于激烈的市场角逐当中。但是短期来看，近两年国内数据库市场并未完全达到预期的增长水平，无论从投资规模还是从中标金额均没有呈现“爆发”的迹象。具体而言，除了整个经济形势的外在影响外还有一些产品或者行业本身存在的问题和挑战，下文从市场需求角度简要分析国内增量市场和存量市场的“鱼和熊掌兼得”问题。9.29.2 国内数据库存量市场概况国内数据库存量市场概况（1 1）“存量市场存量市场”说明说明国内数据库领域的“存量市场”概念和通俗意义经济学上所指的“现存已被看到的确定的市场”有一定区别，指的是“在数据安全和供应链安全因素下进行的对国外产品进行对等替换的市场”。-34-以国外某数据库的数据为样本，推测整个替换市场空间：据公开财报数据显示，近年来某国外头部数据库公司的年销售额约为 2500 亿元；数据库销售额占总收入比值约为 40%（35E%浮动）为 1000 亿元（来源：Gartner，中泰证券）；中国区市场占全球市场约为 4%（3%6%浮动），为 40 亿元；据调研以及实地用户走访调研统计：某国外头部数据库非正式授权市场规模和正式授权市场相比约为 9：1，即隐性市场和显性市场分别占比 90%和 10%；以金融行业为例，据统计，国外头部数据库 TOP4 市场占比约为 55%、19%、13%、6%。基于上述的行业报告和市场统计，可以得出如下大致的存量年平均市场估算图：图 1：国内数据库存量市场年估算上述的统计如果考虑到在限定时间内完成的话，例如 5 年，那么年替换市场规模可以扩大 23倍（需累计计算过去 20 年国外产品在国内的 License 总量）。（2 2）“存量市场存量市场”需求分析需求分析受“真替真用”的相关要求，目前国内存量市场不再具有早期的“低售后成本红利”，市场开始更多关注产品本身的能力与特性。对目前的存量市场进行需求分析之前需要对客户类型进行分类，本文按技术能力水平可以将客户分为技术实力充沛型客户和技术实力匮乏型客户。-35-技术实力充沛型客户在面临数据库技术路线变化的替换需求时往往选择更高成本但是更彻底的“完全解绑”路线，即从应用层面进行重构，包括但不限于单元化改造、微服务改造、分布式改造等。技术实力匮乏型客户有两类，一类是行业属性导致对信息化投入低，例如制造、工业等传统企业，一类则是行业腰部及以下客户，不具备储备大量技术人员的条件。受限于技术实力和信息化投入比例，此类客户往往选择更为便捷和平滑的替换方案，包括但不限于产品同构替换、应用集成替换等。由于用户对基础技术的了解不深入特点，所以往往基础软件需要由供货商或服务提供商兜底。9.39.3 国内数据库增量市场概况国内数据库增量市场概况（1 1）“增量市场增量市场”说明说明数据库领域的增量市场区别于经济学中的“可能会被激发的潜在的市场份额”概念，一般指的是“由于应用新建或者业务变化带来的数据库销售”，更偏向于“新增市场”概念。国内的数据库市场规模统计口径在 2020 年之前主要是以增量市场（新增市场）为基础的，“存量市场”占比基本低于 3%，可以忽略不计。基于以下统计数据，可以大致评估出国内增量市场规模：中国信通院数据库发展研究报告（2021）：中国数据库市场以每年 23.4%的增速增长，在 2025 年达到 688 亿元规模；中国赛迪顾问“十四五”关键应用领域之数据库市场研究报告统计：中国数据库市场本地部署与云市场比例为 47.7%和 52.3%。图 2：中国数据库市场预计统计（增量）-36-目前我国数据库的增量市场是和数据管理业务强相关的，随着数据重要性逐步提升，数据的规模和重要程度会从金字塔模型逐步过渡到倒金字塔模型，如下所示：图 3：数据规模金字塔模型具体来说，早期受限于硬件能力和大数据处理技术，地方应用的数据规模总量往往是最大的，其经过处理以后将总结数据层汇聚到国家级应用中，此时国家级的应用数据是规模较小的结果数据和历史数据。以自然资源系统和统计系统为例，国家层面的数据往往是统计结果，并不存储原始数据，所以其数据时效性和价值并不能完全展现。在数字化改革和数据集约影响下，传统应用开始转型，呈现从地方/自动化端侧直报国家级中心的态势，区域数据则是由国家中心下发。此模型无论从时效性还是管理上都要更进一步。随之而来的则是地方应用（端侧）数据规模会逐步降低，国家级应用（云）的数据规模和数据时效性会逐步上升。数据的价值是建立在数据的规模和数据时效性之上的，只有原始数据的快速汇聚才能打通横向和纵向的数据孤岛，完成数据的可服务化从而提升数据价值。（2 2）“增量市场增量市场”需求分析需求分析整体而言，国内企业/单位分为了守成型和开拓型两类，前者指的是业务模型较为固定，或者客户总量确定的企业，例如部分国企、央企、金融机构；后者指的是客户数量快速增长、业务压力提升迅速、政绩需求突出的单位和企业。守成型客户对数据库的需求乃至对信息系统的需求更多是从供给侧发起的，包括但不限于对降低成本、风险规避、合法合规方面有较强需求。开拓型客户的需求和守成型客户的需求发起点相反，大多从消费侧发起，目前国内 IT 领域对数据库或者说数据产品的最大期望是能为其带来数据的增值，从而实现市场的开拓。具体的数据应-37-用包括但不限于数据共享（数据交易）、数据挖掘、数据分析（决策）等。（3 3）增量市场和存量市场平衡思路）增量市场和存量市场平衡思路通过对增量市场和存量市场的概况分析可以大致得出，存量市场主要关注替换本身的“低成本”，包括但不限于时间成本、人力成本、学习成本等；增量市场主要关注产品为业务带来的附加值，即数据利用的“高效性”，包括但不限于降本增效、数据集约、数据分析等。但是随着传统企业转型升级迫在眉睫，国家数据安全要求逐步覆盖全行业国家数据安全要求逐步覆盖全行业，原有的增量市场和原有的增量市场和存量市场的界限开始变得模糊存量市场的界限开始变得模糊。通俗来讲，客户期望一次数据库销售可以同时满足存量替换和数据增值的需求，而非分步进行，所以平衡存量市场和增量市场需求就显得尤为重要平衡存量市场和增量市场需求就显得尤为重要。要解决平衡问题首先需要分析目前国内数据库产品和企业状态，国内目前存量市场主要优势企业是传统数据库企业，增量市场主要优势企业是新兴数据库企业，这两类企业或者产品应对另外一方的市场来说还略显不足，具体来看如下：传统数据库厂商产品以集中式数据库进行同型替换方案为主，在面对增量市场的时候存在一些挑战：a.不能独立依靠数据库产品解决数据集约化问题；b.不能很好地在国内服务器能力不足的情况下匹配业务性能要求；c.扩展性不足，难以低成本满足国内“多期建设”诉求，即相同的业务从小规模示范过渡到大规模应用。新兴数据库企业大多采用分布式数据库技术路线，以全面应用改造方案为主，在切入存量市场的时候存在部分难点：a.提供的替换方案整体庞大，业务入侵性过高，应用修改量大，难以规模化替换；b.语法兼容性弱，体现在对被替换产品的语法、数据类型兼容性弱，需要大量人工介入；c.功能兼容性弱，体现在对被替换产品的内置函数、存储过程兼容性差，尤其是大部分分布式数据库产品将存储过程分布式化的能力，需要重构应用。针对上述问题，下文通过“从市场需求层映射到产品特性的方法”提出对数据库产品能力的要求，提供一种解决“鱼和熊掌不可兼得”问题的思路，如下图所示：-38-图 4：数据库产品能力的要求二、二、数据库关键技术概览数据库关键技术概览数据库管理系统作为能够使用户定义、创建、维护和控制访问数据库的软件系统，其整体架构与技术路线不断深化发展，如今呈现 NewSQL、分布式、HTAP、serverless、湖仓一体、内存技术、超融合与流式处理、云原生等技术现状。1.1.NewSQLNewSQL从数据库与数据应用需求相适应的角度切入，我们可以将众多不同类型的数据库按演进过程划分为 SQL、NoSQL 与 NewSQL 三类。最初的数据库系统是为了解决基于文件系统的数据应用面临的各种困难和挑战而诞生的。主要面对的是数据应用对于共享、可靠、一致、高效、安全、低冗余的数据访问需求。这一时期，在关系模型基础上，支持事务机制，提供 SQL 访问接口的关系型集中式数据库纷纷涌现，典型的如Oracle、DB2 等商业数据库产品以及 MySQL 和 PostgreSQL 等开源系统。狭义来说，SQL 是关系型数据库提供的极具用户粘性的查询语言，但是在此上下文中，用 SQL 特指传统的集中式关系型数据库。此类数据库成为这一时期数据管理软件中 one-size-fit-all 的最终形态。但是，随着无线互联环境的日趋成熟，大数据浪潮随之而来，各种大数据应用纷纷出现。大规模高速并发流量不-39-断累积海量数据，加之大数据应用对不同类型数据的高速处理需求，使得集中式数据库难以有效应对。因此，这些新型数据应用亟需分布式的系统解决方案，也对数据库系统在高可扩展、高可用等特性上提出了新的需求。这一时期的数据库都是分布式形态，除了在支持的数据类型（如键值、文档、图模型等）以及分布式特性上需要“加法”，由于其主要面对的是互联网应用，因此在严格事务语义、SQL 接口等特性上也采取了部分“减法”。数据库内部降低了对复杂数据业务的支撑能力，将诸如维护访问一致性的困难转移到了应用开发层面。但是由于释放了传统关系型数据库的诸多约束，这一时期的数据管理系统呈现爆发式的发展态势，该时期涌现的数据管理产品统称为NoSQL 数据库，典型的如键值数据库 Redis、文档数据库 MongoDB、图数据库 Neo4j 等。之后，随着大数据生态的日益完善和在不同应用领域的深入使用，特别是在关键业务领域，在满足高扩展和高可用的前提下，数据应用对于数据强一致性和既有应用透明对接的需求愈发强烈。在这一时期的初期，传统关系数据库系统也通过分库分表以及具有分布式服务能力的中间件等方案，尽力适应新的数据应用需求，典型的如 PostgreSQL XC 项目等。但是此类方案并非数据库原生的分布式解决方案，特别当集群规模不断增大时，开发与运维的复杂度都呈现指数级增长趋势。因此，虽然类似 PostgreSQL XC 项目的方案具有与既有应用和成熟生态高度兼容的优势，但是，从架构先进性上来看，此类方案存在结构性限制，其各方面的天花板都受到底层技术的制约，属于一种过渡性技术方案。所谓原生的分布式数据库解决方案是指在数据库系统设计时，采用存储与计算分离的设计思想，在其内部实现对数据分片、强一致多副本复制、严格事务、SQL 接口、高可用、高可扩展等功能和特性的支持，此类原生分布式数据库被称之为 NewSQL 数据库。以 Spanner 为代表的Share-nothing 架构以及以 Aurora 为代表的 share-storage 架构是 New SQL 类数据库目前最主要的两种架构形式。这两种形式都支持存算分离，但是在扩展能力上有所差异。Share-storage 架构的系统大多只提供共享存储层的水平扩展能力，而由单一读写实例和若干只读实例构成的计算引擎层则不具备写并发能力。针对此问题，很多系统在后期通过引入Multi-Master 多主架构，在一定程度上为写引擎提供了写并发能力。有的核心设计思想是借助无锁的共享写节点的异步写方式，推动多写计算节点的事务完成，计算节点之间需要协调和回滚发生冲突的事务。有的则是基于共享缓存层以及多版本一致性模型和锁机制完成冲突事务的解决。但是，上述改进目前还存在冲突检测互斥粒度过大、极致的水平写扩展能力有限等架构性难题。Share-nothing 架构则在扩展性上具有良好的表现能力，计算引擎和存储引擎理论上都可以线性的水平扩展。这种架构下，对用户完全透明的分区必然会引入分布式事务，也是影响系统性能的重要因素。除了在两阶段提交协议上进行各种优化，有的系统也给用户提供了可定制的分区规则，业务端可以根据应用场景和数据特征，将特定访问所需的数据划分在特定的单分区内，利用规则约-40-束分布式事务的发生。但是这种方式无疑也提高了数据应用开发的门槛，需要业务层做仔细谨慎的设计，否则就可能产生不可预估的性能问题。总体来说，从 NoSQL 全新迭代设计的 share-nothing的 NewSQL 数据库，系统组件层次清晰，耦合程度低，但是与既有应用的兼容和生态的建设需要不断的打磨。这种全新架构的产品具有很高的上限，还需要更多的成长时间。此外，share-storage架构的数据库天然和云具有亲和性，但是又存在被某一厂商绑定的潜在问题，Share-nothing 架构的数据库则有更灵活和独立的部署策略。客观来说，除了具有完整理论支持的 SQL 关系型数据库外，NoSQL 和 NewSQL 数据库其实并没有严格意义上的定义。它们代表一种数据管理系统随数据应用需求而演化的阶段性分类。特别是对于 NewSQL 类系统，它们既存在一些公认的特征，而不同系统又都基于不同的设计假设和偏好场景，具有独特的技术特性和优势。例如，Spanner 利用独有的物理时钟系统 TrueTime 实现了分布式事务，解决了全球级跨区域的数据一致问题；TiDB 在承载 spanner 设计哲学的基础上，利用开源方式进化成为 HTAP 数据库；Aurora 基于“网络是数据库瓶颈”的假设，提出了 log isdatabase 的设计哲学；PolarDB 则根据网络环境变化的事实观察，认为瓶颈将由网络转向软件栈，利用新硬件驱动的用户态设计模式提出了一系列关键技术；OceanBase 在不断强调水平扩展的设计目标下，又回头重新审视极致的单机性能的重要性，提出单机分布式一体化的演化思想；YaoBase 则在读写分离架构下，通过内存计算加速的增量聚集系统架构实现了高性能事务。目前各种 NewSQL 类系统“道”相似而“术”不同，而不同的技术路线必然会导致此类系统在系统性能、适用部署模式（On-Promise 与 On-Cloud）、研发和维护成本、使用者代价以及可靠性与稳定性上都存在差异，任何一个系统都不是“银弹”，需要结合应用的实际需求进行考量。图 1：TiDB 的 HTAP 架构-41-图 2：PolarDB 新硬件赋能的架构图 3：OceanBase 单机分布式一体化架构-42-图 4：YaoBase 内存计算加速的增量聚集架构我们认为，应用需求的驱动是数据库演化的最直接动力，不同阶段的数据库也在通过螺旋式的迭代演化，不断融合最核心的功能。现阶段来看，NewSQL 是具有架构先进性的，基础架构决定了上层功能，不同具体产品形态又各具特色并在不同场景中彰显不同优势，NewSQL 数据库也正在试图将以往阶段数据库系统的重要特征不断吸收交汇，试图再次以 one-size-fit-all 的姿态独领数据管理领域。当然，未来是百花齐放还是一枝独秀，还有待市场、技术和时间的相互验证。2.2.分布式分布式2.12.1 分布式数据库出现的背景分布式数据库出现的背景数据库系统有确定的功能集吗？数据库系统有明确的边界吗？如果有人问这两个问题，答案都是否定的。数据库管理系统是一种非常复杂的软件系统，它的形态和边界是不停变化的，在适应持续迭代的硬件环境和不断变化的用户需求的过程中，数据库系统也不停地变化着自己。回顾历史上成功的系统，数据库系统的功能总是在竞争中发展、完善，成为更好的支撑业务的底座。Oracle 公司的 Oracle 数据库系统真正对外是 1979 年，发轫之始，Oracle 就面对 Ingres的竞争。两家公司在哪种语言才能最好的代表关系数据库而拼命发展自己的路线。如果说图灵奖获得者 E.F.Codd 的关系代数是灯塔，那么数据库公司里的软件工程师们就是与惊涛骇浪搏斗的水手们，是在这些勇士的手中，SQL 功能被不断的丰富，SQL 的执行性能被不断的提升，终于成为支撑了半个世纪数据技术发展的主流解决方案。Oracle 公司经历的激烈竞争还有很多，有些竞争不仅差点击跨 Oracle，而且改变了 Oracle系统，也改变了整个业界对于关系数据库系统的认知。Sybase 系统经过 2 年的低调研发，从 1987年开始进入市场，以更强的 OLTP 处理能力横扫客户。Oracle 面对 Sybase 的竞争，也持续不断-43-的优化 OLTP 场景的性能，并且积极发展了 Client/Server 的运行能力。在此之前，应用程序要和数据库系统运行在同一台机器上，这种“集中式”的使用方式被认为是更高效的，经这一役，关系数据库处理 OLTP 的性能获得了极大提升，Client/Server 的“分布式”运行方式获得了市场的认可，成为了业界主流。互联网兴起发展的这些年里，分布式技术得到了极大的拓展和实践。硬件环境摆脱了对于专用高端硬件的依赖，越来越多的刀片服务器成为了新主流。将分布式技术应用在数据库系统内核中，是新的分布式数据库系统的目标。基于分布式技术的数据库系统，具有功能、拓展性等多方面的优势，数据库的存储和计算能力不再受单一服务器的限制。基于分布式的技术，在数据库内部能够维持副本之间更好的一致性，进而提供更好的数据库服务的连续性。基于多台服务器的集群，数据库也能利用更多的硬件资源提供更强大的数据分析能力。在分布式数据库发展的第一阶段，新的系统为了突出分布式的优势，研发精力自然的放在高可用、扩展性等分布式数据库特有的功能上，而这类功能也充满了技术上的挑战，需要研发团队跨过从理论到技术再到产品的多种难关。这时候的分布式数据库，有其架构带来的独特优势，但是在功能的全面性上有所欠缺，使用者可能只会把分布式数据库定位成传统数据库的补充。随着分布式数据库的持续迭代，在继续加强扩展性和高可用等优势功能的同时，从市场的实际需求出发，解决了很多数据库使用者原本关心的功能、性能等特性问题，作为分布式数据库代表的OceanBase，已经步入成熟阶段，成为全场景的数据库系统解决方案，可以更方便地让不同的应用集成分布式数据库。2.22.2 成熟分布式数据库的标志成熟分布式数据库的标志分布式数据库系统成熟有两个重要的标志：功能完备，运行效率优秀。下面分别从这两个方面详细聊一聊。（1 1）功能完备功能完备数据库系统是在实践中逐渐成长完善的软件系统，功能集是相当的庞大。数据存储、数据修改、数据查询、数据管理等不同方面，都有各种类型的业务诉求。数据存储方面，以 OceanBase 为例，分布式数据库在已经拥有非常高效的存储压缩的基础上，在最新的迭代中也支持了更多的字符集。同时，对大对象的支持也是 OceanBase 一个很大的突破，同类的其他分布式数据库对大对象支持得都不够友好。应用开发中，虽然不是所有业务都会依赖大对象，但是总有一些业务场景比较依赖大对象功能。OceanBase 现在可以提供对大对象功能的全面的支持。并且，在大对象功能的基础上，还支持了 JSON、GIS 等复杂数据类型，这类数据通常-44-都会在一个元素中存储比较多的内容，如果没有大对象能力在底层做支撑，还真是不好用。数据修改方面，OceanBase 支持了任意大小的事务，在应用的数据导入、数据订正、数据维护等流程中，应用开发者或者数据库管理员不时会在一个事务中修改大量数据。这种使用方式，对于传统数据库来说不是难事，对于新的分布式数据库来说，因为事务模型发生了很大改变，支持大事务都是很大挑战。当 OceanBase 支持了任意大小事务后，使用者再也不用操心一个事务修改的数据量是否过大。OceanBase 还全面支持了各种重整数据的 DDL 功能，比如修改主键、修改分区键、重新定义列类型等等。再结合 OceanBase 之前就支持在线的后建索引的能力，OceanBase已经具备了完善的对于数据维护操作的能力。对于新业务和变化很快的业务，Schema 会随着业务发展不停的变化，有了重整数据的各种 DDL 的支持，用户就能很方便得使用 OceanBase 来承载这种经常变化的业务场景。数据查询方面，OceanBase 在语法上兼容 MySQL 和 Oracle，支持了从大量琐碎的函数到存储过程等重量级功能。同时，OceanBase 的查询优化器、执行器也都不断迭代，任何数据库的查询优化和改写能力都来自实践经验的不断积累，业界比较公认的 Oracle 的查询优化能力是很强的，目前的 OceanBase 的查询优化器已经达到了 Oracle 的同等水准。OceanBase 的执行器的并行执行和向量化执行能力也已经是成熟和高效的引擎，可以很好的支持大数据量的查询，这是新兴的 HTAP 系统才具备的能力，OceanBase 这方面的能力已经超过了传统的数据库系统。数据管理方面，数据库系统里通常都存储了用户的关键业务数据，用户使用数据库系统不仅只是运行一个实例进行数据操作，还为了备份、安全、监管，进行各种数据管理操作。比如，定期备份所有的数据，或者在异地搭建一个从库等。对于数据库系统来说，备份数据和搭建从库都有物理和逻辑两种方式，物理备库和物理从库才拥有保证数据的一致性和应对所有业务场景的普适性。OceanBase 是分布式数据库中最早支持了物理备份恢复和物理从库的系统，使用 OceanBase 可以让数据库管理员非常方便的完成各种数据管理的任务。（2 2）运行效率优秀运行效率优秀数据库系统为什么要重视运行效率？数据库系统作为底层基础软件，其与生俱来的使命就是更好的利用硬件来完成数据库的各种功能。作为大规模部署的通用软件，软件自身的每一点运行效率的提升都能带来巨大的生产效率的提升和生产成本的下降，所以，所有的专业数据库系统都在不停的优化运行效率。相比于其他分布式数据库，OceanBase 的整体性能非常优秀。而且，OceanBase 在单机部署时，与传统的单机数据库相比，OceanBase 的性能也非常优秀。也许有人会有疑问，分布式数据库为什么要重视单机性能？性能优化的本质是尽可能发掘出硬件的极致，在一台服务器上的操作-45-与跨机的操作走不同的硬件，天然有不同的特性，当然需要针对不同的特性进行优化。换个角度看分布式系统。分布式系统是由网络连接的一组服务器上工作的系统。这里的网络指的是以太网。但很容易被忽视的事情是服务器内部也是由若干个网络有机结合的一个系统。CPU利用内存控制器把数据通过消息从内存中加载到 CPU 的 Cache 中。CPU 利用 IO 控制器通过消息把数据从硬盘加载到内存中。CPU 的核心之间通过消息交换访存的信息和 Cache 的信息。每一处都类似一个小网络不停地进行信息的交换。从运行效率角度看，以太网比机器内的网络具有很长的传输距离、更低的传输功耗，但是操作复杂、延迟大。当不同特性的硬件摆在数据库系统设计者的面前时，设计者一定要考虑怎么更好地利用不同层次的硬件能力，更加高效的实现数据库的特性。OceanBase的单机分布式一体化架构核心就是让OceanBase系统在一台机器上运行开销与传统单机数据库是类似的，同时让 OceanBase 还具备分布式的扩展能力，支持利用多台服务器进行数据存储和服务能力的扩展。OceanBase 的一体化架构的核心就是让系统以机器为单元组织数据库的管理结构，能在一台机器上通过本地操作和本地引用完成的事情就放在一台机器做，尽量减少跨机的操作与跨机的结构。通过在保证扩展性的同时，还能把一台服务器的硬件能力发挥到极致，OceanBase 可以给到使用者从一台很小规格的机器到多台服务器组成的集群都能高效运行的数据库系统。2.32.3 从一体化到一站式从一体化到一站式基于分布式技术构建的数据库系统，其能力上限远大于传统的单机数据库系统。随着社会数字化进程的加速，市场对于数据库系统的需求也是越来越多。在一体化架构的加持下，OceanBase已经具备了传统单机数据库的主要功能，并且还拥有比传统单机数据库更优异的性能，有能力承载各种业务场景的对数据库系统的需求。现在的数据库系统的功能集愈发丰富，从之前的仅仅解决某一种业务模型的需求，演变到集实时交易处理与在线分析查询能力于一体的综合系统。分布式数据库系统已经成长为能力强大的综合性系统，用户可以在一个系统内既承载业务的事实交易，又进行数据模型的转换，再进行挖掘数据价值的查询分析，让数据在一个系统内流转，一站式的解决用户从数据产生、到数据转换、再到数据消费的一系列操作，在带给业务便利性的同时，进一步降低数据处理的成本。3.3.HTAPHTAP3.13.1 技术背景技术背景（1 1）商业层面商业层面。陈旧的报告、缺失的数据、缺乏高级分析以及完全缺乏实时分析对于任何需要新见解以在商业客户时代保持竞争力的企业来说都是一种无法忍受的状态。-Forrester。-46-随着业务需要的发展和数据库技术的发展，使得数据库产品需要具有同时处理 AP 和 TP 的能力，需满足：（1）负载隔离能力，AP 负载不会影响 TP 负载；（2）数据的新鲜度要高，AP 可以访问最新的 TP 数据。因此，基于 HTAP 的能力可以简化业务系统的架构。AP 和 TP 的能力由统一的系统对外提供，由此带来：（1）业务架构简单化；（2）具有一定的扩展能力；（3）系统技术栈简单，运维方便等等优势。产生 HTAP 用户侧的需求或者诉求如下：（1）事务数据及历史数据的集成；（2）理解用户需求的超维度数据分析的需要；全局视角来看数据，方能看清事物的本质。（例如：从手机的位置信息，用户的填表所获得信息，社交媒体所获得富媒体信息）;（3）企业运行所需的商业分析的实时性需求。（2 2）技术层面技术层面。以下技术的发展进一步的推动了 HTAP 技术的快速发展及在业务层面的落地。列存技术列存技术：该种数据存储模型下，只需要读取分析计算所需的属性即可，由此可以节约宝贵的 IO 和 memory 资源。同时，列存模型也属于 CPU Cache 友好型。但是，该模型有一个问题：其在将结果返回用户的时候，或者在上层算子进行计算的时候需要重构记录（Tuple）。in-memoryin-memory 技术技术(包括：distributed in-memory)：当执行 Analytical Processing（AP）的时候，可以将 AP 所需数据加载内存中，甚至可以将所需的表的数据全部加载至内存，获得急速的处理速度。最后，为了保证系统 crash 的时候可以正确且快速的完成 recovery，需要将内存中的数据持久化至磁盘中。可扩展的架构可扩展的架构：（scale-out architect）:水平扩展架构的发展，分布式锁技术的成熟，记录的分布式管理。当然分布式对于 HTAP 来说，只是一个充分条件，而非必要条件。数据压缩数据压缩（data compression）。分层存储架构分层存储架构（tiered storage）：为能够以最大的性价比对用户提供高性能，分层存储架构应运而生。例如：使用 DRAM，NVME，SSD，HDD 来构成分层存储架构。将对于计算实时性有要求的数据加载至 DRAM 中进行计算，以获得实时计算结果。如果计算过程复杂，中间结果集较大，可将中间结果集保存至 NVME 中，这样既可以保证数据的实时性，又可以支持更大的数据量，以获得较高的性价比。同样，SSD 和 HDD 也起着同样的作用。3.23.2 发展历程发展历程HTAP 数据库的兴起和发展是在 2010 年代，有三条技术路线，分别是单机数据库，云数据库，NewSQL，SAP HANA 是以内存数据库为主的单机架构，MySQL 在 2021 年发布的-47-Heatwave 虽然在分析能力上是个 MPP 的架构，但 MySQL 本身还是单机版的，Google AlloyDB参考了 AWS Aurora 的架构，做到了青出于蓝的效果。NewSQL 的分支鼻祖是 Google Spanner,但同为 NewSQL 架构的 TiDB 持续在 Real Time HTAP 投入巨大，TiDB 早期解决了 MySQL分库分表的问题就面临用户的在线分析需求，在 2018 年 TiSpark 的引入，2020 年 TiFlash 架构完成了 HTAP 架构的闭环，再到 2021 年 5.0 版本 MPP 能力，这个能力通过 TiDB Cloud 向所有云上用户输出，在 5 年时间完成了 Real Time HTAP 产品能力的四连跳。图 1：主流 HTAP 数据库大事件与 2014 年 HTAP 刚刚提出来的内存数据库架构大不相同，当前最有四个代表性的新一代HTAP 数据库，我们会发现一些共性：首先新一代 HTAP 数据库都应对的是互联网和数字化催生的更大数据量，更低延迟，更低成本的新一代需求，其次，新一代 HTAP 数据库无论路径如何，都采用了分布式架构，行列混存，低延迟的 Log 复制机制，并通过云端的扩展获得了准 PB 级别的扩展性，很多还借助了 ML 的学习能力来提升查询的效率，最终都实现了以全托管的模式给用户提供一个简单而强大数据库的使用体验。合久必分，分久必合，新一代 HTAP 数据库在云端，以一种简化而强大的数据库能力为用户提供秒级的实时交易和查询体验，已经是一种公认的潮流。3.33.3 典型厂商典型厂商及架构对比及架构对比国外国外：SnowFlake（Unistore)、Google（AlloyDB）、Oracle（MySQL HeatWave)、SingleStore、SAP HANA、Microsoft SQL Server、Aurora（Parallel Query）等。国内国内：OceanBase、TiDB、StoneDB、PolarDB、GaussDB、TDSQL-H 等。-48-（1 1）AuroraAurora ParallelParallel QueryQuery熟悉 Aurora 架构的读者清楚，Aurora 最早的版本是基于 MySQL 的，Aurora 的理念是“Log is Database”。Aurora 主要是靠存算分离和共享存储来提升系统的扩展性，在 OLTP 方面，主库和从库采用 Log 在共享存储层的同步机制来保证从库的数据及时更新；在 OLAP 方面，Aurora 基于 MySQL 5.6 和 5.7 兼容版本都支持并行查询，2019 年，AWS 基于 Aurora 上推出并行查询（Parallel Query），借助 Aurora 的存算分离架构，Parallel Query 可以把大规模查询的负载下推给 Aurora 存储层，而 Aurora 计算节点可以继续为事务服务，这样就可以在一个 Aurora 数据库中互不干扰地运行事务和分析负载。Aurora 解决混合负载的办法主要是采用存算分离的架构特点，充分借助云存储层的扩展性；但 Aurora 一写多读的架构在写入扩展性方面存在瓶颈，造成在 OLTP 上面的性能很容易达到上限。对于大多数 MySQL 用户来说，迁移到Aurora 可以体验到云端 OLTP 性能和扩展性得到一个巨大的提升。Aurora Parallel Query 也提供了 MySQL 架构的并行版本，但无论是 OLTP 的写瓶颈，还是缺少列存支持的 Parallel Query，都在 OLTP 和 OLAP 方向留下两个不小的遗憾，是带有缺憾的 HTAP 解决方案。图 1：Google Cloud AlloyDB-49-（2 2）GoogleGoogle CloudCloud AlloyDBAlloyDBGoogle AlloyDB 是基于 PG 协议的，总体采用类似 AWS Aurora 的共享存储架构，通过存算分离和共享存储来提升系统的整体扩展性。从 AlloyDB 官方的架构演进图可以看到，AlloyDB的扩展性和 HTAP 能力都是靠智能存储引擎“Intelligent Database Storage Engine”OffLoad 数据计算节点的 IO 来实现的，而这一层“智能存储引擎”是围绕 LPS 通过 Log、Cache 和 Shared Block Storage 来实现的。在 OLTP 的写操作，主库通过 WAL 机制加速，在 OLAP 的读操作，可以应用可以从从库的 Buffer Cache、Ultra-fast Cache、智能存储层依次并行地去读取数据，可以自适应地决定资源的分布，无论读写，都可以解决 IO 瓶颈、热点、Block Write 等瓶颈，并借助 AI 算法可以不断地学习数据放置的方式。AlloyDB 增加了针对OLAP 的列存引擎，这使得 OLAP 的分析能力大幅增强，不过这个主要是靠内存和缓存来完成的，由于 OLTP 和 OLAP 都采用的是一个跨 Region 的共享存储，所以 OLAP 永远读到的都是最新的数据，这是 HTAP 能力一种非常好的实现方式。Aurora 的共享存储从根本上是一个服务 OLTP 的引擎，没有提供列存引擎，Aurora ParallelQuery 还是要通过下推利用多节点从行存中 Query 数据。而 AlloyDB 是在 Aurora 的架构上为共享存储的 Log 服务机制增加了 AI 的能力和列存引擎，在 OLAP 处理方面会带来很大的提升，但是 OLTP 的单写机制是否有足够的扩展性有待真实场景检验。AlloyDB 的出现给 PG 的用户带来一个云上 HTAP 加强版，这对于 PG 用户来说是一个福音。无论是 Aurora 还是 AlloyDB 都是 AWS 和 GCP 的专有服务，用户只有成为 AWS 和GCP 的用户才有可能使用。此外，AlloyDB 在付费的透明度方面针对 Aurora 做了很大的改进，算是青出于蓝了。-50-图 2：AlloyDB 的改进（3 3）MySQLMySQL HeatwaveHeatwave，增加列存外挂引擎和，增加列存外挂引擎和 MLML 的大号的大号 MySQLMySQL图 3：MySQL HeatwaveMySQL 在原有架构上增加了一个列存引擎 Heatwave，成为了一个 MySQL 统一入口的分析引擎外挂，主要解决 MySQL 用户的规模化查询的问题。从系统架构上看，用户的 SQL 请求由系统判断是去 MySQL 自身的 InnoDB 还是 Heatwave，大规模的查询可以下推给Heatwave 多节点并行计算，再返回结果，可以将查询提升一到两个数量级，处理的同时Heatwave 和 InnoDB 互不干扰，不影响 InnoDB 侧的事务处理和 OLTP 查询。Heatwave 虽然大大提升了查询能力，但 InnoDB 本身的扩展性依然有瓶颈，OLTP 的吞吐量依然很容易达到上限，造成 OLTP 的扩展性仅限于 MySQL 原有的处理能力，无法满足MySQL 用户对OLTP 大规模扩展性的需求。（4 4）TiDBTiDB HTAPHTAP，独立列存引擎设计，基于分布式，独立列存引擎设计，基于分布式 NewSQLNewSQL 的跨云的跨云 HTAPHTAPTiDB 是 2015 年在 GitHub 开始发布的 NewSQL 数据库，其架构的灵感来源是 GoogleSpanner/F1，兼容 MySQL 协议，在 GitHub Star 数超过 31000 ；在 TiDB 2017 年的早期版本 就开始尝试支持 HTAP 的能力，并分别在 2019 年发布了 TiSpark,2020 年发布了列存引擎 Ti Flash，其行列混存的 Real Time HTAP 架构论文（此处嵌入论文链接）是对 NewSQL架构的一次创新，2021 年 TiDB 5.0 支持了 TiFlash 的 MPP 版本，从而使得 TiDB 的Real-Time HTAP 变成了在 OLTP,OLAP 双向扩展能力的 Real-Time HTAP 数据库；2022年 5，经过一年的预览后，基于 TiDB HTAP 数据库能力的全托管服务 TiDB Cloud 正式全球商用，成为以全托管模式支持 Real-TimeHTAP 数据库服务。-51-TiDB HTAP 的架构如下图：TiDB 采用计算存储分离的分布式架构，TiKV 采用行存，TiFlash采用列存，通过 Raft 协议同步数据，行列存之间保持强一致的数据读取。用户层面使用 TiDB 数据库，一个访问入口，一份数据，只要写 SQL 就行了，不用去考虑业务是 OLTP 还是 OLAP。TiDB HTAP 提供的 OLTP 与 OLAP 能力在架构设计上是完全对等的，各自都可以根据业务的规模实现规模化扩展，在实时性与一致性前提下 OLTP 和 OLAP 是完全隔离的，互不干扰和影响。图 4：TiDB 负载分离TiDB 列存引擎的 MPP 执行器对窗口函数的框架性支持，内存消耗被分布式分担，批处理场景的处理性能较为突出。TiDB Cloud 已经在 AWS 和 GCP 上面提供服务，用户可以构建跨云构建 HTAP 数据架构，避免了单一云厂商的锁定。本文初版写完的时候，Data Cloud 的领导者 Snowflake 也加入了 HTAP 的行列，他们发布的 Unistore 一看名字都是行列混存的路子，大家都知道 Snowflake 之前的主要领域是把 云上数据库仓库服务，重点在偏向 OLAP 的分析领域，用的也是列存引擎，此次 Unistore 的发布主要是通过新发布的 Hybrid Table 增加了对行存的支持，一方面支持的交易类型的应用，另一方面让实时分析可以在不移动数据的情况下，分析来自交易应用，分析引擎，和原有 Snowflake 数据源的数据。Snowflake 在 HTAP 的用户价值角度也强调了一个数据栈，不移动数据，同时支持在线交易和实时分析。讲了那么多比较，现在用一张表来看这几个主要HTAP 数据库的特点，此表格对HTAP数据库的关键能力做了一个粗颗粒的对比。产品名产品名GoogleGoogle AlloyAlloy DBDBAWSAWSParallelParallelQueryQueryMySQLMySQLHeatWaveHeatWaveTiDBTiDB HTAPHTAP架构特点存算分离共享存储存算分离共享存储存算分离行列混存存算分离行列混存NewSQL-52-OLTP 规模化智能存储写瓶颈写瓶颈多读多写列存/MPP（HTAP 必选项）支持/Memorycache 的列存不支持支持/MPP支持/MPP一个入口（HTAP 必选项）是是是是一套架构（HTAP 必选项）兼容 PG兼容 MySQL兼容 MySQL兼容 MySQL互不影响（HTAP 关键能力）不影响不影响不影响不影响AI 能力（HTAP 加分项）有无有有多云/云中立否否否是开源大数据集成是否是是表 8：HTAP 数据库的关键能力对比新一代 HTAP 数据库最关键的指标是什么？它和数据仓库，数据湖靠什么来区分？前面这个分析表从各个不同角度分析了 HTAP 数据库应该具备的关键能力，从结果上看，HTAP 数据库和数据仓库，数据湖最简单的划分是什么？答案只有一个，Latency，下面一张图把HTAP 能力的 Operational databases 和数据仓库，数据湖做了区分，回到本文开头的“秒回”这个词，无论具备 HTAP 能力的 Operational Database 采用了那些技术组合，最终的效果就是要“秒回”，而数据仓库总体来说是秒到分钟级别的，而数据湖的数据访问都要分钟到小时级别了。图 5：HTAP 能力的 Operational databases 和数据仓库，数据湖的区分-53-3.43.4 选择选择 HTAPHTAP 产品的维度产品的维度（1 1）业务场景业务场景:首先，我们从业务场景的角度来讨论如何选择一款 HTAP 数据库，主要有以下四个维度：业务类型业务类型业务所在的领域决定了产品底层技术栈的选择。这个很好理解，比如电商这个业务场景所需要的技术栈和产品特点与传统制造、CRM 等所关注的侧重点就完全不一样电商关注高并发、低延时、数据一致性和秒杀场景等等，而传统制造商则对海量多样化数据的处理和如何有效挖掘数据价值这些方面更加关注。在不同的业务类型下，选择一款 HTAP 产品需要重点考察的是这个业务类型需要哪一部分能力为主：TP 能力为主亦或是 AP 能力为主。对于电商系统需要更加注重其在 TP 方面的关键能力，例如：事务、数据一致性等等；而对于 CRM 系统，经销存等等对 TP 能力则不会那么严苛，其可能更加看重 AP 的能力，在 TP 能力满足其基本业务需求的情况下，哪款产品的 AP 能力更强，业务侧可能会更倾向于选择该款产品。而现有 HTAP 产品从技术实现路线上，基本可以分为这么两类路线，其决定产品的基因：即侧重于 TP 还是 AP？路线 1：以成熟的 TP 系统为基础，在其上进行 AP 能力的扩展。现有大部分 HTAP 数据库产品均采用该种策略。为什么采用该种策略？其原因是显而易见的，TP 系统发展到现在其相较于AP 系统，更加成熟。例如：国内外的 OB，StoneDB，TiDB，Oracle MySQL Heatwave 和Google AlloyDB 等；路线 2：在 AP 系统的基础上扩展其处理 TP 的能力。例如：Snowflake 等。这种路线，比较困难，但是成熟的科技公司会有更多的资源去做这个事儿，难度大，但是做出来了，也会是一大利器。端到端的解决方案能力：端到端的解决方案能力：对于业务开发相关人员，一个新产品或者解决方案的引入，自然希望不会给其带来额外的工作负担，并且最好能够与其原有的技术栈相兼容，这样对于原有业务系统的改动要求最少。但也不完全就是为了让干的活儿更轻松一些，因为，对于一个在线运行的系统，其对于稳定性的要求非常高，而新组件的引入往往会让整个业务的不稳定因素增大。因此，如果不能够保持原有的技术栈，则需要提供端到端的解决方案。例如：原系统采用的 ClickHouse 或者 ElasticSearch，如果需要替-54-换为 OB 或者 StoneDB，那么需要考虑原系统 ClickHouse 或者 ElasticSearch 上下游相关模块接口兼容性，数据同步到 CK 或者 ES 的方式等等，这些解决方案都要提供出来。数据实时性要求：数据实时性要求：数据实时性的高低同样也会影响到产品的选择。当前现有的 HTAP 数据库在 TP 和 AP 之间的数据同步策略实现机制不尽相同。例如：有些云厂商通过 MySQL Binlog ClickHouse 的组合方式提供 HTAP 服务，从用户的角度看似乎该服务具备了 HTAP 的能力，但实际上完全不是那么回事儿因为通过 Binlog 这种方式会有很多弊端，又如有厂商通过 TP Redo Raft AP这样的组合构成 HTAP 产品，其相较于前一种在数据的实时性上有了较大的提升，但也只是提供数据的最终一致性，同样数据的实时性还是得不到保证；有的厂商则采用了基于 LSM-tree 实现的行列混存，这种可以基本保证对于数据实时性的要求；而像 MySQL Heatwave 和 StoneDB则提供了基于内存计算的强实时性的方案。HTAP 数据库在产品具体实现的时候，其选择的存储方案会直接到影响架构的选择：是一体化的架构？还是 TP 系统叠加 AP 系统的方案？架构的选择则会直接决定数据同步策略和数据实时性的高低。技术能力：产品背后其公司所代表的技术实力也是业务方选择一款产品的考量因素，例如：我们在下文第六点中给出的观点。（2 2）性能）性能考量完业务场景相关的因素后，接下来需要考量的一个重要因素就是性能。不同于 TP 系的Benchmark TPC-C 或者 AP 系统的 Benchmark TPC-H，对于 HTAP 的性能测评一般不再使用这两个传统的方式来进行衡量。当前大家更多地使用 TPC-H 来对其 AP 的能力进行评估，该种方法可以对其系统有一定的评价作用，但也存在着一定的弊端，那就是 TPC-H 无法全面地衡量一款 HTAP因为 HTAP数据库的系统中会同时存在两类负载：TP 负载和 AP 负载。两类负载需要同时使用系统的 CPU 资源、IO 资源和网络资源等等。对资源的竞争会导致两类负载的相互干扰。因此，为了更好的衡量HTAP 数据库，无论是学术界还是工业界，都逐渐提出了一些适用于 HTAP 数据库的 Benchmark系统。这里也简单提一下，除了具体的性能指标，例如：TPS、QPS、吞吐量等等，资源隔离性也是我们的重要考量。而资源隔离通常有两种方式：（1）通过系统手段（软件）隔离。例如，通过 Cgroup的方式进行资源的管理；（2）通过物理手段进行隔离。例如，依据不同的负载类型 Route 到不-55-同引擎上，将 AP 查询路由到列存引擎节点上，这样可将 TP 负载和 AP 负载运行于不同的节点上，从而做到真正的物理隔离。（3 3）运维）运维运维的难度也需要我们认真考量。数据库的运维不同于其它基础系统，其对于 DBA 的综合素质有比较高的要求。在系统长时间运行的过程中会遇到各种数据库的使用、功能、性能等等问题。解决这些问题除了需要数据库、操作系统和业务等多方面的知识，同样也需要相关运维工具的支持。运维手段和运维工具可以高效的支持 DBA 的运维工作。复杂的系统形态，会导致 DBA 的运维工作量增大，最直接的影响就是难以快速定位问题，增加了解决问题的耗时。（4 4）生态）生态生态是选择一款 HTAP 数据库的一个重要因素。当前有两类生态：PostgreSQL 和 MySQL。选择哪一种生态，会直接影响到后续围绕数据库所构成的整个技术栈。同时，业务也会从其自身的特点选择相应的技术路线。例如：如果业务系统是基于 JSON 和 GIS 能力的话，那么多数的业务开发者可能更倾向于选择 PostgreSQL 生态；如果是电商业务则更多的会选择 MySQL 生态。具体来讲，生态中的周边工具、中间件和解决方案的完整性和丰富性非常重要。除工具、方案外，社区参与的人数（不管是对开源的 HTAP 数据库，还是对于商业或云上的 HTAP 服务，都需要考量该使用该服务的人群数量），更多的社区参与人数往往意味着社区比较活跃，那么，我们使用者遇到的一些问题就可以得到快速的响应。生态的繁荣也从另外一个侧面反映出该技术路线获得了相当多的上下游厂商的支持。（5 5）成本）成本成本是一个无法绕过的话题，一般企业/组织内的管理者对于成本的关注度往往是多于其他项的。如果想要使用一款 HTAP，需要考量的成本主要包括以下几个方面：硬件成本、替换（迁移）成本、运维成本等：硬件成本：硬件成本：其中最主要包括：计算成本和存储成本。在 StoneDB 实际的产品 POC 过程中，遇到很多客户实际的业务数据量在 100GB-1TB 内。如果采用一些现有的其他国产 HTAP 产品，由于这些产品对最小集群有要求，从而使得这些小厂商在使用 HTAP 服务时，必须付出比较高的集群硬件成本，这个是他们不愿意接受的。特别地，当需要替换现有 MySQL 数据库的时候，目前的一些国产 HTAP 数据库，基本都存在 MySQL 语法兼容性的问题，这导致迁移到新的业务系统上需要进行大量的修改，从而造成整体成本的飙升。如果厂商比较在乎这一部分的成本的话，StoneDB就是很好的选择了。-56-替换成本：替换成本：需要能够提供对于原系统的平滑迁移能力。对于业务侵入改动最小，业务无需做修改即可平滑迁移到新的数据库平台。运维成本：运维成本：在第三点中我们讨论运维问题，这里就不再详细讨论了。运维成本将会是系统稳定后，最主要的支出成本。（6 6）LTSLTS 支持性支持性对于 LTS（Long Term Support，长期支持版）支持性，这里又可以从两个方面来讨论。（1）商业 HTAP 数据库（2）开源 HTAP 数据库。无论对于商业数据库还是开源数据库都面临某个版本的生命周期问题。商业数据库相对来说，其售后服务有保障，但同时商业数据库又面临闭源和售后服务需要支付昂贵的服务费用等问题。而开源数据库，其 LTS 的支持除了需要社区支持以外，也需要由其背后的公司来进行保证。我们也很容易发现，一个成功的开源数据库项目背后，通常都有一个成功的商业公司支撑。因此，无论是选择哪类 HTAP 数据库，都需要注意所选择的产品的 LTS 支持性的问题。好了，以上就是我们总结的选择一款 HTAP 数据库需要考量的六大因素，也即：业务场景、性能、运维、生态、成本和 LTS 支持性，希望对于这六点的分析能给大家在做 HTAP 产品选型时提供帮助。3.3.5 5 新一代新一代 HTAPHTAP 在云端重构在云端重构新一代 HTAP 面对的市场需求和技术环境已经发生巨变，理论上，只要 MySQL 和 PG 的交易类应用有实时分析的需求就会需要 HTAP 的能力，随着云基础设施普遍应用，“分布式云原生”正在重构企业数据架构，成为新一代 HTAP 的技术环境。HTAP 最早在 2014 年由分析机构 Gartner 提出，当时主要指以 SAP HANA 为代表的内存数据库的混合负载能力，HANA 快是快，但数据量有限，最大的门槛是“贵且专有”，仅在使用 SAP 的 大企业有少量用户，那一代 HTAP 并没有真正扩展起来，也并没有流行形成趋势。直到最近几年，互联网“海量、实时、在线”的需求越来越广泛，大量采用 MySQL 和 PostgreSQL开源数据库的新一代企业需要提升对于热数据的实时在线分析能力，这类需求遍布几乎所有的互联网企业，从事线上业务的数字化转型企业。电商、游戏、数字媒体、金融科技、网络安全等互联网和数字化业务，对于新鲜数据的实时分析能力直接决定了这些业务的生死存亡，秒甚至毫秒级的低-57-延迟成为他们提升消费者体验的重要手段，实时营销、实时风控等业务诉求变得更加普遍，这种新诉求催生了新一代 HTAP 的共同诉求：一个数据库，一套架构，同时满足 OLTP 和 OLAP 的低延迟数据处理且互不干扰，这个架构 Gartner 定义为 Augmented Analytics，IDC 称为 ATP（Analytic Transaction Processing），Forrester 称为 Translytical Data Platform,可见新一代 HTAP 已经成为三大分析机构关注的焦点趋势。下面重点拿几个 HTAP 代表产品来看新一代 HTAP 技术架构的异同点，他们分别是 GCPAlloyDB,AWS Aurora Parallel Query，Oracle MySQL Heatwave 以及 TiDB。总体来看，虽然各产品的具体实现虽有不同，但新一代 HTAP 架构有一些明显的共性追求：以开源打底，借助了云端扩展性，追求一个入口，一套数据栈，可以将 OLTP 数据和 OLAP 数据实时同步，部分厂商 OLAP 的实现采用了类似 MPP 下推方式，达到 No Application Change、No SchemaChange、No ETL，No data move 的四不效果，最大化减少对应用程序的改动。任何一种数据库潮流都是“需求变化 技术变革 架构创新”三者融合的产物，HTAP也不例外。首先，在需求变化侧，推动新一代 HTAP 的数据库厂商在提到 HTAP 的时候都不约而同地用到 Operation 这个词，借助热数据实现运营级别的实时分析，获得实时的洞察以支持运营动作的反馈，这是推动新一代 HTAP 走上舞台中央的最大需求侧变化。其次，在技术变革与架构创新侧，云基础设施的发展带来了存算分离更为彻底的变化，这是技术变革带来的新可能性，分布式理论与云计算、AI 算法的融合带来了新一代的架构创新，这些都使得 HTAP 在云端可以支持不同的云存储，AI 等新技术，打造更有成本竞争力的创新。第三，这一轮 HTAP 的用户群体和上一代内存数据库 HTAP 的小众贵族非常不同，这一代 HTAP 的用户非常大众化，几乎采用MySQL 和 PG 开源数据库的所有企业都可以借助新一代 HTAP 架构拓展OLTP 和 OLAP的能力范围，都能用上一种不用修改应用，不用增加额外数据系统且拥有强大分析能力的数据库。3.3.6 6 问题问题和和挑战挑战HTAP 是将 TP 和 AP 进行高度融合的产物，而非简单的 TP 和 AP 相加：TP AP HTAP。真正的 HTAP，而非 TP 与 AP 的叠加。（1 1）架构的选择）架构的选择。Single system（即 One system）还是 Seperate system 的选择当前更多是基于工程上的难度。目前不少产品均是在原有的 TP 系统之上，叠加了一个 AP 系统并使用某种数据同步工具将 TP 系统中的数据同步至 AP 系统中。Seperate system 虽然有其优点，但这种方案存在着许多不容忽视的问题，比如无法保证对事务的支持能力、数据的时效性，以及复杂的系统架构等（下文会有详细的解释）。相比之下，One system 不仅架构简洁，对于事务的支持能力和数据的时效性等方面都能提供更好的保证。但是，One system 架构的技术难度相对较大，工程上也具有一定的难度，同时还需要考虑 TP 和 AP 负载间的相互干扰等问题。-58-（2 2）查询处理及数据导入引擎。）查询处理及数据导入引擎。HTAP 数据库首先需要解决的问题是高速的数据载入。全量数据的载入方案，保证海量数据快速准确导入。增量数据的更新方案，保证数据的时效性。（3 3）存储方案。）存储方案。高速存储介质正在广泛地应用到数据库领域。（4 4）数据组织方案。）数据组织方案。选择列存储加行存储（DSM NSM），还是 PAX（Partition AttributesAcross）方案或者是其它方案。系统的整体性价比也是我们挑选产品的重要指标之一。（5 5）事务语义。）事务语义。无论是 TP 部分还是 AP 部分都需要对事务进行完整的支持。（6 6）数据的时效性。）数据的时效性。需要保证 AP 系统所处理的数据均为当前最新版本的数据。（7 7）索引的支持索引的支持。如何能够通过设置索引快速定位到需要更新的数据（尤其是在以列存且数据多为压缩形式的情况下）也是需要解决的一个难题。（8 8）不同类型负载间的相互干扰。）不同类型负载间的相互干扰。系统需要能够保证 AP 负载对 TP 负载无影响或者使得两种类型负载间的影响最小化。4.4.S Serverlesserverless毫无疑问 Cloud 是数据库领域最大的趋势，从 Gartner 的报告可以看出，今年全球企业在Cloud 上的投入已经超过了私有化数据中心的投入，并且每年的增速都非常快。在数据库领域中也有着同样的趋势，2019 年云上的数据库服务（Database as a Service）还不到传统数据库的一半，但在 2022 年几乎接近持平，可以预见 2023 年云数据库的占比一定会超过传统数据库。所以，云是毋庸置疑的趋势，在未来的数据库产品中，Cloud 一定会变成数据库服务的承载平台。4.14.1 数据库走向数据库走向 ServerlessServerless近年来 Serverless 概念的热度相当高，Gartner、Forrester 等知名咨询机构对 Serverless投来关注的目光，AWS、阿里云、腾讯云等云计算大厂也在不断布局 Serverless 相关产品。可以说与 Serverless 的结合，再次为数据库的发展添了把火。那么，Serverless 数据库到底是什么，有何价值？更进一步，Serverless 会成为数据库的未来形态吗？想要理解 Serverless 数据库，就要先了解数据库的发展历程。在早期，用户普遍是自建数据库。作为最传统的数据库应用方式，用户在自己的机房中部署，不仅需要考虑物理部署和运维的方方面面，传统数据库的灵活性和可扩展性也很低，且价格昂贵、维护成本很高。随着云计算的普及，数据库上云成为应用主流。数据库在云上以 PaaS 服务的形态、以租用服务的方式提供，用户不用再关心机房的物理部署。由于这个阶段的云数据库只是简单地把-59-数据库从本地迁移到云端，在架构上并没有做太多改变，因此数据库的弹性依然受限。为了解决这一问题，云原生数据库出现了。由于云原生数据库完全为云设计，让计算、存储资源完全解耦，使用分布式云存储替代本地存储，将计算层变成无状态，从而能够充分发挥云的优势，具备弹性可扩展的特性，让用户不需要担心日常业务扩容问题。但云原生数据库也有自己的瓶颈，即不能按需自动缩放，也不能按更小粒度实现按使用量付费。当用户遇到数据库扩容的突发需求时，就只能根据业务实际使用情况手动调整数据库容量大小。尽管这种方式的确可行，但却会耗费大量的时间和成本。即使是数据库方面的专家，面对波动剧烈的应用，在兼顾性能及成本的情况下，要手动管理数据库容量也并不是一件容易的事情。在此背景下，Serverless 数据库出现了。由于具备完全自动化的扩容能力，Serverless 数据库能够随着用户业务的请求数的增加和减少，智能化的“膨胀”和“缩小”，实现资源的自动“吞吐”。当流量洪峰来临时，可以自动调配资源支持；流量进入低谷时，则可以自动释放掉资源，节约成本。这种能力正是 Serverless 理念的体现，将数据库底层和业务不相关的部分抽象出来，为开发者提供直接的运行环境，让开发者不需要关心服务器基础设施，就可以直接调用函数平台完成函数运行。服务器的逻辑和状态也是由服务提供方管理，服务只有在需要的时候才会自动伸缩，从而让数据库获得了极致的弹性，且开发者不用再为复杂的底层基础设施所困扰。4.24.2 ServerlessServerless 数据库的价值数据库的价值Serverless 概念的火爆，让 Serverless 数据库获得了越来越多的关注。其实从开发者的角度不难理解，为什么 Serverless 数据库一出现就受到了广泛的追捧。一项名为“在你的组织内部到底是谁在选择 Database”的调查显示，架构师、开发者、DBA 三者作为数据库软件真正的用户，日常工作时间中有 41%的时间都在做基础设施维护，如买服务器、部署服务器、运维等等，只有39%的时间在做业务创新。随着数据架构越来越复杂，数据库越来越多，每一种数据库都有一套自己的技术，开发者要学习的东西也越来越多。要解决这种复杂性，释放开发者的生产力，让他们有更多的精力关注业务创新，Serverless 带来的抽象就必不可少。抽象程度越高，开发效率越高。从传统数据库上云到云原生数据库，已经一步步将云基础设施能力以及数据库内核层面能力抽象化，让数据库得以支撑高效的应用开发迭代。如今，Serverless在云原生基础上进一步抽象，可以让开发效率再次提升。Serverless 是云原生走向成熟之后演变出的开发模式，Serverless 数据库是云原生数据库发展的必然结果。对于所有创新的数据库公司来说，如果前两年的门票是云原生，那么今年的门票就变成了 Serverless。-60-在高度的抽象下，Serverless 数据库带来的价值显而易见：第一，创建便捷。第一，创建便捷。Serverless 数据库的创建，用户不需要关心任何部署细节，几十秒内即可一键创建，召之即来，挥之即去。第二，自动缩放。第二，自动缩放。用户不需要考虑基础设施，Serverless 数据库可以根据业务负载变化自动匹配。当业务吞吐达到一定程度，不用再停下来加服务器，系统会自动进行扩展；当业务峰值下降，系统能自动缩回，甚至缩到 0。第三，节约成本。第三，节约成本。Serverless 数据库能够提供更细粒度的计费，按照实际使用付费，不使用则不计费。第四第四，和应用开发体验深度整合和应用开发体验深度整合。在过去数据库只关心性能、稳定性等各种指标，很少从开发者使用的角度来设计。Serverless 的出现，让数据库开始真正从用户角度出发，融入到现代的开发应用过程中，帮助用户更快、更流畅的构建应用。基础设施层面，Serverless 部署的成本变得极低，极致的 Serverless 不用关心任何运维的细节。你可以通过代码和 open API 控制这些集群的起停。在拥有更大规模的基础设施时，这点是非常重要的。Serverless 在处理更复杂或更大系统的时候，能显著减低复杂性；在成本控制层面，Serverless 能够真正按照资源的消耗量来去计费。对于开发者来说，想用数据库的时候，只要招手它就来，不用的时候，也不用给钱，任何时候去访问它，数据都在那儿，也能对外提供服务。在这样的 Serverless 架构下，我们其实还能解锁更多的能力、更多的可能性。举个例子，S3 是 TiDB Serverless Tier 底下重度依赖的云对象存储服务。用过 S3 的肯定都知道它便宜，可用性很高。更重要的一点是数据共享，比如大家都在用 AWS，A 用户用 S3，B用户部分数据也在 S3 上，比如说我想把我的数据共享给另外一个用户的时候，既然都在 S3 上，那共享就变得很简单。以前在私有环境下，你还需要把数据下载出来拷给他，再上传进去，然后才能做分析。如果是在数据量比较大的情况下，这几乎是不可想象的。这种新架构的一种可能性就是真正能够做到 Data Sharing，当然这里面肯定还涉及到包括隐私计算，各种各样的安全性问题。但从技术底层来说，这种产品形态并非不可能了。另一种场景，比如说我想做一个区块链的数据分析应用，但做这样的应用，第一步你得把数据准备好。区块链的数据其实也不小，经常是大几百 GB 或几个 TB 的数据。但如果在 S3 上有一个公共的数据集已经准备好了，那在云上 Serverless 用户只需要在启动的时候，加载这部分数据就好了。这些能力在云下是根本不可能完成的任务。-61-这些能力具备后，数据库的商业模式会变成什么样子？预计数据库作为一个软件形态本身会消亡，而数据库的平台化、微服务化会取代原来的数据库软件形式。今天可以看到几乎所有的数据库厂商，都在云上提供服务，印证了这个理论正在变成现实。展望未来再往前一步，会发展成什么样子？Serverless 其实是云上 Database Service 更进一步产品形态的体现。现在用户可能还需要去关注买多少个数据库节点，买多少个集群，但是在未来，真正从开发者的角度来说，他所关心的应该只有数据操作的 API，这一层才是离业务更近的东西。另一方面，当 Serverless 在云上被提供后，数据共享、交换就变成了一个很自然或者很简单的事情，那时候可能会出现一个叫做 Datamarket 的新商业模式。数据库应该做得更简单，把开发者的体验带回从前。我们应该花更多的时间关注于业务的创新、关注于真正重要的事情，这些复杂的东西，就让它简单起来好了。未来真正重要的东西是什么？是流畅的开发体验。这就是行业终极的前进方向，也是每一个基础软件提供商应有的担当。5.5.湖仓一体湖仓一体分析型数据库的出现可以追溯到上个世界的 70 年代末期，以 IBM 的 Db2 和甲骨文的 Oracle为代表，基于共享存储架构的数据库对业务的处理；早期企业数据分析场景较为单一，业务多源自于管理层固定报表，需被处理的数据均已结构化数据为主。因此，第一代的分析型的数据业务是基于共享存储架构的数据仓库发展的。随着 1984 年 Teradata 推出的基于其专属硬件的无共享架构的 MPP 数据仓库平台开始，企业数据分析平台逐步从少量的报表转变为面向更多业务人员的批处理业务，并以 BI 报表形式进行可视化展示，并将报表数据用于业务的决策。因此，基于无共享架构的数仓仓库拓展出了第二代数据仓库业务。更多的 MPP 类数据库如 Greenplum、Vertica 在分析业务处理上崭露头角，企业需要处理的数据类型依旧是结构化数据，但数据量出现了快速增长，达到了 GB 或 TB 级。随着 2005 年以Hadoop 为代表的数据湖推出之后，伴随着互联网企业的兴起，各种结构的数据逐步被加入了分析平台中，同时被分析数据的逐步增长，除去传统的数据查询、固定报表，第三代分析业务还涌现了大量的面向业务监测和洞察的自助式分析，还伴随一定的时效性要求。通过对近年来数据分析的应用场景、数据以及计算环境等方面的分析，以及现有的分析型数据库在应对这些变化时的不满足，第四代的分析型数据库已经向着增强分析性能、提升易用性、降低使用成本的方向发展。-62-在如此趋势下，Databricks 于 2016 年推出 Delta Lake，旨在在数据湖上支持类似 DBMS的数据管理功能，而随着 Databricks 于 2020 年率先在业内提出 LakeHouse 的概念，湖仓一体概念由此开始兴起。Snowflake 同步推出了数据云产品，在其云上数据仓库的基础上增加了数据湖的功能。亚马逊云科技基于 Amazon S3 构建数据湖，绕湖集成数据仓库、大数据处理、日志分析、机器学习数据服务实现智能湖仓。国内在此技术背景下，同样不甘示弱，星环推出了 ArgoDB 数据库，加强数据湖和数据仓库技术相结合，在同一平台中，避免数据移动，将原始的、加工清洗的、模型化的数据，共同存储于一体化的“湖仓”中，既能面向业务实现高并发、精准化、高性能的历史数据、实时数据的查询服务，又能承载分析报表、批处理、数据挖掘等分析型数据集市业务，实现“湖仓集一体”。星环科技湖仓集一体化的方案可以给用户的业务提供：（1）统一访问接口，最大程度上降低数据湖、数据仓库、数据集市业务过程中业务接口的调整；（2）统一元数据管理，可以在精准的ACL 控制下，实现按需展示湖仓集内的相关元数据的统一查询；（3）统一存储管理，对使用者屏蔽不同数据源的数据存储，降低业务数据管理难度；（4）增强实时数据处理，使得湖仓集业务数据能够得到高效处理；（5）无缝衔接 AI 技术，帮助业务挖掘更多数据价值。图 1：星环科技湖仓集一体化方案6.6.内存数据库内存数据库随着数字化发展，高并发、低时延的应用需求日益增强，客户对信息系统的计算能力要求越来越高。由于摩尔定律减缓及存储能力得到极大提升，传统信息系统的计算力将面临新的挑战。数据库与 CPU、操作系统一直被认为是 IT 领域的三个核心，数据库是关键信息基础设施重要组成部分，是承载与加工数据的关键，如何提升数据库算力以满足数字化时代对应用快速响应的需求也将成为-63-数据库发展的重点。我们知道，在计算机硬件系统中，CPU 最快，一个时钟周期不到 0.5 纳秒，访问内存速度在100 纳秒级别、访问固态硬盘约 50-150 微秒、访问硬盘约 1-10 毫秒。显然，内存访问速度依然快于固态盘、硬盘千倍、十万倍。所以，CPU 直接访问内存是减少 CPU 对硬盘访问、实现数据库应用低时延的有效办法。据统计（https:/年代至今，内存每兆字节的价格已经下降了 9 个数量级，DRAM 内存芯片价格在 2022 年上半年同比就跌了 30%，目前比较便宜的 16GB DDR4 内存仅需 69 元，而这种内存在几年前还是 3、4 百元。由此可见，在数字化应用发展需要更高的算力的同时确保算力提升的重要组成部分的内存，其价格已经在惊人的下降。这两种趋势的并存，不得不让我们相信，充分利用内存技术是提升数字化应用算力的有效途径。内存数据库是一种主要依靠内存来存储数据的数据库管理系统，内存数据库把整个数据库放进了内存中。而传统数据库是使用磁盘读写机制，通过增加内存缓冲池，或者共享内存技术，达到最小化磁盘访问。相较于传统数据库，内存具备更极致的读写速度，性能比传统的磁盘数据库有数量级的提升。从下图可以看出，内存数据库与传统数据库对数据访问是有显著区别的，基于内存数据库的查询，无需判断数据是否已经在内存中，无需在内存和磁盘之间换入换出数据。传统磁盘数据库系统的数据组织、访问方法、查询处理算法的设计都针对减少磁盘访问次数与有效利用盘存储空间，甚至牺牲 CPU 时间来减少 I/O 次数（如查询处理有大量中间数据），而内存数据库的设计则主要考虑如何有效地利用 CPU 的时间和内存空间。图 1：内存数据库工作原理-64-内存数据库充分利用内存技术，极大降低 CPU 访问存储的时延，内存数据库和传统数据库一样，在异常掉电时可以保证数据得持久化。因为，内存数据库仍使用持久性存储在发生故障时提供回退。日志按数据库事务捕获所有更改，数据和撤消日志信息在常规保存点-Save Point 自动保存到磁盘，在数据库事务的每个 COMMIT（等待磁盘写入操作结束）之后，日志也会连续同步保存到磁盘，发生电源故障后，可以像基于磁盘的数据库一样，通过重播自上次保存点-Save Point以来的重做日志，重新启动数据库，正常返回到其上一个一致状态。最近几年，内存数据库技术发展很快，内存数据库技术也趋向成熟。目前比较常见的内存数据库有美国 Oracle 公司的 Timesten、德国 SAP 公司的 SAP HANA，以及国内科蓝软件的 SUNDB数据库等。事实上，SAP HANA 与科蓝软件的 SUNDB 数据库技术上是同源的，但各自都在新的技术路线上进行发展递进。科蓝内存数据库经过多年的技术积累，并会同国内顶尖研究机构进行升级，已经完全融入了国产化信创生态系统。内存数据库特有的内存计算机制可以确保数据库核心事务处理的延时短、交易稳定，从而更加适应交易型数据库需要具备的特性，而这也是国产化数据库的核心难点所在。相对于目前市场常见的分析型数据库，交易型关系数据库技术门槛更高，金融、电信、能源交通等行业的关键领域离不开交易型数据库，这些领域直接关系到我们国家的信息安全。科蓝软件 SUNDB 数据库是 100%拥有知识产权国产化数据库，是我国目前为数不多的高性能、高稳定、高可靠的交易型关系数据库。综上所述，一方面，随着移动互联网飞速发展，高并发、低时延的应用需求强劲，另一方面，内存硬件价格多年来在不断下降，内存变得更加“平民化”，已经不再是“奢侈品”。内存数据库由于省去了磁盘读写的开销，在性能上比基于磁盘存储的传统的数据库有数量级的提升，今后革命性创新的 CXL 协议将使内存数据库的发展优势更加凸显。故此，我们坚信，内存数据库发展是数据库技术发展的趋势，是突破企业关键基础设施算力瓶颈的重要途径。7.7.超融合与流式数据处理超融合与流式数据处理7.17.1 谈传统数据库与流计算模式的有机融合谈传统数据库与流计算模式的有机融合国务院近日发布的 关于构建数据基础制度更好发挥数据要素的工作意见，也被业内称为“数据二十条”，在新二十条的指导下，为充分发挥我国数据规模和丰富应用场景优势，国产数据库面临的挑战，主要有以下两个方面：（1 1）简化融合）简化融合数字化深化带来技术需求的多元化，与之对应的产品方案也呈同样态势。如果能从统一管理的角度简化使用，通过单一平台提供所需能力，无疑对用户非常有吸引力。AntDB 数据库全新推出-65-的超融合架构，在统一框架下，实现了交易、分析、流处理等多种数据处理能力的融合，用一款产品为客户带来“一站式”的数据管理服务。（2 2）实时性）实时性数据更多参与企业决策、驱动业务变化。一些数据在业务发生后不久具有很高的价值，随着时间的推移，数据的价值会逐步降低。因此，数据的处理速度变得尤为重要，实时处理的关键价值之一在于能够更快地提供数据洞察。AntDB 数据库通过内核级的数据流式处理，使传统数据库与流计算模式有机的融合，大幅降低实时业务架构的复杂度，给 DBA、BI 工程师带来便利，进一步减低人们使用数据的门槛。7.27.2 超融合架构，打造分布式数据库新纪元超融合架构，打造分布式数据库新纪元谈国产数据库，必谈分布式与云计算能力。上一个十年，随着国内金融、互联网行业高速发展，带来的数据规模庞大，查询复杂度高、关联度高等业务需求。相比于集中式数据库，分布式数据库具有平滑扩展、高可靠、高可用、低成本等关键特性和显著优点；而数据库等基础软件的服务方式向云化发展，有利于降低数据库运维成本，灵活调度资源。在下一个十年，“数智化转型”是推动经济社会从“量增”到“质变”的快速路。用户对数据库的需求日益精细化，从技术底层支撑多业务的系统架构，将越来越受到企业侧的青睐。在此背景下，多引擎数据库的融合能力开始出现，HTAP、湖仓一体、流批一体等都是这个趋势的先行者，即超融合。图 1：亚信科技 AntDB 数据库超融合框架-66-亚信科技 AntDB 提出了全新的“超融合”理念，即将多引擎、多能力融合在一起，满足企业越发复杂的混合负载场景与混合数据类型业务需求。AntDB 的超融合框架，能够充分利用分布式数据库引擎的架构优势，在 HTAP 概念上进行进一步拓展，将时序存储、流处理执行以及向量化分析等多引擎进行统一架构封装。在同一个数据库集群支持多种业务模型，支持多样化的数据需求，大大降低业务系统的复杂性，实现统一框架下的“一站式数据管理”。7.37.3 流式处理引擎，颠覆流式处理引擎，颠覆 5050 年未变的数据库内核年未变的数据库内核（1 1）流式处理的概念）流式处理的概念2001 年 9 月 11 日，美国世贸大楼被袭击，美国国防部第一次将“主动预警”纳入国防的宏观战略规划。而 IBM 作为当时全球最大的 IT 公司，承担了大量对于基础支撑软件研发的任务。其中 2009 年正式发布的 IBM InfoSphere Streams，就是全球最早真正意义上的商业化流数据处理引擎之一，通过对实时产生数据预先定义好处理逻辑后，随着每一个事件的发生执行相应的处理与判定程序。流式处理机制直接被后期的 Apache Storm、Spark Streaming、Flink 等流处理框架所借用，应用于大量实时互联网类型的业务中，对前方产生的海量事件进行实时预处理。Gartner 在 2022中国数据库管理系统市场指南中，对其定义为：涉及对“事件”（event）的观察和触发，通常在“边缘”采集，包括将处理结果传输至其他业务阶段。流式处理将在未来五年中获得更多关注。图 2：Gartner 对于流/事件处理的定义（2 2）传统部署架构的痛点）传统部署架构的痛点不论 Apache Storm、Spark Streaming、还是 Flink 等流处理框架的设计，都是将目光集中在“处理”本身。由于其自身不具备数据库的能力，当需要与其他数据进行关联、临时存储等互动时，则需要进行复杂的数据抽取。这使得大量的开发人员，还需要编写复杂的 Java/C /Scala代码，用最传统的方式对记录进行一条条预处理，并且还需要经常从其他外部的缓存/数据库中实-67-时调取额外数据进行手工关联，对开发和运维的负担极大。而数据库作为信息的核心载体，在过去的半个世纪中其基本的设计理念完全没有过大的改变，所有对于实时数据处理的能力，都是通过应用框架直接建立在数据库引擎之外的。真正与数据贴合最为紧密的软件产品，在过去的 20 年中并没有充分发挥自己的能力与优势地位。因此因此，数据库融入流式数据处理能力数据库融入流式数据处理能力，是这几年行业中提出的全新课题。亚信科技 AntDB 数据库就是最具典型的代表，可以通过 SQL 触发器对实时数据的处理逻辑与拓扑进行定义，也是国内为数不多的率先研发并具备“超融合 流式处理”能力的数据库。在亚信科技 AntDB 发展的十几年历程中，我们看到运营商大量对核心数据处理加工的业务场景。这些需求中有些能够很容易地使用传统技术满足，但还有一些一定需要采用流式计算等实时处理能力才能支持。（3 3）数据库与流式处理的有机融合）数据库与流式处理的有机融合流数据处理模式与传统数据库的内核设计有着极大的区别。其核心本质在于，传统数据库架构设计中，应用与数据库之间是“请求-响应“的关系，即业务发起 SQL 请求，数据库随即执行请求并返回结果。而流处理内核则是“订阅-推送“的模式。通过预先定义好的数据处理模型，对数据承载的业务“事件”进行处理，之后将处理后的结果推送给下游应用进行展现或入库。因此在流式数据实时处理领域，亚信科技 AntDB 做了大量从零开始的创新性探索与研究，于2022 年底推出 AntDB-S 流处理数据库引擎，彻底将流式计算与传统交易、分析型数据存储进行了融合，让用户可以在数据库引擎内，通过标准 SQL 自由定义数据的结构以及实时处理逻辑。图 3：亚信科技 AntDB 数据库流式处理引擎的基础架构-68-同时数据在数据库内部的流对象、表对象之间自由流转过程中，用户可以随时通过建索引、流表关联、触发器、物化视图等方式对数据进行性能优化、数据加工、集群监控、以及业务逻辑定制。（4 4）功能优势）功能优势技术堆栈简化技术堆栈简化：在实时流事件的处理上，AntDB 流式处理一体引擎将大量的实时数据处理做到数仓内部，更进一步向通用事务靠拢。标标准准SQSQL L定义定义：传统流处理方式对于SQL的处理很弱，还要写大量业务代码，而AntDB-S可以通过统一 SQL 语句进行处理，流的使用上更便捷。统一数据接口统一数据接口：支持流批模式的转换，AntDB 统一超融架构，实现了对外的接口统一，数据的采集与处理无需分开，流批都用 SQL 即可全部搞定。支持完整事务处理支持完整事务处理：传统流处理过程中不支持数据的修改，AntDB-S 支持流处理中对数据的修改和事务操作。实时结果更准确实时结果更准确：通过分布式事务的 ACID 特性，解决实时流数据处理中，数据容灾和一致性的问题，可以精确判断数据故障点，完成流事件的矫正计算和重统计。7.47.4 实时数据平台，快速实现企业全链路实时化实时数据平台，快速实现企业全链路实时化引入数据仓库、数据挖掘、HTAP 等先进理念，通过实时数据应用平台来装载庞大的信息量，进行实时分析处理，克服数据处理过程中的困难，是当下各企事业单位、互联网、金融，政务等行业核心系统建设的重点。AntDB-S 流式数据库可以被应用于实时数仓、实时报表、实时告警、异步交易等业务场景，用户可以通过直接使用简单 SQL 创建复杂的流式数据处理业务逻辑，轻松替代 Apache Storm、Spark Streaming、Flink 等传统流式处理引擎。图 4：亚信科技 AntDB 数据库新一代流式处理引擎-69-譬如说，对于实时统计报表来说，所有的统计指标项都可以通过 SQL 命令做到监测实时变化数据。而对于实时告警来说，所有的告警记录都能够被数据库在毫秒级推送给前端应用，而不需要应用定时从告警表中反复循环查询。在对传统流式引擎替代的过程中，AntDB-S 可以帮助用户节省大量的开发与测试资源，同时数据的安全性与 ACID 也完全依托于其底层的 AntDB 数据库，从根本上保证数据的一致性与安全可靠。除此以外，AntDB 数据库所支持的全部高可用、容灾、多租户、鉴权授权、分布式、事务等能力将会完全被 AntDB-S 所继承，几十倍降低用户对流式业务的开发与维护成本。图 5：亚信科技 AntDB 数据库功能特点7.57.5 典型业务场景典型业务场景实时营销实时营销：实时捕获所需的业务信息和数据，向用户主动推动即时的数据统计和分析服务。风险监测与实时预警风险监测与实时预警：根据不同业务系统的风险监测需要,提供了各自的预警规则，适用于银行、警务、交通、城市安全治理等场景。精细化营销精细化营销：助力行业客户建立营销数据库，以数据挖掘和数据分析的结果为依据使营销过程标准化、高效化。数据共享价值数据共享价值：消除数据孤岛，通过实时数据安全计算，实现多方数据的可用不可见、数据不动价值动，打造智能化、可视化、规范化的数据共享与管理。8.8.云原生数据库云原生数据库“四化四化”权威市场研究机构 Gartner 预测，中国数据库行业将加速增长并逐步向云端迁移。未来四年，中国数据库行业向公有云迁移的速度将超过全球平均水平。2022 年云数据库营收数据将占据数据库整体市场的半数以上。根据 IDC 报告显示，未来四年中国数据库行业向公有云迁移的速度甚至会超越美国。2021 全年中国公有云关系型数据库规模达 15.4 亿美元，同比增长 49%。在云数据库时代到来之际，引领中国云数据库创新的阿里云，再次做好了持续领跑的卡位。阿里云预测数据库整体将向“四化”方向发展：云原生化(资源解耦、Serverless 化)、平台化-70-(基于云构建数据平台能力、OpenAPI 标准化）、一体化（处理分析一体化、离在线一体化、集中分布一体化、多模处理一体化)、智能化(AI for DB 简化运维、In-DB ML 挖掘数据价值)。8.18.1 云原生化云原生化从早期的资源解耦，到现在的无服务化（Serverless）都是云原生化的重要体现。历经十年的发展，目前阿里云已进入 全面云原生深度用云 阶段。全面云化的同时，阿里云数据库与新型软硬件充分融合，例如面向倚天 710、CIPU、飞天操作系统等深度优化，性价比提升达到 30%以上，单位算力功耗降低 60%以上。数据库云化深度赋能用户数智转型能力，驱动云上用户从资源消耗向能力获取转变，加速数据业务上云；推动资源解耦、资源池化、Serverless 等核心能力真正转化为用户的价值。（1 1）OLTPOLTP 数据库云原生化数据库云原生化数据库云原生化最显著的技术架构特征是将一体运行的数据库模块进行拆解。云原生数据库是通过计算存储分离，使用分布式共享云存储替代本地存储；并采用物理复制技术，解决传统云上托管 RDS 的一写多读架构带来的存储无法扩展、binlog 复制造成读延迟大的问题，典型代表为PolarDB 云原生数据库。PolarDB 充分利用计算、内存、存储三层解耦和 Serverless 相关技术，可实现秒级弹性伸缩（2 秒内节点内变配，01000 核全场景无感秒级弹性），集群内保障数据全局强一致且性能线性增长，对比传统架构 Serverless 成本再降低 60%。PolarDB 还利用功能节点（多写节点、分析节点、内存节点）快速转换能力支持多态，满足按需架构部署，可实现跨机，跨区，跨域等多种模式的数据一体化，满足全球部署以及冷热分离能力。（2 2）OLAPOLAP 数据库云原生化数据库云原生化对于 OLAP 数据库，存储计算分离、资源归一化同样是云原生、Serverless 化的基础，典型代表为阿里云 AnalyticDB（以下简称 ADB）。在此基础上，ADB 引入分布式或者单机 Cache 解决带宽的问题；通过计算算子（Shuffle、Scan）分离，读写负载分离，保证性能稳定。对于 Meta、负载均衡、接入层等非计算存储资源进行池化，配合智能化的资源分配策略，实现按需计费及按财务预测计费等，帮助用户最大化降成本。同时利用多云、多租户解决超大用户的资源应用效率提升问题。（3 3）云原生管控技术云原生管控技术云数据库要实现 Serverless、按需弹性、按量计费能力，需要有底层的支撑平台来提供精细化的资源调度能力。为了支撑 Serverless 产品形态，阿里云数据库的云原生管控 DBaaS 在底层实现了实例 CPU、内存的实时（最快至 2 秒内）弹性能力；同时，为了实现跨云、跨平台的统一-71-资源调度，DBaaS 的底层资源调度技术构建了统一化资源调度和交付平台，实现基于 Cgroup、Docker、Pod 运行态上物理机和云原生资源的统一化资源调度和交付的平台能力。8.28.2 平台化平台化阿里云数据库的全新品牌“瑶池”涵括关系型数据库、NoSQL 数据库、分析型数据库、数据库生态工具等版块，包含 PolarDB、RDS、ADB、Lindorm、MongoDB、DMS 等产品家族，为企业提供覆盖实时处理与存储、分析和发现、数据开发与治理的一站式数据管理与服务。数据库发展到今天，必须基于云平台构建具备一站式数据管理与服务能力的数据库产品矩阵，才会有生命力和未来，阿里云数据库平台化的核心就是帮助客户减少业务烟囱。（1 1）一站式管理平台）一站式管理平台为了应对数据管理服务多样性，阿里云数据库结合云平台，构筑了一站式的数据管理服务能力，一站式在线数据管理平台带来的最大变化是企业能够用数据库的方式进行大数据量的管理。DMS统一管理数据库和数据仓库，让数据自由流动。与传统数据集成不同，DMS 可以在源端数据库DDL 或扩缩容等运维变更对链路无感知，并且内置 ETL 能力缩短数据链路，同时还可通过跨库查询将源端数据库的表直接作为数仓 ODS 层参与计算，免去数据物理搬迁的问题，真正实现按需建仓、敏捷分析。DMS 还支持灵活的任务编排和数据开发、报表展示。（2 2）可观测性）可观测性可观测性，随着云原生方向演进，平台组件服务化后，整体业务监控运维和服务调用关系复杂化，阿里云数据库结合阿里云基础设施，基于全球可观测性标准，构建了一整套完善的可观测性方案。通过自动埋点机制，对现有代码库进行无侵入式埋点，最大限度地减少对业务代码的改动。（3 3）OpenAPIOpenAPI 标准化标准化OpenAPI 是云服务开放的重要窗口，没有 OpenAPI 的云服务将很难被客户的系统所集成，既影响了用户体验，也制约了云厂商本身的发展。阿里云数据库制定了一系列 OpenAPI 规范，与国际标准看齐，统一思路来解决各产品线之间 API 设计标准不一，风格混乱，开发不足、不完整，定义以及文档描述不够清晰等。（4 4）平台软硬件协同）平台软硬件协同在软硬协同方面，阿里云 PolarDB 采用了领先的硬件技术，包括使用先进的 3DXpoint 存储介质的 Optane 存储卡、NVMe SSD 和 RoCE RDMA 网络。同时面向新硬件实现了软硬一体优化，打造了贯穿整个 IO 链条各个层次的深度优化软件栈，是云厂商中第一个基于这些先进硬件一-72-体化的存储引擎。如 PolarDB 采用了 Alibaba 自研先进的 Aliflash V5 SMART-SSD，可有效卸载数据压缩、加解密等 CPU 计算负载，提供高性能的透明数据访问，降低软件适配工作量。（5 5）平台安全可信）平台安全可信云平台安全对于用户至关重要，全加密数据库是体现数据库安全能力的关键技术。阿里云在全加密数据库领域属于业界第一梯队，是业界唯一具备跨产品（包括 PolarDB、RDS、AnalyticDB）和多 TEE 架构（包括 Intel SGX、自研 FPGA 神盾卡、Dragonfly Enclave）全加密特性的云厂商，已实现商业化输出。其中自研的领先技术发表于 VLDB、SIGMOD 等数据库领域顶级学术会议，并获得了 IEEE ICDCS 2020 国际分布式计算与系统会议全场唯一的最佳论文奖。在可信存储领域，具备多用户数据可验证能力，通过中心化架构保证了系统的高性能，该特性也已集成至阿里云自研数据库产品 Lindorm 中。8.38.3 一体化一体化近年来，数据库领域出现诸多“一体化”概念，如“湖仓一体”、“流批一体”、“存算一体”、“处理分析一体化 HTAP”等等，其中“存算分离”的分布式数据库架构已经成为云原生数据库架构事实标准。对于“集中分布一体化”，阿里巴巴集团副总裁、阿里云智能数据库事业部总负责人李飞飞表示，“我们的客户并非是 0 或 1 选择，他们需要的是平滑地从集中式到分布式的过渡，根据业务场景和业务负载，可以自动的在集中式和分布式之间进行切换，业务和客户不需要再做痛苦的选择。”目前，阿里云在事务处理和计算分析一体化、集中分布一体化、离在线一体化、多模数据处理一体化、多引擎融合一体化等方面有诸多创新，取得了很好的应用效果。（1 1）离在线一体化）离在线一体化离线的大数据数据仓库与在线的分析型数据库数据仓库融合，我们称之为离在线一体化。近年来随着在线的数据仓库（如阿里云的 ADB）Serverless 能力提升，扩展能力大幅提升，利用 OSS等廉价存储实现低成本化，在保证在线处理能力基础上，集成离线的大数据数据仓库能力，实现一体化融合。在线数据仓库从存储与计算独享节点并行处理以在线查询为主的模式发展为支持离线ETL、在线查询的云原生离在线一体化数据仓库，可以一体化解决数据仓库 ODS、DWS、ADS等各层的清洗、查询需求，做到从业务数据库与埋点同步到离在线数据仓库后，一体化满足客户数据业务需求。（2 2）集中分布一体化）集中分布一体化集中式和分布式结合架构，将 shared-storage/shared-everything 架构（共享存储/共享状态）与 shared-nothing(无共享架构)相结合，可兼顾大多数场景下 OLTP 的高并发处理能力，并-73-支持跨 Shard 数据分片的分布式处理能力。阿里云云原生分布式数据库 PolarDB 在共享存储架构基础上，混合存储层面在云原生共享存储基础上，引入弹性并行计算技术，满足复杂查询的线性扩展性要求。最终，PolarDB 通过分布式、混合存储、智能调度等多项技术，即可以满足业务在单个数据库实例内部实现混合事务分析处理(HTAP)的诉求，也可以扩展为多个实例的分布式架构实现更大规模数据的读写能力。（3 3）多模数据处理一体化）多模数据处理一体化在数据密集性场景中，业务往往需要同时处理结构化、半结构化、非结构化多种数据，而传统使用多种数据库组合解决的方式，存在技术架构复杂、学习成本高、资源碎片化、运维困难等痛点。阿里云云原生多模数据库 Lindorm，在统一的分布式文件系统之上，重点研发了多模一体化存储和处理能力，其能够同时支持宽表、时序、流、对象、时空等多种数据模型，并支持使用统一视图和 SQL 访问进行数据管理，可以大幅提升业务存查多种结构数据的效率。（4 4）多引擎融合一体化）多引擎融合一体化2014 年 Gartner 在报告中第一次提出混合事务分析处理(HTAP)，以打破 OLTP 和 OLAP 之间的隔阂，既可以应用于事务型数据库场景，亦可以应用于分析型数据库场景，实现实时业务决策。近年为满足混合事务分析处理(HTAP)的述求，HTAP 数据库应运而生，OLTP 和 OLAP 数据库均通过弥补其不足，实现 HTAP 能力，但较多场景下，OLTP 和 OLAP 从架构设计层面会存在“鱼与熊掌不能兼得”的情况，只能通过损失性能或其他能力实现 HTAP 兼容。今年 AWS reinvent2022 亚马逊利用 Aurora 和 Redshift 结合，实现跨产品 HTAP 能力，用户层面实现统一入口，实现无感 HTAP 数据库融合，带来全新 HTAP 体验。Oracle 也退出了 OLTP 和 OLAP 数据库融合一体化方案，国内厂商阿里云数据库利用 PolarDB 和 ADB 实现数据库融合一体化，给用户带来极致性能，无感 HTAP 一体化体验，提供多引擎融合同步查询，统一计费等能力。8.48.4 智能化智能化智能化的范畴很大，阿里云数据库强调将智能化与“一站式数据管理与服务”融合：一是融合AI 能力的数据库自治服务，提升运维效率与体验；二是数据库内置机器学习功能，无需移动数据即可进行模型训练、生成推理和预测，目标是让数据库“更好用“。围绕上述方向，以功能，运维和内核的智能化为手段，结合分布式系统的最新进展，通过不断技术创新，呈现给用户智能化的数据库，让用户解放脑力与体力，轻装上阵，“八仙过海，各显神通”。（1 1）AIAI forfor DBDBAI for DB 的代表产品为数据库自治，目标是简化数据库的运维。自治技术基于全量 SQL 的-74-大数据能力，深度融合人工智能和专家经验，形成可观测与可控制的自闭环。实现实时异常检测、案例中心、异常自愈、自动优化、智能调参、自动弹性、智能压测等自治能力。目前已经基本实现主流引擎全覆盖（关系型、NoSQL），覆盖度业界领先，并具备差异化优势。（2 2）DBDB forfor AIAIDB for AI 的产品方向为 In-DB Machine Learning，目标为挖掘数据价值。精选和数据库应用紧密相关的 AI 场景，把相应的 AI 支持作为数据库内置服务能力，统一且简化数据和模型的存储，AI 的运维管理和服务。阿里云目前已支持的产品形态包括 PolarDB for AI 和 Lindorm in-DB 时序分析，利用数据库引擎内置 SQL 语法支持，SQL 抽象屏蔽繁杂数据流转过程等技术，满足客户日益增长的数据价值挖掘需求。9.9.多模数据库多模数据库随着业务数据量不断增长的同时，数据结构也变得越来越灵活多样，数据不再局限于规整的结构化数据，半结构化、非结构化数据在数据域处理中的占比逐年上升，因此对不同模态的数据进行智能化数据处理的需求越来越迫切。中国信通院在数据库发展研究报告（2021 年）中指出，在后关系型数据库阶段，数据结构越来越灵活多样、业务类型越来越复杂多变，为应对此类现状，越来越多的用户选择通过多模型数据库实现“一库多用“，将各种类型的数据进行集中存储、查询和处理，满足对结构化、半结构化和非结构化数据的统一管理需求。此外，中国信通院在数据库发展研究报告（2022 年）中再次将多模数据管理列为九大数据库关键技术之一，报告中指出，随着理论创新和技术突破，以及新场景、新应用的不断涌现，数据库经历了层次、网状、关系、对象、键值、文档、图等数据模型的发展，当前多模数据管理得到广泛关注。图 1：多模数据库发展历程-75-Gartner 对多模数据库的定义如下，多模数据库是指在一个数据库管理系统中包含了多个数据引擎，关系型和/或非关系型(例如文档、图、键值、时序、宽列)。它们为不同的持久性类型提供了一种通用的访问机制，每种持久性类型都针对所使用的数据的性质进行了优化。在 2022 年Gartner 发布了中国数据库管理系统供应商甄选，列举了中国数据库市场的 48 位供应商候选名单，并将每个厂商的产品按照关系型和非关系型/多模两大类 8 个细分子类进行归类，帮助中国市场企业用户更全面地了解各厂商及其产品情况。在多模数据库领域，星环科技 ArgoDB、阿里云Lindorm、武汉达梦 DMCDB、巨杉数据库 SequoiaCM 四款产品上榜。多模数据库支持灵活的数据存储类型，将各种类型的数据进行集中存储、查询和处理，可以同时满足应用程序对于结构化、半结构化和非结构化数据的统一管理需求，大幅度简化运维，节省开发成本。国外比较有代表性的多模数据库主要是以文档存储为主的 MarkLogic、ArangoDB、CosmosDB 等，国内也逐渐涌现选择多模技术路线的数据库产品，如上面提到的星环科技 ArgoDB，基于多模型统一架构，实现了多模数据库的“四个统一”：统一的 SQL 编译引擎、统一的计算引擎、统一的存储管理系统和统一的资源管理，支持关系型存储，宽表存储、搜索引擎、事件存储、图存储、键值存储、时序数据存储等 10 种数据模型，满足多种数据模型处理场景和复杂业务需求。例如在反欺诈场景中，传统反欺诈解决方案由于不同数据模型分散存储在不同的数据库（例如关系型数据库和图数据库）等原因，在实际业务中需要大量数据转换操作，应用实施成本高，实时性有待提高。ArgoDB 可将关系型数据和图数据库进行统一存储，用户只需通过一个 SQL 即可关联查询分析关系型数据和图数据，在数据免搬迁、减少人工操作的同时，提升业务效率。图 2：星环科技 ArgoDB 与传统跨模型分析应用方案对比-76-10.10.时序数据库时序数据库数字中国发展报告（2021）和“十四五”数字经济发展规划等政策对数字技术自主创新、加强数字基础设施建设等信创和信息安全的指导意见，强有力地支撑和推动了作为信创产业核心品类数据库的新一轮国产替代和发展浪潮。而随着大数据时代逐步走向成熟阶段、多模数据存储一体化逐渐成为大趋势，不同类型数据的存储、处理与分析技术也在逐步细分化发展以实现广度上的统一融合与深度上的持续挖掘，使得专业的应用场景能够持续以点精准突破从而带动面的发展。随着物联网、车联网和工业互联网等的迅速发展，各类应用产生的时序数据量呈爆炸式增长，并具有海量性、关联性、时效性、实时性等特征。尤其是在工业互联网领域，工业和信息化部近 2年印发了一系列发展规划，例如在工业互联网创新发展行动计划（20212023 年）中提出，到 2023 年，我国工业互联网新型基础设施建设量质并进，新模式、新业态大范围推广，产业综合实力显著提升；新型基础设施进一步完善、融合应用成效进一步彰显、技术创新能力进一步提升、产业发展生态进一步健全、安全保障能力进一步增强。据中国信通院统计分析，截止 2022 年 6 月，全球时序数据库有 51 个,在非关系数据库中占比 18.2%。根据 DB-Engines 官网数据库流行度曲线显示，在过去 2 年里，时序数据库流行度高居榜首，可见市场对时序数据库的关注和相应需求的迫切。在墨天轮数据库流行度排名中，截止2022 年 6 月底，中国有 36 个时序数据库产品参与排名。由此可见，时序数据库正处于高速发展阶段，时序数据技术逐步走向成熟，竞争激烈。图 1：DB-Engines 近两年各模型数据库流行度趋势图-77-时序数据库作为非关系型数据库中的细分类型，且基于国家政策与行业发展在物联网和金融数字创新领域的持续推动与强劲需求，当前已逐步成为重点发展和首要突破的对象之一。尤其在金融行业，大量时序数据每分每秒都在呈指数级增长，且随着更多金融市场参与者逐步推进数字化进程，更多种类的时序数据也在不断地增加，因而对高并发的数据写入、多维度的海量数据存储以及多类型的高效数据处理、分析与计算要求日渐提高。时序数据库有几点重要的技术发展方向，如具有分布式架构，能够灵活扩展，以满足海量时序数据库的存储和计算要求；超高的数据压缩能力，大幅降低企业硬件存储成本；更强的数据导入、存储和计算性能，并且基于分布式特性能够线性扩展，以满足更大数据量、更高的分析要求；此外，为了更高效的满足多种应用场景，需要能够支持丰富的 API 接口，如支持 C 与 Java 语言开发接口，RESTful API 等，并且能够支持包括 OPC-UA/DA，MQTT 等多种标准化通信协议，从而更好地支持多样化端传感器的数据采集工作，像在金融量化领域，还需支持 Python API，并提供了对分布式文件系统格式数据的读取与入库支持，极大降低了从数据层到应用层的数据流转技术门槛，使更多的金融领域数据工作者能够快速上手。国外比较典型的厂商有 InfluxDB，Kdb 等，国内代表的厂商有如云厂商腾讯云 CTSDB，涛思数据 TDengines、智臾科技 DolphinDB 等。其中，涛思数据和智臾科技是专门做时序数据库的厂商，也有如阿里云 Lindorm、星环科技 ArgoDB 这种多模数据库来支持时序数据的存储计算，此外，星环科技也推出了单独的分布式时序数据库产品 Timelyre，基于星环夯实的大数据技术底座，针对金融行业对海量、高频的时序数据存储、处理和分析以及大量衍生因子的计算、策略回测的需求，通过严谨的技术框架搭建与灵活、高可用的语言体系支持，支持高吞吐实时写入、时序精确查询、多维检索等多功能时序数据库产品，可以有效支撑金融量化场景中海量因子计算、复杂策略回测的场景。11.11.实时数据库实时数据库和通用数据库不同之处在于，实时数据库技术不止是数据库，而是工业技术、实时技术、数据库技术以及先进的 IT 技术深度融合的产物，是一套包括数据采集、数据存储、数据计算和数据可视化的工业数据管理系统，管理工业数据从生产到应用的全生命周期，是工业信息系统的工业数据管理底座，是工业数字化、信息化和智能化的基础核心基础软件。11.11.1 1 实时数据库是工业数字化建设的核心实时数据库是工业数字化建设的核心实时数据是工业名词，统一表示强实时属性工业系统、过程或行为随时间变化的数据。作为数据库系统发展的分支之一，实时数据库主要但不限于不断更新的快速变化的实时数据及具有时间限制的工业事务处理。因此，和其他通用数据库不同之处在于，实时数据库技术不止是数据库，而是-78-工业技术、实时技术、数据库技术以及先进的 IT 技术深度融合的产物，是一套包括数据采集、数据存储、数据计算和数据可视化的工业数据管理系统，管理工业数据从产生到应用的全生命周期，是工业企业信息系统的工业数据管理底座，是工业数字化、信息化和智能化的基础核心软件。实时数据库专门解决工业实时数据采集、存储和应用问题，融合各种先进技术和优化架构设计，通过提高效率来处理大规模实时数据的同时带来系统性能的提升，包括更精准的数据采集、更高的容纳率、更快的大规模查询、更好的数据压缩以及更有效率的数据应用支撑。图 1：实时数据库简介新一代实时数据库管理系统创新融合了工业数据采集技术、中断触发技术、自动化控制技术、内存库技术、关系库技术、行列存储技术、多核并行技术、安全通信技术、高效实时检索技术等等，在国外垄断的核心技术领域突破了卡脖子重围，实现了完全的自主创新，通过用户共创，完成了大量实践和长期检验，在提高工业数据管理能力的同时，为企业数字化、信息化和智能化做出了重大贡献。11.211.2 实时数据库发展历程实时数据库发展历程实时数据库最早期的研究始于上世纪 80 年代的英国，四十余年发展过程中，经历了早期实时数据库、标准实时数据库、新一代实时数据库三大阶段。早期实时数据库阶段（1980-2000）的实时数据库代表产品为西门子、ABB 等工业自动化厂商，该类产品当时较好地解决了生产线实时数据采集、就地存储的问题，但在厂级异构数据采集、数据汇总集中和海量数据容纳、大规模复杂查询及灵活数据应用支撑方面存在明显不足。标准实时数据库阶段（2000-2020）以 OSI、Instep、庚顿数据、麦杰等为代表，该阶段技术脉络逐步清晰、解决方案架构趋于稳定、应用领域极大丰富，进一步拓宽了数据采集范围，同时极大提升了数据容纳能力和支持复杂业务的查询计算能力，成为以流程工业为代表的生产监控领域-79-标准配置。中国实时数据库起步较晚，但 21 世纪初由于国家层面将实时数据库作为与操作系统同一级别的软件鼓励支持，同时赶上了 20 余年来中国流程工业声势浩大的信息化浪潮的推动，中国实时数据库产业得以快速高质量发展，以庚顿数据为代表的实时数据库厂商开启了新一代实时数据库阶段（2020 至今），该阶段由于数据规模爆炸增长、数据采集难度提高，工业企业深水区的数据应用进入全面数字化和智能化阶段，大型工业集团化应用日益增多，工业企业生产连续性、工业安全以及智能化应用需求不断提升，实时数据库技术路线呈现多样化和融合化发展。随着全球市场格局剧烈变革，工业数字化转型不断进入核心业务深水区，我国工业企业进入通过新型工业技术和数字化技术实现高质量和低碳化发展目标的发展新阶段，5G、云计算等新兴技术快速发展，传统实时数据库的应用系统纷纷优化升级，我国实时数据库产业正在迎来重大发展机遇。11.311.3 实时数据库关键技术研究现状及问题实时数据库关键技术研究现状及问题实时数据库管理系统作为涵盖工业数据采集、数据管理及数据应用的软件系统，其整体架构与技术路线不断深化发展，在端云采集同在、集控式与分布式并存、边缘计算与云平台共处等应用趋势驱动下，国内外在海量数据存储机制、实时事务管理策略、分布式并行处理技术等关键技术领域的研究一直火热，其理论更为成熟，实践场景更为丰富，以流程工业为代表的核心应用领域成果尤为突出。（1 1）海量数据的存储机制海量数据的存储机制实时数据库包括内存数据库和历史数据库，内存索引机制和外存索引机制必须深度融合才能真正提升读写性能，满足不断升级的应用需求。ARTs_EDB 系统提出兼有 AVL 树和 B 树优点的 SB树作为其内存索引机制，并利用基于时间点的方法实现了一种新的时态索引技术。GDREAL 实时历史数据库针对性能瓶颈，提出新的储存机制Z 树，有效提升了磁盘存储性能。由于高效的查询算法对于内存实时数据库的性能至关重要，专口面向工业控制领域数据和业务的哈希索引算法及接口设计具有更强的适应性和更高的效率。此外，考虑到实时数据库基于测点的存储结构特征，综合 B 树与哈希索引与一致性哈希索引的方法能够有效提升数据查询效率。实时数据库在组织存储文件格式时，极其重视数据压缩算法的研究，以应对实时数据库在生产环境面临海量数据存储的挑战。在实时数据库领域中，数据压缩技术主要有两类,无损压缩和有损压缩。无损压缩以通用压缩理论为基础，采取哈佛曼算法等经典的压缩算法，如 InStep 公司的eDNA 实时数据库；而有损压缩则更多地考虑了工业实时数据的特征，采取特殊舍点的算法，著名的有损压缩算法是 OSI 公司的 PI 实时数据库使用的旋转门压缩算法；麦杰数据库在时间维度上-80-有更全面考虑，综合定制采样频率、例外报告、和矢量线性压缩三种措施；庚顿数据将数据压缩划分为存储前的定制采样频率、例外报告，和存储后死区压缩算法、可行域有损压缩算法（自研）、两阶段无损压缩算法，综合压缩比超 1000:1。此外，低成本的存储是实时数据库需要解决的一个主要问题，对数据进行分级存储，从使用不同存储介质，以及减少数据的副本数等方面，解决如何在保证数据查询性能的前提下，降低数据的存储成本。对于实时数据库来说，多级存储表示：CPU 寄存器-内存-SSD 固态硬盘-HDD 机械硬盘-磁带/光盘存储，实时数据库把各种不同存储容量、存取速度和价格的存储器按照层次结构组成多层存储器，并通过管理有机的组合成为一个整体，使所存放的数据按照时间层次分布在各种存储器中，同时随着数据不断增长将数据从高速存储向低速存储持续迁移，在每一级存储可以挂载多存储路径，实现存储空间的在线扩容。近年来非易失性内存等信息存储硬件开始普及，基于这类新型硬件的实时数据库的内部处理逻辑、算法等需要重新设计，实时数据库技术可借此进一步发展和完善。（2 2）实时事务的管理策略实时事务的管理策略事务是指必须原子地执行的一个或多个数据库操作的集合，集合中的所有操作或者都执行，或者都不执行。实时数据库的事务则兼具传统数据库事务与实时任务两者的特征，必须同时实现数据一致性和定时限制。因此，实时事务的管理策略与传统事务存在显著差异，通常包括事务调度和并发控制两项内容。事务调度的目标是满足定时限制事务的比率最大化，即让尽可能多的事务处理在截止期之前完成。目前国内外的实时数据库中最为常用的是基于优先级的事务调度策略，包括基于事务截止期来指派优先级的截止期最早最优先策略、基于空余时间（事务可推迟执行的时间估算）来指派优先级的空余时间最短最优先策略、通过价值函数来指派优先级的价值最高最优先策略、通过价值密度函数（事务期望化值与所需执行时间的比值）来指派优先级的价值密度最大最优先策略、基于事务执行历史日志的调度策略和广义截止时间最优策略等。上述事务实时调度策略有着各自的化势应用场景，但是能够结合国防军事领域特点的事务调度策略研究则相对不足。并发控制的目标是通过规范多个并发事务的执行顺序来避免它们之间的相互干扰，防止数据库状态一致性的破坏。实现并发控制的传统技术包括锁协议、时间戳和有效性确认其中两阶段锁是最经典的锁协议之一，但是在基于优先级的事务调度过程中会产生“优先级倒置”等问题。为解决上述问题，高优先级两阶段锁对传统的两阶段锁协议进行了改进，在发生“优先级倒置”时能够中止低优先级事务而确保高优先级事务及时获得相应资源。分布式环境下的并发控制（分布式锁）目前尚没有特别高效的方案，国外分布式系统已经广泛应用的算法和实现包括 Paxios、Raft、Zookeeper 等。-81-（3 3）分布式并行处理技术分布式并行处理技术在当前最流行的分布式框架 Hadoop 中，不同的调度算法对于其性能有极大的影响。目前常用的作业调度算法主要包括先进先出调度算法、公平份额调度算法和计算能力调度算法，其中应用得最广泛的是先进先出调度算法。支撑 Hadoop 框架的两个核心技术是源自 Google File System的 HDFS 和 MapReduce。MapReduce 模型适用于批量处理任务，但计算实时性不高。对于实时计算任务，流式计算框架拥有更为针对性的设计，典型地包括 Twitter 公司开源的 Storm 框架、Linkedi 公司开发的 Samza 框架和 UC BERKELEY 大学研究的 Spark 流式框架。用于分布式环境下实时性要求严格而计算精确度要求稍低的应用场景。然而，工业领域有着丰富的数据查询与处理场景，例如流程图监控页面的实时数据展示，面向报警管理与优化的数据挖掘分析等，需要系统能够同时提供分布式查询、实时订阅、实时与非实时并行计算等多种能力。如果简单地将上述并行处理技术进行集成和拼装，而缺乏对流程工业数据处理场景的深入分析，将导致系统复杂而低效，无法满足应用的实时性和可靠性要求。因此，该方向尚存在大量研究工作有待开展。分布式实时数据库的服务橫型包含分布式存储服务、分布式计算服务和网络通信服务三大分布式服务群。同时，基于工业互联网的跨地域数据传输与服务接口访问使得分布式实时数据库的开放性日益提升，信息安全问题也逐渐成为分布式实时数据库系统设计过程中必须重点考虑和投入的方向，对应的网络信息安全和用户访问认证技术成为隔离系统外部和内部的重要安全屏障。除此之外，组态管理服务用于对系统组态配置信息和工厂模型信息迸行统一管理和发布。事务管理服务参与全生命周期流程，将全局任务与分布式服务节点进行紧密连接，确保任何涉及多服务节点的任务能够完整、有序、正确地执行，并在调度过程中尽可能满足其实时特性。进入二十一世纪，随着国家鼓励发展实时数据库等基础软件的鼓励以及数字化转型、双碳目标等国策的出台，国内实时数据库系统研究和应用不断深入，国产实时数据库软件取得长足进展，其功能和性能在电力、化工、冶金、烟草、军工、新能源等众多行业的重大项目中不断得到验证，逐步实现了对国外软件的赶超。虽然实时数据库管理系统属于核心基础软件，但目前大部分国产实时数据库软件针对自主可控CPU 和操作系统进行优化不足，软件在一些功能的技术实现上使用通用但更依赖 CPU 计算能力的方法，CPU、IO 设备等硬件能力不足。因此，如果想要真正满足大工业市场海量传感器数据实时存储和处理的需求，尤其核电应用等态势感知、装备运行状态监控等高级数据应用领域的特殊需求，目前大部分国产数据库管理系统还需要更进一步。针对以上问题，以庚顿数据为代表的实时数据库厂商例近年来不断突破创新，海量顺序和乱序数据的高性能写入、海量实时和历史数据的原始及聚合查询、广泛适配国产硬件设备和操作系统以及如何实现实时数据库更高可靠性和安全性等领-82-域均进行了大量深入的研究与创新应用，取得了丰硕的成果和市场回报。11.411.4 中国实时数据库市场发展趋势中国实时数据库市场发展趋势对大型工业企业而言，精准、快速掌握数字化转型进程中产生的各种数据和信息，可以进一步保障生产稳定、业务优化、设备健康和能耗降低，而这些正是企业获得高质量发展的关键驱动力。充分发掘工业数据价值的企业，才能最大限度释放工业数据生产力，帮助工业用户在激烈的市场竞争中抢占主动、获得先机。随着 5G 技术、高性能电池技术的发展和低成本传感器的普及，工业数据呈现爆炸式增长，流程工业的工业数据资源日益丰富，但企业对数据的掌握和应用没有跟上数据增长的速度，大部分工业数据并没有得到有效的共享和利用，数据收集和整理的时间占比过大，真正被发掘并运用到企业的日常运营中的数据不到三分之一。因此，流程工业迫切需要海量工业数据的整体解决方案，更加高效地、精准地、实时地采集需要的工业数据，同时对这些数据进行整合分析并及时共享给各业务部分的数据使用方，以期创造更新的增长极。数据已然成为现代流程工业数字化转型的核心，真正实现工业数据的采集、存储并帮助建立工业数据分析和应用平台挖掘工业数据价值，成为驱动实时数据库行业面临的挑战和机遇。实时数据库开发的理念是为了实现工业监控及工业数据分析应用，其数据读取以及存储压缩能力作为核心功能一直在升级迭代。为满足工业企业更高标准要求，突破原有应用场景限制，开辟新的增量市场，实时数据库厂商需要在技术层面上需要实现更多种信息技术的深度融合，尤其要和边缘计算结合互补；为了降低企业应用难度，提升使用感受，需要高度统一协议接口，进一步提高系统一体化水平。（1 1）融合与统一，实时数据库技术创新不能停融合与统一，实时数据库技术创新不能停与各类信息技术的高度耦合，边缘计算将算力下沉。实时数据库当前采集频率已经突破毫秒级，超越了多数设备数据采集需求的上限。虽然性能已经达到单体设备采集标准，但是设备数量未来几年将快速增长，与物联网、云计算、边缘计算等不同技术横向融合是提升自身价值的重要途经，其中以边缘计算与实时数据库的相关性最强。当数据过于庞大，集中化的处理方式很难响应实时的数据分析需求时，需要通过边缘设备实时响应的处理并反馈，采取这种分级处理的方式能够有效提升时效性数据的价值，同时减轻存储系统的负担。尤其在离散制造业当中，行业碎片化程度高且呈横向分布，应用边缘计算技术可以更契合离散制造系统实时工业软件开发。-83-图 2：实时数据库的技术创新系统一体化程度提升，软件协议接口统一化。硬件上，设备由企业采购，但是不同品牌的智能制造设备数据测点反馈的数据真实性、时效性会略有不同；软件上，目前不同实时数据库产品适用的开发平台或多或少存在限制，接口标准众多难以高度统一，激化设备和软件数据对接问题。对实时系统的一体化成为企业、设备提供商、实时数据库提供商的统一需求。（2 2）更强大，更成熟，实时数据库产品升级迫在眉睫更强大，更成熟，实时数据库产品升级迫在眉睫功能升级，应用场景增加。实时数据库目前主要还是应用于传统大型工业例如火电厂、核电厂、炼钢厂等，这些行业实时数据的并发量和处理量已经处于金字塔顶端，印证了实时数据库核心功能已经具备“向下”兼容的能力，例如汽车、家具、食品等行业。可结合云平台技术，突破现场控制监控的瓶颈，赋能于更多的场景当中。最大程度实现工厂自动化生产，实现无人化“黑灯工厂”减少企业人力成本，提高生产效率。更完整成熟的实时数据库产品。相较于通用的时序数据库，完整的实时数据库产品更适用于工业制造领域。制造业企业与互联网公司相比，缺少专业研发优化人员，更多是使用者的身份，对产品的首要需求是高稳定、可维护。工业智能生产采用的架构比较类似，拥有相对成熟的体系，标准化、成熟度高的实时数据库产品更契合工业需求。成熟的实时数据库产品需要提供标准的数据挖掘模式，对于基本的过程参数、不同工序之间一些标准的产品无需企业进行进一步开发应用。-84-（3 3）市场规模急速膨胀，资本进入最佳时机市场规模急速膨胀，资本进入最佳时机中国工业实时数据库市场经历了二十多年的发展，至今一直处于稳步增长状态，但是增速较为缓慢，应用动机基本出于行业领头企业“尝鲜”使用、制造标杆工厂的想法，未能得到深度开发应用，但是在工业数字化从口号进阶至国家重要发展方向后，给市场注入一阵强心剂。工业场景中，80%以上的监测数据都是实时数据，过去企业没有重视保存历史数据，如今对数据价值挖掘及应用的需求和实际使用的情况之间存在巨大缺口，市场有很大上升空间，预计至 2025 年达到 269亿元的规模。以数据为核心竞争力的意识将在制造业中蔓延渗透至大大小小各个细分行业，未来大量应用实时数据库成为必然趋势。（4 4）产品国产化替代大势所趋产品国产化替代大势所趋随着大数据时代的来临，数据成为企业的重要战略资源，数据的隐私性和安全性是企业在选择实时数据库时的重要考量因素。特别是工业数据，具有其他行业不具备的特征。与互联网大数据不同，工业数据虽然规模庞大，但是大多为有效数据，数据价值密度高，对企业而言具有绝对的商业价值。工业数据主要来源于各类传感器设备对环境和生产流程的监测，多种类数据并发量巨大，数据类型异常庞杂。工业制造是国家发展的重要依靠，特别是在高精尖领域，对数据泄露采取零容忍态度，数据机密性强。中国实时数据库研发起步较晚，初期阶段更多借鉴国外的优秀技术和经验，导致海外品牌在中国市场中占据了先机。近几年在产品性能方面，本土产品奋起直追，甚至实现弯道超车，却在营销层面存在薄弱环节，暂未打破垄断局面，但海外产品灵活性不足及数据隐私两个主要驱动因素暗示着国产化替代浪潮的到来。在保证数据安全的前提下使用性能优秀、维护便捷、成本更低、接口协议更开放的产品是每一个理性的中国企业都会做的选择，本土化产品的迅速崛起让中国企业看到了新方向。（5 5）头部效应驱动实时数据库再上层楼头部效应驱动实时数据库再上层楼工业实时数据库不同于时序数据库等通用数据库，在生产线的运行时间可长达数十年，且价格高昂，是企业实时系统的核心构成。在初期选择阶段企业会进行再三考量，安装使用后不会轻易更换。替换周期长、成本高或造成未来市场产生头部效应。对实时数据库有迫切需求的更多是中大型工业企业，产品应用一步到位和可持续运行是首要考量因素。实时数据库未来的市场将属于拥有绝对产品竞争力的优秀企业。但目前市面产品质量层次不齐，市场中得到认可的产品来自十几家不同的实时数据库企业，由于缺乏统一的对比标准和长时间的调教优化，部分国产产品在基本功能上仍存在缺陷。例如在数据点采集存储方面，不少厂商在数据采集过程中存在数据不稳定、数据断包的现象；服务器兼容性、-85-可靠性和稳定性不足，导致经常性停运维修；数据检索能力弱，进行历史数据定位提取时发生目标属性类型不匹配的情况。实时数据库是典型的长期主义市场，爬坡周期长，产品成熟慢，用户共创程度高，成熟稳定性要求高，需要不断优化调节和岁月的沉淀。研发具有自主知识产权的实时数据库系统具有重要的意义，实时数据库系统的设计与结构的开发尤为重要，开发流程繁琐，需要时间的沉淀来对产品进行反复的优化调试。前期设计开发包含概念结构设计、逻辑结构设计、物理设计，对接入层、存储层、计算层、平台层以及应用层多层面的开发。后期运维调试阶段，则需要根据行业特定需求进行实时数据库优化调整，产品的成熟度与工程支持人员的专业度及工业知识沉淀程度决定维护调试周期的长短。12.12.图数据库图数据库1 12 2.1.1 背景背景图数据库是一种使用图结构对数据进行查询和存储的数据库。目前，主流工业级图数据库是以属性图形式存储图数据。属性图的图结构由点、连接点的边以及点和边所拥有的属性构成。使用图结构可以更加灵活地对客观世界数据进行建模。图结构中的点可以用于关联客观世界的实体，客观实体属性就可以作为点的属性；图结构中的边可以用于表征客观世界实体之间的各类关系，客观关系的属性则可以作为边的属性。为应对数据快速增长对图数据库查询和存储性能上带来的挑战，主流图数据库都是基于分布式架构设计实现的。根据多家行业研究机构的历史数据和分析，图数据库的受关注程度和热度基本呈现上升趋势，图数据库技术的发展也正在经历去泡沫化并向健康发展的阶段过渡。国内外众多行业也在陆续布局图数据库的应用，并且在未来几年内，图数据库技术还会吸引更多企业、公司进行业务应用方面的投入。在国内，图数据库发展势头迅猛，主要受到几个方面的影响。首先，国家持续推动各行业、领域进行数字化转型，并且大力推动、支持技术领域自主创新，从而摆脱国外技术“卡脖子”的困境。国家的政策强有力地激发国内企业对于图数据库这项新兴技术的投资和研发，并不断激发各个行业、领域对于图数据库技术的应用探索；其次，图数据库作为一项新兴的数据存储管理系统，因为其灵活的建模能力和优异的关联关系查询性能，尤其是在诸如政府、金融、通信、推荐、社交等对海量数据分析需求旺盛的行业或领域受到了较高的关注和应用，极大地推动了图数据库技术在国内的认知和应用程度。在国际环境不稳定的大环境下，图数据库厂商也在积极响应国家自主创新的号召，不断深耕领域技术，持续突破技术难关，为自研技术打好稳固的地基。星环科技结合自身大数据技术储备，通-86-过自主研发，不断打造优质产品，为用户提供优质服务。StellarDB 图数据库作为其大数据平台生态中的一个重要组成部分，同其大数据平台一同适配多种国产软硬件，加强技术自主可控能力。政府机构、金融行业、通信行业、交通行业等若干类行业中，部分业务呈现出数据量增速快、增量大的特点，并且这些行业还具有基础数据量大的特点，因此也对图数据库存储能力提出了更高的要求。比如在星环科技的 StellarDB 图数据库某落地案例中，该客户实际存储已经达超万亿点边数据量。图数据库不仅是图数据存储的仓库，还要提供完备图查询能力的系统。工业级图数据库需要处理不同数据量场景下不同规模数据查询的业务请求，因此需要快速处理简单或短查询，以及及时响应复杂或长查询的能力。这些能力可以赋能于诸如股权穿透分析、深度关联关系分析等场景。比如星环科技的 StellarDB 图数据库除了具备支持大规模并行处理，毫秒级的查询响应能力，而且在其某客户现场环境下支持 12 层深度关联关系查询的秒级响应。工业级图数据库不仅通过优化复杂数据操作的性能、提供优质内置图算法等形式提升其在大规模图数据集计算、分析能力，还通过支持数据的实时增删改查、事务等能力提升其在交易型处理场景中的能力。这些能力的提升，可以为客户提供更加友好的开发、应用平台。星环科技 StellarDB图数据库也在其上半年发布的 4.0 版本中，提升了其分布式图查询能力和实时数据操作能力，从而提升了该产品在 HTAP 场景的表现。1 12 2.2.2 图数据库简介图数据库简介图数据库是非关系型数据库的一种，采用图这种数据结构来进行数据存储，将世界万物的实体映射为图上的点，关系映射成图上的边。图表达力极强且非常简洁，图在表达事物关系上相比传统关系型数据库有千倍性能提升。此外，随着信息化、数字化建设的不断深入，当前数据呈现爆炸式增长，数据之间的关联关系越来越重要，对数据进行关联分析将挖掘出巨大的数据价值。图数据库的应用场景非常多，而知识图谱是最为基础的底层应用场景，知识图谱在数据组织形式上和图数据库天然契合，能够充分利用图模型在存储和查询的优势为多行业提供知识服务。1 12 2.3.3 图数据库模型图数据库模型图数据库按照数据模型划分主流的图数据库可以分为 RDF 图数据库和属性图图数据库。RDF图数据库表达方式非常简洁、具有极强的灵活性和可扩展性、并且采用 W3C 定义的 OWL 和SPARQL 国际标准体系来进行知识表示和查询，非常适合知识图谱的应用以及知识推理的场景，代表 RDF 图数据库有 Virtuoso、gStore、Jena 等。属性图数据库对知识表示更加直观且更接近RDB，非常适合大图分析等场景，代表属性图图数据库有 Neo4j、Tigergraph 等。-87-图数据库按照底层存储模式可分为原生和非原生两种产品。原生图数据库是专门针对图存储进行了底层设计和优化，支持高效的图分析算法和查询，常用的底层数据结构为链表、B 树、LSM树等来存储图数据，代表图数据库有 Neo4j、Tigergraph、gStore。非原生大部分依赖关系型数据库等数据库来存储数据，然后用存储引擎将数据以图数据的逻辑进行管理，代表图数据库有 Titan、JanusGraph。1 12 2.4.4 图数据库发展状况图数据库发展状况图 1：图应用成熟度发展图图数据库以图论为理论基础，使用图模型，将关联数据的实体作为顶点存储，关系作为边存储，解决数据复杂关联查询问题。赋能各行业从数据资源到数据资产的价值转化。业务驱动技术，技术带动业务，所以本章节从业务和技术两个角度说明图数据库的发展状况。从业务角度，最开始的时候图的应用主要集中在参考数据领域，比如说知识图谱、产品图谱等各种各样的知识图谱。这种基于一些事实关系的数据是非常典型的相对静态数据，数据量较小，随着业务的发展，业务需要增加基于交易数据的维度进行分析，交易数据的数据量比较大，且动态增加，所以这个时候对图数据库的数据处理能力、横向扩展能力的要求也会越来越高；再往后，更加成熟的图应用就不仅局限在静态的关系数据和交易数据，还会增加各种各样的事件和行为数据的分析，事件和行为数据的增长量是井喷式的，通常会形成 TB 级、PB 级的海量数据。在图应用成熟度这个发展历程中，先是管理企业的或者说是我们自身的核心数据，变成进行交易数据分析，最后升级为进行事件和行为的分析，随着这样的图应用的成熟度发展，对底层的图数据库技术的要求也是在逐步发展的。从技术角度，图数据库发展至今可分为三个阶段：第一个阶段是在 2007 年左右，该阶段的特点是部署简单且底层原生存储，原生图存储指同时满足原生图存储（native graph storage）和原-88-生图处理（native graph processing）两个要素，即使用专门适用于图数据库的存储结构，底层存储就是以免索引邻接的数据结构存储，在存储层实现免索引邻接，不依赖于第三方的存储组件，如 Neo4j。随着 2013 年左右，大数据时代的到来，渐渐的就无法承载大量的数据了，因此 graph2.0时代应运而生，该时代以分布式图数据库为代表，使用非原生图存储，即底层使用非图的存储结构，在处理层近似实现免索引邻接，依赖于第三方的存储组件，如 RocksDB、HBASE 等。该阶段的图数据库扩展性好，但因为非原生的架构导致查询性能，尤其是深链查询性能不高。且该阶段产品的图计算主要依赖于第三方开源计算引擎，如 Spark GraphX，图数据库本身不能提供图计算能力，在计算的时候需要通过 ETL 将全量数据加载到内存中，在内存中模拟图结构进行计算，当底层数据发生变化时，需要重新通过 ETL 加载全量数据到内存，这种架构导致产品使用的局限性，只适用于 T 1 的离线分析场景，无法满足业务对实时计算的要求，如 JanusGraph。第三代图数据库采用分布式 原生的架构，兼顾第一代图数据库的原生架构和第二代图数据库的分布式架构。即满足业务的快速的查询能力，又兼顾水平扩展能力，同时能够智能化地辅助商业决策，如 Galaxybase、Tigergraph。国际主流图数据库以开源为主，开源比例占到 60%以上，但是也随着商业化进展的不断深入，各大开源厂商也逐渐将图数据库完全开源变为内核模块开源，更多功能需付费使用。图数据库厂商主要由行业垂直厂商、高校产学研团队、传统数据库厂商、互联网大厂组成。行业垂直厂商专注于图数据库的研发以及图数据库在知识图谱领域的应用实践，例如 Neo4j、Tigergraph、Nebula、Galaxybase 等；高校产学研团队主要是从学术界出发，从理论到产品落地，然后逐渐开展商业化应用，例如 gStore、PandaDB 等；传统数据库厂商关注到图数据库的发展趋势，不断弥补自己在图数据库方面的能力，例如 Oracle Graph、IBM Graph 以及达梦（蜀天梦图）；互联网大厂由于内部业务的需要也组建了专门的图数据库团队，并且逐步由内部能力提供向外部赋能，例如 Twitter Flock DB、Facebook TAO、阿里 GDB、百度 HugeGraph。图数据库面向知识图谱的应用在各个行业均有结合点，但是受限于不同行业的信息化建设阶段不同，目前主流的应用行业在金融、公安，市场占比近 40%。随着政务行业、医疗、电网等能源行业的信息化建设不断推进，其知识图谱应用也在逐步加深，而且政策方面对政务大数据利好，将进一步深化政务行业的知识图谱应用。主要的应用形式分为两个，一个是构建专家知识图谱，将专家知识沉淀下来，然后对于数据进行分析和匹配，得到相应的分析结果，该类知识图谱存储的数据量较少，主要应用在交通、制造业等领域；一个是存储真实数据的行业知识图谱，通过行业内的多源异构数据构建知识图谱，然后在该知识图谱中进行查询、关联分析得到结果，该类知识图谱存储数据量较大，主要应用在金融、公安等领域。1 12 2.5.5 测试标准测试标准-89-图数据库是未来数据管理的发展趋势之一，通过图数据库测试来评估图数据库能力至关重要。现如今，图数据库测试方案多种多样，但存在各种弊端。所以需要一个权威、真实、公平的图基准测试。关联数据基准委员会（LDBC，Linked Data Benchmark Council）是由 Oracle、亚马逊、Intel、蚂蚁金服等软硬件巨头，Neo4j、TigerGraph、创邻科技、海致星图、Ultipa、TuGraph（阿里，原费马）等国内外主流图数据库厂商，伦敦大学、爱丁堡大学、希腊研究与技术基金会等国际知名学术组织等组成的非赢利机构，是全球图数据库领域唯一的第三方、非赢利、权威测试标准制定与发布机构，在行业内有着很高的影响力。LDBC 提供了公平、公正、公开的图基准测试标准，LDBC 图基准测试以图模式查询中常见的瓶颈点（Chock Points）出发，从聚合、连接方式、数据访问方式、表达式计算、子查询优化、并行化、图特征计算、更新操作八项维度出发，基于相同的标准、相同的数据集、相同的测试工具，全面考察图数据库的性能、高可用、并发等能力。（1 1）LDBCLDBC 对图模式查询的瓶颈点设计对图模式查询的瓶颈点设计聚合：包括排序、并行排序、TopK 排序等，比如追踪资金流向业务中，找出最近 10 次转账；连接方式：包括深度优先遍历（Depth First Search）、广度优先遍历（Breadth FirstSearch）的图遍历方式，比如追踪资金流向业务中，找出 5 跳内的转账链路；数据访问方式：包括随机查询的能力，比如根据 id 查找顶点，根据顶点找到邻居，获取邻居的属性信息；表达式计算：包括公共子表达式复用的能力，比如统计杭州一天的交易总量；子查询优化：包括一个查询内相同或相反的计算，合并到一个子查询的能力、不同查询间，复用子查询结果的能力、一个查询内复用子查询的能力；并行化：包括在大量查询的情况下，使用缓存子查询的能力；图特征计算：包括基于图遍历重用之前找过的路径的优化能力、基于查询两点间路径的优化能力、基于查询两点间不带权最短路径的优化能力、多个图查询组合查询的能力等；更新操作：包括对顶点、边以及属性的增删改查操作。（2 2）LDBCLDBC 图基准测试内容图基准测试内容LDBC 图基准测试主要包含三大类，总共 29 项测试，通过这 29 项测试，考察图数据库产品-90-是否有能力解决常见的图模式查询瓶颈点。交互式插入更新 II(Interactive insert updates)8 项交互式简单查询 IS(Interactive short reads)7 项交互式复杂查询 IC(Interactive complex reads)14 项（3 3）LDBCLDBC 图基准测试方式图基准测试方式LDBC SNB 提供了标准的测试工具，相当于黑盒测试工具，测试方无需自己实现测试工具的逻辑，确保测试方式一致。如下图 LDBC 图基准测试流程所示，黄色是测试者需要准备的内容：即查询语言，适配工具和测试的图数据库产品，LDBC 的官方会提供数据生成器与测试驱动的工具，包含了数据生成、样本生成、正确性验证、性能测试的功能，在整个测试过程中，LDBC 审计员会全程审计测试过程，严格记录每一个过程的日志和结果并公开，是一套非常完善的基准测试流程。图 2：LDBC图基准测试流程1 12 2.6.6 发展前景发展前景图数据库及其在知识图谱行业的应用整体来看还处于市场爆发前期，但是其关注度无论是学术界还是产业界都在逐年增加，DB-Engines 中数据库流行度排行榜中图数据库一骑绝尘，保持高速增长。在学术界图相关的关注度明显增长。-91-图 3：DB-Engines各模型数据库流行度趋势变化图图 4：主流图数据库论文数趋势图图数据库及知识图谱行业的发展目前还是以行业结合应用为主，但是存在着图数据库及知识图谱应用厂商对行业理解不深，而行业专家对图数据库和知识图谱技术了解不够，导致了应用结合点的分裂，还需要图数据库和知识图谱技术的不断深入普及和市场导入。-92-1 12 2.7.7 技术技术趋势趋势（1 1）趋势一：图）趋势一：图 HTAPHTAP 技术技术HTAP 是能同时处理 OLTP 和 OLAP 两种业务的混合处理系统，以打破 OLTP 和 OLAP 之间的隔阂，既可以应用于事务型数据库场景，也可用于分析性数据库场景。基于创新的计算存储框架，在同一份数据上保证事务的同时支持实时分析，省去了费时的 ETL 过程。在图数据库中，OLTP 指对顶点、边以及属性的增删改查。主要评价指标为：吞吐量、响应时间；OLAP 分为两种，第一种是全图的算法，使用全量数据进行图运算，比如 Louvain、PageRank等。衡量指标为图算法的丰富性、易用性。第二种是局部算法，使用部分子图数据完成运算，比如最短路径、K 跳查询等。衡量指标为吞吐量、响应时间。HTAP 指综合 OLTP 和 OLAP 的第二种情况。如下图所示，用户端发起请求，通过消息中间件转化成流的形式进入系统。图平台解析请求中的数据，将数据对应的操作（CURD）实时应用到图数据库中。然后就可以调用对应的图计算代码段，对刚刚处理的这条数据进行相关的计算操作（以新插入或更新的点为出发点、一定深度的邻居节点）。计算完成后的结果，可以实时写入到各个点边类型的属性中去，也可以选择一部分作为算法调用的结果返回给客户端。实时写入到各个点边类中的属性，是立刻查询可见的，可以在前端界面等查询结果的地方展示，也可以被实时的用到后续请求的相关计算中来。图 5：图数据库数据处理过程（2 2）趋势二：）趋势二：Graph AIGraph AI 技术技术图数据库会与人工智能进一步融合成为未来人类智慧的“新基建”。梅特卡夫定律表明，网络价值取决于网络中可以建立的连接的数量。同理，数据要发挥它的最大价值，一定要打通数据间的连通性。图数据库作为高效联通孤立数据点的技术，是引爆数据价值的关键要素。认知的基础是知识，而创新的来源是跨知识点之间的连接。可以想象，随着区块链等技术的发展、数据确权及相关政策法规的成熟，未来图数据库发挥价值的一种形态是通过技术与数据结合将庞大知识图谱及基于它的认知计算能力作为基础设施服务提供给多方调用和查询，又通过多方的使用反馈进一步完善系-93-统本身。在未来的商业中，知识也会像今天的水电煤一样随用随取，用户无需再关心底层到底是哪一种数据库，用的是什么计算引擎，只需专注于查询和调用自己需要的知识并将知识推理的结果运用于当前的业务场景创造商业价值就好。图和图数据库技术管理关联数据并定义关系，通过应用领域相关知识增强 AI 的性能，图技术提供了一种有效的技术手段来实现复杂 AI 应用程序的开发。至少在四个主要区域，图可以为 AI提供领域相关知识：首先是知识图谱，它为决策支持提供领域相关知识/上下文（例如智能问答）并且帮助明确答案适合于该特定情况（例如在多雨驾驶条件下的自动车辆）。其次，图提供更高的处理效率，因此借助图来优化模型并加速学习过程，可以有效的增强机器学习效率。第三种，基于数据关系的特征提取分析可以识别数据中最具预测性的元素，基于数据中发现的强特征所建立的预测模型拥有更高的准确性。第四种，图提供了一种为 AI 决策提供透明度的方法，这使得通过 AI 得到的结论更加具有可解释性。（3 3）趋势三：图）趋势三：图 联邦学习技术联邦学习技术图神经网络（Graph Neural Network）相比于传统的机器学习算法，在复杂图结构数据上有着不可比拟的优势。图神经网络能够更好的提取数据之间的特征，如药物发现、社交网络、推荐系统和交通建模等，近些年来图神经网络技术正在如火如荼的发展。而数据作为机器学习的“燃料”，数据的好坏、数据量的大小直接决定机器学习的训练效果。而数据的获取存在诸多的困难，一方面企业难以获得模型训练所需要的大量数据，另一方面，因为用户隐私、法律限制、商业竞争等问题，造成数据流通困难，“数据孤岛”现象普遍存在，所以催生出图联邦学习这一项技术，旨在保证用户隐私和公司数据的前提下，更好的发挥数据作为机器学习“燃料”的重要作用，图联邦技术作为两者的交叉学科，未来存在广泛的应用前景，通过图神经网络和联邦学习相结合，更好的推动社会生产力的发展和保障人民财产安全，任重而道远。但目前图数据库在机器学习领域还没有被广泛采用，主要有如下原因：一是目前的文献中，缺乏对各种图联邦设置和任务的统一表述，使得专注于基于 SGD（随机梯度下降）的联合优化算法的研究员难以理解图 联邦学习技术的基本挑战。二是现有的联邦库并不支持不同的数据集和学习任务以衡量不同的模型和训练算法，鉴于图数-94-据的复杂性，在联邦学习环境下训练图神经网络的动态与训练视觉或语言模型有较大差异。三是面向模拟的联合训练系统对于跨语境的大规模私有图数据集的联合图神经网络研究来说是低效的、不安全的。未来应该设计一个联邦学习系统和图神经网络基准，包括开放的数据集、基线实现、可编程的API 等，都集成在一个大的系统中，供研究人员探索图 联邦学习交叉的重要问题。系统应支持更多的图数据集和图神经网络以适应不同的应用，可能的应用包括但不限于传感器网络和时空预测，不断的优化迭代系统，进一步加快大型图的训练速度；设计先进的图联邦算法，提高数据集上的准确性，解决图联邦下的安全和隐私挑战；组织数据竞赛、建立合作生态、人才培养等。（4 4）趋势四：图数据库处理时序数据技术）趋势四：图数据库处理时序数据技术未来图数据库的发展，将出现具备时序数据处理能力的图数据库。5G 以及 IoT 的兴起催生了大量的时序数据，这些数据蕴藏着丰富的人、设备、车辆等的流动变化的关联数据。要基于这些流动变化的关联数据作出实时精准的商业决策，就需要底层的数据存储与计算能力的支撑。传统的流式大数据处理技术框架虽然可以进行实时数据处理，但缺乏针对图数据的关联分析能力，无法对图处理任务进行语义解析，也无法执行多层查询等图计算。现有的图计算框架虽然具备以内存存储图数据进行图表达能力，但仅能执行预定义的图任务，不知此动态追溯查询，无法基于指定时间窗口下的历史数据进行图处理，灵活性较低。图计算引擎可以对图结构进行查询，但这些图查询不具备原生的时序分析能力，需要进行原始数据的遍历搜索运算，时空开销大，且缺乏高性能支持。时序数据一般具备以下 3 个特点：一是抵达的数据几乎总是作为新数据被记录；二是数据通常按照时间顺序抵达；三是时间是一个主坐标轴（即可以是一个规则的时间间隔，也可以是不规则的）。时间序列数据累计速度非常快（比如一辆物联网汽车每小时能收集 25GB 数据。）常规的数据库在设计之初并非处理这种规模的数据，关系型数据库处理大数据集的效果非常糟糕。图数据库目前虽然可以很好的处理大规模数据集，但是仍然需要借鉴时序数据库技术，提升处理大规模数据集的性能，包括更高的入库性能、更高的容纳率、更快的大规模查询以及更好的数据压缩。未来图数据库需要能够更好的支持空间、时间维度的数据查询和处理。具备时空高效的大规模时序图构建、任意时间窗口的图数据动态追溯查询、基于分布式计算的算法查询、支持原生时序语义表达的图查询语言设计。（5 5）趋势五：大规模图数据的分布式管理系统）趋势五：大规模图数据的分布式管理系统随着社交网络、知识图谱等领域研究的发展，越来越多的图数据被发布了出来。比如，在社交-95-网络中，美国 Meta（原 Facebook）公司在全球拥有超过约 29 亿活跃用户，这些用户可相互关联与通信，并形成大规模图结构社交网络；德国的莱比锡大学和柏林自由大学合作从维基百科上抽取结构化数据形成的知识图谱 DBpedia 已将近有 24 亿。针对上述大规模的图数据集，如何有效地进行分布式管理就成为了一个重要问题。为此，学术界和工业界当前已经构建了不少高效的分布式图数据管理系统。这些图数据的分布式数据管理系统可以分为两类：基于大数据处理平台的分布式管理系统和自定义的分布式图数据管理系统。基于大数据处理平台的分布式图数据管理系统基于大数据处理平台的分布式图数据管理系统基于大数据处理平台的分布式图数据管理系统利用现有大数据处理平台进行图数据分布式存储。典型的大数据处理平台包括 Hadoop、Spark 等等。这一类方法因为使用了已有大数据处理平台，所以有很好的可扩展性、容错性，也能更好结合已有的大数据生态。但是现有大数据处理平台整体读写性能先对于单机硬盘还是低很多，所以这些基于大数据处理平台的系统的查询性能都相对比较低。典型基于大数据处理平台的分布式图数据管理系统有 JanusGraph、GraphScope、DP2RPQ等。其中，JanusGraph 是一个常用的图数据管理系统。它的存储系统可以建立在 Cassandra、HBase、BerkelyDB 等多种存储系统上，同时支持适配 Elasticsearch、Solr、Lucene 等多个索引技术。因为支持基于多种大数据处理平台的存储系统，JanusGraph 可以和大数据生态结合的非常好，也支持和 Spark 结合做一些大型的图计算。GraphScope 是阿里公司开发的一个开源图计算引擎，可以支持交互式查询引擎、图分析引擎 FLASH、图学习引擎。在数据交换与存储层，GraphScope 采用分布式内存数据管理系统 Vineyard，用以支持管理数据的分区、元数据等以及为上层应用提供本机零拷贝的数据读取。天津大学团队基于分布式图计算系统 GraphX 开发了分布式 RDF 图数据管理系统 DP2RPQ。DP2RPQ 支持基于 GraphX 来处理正则路径查询。自定义的分布式图数据管理系统自定义的分布式图数据管理系统另一类分布式图数据管理系统是基于分布式环境中各个机器自身的文件系统来设计实现分布式图数据存储。这类系统首先将图数据划分成多个子图，然后这些子图分布到不同机器上进行管理。所以它们性能往往能做到比基于大数据处理平台的分布式图数据管理系统高。但是它们的可扩展、容错也要自己实现，所以这些方面往往不及基于大数据处理平台的分布式图数据管理系统。典型自定义的分布式图数据管理系统有 Neo4j 的分布式版本、TigerGraph、gStore 的分布式版本、GSmart 等。Neo4j 是目前最流行的图数据库系统。它目前的分布式版本就是在其基于各个机器自身文件系统的单机版基础上开发的。Neo4j 分布式版本包含 Core Servers 和 ReadReplicas 两类计算节点。Core Servers 主要负责写数据，并通过 raft 协议提供事务保证；而 ReadReplicas 只负责读数据，分担集群读负载压力。TigerGraph 也是一个著名的图数据库系统。其的-96-分布式版本将大图按照顶点进行一致性 hash 切分成若干分片，然后将边与其起点存储在同一个计算节点。然后，每个计算节点只负责存储一个分片的一个副本，并支持其上的图存储和图处理。基于国产自主可控的单机 RDF 图数据管理系统 gStore，湖南大学和北京大学研发了相应的分布式版本。该研究主要讨论了如何通过设计良好的图数据划分策略来减少查询处理时间。该研究提出了一种新的图数据划分方法最小属性划分，来降低图数据划分过程中跨多个子图的边上的属性数量。这样划分的子图分布到不同机器上之后，如果一个查询不涉及跨子图边上的属性，那么这个查询就可以避免跨机器通信，进而实现降低通信代价。GSmart 是国家超级计算长沙中心基于 CPU GPU的异构融合并行计算体系结构所设计的分布式 RDF 图数据管理系统。GSmart 将所有 RDF 图数据上的查询操作都转化成了稀疏矩阵运算，然后利用 GPU 来优化这些稀疏矩阵运算。（6 6）趋势六：查询语言统一）趋势六：查询语言统一目前，图数据库市场查询语言不一，包括 Gremlin、Cypher、SPARQL 等，也有使用自己开发定义的查询语言。用户在业务中使用图数据库时学习成本高，对图数据库产品的推广带来一定的阻碍。同时，国际上 ISO/IEC 的 GQL 制定耗时 4 年，与当前图数据库市场的发展速度严重不匹配。如何解决这一问题已是厂商与用户共同关注的问题。（7 7）趋势七：图数据库与图处理引擎融合）趋势七：图数据库与图处理引擎融合现今非原生图数据库只能提供较简单的图查询进行实时查询，不能独立完成复杂的全图迭代计算，需要与图处理引擎结合，增加了额外的处理过程，加重了系统负担。当前，分布式图数据库支持了更大规模的数据，同时通过优化保证了查询的高性能，未来与图处理引擎深度融合从而为用户提供更简单、更复杂的计算能力是图数据库厂商的研发方向。（8 8）趋势）趋势八八：无代码无代码/低代码的平台低代码的平台为了进一步降低图数据库的使用门槛，方便具有各种背景的图数据库使用者使用图数据库，图数据库厂商也都在提升其产品使用的友好程度。例如通过为图数据库可视化工具提供诸如自定义查询一键执行、可视化查询语句配置等功能。1 12 2.8.8 面临面临挑战挑战图数据库技术面临的挑战依然很多。上文提及的诸多需求和发展趋势，也同样为图数据库技术提出了诸多挑战，除此之外，浅谈以下几点：（1）动态图。图数据的更新可能是实时的、涉及大数据量的，诸多实时性场景对新增数据参与计算分析的结果有较高的实效性要求，这是其中一个挑战。-97-（2）超级节点。尽管超级节点的处理方案有很多种，但其任然是图查询、图计算中不可回避的问题。（3）超大规模图数据可视化。在图数据库使用过程中，可视化工具担任了图数据分析探索的重要角色，对于超大规模图数据进行合适的可视化，也是未来图数据库需要应对的挑战之一。1 13 3.搜索引擎搜索引擎搜索引擎数据库是一类专门用于数据内容搜索的 NoSQL 数据库，是非结构化大数据处理分析领域中重要的基础支撑软件。近年来，中央出台多项信创相关政策，大力支持信创产业持续发展，努力实现国产替代。数据库作为信息系统的核心和信创基础软件的重要部分，将迎来重大发展机遇。在数据量的爆炸式增长浪潮中，非结构化数据占据了总数据量的大部分，搜索引擎数据库作为非结构化大数据处理分析领域中重要软件，伴随着搜索引擎系统的发展也逐渐发展起来。2022 年 11 月 17 日，中国信通院组织召开了“搜索型数据库”技术研讨会，讨论了搜索型数据库的市场前景、技术趋势、应用场景、发展态势等议题，搜索型数据库的数据安全问题日益受到业界的关注，标志着我国对搜索引擎数据库领域的国产替代关注度将逐渐提升。据东方证券-计算机行业深度报告预计，搜索引擎数据库未来具有广阔的市场前景，到 2025 年中国搜索引擎数据库市场将达到 32 亿元。图 1：东方证券计算机行业深度报告搜索引擎数据库发展历程从全球范围来看，国外搜索引擎数据库发展较早，国外开源产品 Elasticsearch 是目前搜索引擎数据库领域的龙头产品，并占据了相当大的市场份额。Elasticsearch 在过去几年内，数据泄露事件频发，甚至一个月被曝 6 次数据泄露。去年，受美国出口管制的巴林，暴露的 Elasticsearch集群中近 200 万条信息被泄露，包含有关人员的敏感信息。而作为美国出口管制重点对象的俄罗斯，近几年发生多起 Elasticsearch 数据泄露事件。根据 Group-IB 报告显示，2021 年网络上暴-98-露的 Elasticsearch 实例超过 10 万个，约占 2021 年暴露数据库总数的 30%。Elasticsearch 开源版本是不具备数据保护功能的，看似免费，但不安全。用户必须付费获得 Gold 许可才能获得相关的安全保护功能，且不同的安全功能对应不同的收费标准。2021 年初，Elastic 公司决定将这款开源软件的 Apache License 2.0 变更为双授权许可，即 Server Side Public License(SSPL)和 Elastic License。其核心条款是“如果将程序的功能或修改后的版本作为服务提供给第三方，那么必须免费公开提供服务源代码”。这意味着不法分子可以获得其源代码并研究其漏洞，给企业用户带来巨大的安全风险。此外，Apache 软件基金会和 GitHub 官网都有公开说明，产品和技术受到美国的出口法律和法规限制，受美国出口管制的俄罗斯在近期俄乌事件中将这方面风险彻底暴露，警示我们要摆脱被科技制裁风险的唯一出路就是要自主研发，实现真正的自主可控。国内搜索引擎数据库产品获得关注较少，国产替代产品少，墨天轮排行榜上两大搜索引擎数据库产品，星环科技 Transwarp Scope 和有百度开源的 Tera。Transwarp Scope 是星环科技自主研发的企业级分布式搜索引擎，通过工信部源代码扫描测试，并于 2019 年上榜由信息技术应用创新工作委员会编制的国产软硬件技术图谱。Scope 可提供 PB 级海量数据的交互式多维检索分析服务，支持百万级高并发和毫秒级低延时检索业务，覆盖模糊匹配，精确查询，多维检索等各类检索类场景，满足数据检索多样化需求。此外，在国产化生态适配方面，Scope 已完成与主流信创生态厂商的适配互认工作，支持适配长城飞腾、华为泰山、龙芯等服务器架构，同时满足麒麟，UOS 等操作系统，根据星环科技官方信息显示看，Scope 在 ROI、扩展性、稳定性、安全性、数据读写/恢复/一致性等全面超越开源 Elasticsearch，满足信创要求和国产化替换需求。图 2：Transwarp Scope与Elasticsearch性能对比-99-1 14 4.数据库安全数据库安全1 14 4.1 1 数据库安全数据库安全背景背景2020 年以来，全球经济传统经济增长放缓，数字经济成为了经济增长的切入点与发动机，国家也将发展数字经济提升到战略高度。相较于传统产业，数字经济的发展更依赖数据，因此数据安全成为了一项重要议题。2021 年 9 月 1 日起，中华人民共和国数据安全法正式实施生效，是我国第一部有关数据安全的专门法律。数据安全法是针对我国数字经济发展现状与未来出台的一部数据领域的基础法律，明确定义了“数据”等相关概念，确立了数据分级分类管理的原则，风险评估、检测预警与应急处置等各项基本制度，对开展数据处理活动时应履行的各项义务做出了规范。数据库是组织、存储和管理数据的计算机基础软件，保护数据库安全是数据安全最为重要的一环。数据安全法的实施在法律层面为数据库安全提供了保障，也对保护数据库安全提出了更高规格的要求，同时明确了在数据处理过程中组织、个人应尽的义务与责任。图 1：数据安全法总结构现在越来越多开发者、数据库管理员、企业领导者意识到，确保数据库的安全应该是他们最重要的目标之一。一方面，数据库中存储的数据对企业在市场中保持竞争优势至关重要，一旦发生数据泄露将造成难以挽回的损失；另一方面，当今黑客们正在构建更隐蔽更复杂的工具，发展地下市场，目的是窃取数据以谋取非法利益，而存储着大量数据的数据库通常是黑客们的“最佳”入侵对象。近年来，已有多起数据泄露事件发生，这些事件的起因或是运维疏忽导致的风险，或为数据库存在漏洞，但都给企业的经营、声誉、信用造成巨大打击。2019 年 2 月 12 日，美国邮件服务商VFEmail 受到黑客攻击，公司积累了二十多年的数据和备份全部被删除；2019 年 1 月 22 日，美国一家网上赌场集团泄露了超过 1.08 亿笔投注信息，泄露源头在于 Elasticsearch 服务器没有密码保护，不需要身份验证，从而被黑客入侵。这些事件警示我们，数据始终处于泄露的风险之中，-100-只有时刻注意、重视数据库安全，采取多种措施保护数据库，才能防患于未然，杜绝数据泄露。据不完全统计，2022 年中国共发生 14 起重大数据安全事件，具体事件及详情见下表。时间时间20222022 年国内重大数据安全事件年国内重大数据安全事件简介简介4 月初大亚圣象邮箱系统遭黑客入侵，肇事者入侵该公司租用的微软公司邮箱系统，伪造假电子邮件冒充该公司管理层成员，伪造供应商文件及邮件路径，实施诈骗，涉案金额约 356.9 万美元（约人民币2275.49 万元）。4 月国家安全机关破获了一起为境外刺探、非法提供高铁数据的重要案件。上海某信息科技公司销售总监王某等人在利益驱动下，非法收集、向境外公司提供涉及铁路 GSM-R 敏感信号等高铁数据。6 月 21 日媒体报道大学生学习软件“超星学习通”的数据库信息被公开售卖，超 1.7 亿条信息疑遭泄露。当日下午，学习通回应经十余个小时排查，到目前为止还未发现明确的用户信息泄露证据。鉴于事情重大，已经向公安机关报案，公安机关已经介入调查。7 月国家互联网信息办公室依法对滴滴全球股份有限公司开出人民币 80.26 亿元的巨额罚款。经查实，滴滴公司共存在 16 项违法事实，包括违法收集用户手机相册中的截图信息 1196.39 万条、过度收集乘客人脸识别信息 1.07 亿条、年龄段信息 5350.92 万条、职业信息 1633.56 万条、亲情关系信息 138.29 万条、“家”和“公司”打车地址信息 1.53 亿条等。此外，滴滴公司被发现存在严重影响国家安全的数据处理活动，给国家关键信息基础设施和数据安全带来严重风险隐患。8 月上海随申码数据库或泄露，4850 万用户的数据，包括用户姓名、手机号码、身份证号、随申码的颜色、UUID（通用唯一识别码），在暗网以 4000 美元价格拍卖。8 月底据北京市朝阳区人民检察院裁定，2020 年至 2021 年，刘某、姜某某、吴某某在多家国内医院内，多次通过技术手段秘密接入医院内网数据库，获取大量药品编码、数量、金额、单位等药品数据后出售，违法所得人民币 200 余万元。9 月国内一“黑客”利用木马病毒非法控制逾 2000 台计算机，入侵 40 多家国内金融机构的内网交易数据库，非法获取交易指令和多条内幕信息，进行相关股票交易牟利，非法所得人民币 183.57 万元。9 月据官方通报，西工大邮件系统遭境外组织入侵，窃取该校关键网络设备配置、网管数据、运维数据等核心技术数据，系美国国家安全局所为。美国安局其下属的特定入侵行动办公室（TAO）在 4 月之前，已经对中国国内网络目标实施了上万次攻击，控制了数以万计的网络设备，并成功窃取超过140GB 的高价值数据。-101-10 月初据香港媒体报道，香格里拉酒店集团的网络系统受到黑客攻击，其中 3 家位于中国香港，造成香港酒店 29 万个人资料泄露。香港安全专家表示：通过技术分析，黑客可能通过传送电邮，在超链接中加入“钓鱼程式”，窃取酒店系统内的资料。10 月经国内网警侦破，麻某利用自身黑客技术，在 2022 年 4 月侵入国内某医疗机构微信公众号系统窃取数据，半年多时间非法获取该计算机系统数据 10 万余条，而后在境外黑客论坛兜售，非法获利1500 美元。11 月初据台媒报道，台湾地区政府系统遭黑客入侵，黑客在国外论坛公开出售 2300 万中国台湾民众数据，打包价 5000 万美元。12 月 11 日蔚来汽车确认，因服务器配置错误导致百万条用户信息泄露，并遭受 225 万美元等额比特币的勒索。声明显示，遭窃取数据为 2021 年 8 月之前的部分用户基本信息和车辆销售信息。表 9：2022 年中国重大数据安全事件一览表1 14 4.2.2 数据库安全技术数据库安全技术在数据库发展过程中，一系列工具、控制和措施被设计完善用以保护数据库的机密性、完整性和可用性，及其安全性。中国信通院关系型数据库安全专项评测设置了五大项安全基础能力，包括用户标识与身份鉴别、访问控制、数据存储安全、数据通信安全和安全审计，共计 29 个测试项，为各行业组织评估关系型数据库产品的安全能力提供参考。图 1：关系型数据库安全能力标准框-信通院-102-此外，随着国家对数据监管要求的提高和企业安全意识的不断增强，数据库安全技术在逐步完善的同时也推出了更高的要求。用户标识与身份鉴别用户标识与身份鉴别：身份鉴别是数据库安全的基础，通过验证用户身份判断其能否连接至数据库。数据库应支持口令验证、操作系统验证等多种鉴别方式，并提供完备的口令管理体系。访问控制访问控制：数据库访问控制要求用户在对数据库进行操作前必须先得到对应授权，是保护数据的前沿屏障。常见的访问控制模型有自主访问控制、强制访问控制等。数据存储安全数据存储安全：攻击者可能绕过数据库应用，直接窃取存储在硬盘中的数据，因此保护数据存储安全是重中之重，其中数据加密（包括数据文件、备份、日志等）是保护数据安全的最佳实践。数据通信安全数据通信安全：保护数据的通信安全要求数据在传输过程中加密，能够发现传输数据是否被篡改。安全审计安全审计：数据库安全审计确保管理者能够监控用户对数据库的操作，并快速检测数据库中的漏洞。以星环科技分布式交易数据库 KunDB 为例，为应对各方面安全性挑战，KunDB 构建了完备的安全体系，并通过了信通院关系型数据库安全专项评测。通过口令管理、多种身份认证方式保障数据库认证安全，并提供了 DAC、MAC 的访问控制模型，使权限控制更为灵活；此外，为防止黑客窃取明文数据，KunDB 提供了全面的数据加密功能，包括数据文件存储加密、通信加密、备份加密、日志加密等；而 KunDBA 平台提供了数据审计功能，协助管理者精准定位操作，管理数据库中可能存在的漏洞。1 15 5.数据库中间件数据库中间件1 15 5.1.1 何为何为数据库数据库中间件中间件中间件（Middleware），是指处于操作系统、数据库与应用系统之间的软件，用来屏蔽、扩增强、扩展底层技术细节及能力，为应用系统提供更为简洁、友好的应用访问能力，以其自身的复杂性换来了应用程序开发的简单。广义中间件的定义是非常宽泛，比如解决系统间网络通信的消息中间件、提供分布式环境下统一配置的注册配置中心、应用服务访问的网关、访问数据库的数据库中间件、集成平台等等，都属于中间件的范畴。中间件的功能特点及其自身定位，决定了中间件的多样性。从类别上看，中间件可大致分为基础支撑类中间件、应用集成类中间件、平台类中间件以及数据类中间件，可参考如下图。目前业内还没有比较标准及权威的划分方式。-103-图 1：中间件的分类数据库中间件数据库中间件作为重要的一种中间件产品，在过去一二十年伴随互联网应用的兴起而发展起来的，帮助很多互联网企业有效地解决了分布式、大规模、经济性、可用性及管理类等诸多问题，也其中诞生很多优秀的中间件产品。这类技术从本质上将是基于数据库产品之上，通过增强、扩展器能力解决原有数据库有所短板的应用级解决方案。虽然其中会用到一些数据库实现技术，但从本质上讲并不是一个数据库系统。1 15 5.2.2 中间件发展现状分析中间件发展现状分析从中间件产品发展来说，目前仍处于一个快速更新、快速发展的阶段。随着数字化转型深化，企业对底层数据基础设施提出了更高的要求。中间件产品位于底层基础设施与应用系统之间，起到很好地承上启下作用。伴随着云计算、大数据、物联网、数据治理等各类新兴技术的快速发展，中间件产品的应用范围和功能被快速扩大，并由于中间件产品的兼容性、共性支撑等核心价值点，其产品价值得以快速提升，并被赋予重要的产业价值。（1 1）中间件商业发展空间中间件商业发展空间从市场侧表现来看，中间件市场呈现稳定高速发展中。下图来自计世资讯2021-2022 年软件基础设施（中间件）市场发展趋势研究报告数据，在 2021 年国内中间件行业市场总体规模达到 88.7 亿元，同比增长 11.7%。整体来看，过去几年虽然由于疫情等原因，实体经济对中间件投入有小幅放缓，但中间件的市场规模仍然保持了 10%左右的增速。图 2：2019-2021 年中间件市场总体规模-104-（2 2）中间件赛道资本投入）中间件赛道资本投入从资本层面上看，来自于中间件的项目颇受资方认同，一大批以开源项目为代表的中间件产品融资走向商业化。这其中包括：2021 年 2 月，网关中间件 Apache APISIX 背后的开源商业化公司“支流科技”宣布完成百万美元 Pre-A 轮融资。2021 年 5 月，数据库中间件 ShardingSphere 团队成员组建的商业公司“SphereEx”完成数百万美元天使轮融资。2021 年 10 月，基于 Apache Pulsar 的初创企业 StreamNative 宣布获得 2300 万美元 A 轮融资。2021 年 11 月，面向 IoT 与 5G 场景消息与流处理的开源基础软件供应商 EMQ 宣布完成 1.5 亿人民币的 B 轮融资。从海外来说同样如此，例如 2021 年 6 月，消息系统 Apache Kafka 背后的公司 Confluent在纳斯达克上市。Confluent 在 2020 年 4 月的最后一轮风险投资中估值为 45 亿美元，一年后在上市首日估值超过 100 亿美元等。（3 3）数据库中间件发展）数据库中间件发展具体到数据库中间件赛道，行业整体呈现一家独秀的局面。如下图是根据第三方平台-墨天轮收集的数据库中间件得分对比。以 Apache ShardingSphere 及对应公司 SphereEx 公司的商业产品，表现尤为突出；此外几家来自于互联网公司的中间件产品也在发展中，但相对有些滞后。图 3：墨天轮中间件流行度排行榜得分-105-1 15 5.3.3 数据库中间件数据库中间件发展趋势发展趋势数据库中间件，自诞生以来，早期更多是用来解决来自互联网、电商平台的业务规模问题。其核心能力定位于解决大规模的数据分片问题。因此也诞生了一大批开源数据库中间件，很好地解决了企业问题。伴随着近些年来数据库碎片化的趋势，这其中部分产品很好地迎合了这一发展趋势，不再拘泥于单一业务、单一功能，而是快速扩展其功能外延。提供诸如数据安全、流量治理、接入网关、异构混算等能力，逐步将数据库中间件平台打造为企业的数据基础服务，形成所谓的“OneDB”的概念。满足企业对异构数据库乃至异构数据基础平台的统一纳管、治理、服务的诉求。相信作为中间件家族的核心产品，数据库中间件未来将在业务化、一体化、云化、标准化、插件化方面继续发展，作为企业数字基础设施的核心关键组件。1 16 6.数据库数据库兼容性兼容性从中兴、华为等一系列高新科技企业被美国制裁，到俄乌冲突事件爆发后，西方各国相继宣布制裁俄罗斯，以 Oracle、IBM、微软、SAP 为代表的科技巨头暂停在俄服务，这一系列动作敲响了加速国产化替代的警钟。数据库作为提供数据存储与处理能力的基础软件，是信息系统的基础、信息安全的基石，因此，数据库自主可控和国产化替代已经刻不容缓。Oracle 数据库发展较早，在国内市场内占领了一定先机，企业经过信息化的长期积累和革新，基于 Oracle 开发了大量的系统业务。为了能够适配新的国产数据库产品，必须对应用代码进行大量修改，各数据表的数据类型、函数、语法规则需要进行系统、全面的改造，这就要求新的国产数据库对 Oracle 数据库能够有很好的兼容性支持，降低迁移的代码改造成本。而中国信通院数据库发展研究报告中表示，“国内关系型数据库产品中多数是基于 MySQL 和 PostgreSQL 二次开发的”。因此，这些产品对 MySQL、PostgreSQL 兼容性较好，但没有体系化的兼容 Oracle，尤其是 PL/SQL 方面。体系化的兼容 Oracle，首先要关注 Oracle 的重点功能。以 Oracle 12c 版本为例，主要功能包括：多租户、RAC、Data Guard、备份和恢复、在线对象重建、FLASHBACK、自动负载管理、结果集缓存、内存引擎、安全加密和审计、存储过程、管理调优和测试工具、分区表、OLAP、压缩、并行处理、数据复制、全文索引、空间数据、XML 等。可以将 Oracle 的这些能力分为以下几类，以此实现对 Oracle 的体系化兼容：1 16 6.1.1 数据语法兼容数据语法兼容兼容 Oracle 数据库的数据类型，其难点一方面在于对 Oracle 特有的数据类型的支持，例如ROWID 和 ROWNUM，需要国产数据库厂商对此进行兼容开发改造。另一方面就是相同数据类型的不同定义，比如 Oracle 中的 Date 类型可以精确到时分秒，而其它数据库则是精确到年月日。-106-为了兼容这种差异，一般是通过提供兼容性开关，开启 Oracle 兼容开关后，将用户定义时写的Date 类型在底层转换成例如 Timestamp 的类型，可以直接精确到秒级。兼容 Oracle 数据库的语法，这方面需要投入大量细致的工作，以提高语法的兼容覆盖度。一类是对 Oracle 特有语法的支持，例如 Merge into 可以将两个表进行合并，国产数据库需要通过封装其它方法尽可能高效率地实现该语法的功能。另一类是 Oracle 语法的差异，例如很多数据库支持对存储过程的实现和调用，而 Oracle 支持三种形式调用存储过程：call 加存储过程、exec加存储过程、直接调用存储过程，需要对这类语法差异进行兼容改造。1 16 6.2.2 核心功能兼容核心功能兼容Oracle 的开发设计中会采用 PL/SQL 来完成内核之外的功能，也会应用现有的 PACKAGE 来实现业务逻辑。国产数据库需要实现 PL/SQL 的结构、基本语句、子程序、触发器、异常等语法，并覆盖常用的 PACKAGE 内容，以实现对 PL/SQL 功能的兼容。在实际使用中，Oracle 的 PL/SQL还会承载复杂的业务逻辑，因此对复杂 PL/SQL 的高效执行也是该功能可用性的关键点。此外，Oracle 的主要功能还包括对数据库对象的创建和管理，Oracle 的主要数据对象有表、约束、分区、视图、索引、同义词、外键、触发器等。国产数据库厂商需要对比这些数据库对象和自身的差异，一方面需要对数据库对象实现全面覆盖，另一方面需要关注这些对象的特性和限制，以及执行时的效率。1 16 6.3.3 运维管理兼容运维管理兼容Oracle 为了方便运维管理做了多种视图，需要对常用的视图和运维命令进行兼容，包括 all视图、dba 视图、user 视图等。此外 Oracle 提供了丰富的运维工具，如功能强大的 Oracle Enterprise Manager 运维平台，其提供了多种可视化的运维功能包括备份恢复、高可用管理、存储管理、性能分析和优化、安全管理、监控告警等，需要国产数据库厂商在自身的运维系统中实现这些功能，保障实际业务生产中数据库可运维性的兼容需要。1 16 6.4.4 业务能力兼容业务能力兼容对业务能力的兼容往往是容易被忽略的。比如一条相同的 SQL 在 Oracle 下正常执行，但是业务迁移到国产数据库后，由于优化器执行器的差异，这条 SQL 产生了低效率的执行计划，性能差需要业务手动对 SQL 进行改造。类似的情况，差异还可能是由国产数据库自身引入的，比如需要指定 Shardkey、需要创建主键和全局索引，这些差异的引入都可能会导致业务能力上的不兼容，因此需要提供迁移工具负责将 Oracle 里的字段类型和对象自动转换成国产数据库的对象。-107-此外，由于不同数据库的架构和部署方案的差异，比如 Oracle 的 RAC 架构提供了高可用的能力，需要国产数据库厂商提供替代的高可用能力的兼容性方案。从容灾的角度考虑，最好能提供国产数据库和Oracle 之间的异构数据库同步能力，既可以在业务迁移切换的过渡环节提供安全性，也能在业务平稳运行后提高系统的容灾能力。1 16 6.5.5 生态工具兼容生态工具兼容驱动是应用程序访问数据库的接口，它与编程语言密切相关，对于 Oracle 支持的多种数据访问接口包括 OCI、OCCI、ODBC、JDBC、.NET、OLE DB、Python、PHP 等，国产数据库厂商应支持多种数据库访问接口，兼容 Oracle 开发生态。在实际的业务使用中还会用到各类数据库相关工具，例如性能测试工具、可视化开发工具、数据导入导出工具等，因此国产数据厂商需重视产品生态工具的建设，降低 Oracle 用户使用的门槛。星环科技分布式交易数据库KunDB高度兼容Oracle语法，支持VARCHAR2/NVARCHAR2、NUMBER 等全部常用数据类型，支持控制语句、集合、动态 SQL、子程序、预定义包、错误处理等全部PL/SQL语法。并通过自研创新的过程语言编译技术及中间优化语言TIR，支持复杂PL/SQL程序，执行性能比解释执行提升一个数量级。图 1：星环自主原创PL/SQL编译器原理-108-在 Oracle 数据库对象、DML、函数、系统视图、内置包、驱动等方面，KunDB 做到了常用功能的兼容，满足大部分业务的迁移需求。此外，KunDB 适配 Oracle 应用开发生态，支持基于Oracle 的业务直接或者通过中间件框架连接 KunDB，包括 Java、.NET、C/C 等语言开发的应用，尤其是针对 C/C 应用提供兼容 Oracle 的 OIC/OCCI 驱动，来保障业务的平滑迁移。KunDB还提供了开放的数据生态，通过全局事务日志可与异构系统实时同步，可应用在实时数仓建设、Oracle 和 KunDB 双数据库系统并轨运行回切等场景。图 2：星环KunDB数据库兼容情况三、中国数据库标准现状三、中国数据库标准现状1.1.国内数据库行业发展简述国内数据库行业发展简述我国的数据库（在本文中，数据库系统管理软件简称为“数据库”）行业经历了理论化、市场化、自主化三个阶段，分别是基于上世纪八十年代国家工程开启的理论化实验室阶段，上世纪九十年代末本世纪初伴随改革开放和信息化建设兴起的数据库市场化阶段，近五年由于“科技战”和“贸易战”带来的产品自主化阶段。在不同的历史阶段中，人们对数据库的认知有较大变化：早期数据库作为与战略研究和载人航天等项目并列的高尖端项目，在高校和科研院所中萌芽；随着时间推移，我国加入 WTO 开启市场化经济后，信息化建设起步。引入了国外较为先进的信息化路线和软件使用方式后，数据库被认为是信息系统底层最重要的支撑基础软件并以商品的方式进行市场化。在此阶段，选用国外成熟数据库软件产品是信息化建设的主要路线；近期，受国际形势剧烈变化影响，我国各行各业对基础科学-109-和数据管理的安全性及技术连续性提出了较高的要求。数据库作为“基础软件皇冠上的明珠”，其核心技术的自主性和可迭代性的需求是行业演进的首要方向。2.2.数据库标准概况数据库标准概况标准是人们对重复性的事、物、概念做出的统一规定，在国家标准 GB/T 20000.1-2014标准化工作指南 第 1 部分:标准化和相关活动的通用术语中，标准被定义为：“通过标准化活动，按照规定的程序经协商一致制定，为各种活动或其结果提供规则、指南或特性，供共同使用和重复使用的一种文件。”“数据库”早期是作为一个非计算机术语被提出的，直到上世纪六十年代才被具象化为“数据库管理系统”一款计算机软件。经历了短暂的层次模型和网状模型阶段后，数据库于 1970年被 E.F.CODD 在A Relational Model of Data for Large Shared Data Banks一文中正式过渡为关系模型，并经历了漫长的探索和实践才形成了标准。3.3.国外数据库标准发展及现状国外数据库标准发展及现状3.13.1 国外数据库标准化背景国外数据库标准化背景在 E.F.CODD 定义了关系型数据库的特征后，人们纷纷以当时先进的软硬件技术开始研发基于计算机的数据库软件，其中 IBM 公司作为早期的研发主力，除了开发出了第一款关系型数据库原型软件 System R 外，还定义了针对该软件的“结构化的英文查询语言（Structured EnglishQuery Language）”即 SEQUEL（1973），后续改名为 SQL。在后来的近 10 年间，IBM 并未在关系型数据库中投入过多精力，直到 1970 年末期。“关系软件公司（Relational Software,Inc.）”，即后来的 Oracle 公司，开发出了一款基于 SQL 语言的关系型数据库软件，并转售给了美国军队，后又在 1979 年基于 VAX 计算机开发出了商业版的 Oracle v2.0 并大获成功，开启了关系型数据库的商业化时代。此时，IBM 才开始研发基于 System R 的 SQL/DS、DB2 等关系型数据库软件，并与 Oracle 同台竞争。不过，无论是 Oracle 还是 IBM 都基于 SQL 语言来操作各自研发的数据库，这也为后面 SQL 语言的标准化奠定了良好的基础。3.23.2 国外数据库标准化依据国外数据库标准化依据从国外的数据库演进路线可以看出，各家数据库企业研发出的关系型数据库产品已经从事实上遵从了A Relational Model of Data for Large Shared Data Banks中提出的关系型数据库12 条准则，包括信息准则、保证访问准则、统一的数据子语言、数据的物理独立性、数据逻辑独立性、数据完整的独立性、分布独立性等。其中“统一的数据子语言”准则的具体含义是：一个关系数据库管理系统可以具有几种语言和多种终端访问方式，但必须有一种语言，它的语句可以表示-110-为严格语法规定的字符串，并能全面的支持各种规则。这条准则就提供了让数据库的查询语言标准化的前提-通用性和重复性。3.33.3 国外数据库标准化体系国外数据库标准化体系经过近 10 年的商业化实践，数据库的架构、实现在不停演进，但是 SQL 语言则被固定了下来，于 1986 年被 ANSI 组织采纳并作为通用标准，命名为 SQL-86。次年，ISO 组织将其列为国际标准并囊括在 ISO/IEC JTC 1 的信息技术版块中，取标准号为 ISO/IEC 9075。自此，SQL 语言正式被列为数据库的国际标准。具体来看，SQL语言历经了SQL-86、SQL-89、SQL-92、SQL:1999、SQL:2003、SQL:2006、SQL:2008、SQL:2011、SQL:2016 等版本的迭代。从 SQL-86 的单独标准扩充到 SQL:2016的 9 个系列标准，SQL 语言在不断完善中，下图列出了截止 2022 年 12 月份，首次出现的 SQL系列标准的时间和版本：图 1：SQL语言标准发展历程除了 ISO/IEC 9075 的 SQL 标准外，还基于此衍生出了 ISO/IEC 13249 系列标准用于定义SQL 多媒体和应用程序包。其目的是统一典型的访问数据库的应用程序，如文本、图片、数据挖掘和空间数据。4.4.国内数据库标准发展及现状国内数据库标准发展及现状4.14.1 国内数据库标准化背景国内数据库标准化背景我国数据库相关标准起步并不算晚，早在 1991 年机电十五所对 ISO/IEC 9075:1989（SQL-89）进行了采标，编撰了 GB/T 12991-1991信息处理系统 数据库语言 SQL。但遗憾的是，国内数据库行业在接下来的一段时间中仿佛失去了活力。从 1991 年至 2006 年的 15 年间，国内没有一家机构或者单位进行过数据库方面的国际标准采标或者原创标准的编制，GB/T-111-12991-1991 也是在 2008 年才进行了第一次更新，替换为了 GB/T 12991.1-2008 信息技术数据库语言 SQL 第 1 部分:框架。在当时，SQL 国际标准已经迭代了 3 次，系列标准也扩充到了 14 部分，最重要的规定 SQL 语法（Syntax）的 ISO/IEC 9075-2 标准至今并未采标发布。我国数据库安全方面的标准也是在 2006 年才首次制定（GB/T 20273-2006信息安全技术 数据库管理系统安全技术要求）。早期由于我国对数据库产品研发、理论研究以及相关标准编撰制定的不重视，极大影响了目前的数据库市场的自主性和原创性。4.24.2 国内数据库标准体系国内数据库标准体系国外市场相对成熟和固化，数据库使用方式相对自由，数据库使用者对数据库产品的实现方式和原理并不是很关心，所以标准体系聚焦在数据库的使用与访问层面（SQL 语言）。国内数据库起步较晚，从产品成熟度和使用者信任度来说并不能完全匹配市场要求，所以我国的标准规范要求更聚焦在数据库产品本身（技术要求与规范）。国内目前的数据库方面标准呈现多而散，体系化弱的态势。具体来看，截止 2022 年 12 月份，国内已发布数据库标准分类（关系型）及归口组织如下图所示：图 1：国内数据库标准分类（关系型）及归口组织总结来说，国内标准体系呈现如下的状态：基础标准时效性不足基础标准时效性不足对标国外数据库标准体系，国内数据库的基础类标准（国标、行标）更新和修订频率较低，除了安全类的数据库技术要求外，SQL 标准、术语标准等已超过 10 年未更新。-112-标准耦合性较高标准耦合性较高国内的各个团体编制的标准耦合性过高，不同的数据库标准规范有大量重复要求。虽然业界对数据库的应用场景存在不同诉求，但是标准的编制应该更多从技术通用性出发，例如 ISO/IEC9075 的 SQL 标准可以覆盖到所有使用 SQL 语言的数据库。配套标准较少配套标准较少数据库是一款商品化程度较高的产品，除了对产品本身的技术要求外，还需要对数据库的访问（接口）、同步、迁移等进行规范性要求。5.5.国内数据库标准发展方向及建议国内数据库标准发展方向及建议5.15.1 基础标准编制和修订从快基础标准编制和修订从快国内数据库产品技术要求、检测规范、术语定义、接口规范等基础类标准滞后、匮乏，导致如果想编制更多的外部标准和流程规范标准无标可依。建议建议：统一各个数据库编制团体的力量，先对陈旧标准进行修订。如果有基础类的国际标准优先进行采标。5.25.2 标准编制有的放矢标准编制有的放矢标准的目的是规范市场，引导市场。首要是明确标准的读者和适用者，然后分析读者的市场需求，再将需求转化为行业通用的标准条款或者说明，最后编撰标准引导和规范市场。国内目前有不少标准的编撰出发点是“为标准而标准”，需要提高标准编写者的觉悟。建议建议：把标准条款以“解决问题”的方式进行梳理，如果出现条款或者乃至整个标准不具备解决具体市场问题的情况，这一类标准应该杜绝。5.35.3 技术型标准人才培养技术型标准人才培养国内数据库标准编制方面的人才较为欠缺，从厂商角度来看，大部分企业更关注技术和市场本身，不太具有将其抽象成较为通用标准的能力，也对标准的意义与标准的撰写方式较为陌生；对标准机构来说，数据库属于门槛较高的基础软件产品，不仅仅涉及技术，还涉及市场或更多因素，所以可能难以把控标准的适用性与通用性。建议建议：由企业或者有标准化需求的单位组织技术人员或者解决方案专家培训标准撰写的相关能力，了解标准体系、标准意义等。-113-四、四、数据库数据库服务服务及及智能运维智能运维1.1.数据库服务数据库服务1.11.1 数据库服务的过去、当下与未来数据库服务的过去、当下与未来数据库是支撑企业信息化发展的核心技术之一，信息化的高速发展离不开数据库的高效运行与安稳易用，但确保数据库系统的高效运行也是一项较为专业的技术需求，因此，数据库服务一直以来都是众多企业、用户的重要需求之一。在国内信息化高速发展的近三十年内，商业数据库 Oracle 在国内一直作为众多企业信息系统的重要支撑，其稳固、安全、易用、高效等特性已经被认可，与此同时，MySQL 数据库作为互联网行业发展的重要支撑也已经被广泛应用，这些商用、开源数据库经过这些年的发展与沉淀，已经成为国际上众多数据库中实力强劲的一员。但众所周知，即使是站在数据库领域的顶端，这些数据库也仍然存在着很多运维、运行方面的问题，需要大量专业的服务支撑，以保证其能够真正的高效运行与安稳易用。在国产数据库高速发展的当下，越来越多的企业开启数据库国产化之路，而在这个过程中，无论是原有数据库的快速替换，还是各种新型数据库的运维支撑，都产生了大量的专业服务需求和人才需求，数据库服务也成为摆在企业面前的重要问题。事实上，Oracle 之所以在全球取得数据库强者的市场地位，并不是仅仅是依赖其技术能力，人才与服务支持在其中起着关键的作用。截至目前，只要是成功的数据库，无论是 Oracle、MySQL 或者 PG，在技术上都会采取开放的策略，通过数十年技术、知识、经验的传播，培养大量的技术人员、技术爱好者、社区力量和生态环境，使第三方技术公司具备了提供相关数据库服务的能力，构建完整“产品-服务-人才”的生态链，从而强力的支撑了企业的数据库服务需求。生态的繁荣使得市场上有大量熟悉数据库的开放人员和运维人员，各种技术问题可以通过社区、群组讨论等方式形成技术热度与成熟解决方案，这也使得企业在选型时更偏向于寻找热度高，成熟度好，技术储备充足的数据库。这种完整生态的构成对数据库本身和产业的发展起到很强的推动作用。对于当下的国产数据库产业而言，生态问题同样无法绕开，事实上，相比于成熟的商业数据库和开源数据库，国产数据库更需要重视生态，特别是服务体系与人才体系的完善与充实。在近几年，数据库国产化的步伐越来越快，这种急迫性进一步倒逼了对服务市场的迫切需求。需要知道的是，国产数据库的使用不但不会降低技术服务的门槛，反而会大幅增加企业对于服务的依赖。首先，由于数据库本身能力的差异，国产数据库的使用往往需要引入更多的服务器数量，特-114-别是当采用了分布式架构的数据库后，其数据库环境与架构复杂度大幅增加。无论从需求数量上看，还是从运维难度上看，国产数据库都会使运维支撑服务的工作量和难度大幅增加；其次，从供给侧看，熟悉国产数据库并具备基本数据库服务能力的技术人员相对匮乏，成熟的解决方案与技术资料也很难获取，这使得企业在选择国产数据库之后，在后续服务上有很大的缺口急需填补。1.21.2 服务服务 的强需求的强需求在当下，在国内企业面临数据库选择时，很难将单一数据库的选择作为企业信息化发展的决策，因此，同时采用多种国产、开源数据库作为企业信息系统的支撑已经是普遍共识和行为。无论企业使用日益成为趋势的云上数据库，还是保持原有的服务器模式部署数据库，都会存在多种数据库并行运维的情况，这也进一步增加了服务深度、服务广度、服务专业度等多维度的需求。以上种种表明，对于多种数据库并存共用的企业而言，不但单一数据库服务的专业需求在增加，而且需要能够同时支撑多种数据库的服务需求。目前国产数据库生态还未健全、技术人才严重不足的情况下，单纯的人力服务已经无法适应和满足企业的需求，必须采用更为有效且具备一定自动化处理能力的方式来实现数据库的专业服务。因此，当国内数据库产业的多元、异构、国产、开源成为必然的趋势时，伴随而来的，也就是数据库服务形态的转换，数据库服务将从单纯的人工服务，逐渐转向新的服务 方式，即自动、智能数据库服务平台 高专精服务专家的模式，形成类似 8 2 模式的支撑体系，即八成以上的运维支撑仅需自动化平台，剩余两成的专业需求（如架构规划设计、选型、优化、疑难问题处理）由专业人员支撑。实际上，无论是云数据库厂商还是传统数据库服务商，都已经开始构筑能够提供自动化、智能化、多元数据库支撑的数据库运维平台。在此趋势和背景下，以实现数据库全生命周期管理的标准化、自动化和智能化为目标，构建一站式数据库管理平台已成为未来国内数据库产业发展和企业数据库服务的刚需。标准化作为多元异构环境下统管统控的基础，以业界最佳实践作为理论依据和落地准则，从管理模式、管理架构、管理功能、资源供给、访问权限等多方面实现统一化和标准化，屏蔽多元异构下各类型数据库所带来的管理上的差异，并通过标准化在平台内以模版、流程、权限等方式的落地，实现数据库运管制度和规范的软件化，彻底解决了原来有规范但难保持、难核验的问题，为后一步深度的数据库管理打造一个统一的标准底座。自动化是以软件代替人工以极大提高效率和准确度的必备动作，也是数据库管理能力的核心所在，在标准化的基础上，通过自动化实现数据库的自动部署、自动监控告警、自动巡检、自动SQL 审核、自动高可用切换等高频运维工作，区别于单一系统时的运管系统，复杂多样的管理对象是对自动化最大的挑战，要求数据库管理平台的构建者具备丰富的多类型数据库运维管理经验，-115-