2021年中国数据库行业研究报告.pdf

中国数据库行业研究报告2021年22021.5 iResearch I摘要来源：艾瑞咨询研究院自主研究及绘制。中国数据库市场规模：据艾瑞统计，2020年中国数据库市场总规模达247.1亿元，同比增长16.2%。2020-2022中国数据库市场预计将呈高增长态势，由多方面因素促成：1）政策利好，国家大力鼓励国产数据库厂商的发展；2）需求拉动，国产化和数字化转型带动需求的爆发增长；3）供给端传统、初创和跨界各类型厂商厚积薄发，产品和技术经历了多年工程实践的打磨走向成熟；4）国内企业对基础软件的付费意愿和IT支出占比在逐年提升，有利于市场的长期发展。中国数据库市场挑战与趋势：约2015年起，中国数据库市场进入了百花齐放、活跃创新的阶段，但仍面临多方挑战：1）分布式数据库在事务、性能等环节仍待优化；2）信创为国产厂商提供成长沃土，未来发展仍待市场磨炼；3）数据频繁迁移、多库长期并存为厂商提出新的诉求；4）CPU、内存等硬件变化为数据库设计提供更多的想象空间。综合供需两端视角，中国数据库未来发展将呈现多种趋势：1）多场景现状与融合需求长期并存；2）云数据库（包括公有、非公有各种形式）成为主流；3）湖仓一体服务联机交易和联机分析；4）开源成为产业互联网时代数据库厂商的破局之刃；5）人工智能延伸DBA的能力半径，优化数据库性能，是数据库下一步发展的目标。中国数据库市场格局：1）多类型数据库百花齐放，关系型占据绝对主流。从营收角度，2020年中国关系型数据库的市场份额达90%左右，NoSQL数据库更多地基于开源模式，产生二开和服务的费用。2）借助政策东风，国产厂商厚积薄发，市场版图快速扩张。受国产化影响，2020年国外数据库厂商的市场份额下降至52.6%，达梦金仓等传统国产厂商的市场份额上升至7.1%。3）公有云数据库增速放缓，未来仍有一定渗透空间。2020年中国公有云部署模式的数据库市场份额占比达32.7%，预计到2025年将达到47.2%，云厂商将成为中国数据库市场市占率最大的阵营。4）以NewSQL/NoSQL/SQL on Hadoop为典型路线的初创厂商不断涌现，成为中国数据库市场增长率最快的赛道，预计未来五年有10倍以上的成长空间。3产品与技术：数据库内涵与分类1供给与需求：数据库市场现状与选型2案例与启示：数据库典型厂商案例3机遇与挑战：数据库未来发展趋势442021.5 iResearch I数据库定义数据库是由DBMS搭建管理的数据及数据间关系的集合体数据是数据库中存储的基本对象，包括数字、图像、音频等形式，在进行逐级抽象后存储在数据库中。数据库是由特定软件，即数据库管理系统（DBMS）搭建、处理、维护的数据及数据间逻辑关系的集合体。它面向多种应用，可以被多个用户、多个应用程序所共享。DBMS是负责数据库搭建、使用和维护的大型系统软件，它对数据进行统一控制管理，以保证数据的完整性和安全性。数据库和数据库管理系统共同组成了数据库系统（DBS）。来源：公开资料，专家访谈，艾瑞咨询研究院自主研究及绘制。数据库系统架构数据库（DB）数据库管理系统（DBMS）搭建读取修改维护管理写入应用程序数据库系统（DBS）应用程序终端用户DBA终端用户应用程序数据库应用存储网络计算数据库处于IT架构的核心位置，向上是各种应用的支撑引擎，向下调动计算、网络、存储等基础资源。5按数据结构分类 传统关系型数据库 NoSQL数据库 NewSQL数据库 多模数据库62021.5 iResearch I关系型数据库ACID特性传统关系型数据库保证ACID特性，是当今主流的数据库类型随着市场和技术的发展，关系模型因其特有的原子性、一致性、隔离性和持久性优势，取代了层次模型和网络模型，成为了当代主流的数据模型。关系型数据库建立在关系模型上，是多个关系（Relation）即二维表的集合。每个表有唯一的名字，表的每一行代表了一组值之间的联系，称为元组（Tuple），每一列是实体的描述，具有相同的数据类型，称为属性（Attribute）或者字段（Field）。为了唯一标识一张关系表，关系型数据库选定主码/键（Primary Key）来区分不同元组的候选码；同时为了维护数据库的完整性和数据的一致性，设置外码/键（属性）、参照关系（表）建立表之间的联系。注释：1、下划线表示主码；2、此处关系型数据库指传统关系型数据库，支持横向扩展的关系型OLTP数据库（NewSQL）在后续讨论；来源：公开资料，专家访谈，艾瑞咨询研究院自主研究及绘制。关系型数据库架构关系1属性1属性2属性3属性4关系2属性1属性2属性5关系3属性6属性2属性3关系5属性6属性8关系4属性5属性7关系1（属性1，属性2，属性3，属性4）关系2（属性1，属性2，属性5）关系3（属性6，属性2，属性3）关系4（属性5，属性7）关系5（属性6，属性8）原子性Atomicity一致性Consistency隔离性Isolation持久性Durability为避免纠纷，数据库中的事务执行被视作原子不可再分，事务（例如转账）中的操作 要 么 全 部 执 行 要 么 失 败 回 滚（Rollback），一般通过日志机制实现。为保证业务逻辑的一致性，数据库通过设置约束和触发器来保证其完整性约束不被破坏，即每个事务能够看到的数据总是保持一致。为防止事务之间的脏读、幻读、不可重复读，数据库通过加锁，保证多个事务并发访问时，事务之间是隔离的，互不干扰。为防止意外事故（例如断电）导致数据缺失，数据库保证事务对其所作的修改被永久保存，不会被回滚。72021.5 iResearch I关系型数据库语言：SQL作为RBDMS的标准语言，用于定义、查询、修改和管理查询即向RBDMS寻求特定的信息，SQL（结构化查询语言），是RBDMS的标准语言，广泛应用于各主流关系型数据库，它包括DDL（数据定义语言）、DML（数据操纵语言）、DCL（数据控制语言）和TCL（事务控制语言）。SQL作为一种声明式语言，同时具有较好的可扩展性，不仅用于查询，还可以用来定义数据结构、插入、修改和删除数据、执行管理任务（安全、用户管理）等。来源：公开资料，专家访谈，艾瑞咨询研究院自主研究及绘制。SQL主要构成类型SQLDDLDMLDCLTCL命令CREATEALTERDROPTRUNCATECOMMENTRENAMESELECTINSERTUPDATEDELETEMERGECALLEXPLAINPLANLOCK TABLEGRANTDENYREVOKECOMMITSAVEPOINT ROLLBACK 任务用于定义数据库的外模式、概念模式、内模式及其相互的映像，定义数据的完整性和约束用来设置、更改数据库用户或者角色的权限对关系型数据库管理系统里可能发生的事务进行处理让用户或程序员使用，实现对数据库中数据的操作，包括过程式DML和声明式DML两类。SQL语言特点SQL语言集数据定义、数据操纵、数据控制、事务控制功能于一体，在一次操作中可以使用任何语句，为数据库开发提供了良好的环境。语言功能一体化SQL语言不涉及存取结构以及具体的执行过程，因而简化了编程的复杂性，提高了数据的独立性。高度非过程化的编程语言SQL语言的操作对象和输出结果都是元组集合，可以实现对一组记录的增删查改。面向集合的操作SQL作为自含式语言，可作为联机交互使用，每个SQL语句可以独立完成其操作；作为嵌入式语言，SQL语句可以嵌入到高级程序语言中使用。自含式+嵌入式语言SQL用简单的语句（核心命令：CREATE,DROP,ALTER,SELECT,DELETE,INSERT,UPDATE,GRANT,REVOKE）和接近英语口语的语法完成了数据库创建管理维护的复杂功能。简洁易用82021.5 iResearch INoSQL数据库针对数据库高可用、可扩展的需求，NoSQL兴起NoSQL即Not Only SQL，NoSQL数据库指那些不使用关系模型、分布式、不保证遵循ACID原型的数据库。关系型数据库通过“强一致性”来避免数据库应用中出现的写入冲突（两个客户端同时修改一份数据）和读写冲突（某客户端在另一个客户端执行写入操作过程中读取数据）。“CAP定理”阐述了数据库系统的权衡问题，即当有可能发生“网络分区”时，必须在数据的“可用性”与“一致性”之间权衡。电商、社交网络等场景的容错度较高但需要实时可用，NoSQL数据库由于只要求达到“最终一致性”，可以轻松处理海量数据并实现高用户负载的扩展，在此类场景下应用较广。来源：公开资料，专家访谈，艾瑞咨询研究院自主研究及绘制。NoSQL数据库BASE原则基本可用Basically AvailableNoSQL数据库在出现故障时，允许损失部分可用功能，或者降低响应速度，从而保证核心功能可用。软状态Soft state允许系统中的数据存在中间状态，即不同节点的数据副本同步的过程中存在不一致，并认为中间状态的存在不会影响到系统整体的可用性。最终一致性Eventual consistency在系统保证没有新的操作、无故障发生时，经过一段时间，数据库中的最终数据能够达到一致。其延迟的时间取决于网络延迟、系统负载和数据复制方案设计等因素。数据库设计CAP定理一致性Consistency可用性Availability分区容错性Partition-Tolerance无论连接到哪个节点，所有客户端访问的数据副本是一致的即使某一个或多个节点发生故障，每次请求都能够得到非错的响应即使系统中的节点之间发生了通信故障，群集也能够继续工作92021.5 iResearch Icontainer_nameNoSQL数据库存储结构采用键值、宽列、文档、图等结构灵活存储NoSQL数据库使用不同的数据存储模型来满足不同的场景需求，当今主流的NoSQL存储模型有键值对存储、宽列式存储、文档型存储和图形存储，以及扩展的RDF、时序、搜索引擎等。它们基于不同的场景需求，提出了相应的存储架构，从而满足传统关系型数据库所无法覆盖的场景。但是采用这些模型的 NoSQL 数据库并不提供规范化，本身在设计上是模式自由的（schema-free），因而保证了存储的敏捷性，可以依据业务变化而调整。来源：公开资料，专家访谈，艾瑞咨询研究院自主研究及绘制。典型NoSQL数据库介绍title:subtitleaaabbb键（Key）值（Value）键值(Key-Value)数据库以简单的键值对方式来存储数据，键是唯一的标识符。在这种存储结构下，数据库查询时只需要寻找单个键并返回其对应值即可，它通过牺牲数据的结构性，大大提高了读写的速度。键值数据库宽列(Wide-Column)数据库将数据存储在记录中，以行键唯一标识该记录中的列，同时其一行中包含大量动态列，因此可以将其视为二维的键值数据库。它解决了部分列操作、数据压缩（不存储null）和数据过滤的问题。宽列数据库title1aaatitle2列键(Column Key)bbb值(Value)行键（Row Key）row_name应用场景：Web应用程序和会话、PUB/SUB、内存中的数据缓存、购物车等应用场景：时间序列、历史记录、地理信息等文档(Document)数据库以文档格式（JSON、BSON、XML或YAML）储存和查询。文档没有一致的格式，因此文档数据库具有直观的数据模型、动态灵活的架构、横向可扩展的优势，但同时牺牲了一定的安全性和可靠性。文档数据库应用场景：内容管理、APP、目录、日志文件等集合JSONDoc1JSONDoc3JSONDoc2子集合JSONDoc1JSONDoc2大数据时代带来两个明显的变化，即数据量的剧增和数据关联的复杂化。图(Graph）数据库使用图结构进行查询，并通过节点、边、标签和属性等方式来存储数据，可以较好的模拟现实世界中的实体及其复杂关系，具有敏捷、可扩展和高性能的特性，在大数据时代得到了广泛的应用。图数据库节点应用场景：社交网络、知识图谱、搜索引擎等标签标签标签标签Key:valueKey:valueKey:value属性边102021.5 iResearch I关系型数据库 vs NoSQL数据库在标准化一致性与扩展可用性方面各有优势，适用不同场景20世纪70年代，为减少数据冗余、降低存储费用，关系型数据库诞生。21世纪初，随着移动互联网和新一代信息技术的发展，关系型数据库在大数据处理分析和读写性能方面的局限性逐渐凸显，NoSQL运动开展起来。NoSQL数据库解决了关系型数据库只能垂直扩展（即在硬件方面增强）的限制，通过分库分表的方式实现水平扩展，满足不断扩张的业务。两种数据库在数据完整性、横向扩展性、读写可用性、产品成熟性和架构灵活性等方面各有侧重，其适用的场景也有所不同。传统关系型数据库 vs NoSQL数据库NoSQL数据库优势NoSQL数据库局限适用性：对数据安全性和事务支持方面有高度要求的场景，例如电信、电力、金融机构等行业的核心系统适用性：对读写性能要求高，且需要处理非结构化、海量的数据，且数据增长无法预期的场景，例如电商、社交网络、搜索引擎等来源：公开资料，专家访谈，艾瑞咨询研究院自主研究及绘制。满足ACID原则，严格遵守数据完整性约束；具有标准化语言SQL，查询操作方便；二维表数据结构，减少数据的冗余，提高了存储空间的利用效率，维护也比较容易；发展时间长，产品标准化、社区成熟、服务稳定为提高可用性，在数据一致性方面有所牺牲；没有标准化的查询语言，学习和使用成本较高，不适合复杂查询；相关理论和技术成熟度较低；缺乏第三方生态系统，公司需要自己开发BI和分析工具架构刚性，前期需要进行完备的设计，后续修改成本高；缺乏横向可扩展性，需要解决跨服务器JOIN等问题；海量数据和高并发条件下读写效率较低；为维护事务一致性，传统关系型数据库需要付出较大的开销采用动态架构，无需开发人员提前设定数据架构，可以随时更改，敏捷灵活；可扩展性高，通过横向扩展提高可用性，无明显的单点故障；存储模式简单，大多NoSQL数据库可以实现极高的性能（传统）关系型数据库优势（传统）关系型数据库局限112021.5 iResearch INewSQL数据库在底层解决了分布式问题，并满足ACID事务要求NoSQL虽然在可扩展性和可用性方面表现优秀，但是无法满足事务一致性的要求。许多对数据完整性要求较高且数据量较大的企业，只能在应用关系型数据库的同时，购买功能更强大的硬件，或者定制化开发中间件来实现分布扩展。2011年，451 Group的Matthew Aslett 提出了“NewSQL”术语用以定义新出现的“可横向扩展的OLTP关系型数据库”。NewSQL数据库作为一种新兴并正在发展的解决方案，各产品在架构、特性和功能方面各有不同，当前并无通用的定义。但大多NewSQL数据库共有的两个特点：1）保持NoSQL数据库的可扩展性和高性能，2）采用以SQL为主要接口的关系数据模型，保持事务ACID特性。NewSQL并非颠覆式的创新，而是将业界和学术界已有的技术，例如面向内存(memory-oriented)的数据存储、分片、MVCC（多版本并发控制）、TO（时间戳）并发控制、二级索引、广域网数据复制机制、故障恢复机制等，集中到一个架构内。企业采用NewSQL数据库需要较高的硬件和学习成本，且需要承担产品不成熟带来的未知风险。注释：Matthew Aslett在2016年发表的论文中将NewSQL数据库分为三类：全新架构的NewSQL数据库、基于中间件-分片的NewSQL数据库和基于云环境和全新架构提供DBaaS的NewSQL数据库，此页只讨论一、三两类，第二种在后续分布式数据库处讨论。来源：公开资料，专家访谈，艾瑞咨询研究院自主研究及绘制。传统关系型数据库 vs NoSQL vs NewSQL传统关系型数据库NoSQLNewSQL可扩展性纵向扩展水平扩展水平扩展关系模型支持不支持支持ACID事务支持不支持支持性能海量数据读写性能差高性能处理海量数据高性能处理海量数据SQL语言支持不原生支持支持模式自由不支持支持不支持OLTP支持效果较差支持OLAP轻量查询支持支持成熟度高较高较低122021.5 iResearch I多模数据库通过改变原数据和存储结构来扩展多模(Multi-Model)数据库管理系统原数据模型扩展支持新存储方式+新数据模型PostgreSQL关系关系、键值对、JSON、XML、嵌套数据/UDT/对象SQL Server关系关系、JSON、XML、图、嵌套数据/UDT/对象IBM DB2关系关系、XML、图、RDF、嵌套数据/UDT/对象Oracle DB关系关系、JSON、XML、RDF、嵌套数据/UDT/对象原存储方式+新数据模型MySQL关系关系、键值对、嵌套数据/UDT/对象ArangoDB文档键值对、JSON、图MongoDB文档键值对、JSON、嵌套数据/UDT/对象新接口+原存储模型阿里Lindorm原生多模宽列、时序、文档、搜索引擎Couchbase文档键值对、JSON多模型（Multi-Model）一词于2012年被 Luca Garulli 第一次提出，是一种可以在多个模型中存储和查询数据的数据库，为异构数据提供了较好的解决方案。数据库扩展原有模型的路径主要有四种：新存储方式+新数据模型、原存储方式+新数据模型、新接口+原存储模型、原存储模型。第一种的典型代表是支持XML的数据库，它们使用原生XML方法来高效地存储和查询；第二种的典型代表是文档数据库，通过采用特殊的边集合来扩展图结构中的边信息，例如Arango DB和MongoDB；第三种在原关系型存储层上搭建了新的一层，采用相同的方式存储不同类型数据，但是增加了对新数据类型的增删查改支持；第四种即将所有的数据结构简化为Key-Value形式存储。多模数据库的发展时间较短，当今市场上数据库对多模的支持程度不同，在数据模型、索引、多模查询优化策略等方面的能力参差不齐。来源：公开资料，专家访谈，艾瑞咨询研究院自主研究及绘制。多模数据库（典型）扩展路径13按架构分类 分布式数据库 单机数据库142021.5 iResearch I分布式数据库单机性能有限条件下，解决数据量快速增长的最佳解决方案分布式数据库系统的诞生远早于NoSQL和NewSQL数据库，它产生于20世纪70年达末，在80年代由于计算机功能和网络技术的增强而进一步成长。分布式数据库系统即利用计算机网络将物理上分散的多个数据库连接起来组成一个逻辑上统一的数据库，为业务应用提供完整的联机事务处理。随着数据量爆发式的增长以及应用负载的快速增加，单一服务器模式越来越难应对当今应用对数据和事务处理的需求，分布式成为热门的解决方案。分布式数据库的实现形式大致可以分为同构和异构两种。同构分布式数据库系统中，所有的站点都所使用相同的数据架构、DBMS、操作系统和计算机体系结构；异构分布式数据库系统中，不同的站点使用不同的数据模型、DBMS、操作系统和硬件，通过应用程序接口、全局模式和联邦数据库系统结构实现不同数据库之间数据信息、硬件设备和人力资源的合并与共享。来源：公开资料，专家访谈，艾瑞咨询研究院自主研究及绘制。同构型分布式数据库实现形式异构型GDBMSLDBMS1LDBMS2LDBMS3DB1DB2DB3全局用户1全局用户2全局用户3 同构型数据库系统中每个节点的DBMS、操作系统和计算机硬件都相同；全局的数据库管理系统（GDBMS）和局部的数据库管理系统（LDBMS）在数据模型、访问方法、查询语言、优化策略上都相同。异构型数据库系统的各个节点DBMS、操作系统和计算机体系结构均可能不同；异构型数据库系统通常产生于已有数据库基础上，出于业务考虑需要将多个单个站点进行集成。因此多涉及到各节点间的硬件和软件不同带来的转换问题，使得处理极其复杂。152021.5 iResearch I分布式核心技术（一）：复制/分区通过“数据冗余”和“数据分割”实现分布式的扩展分布式数据库的实现方式一般包括两种：复制(Replication)和分区分片(Partitioning/Sharding)。一种是将数据复制到多个服务器上，从而每份数据都能在多个节点中找到；另一种是将不同的数据分片存放在多个服务器中，每一个数据子集都专门由一台服务器负责。复制提供了冗余的能力，包括主从复制（唯一节点负责写入，其他节点保持同步、负责读取）和对等复制（任何节点均可写入，相互协调、同步数据）。随着数据量的增加，出于负载均衡的目的，架构师对数据库进行分区，分区包括垂直分区（列）和水平分区（行）；分片(Sharding)是对数据库系统的水平分区，包括基于键值的分片、基于范围的分片、基于目录的分片等方式。来源：公开资料，专家访谈，艾瑞咨询研究院自主研究及绘制。水平分区（分片）与垂直分片IDNAMEGENDERADRESS1aaamaleAAA2bbbmaleBBB3cccfemaleCCC4dddfemaleDDDIDNAMEGENDERADRESS1aaamaleAAA2bbbmaleBBBIDNAMEADRESS1aaaAAA2bbbBBB3cccCCC4dddDDDIDGENDERADRESS1maleAAA2maleBBB3femaleCCC4femaleDDD垂直分区水平分区（分片）IDNAMEGENDERADRESS1aaamaleAAA2bbbmaleBBB较多162021.5 iResearch I分布式核心技术（二）：分布式事务通过机制设计保证分布式环境下的事务ACID特性单体系统到分布式系统的变化增加了数据库实现ACID特性的难度，但许多环境下企业仍要求较强的一致性。经过多年的发展，各数据库厂商提出了多种分布式事务解决方案，例如两阶段提交（2PC）/三阶段提交（3PC）、TCC方案、可靠消息最终一致性（本地消息表方案-eBay、RocketMQ 事务消息方案-阿里/Apache）、最大努力通知方案等。来源：公开资料，专家访谈，艾瑞咨询研究院自主研究及绘制。典型分布式事务解决方案两阶段提交（2PC）是一种在多节点之间实现事务原子提交的算法，它把事务处理的过程分为prepare-commit两个阶段，增加事务处理器来保证所有节点要么全部提交，要么全部回滚。优势与局限：2PC协议原理简单，保证了强一致性。但是由于机制完全依赖事务管理器管理且过于悲观导致了单点问题（事务管理器一旦崩溃将全局崩溃）、堵塞问题以及事务处理的延迟。针对以上问题，3PC协议在2PC的两阶段中插入了一个准备阶段并引入了超时机制，解决了2PC阻塞的问题，但仍可能出现数据不一致。两阶段提交（2PC）事务管理器节点1节点2事务管理器节点1节点2事务管理器节点1节点2事务管理器节点1节点2成功失败原子瞬间阶段1阶段2“一票否决权”最大努力通知最大努力通知关注交易后的通知事务，发起方通过一定机制，最大努力将业务处理结果通知到接收方，若消息接收不到，则接收方主动调用接口查询业务处理结果。优势与局限：最大努力通知方案下被动方的处理结果不影响主动方的处理结果，适用于跨企业系统间的操作。它是分布式事务中要求最低的一种，适用于一些仅要求最终一致性，且时间敏感度低的业务。发起通知方接收通知方MQMQ业务执行触发，请用业务执行接口发送消息消息ACK机制172021.5 iResearch I分布式架构创新（一）：无共享完全共享无共享：不同层次横向扩展的实现数据库构架设计中主要有完全共享(Shared Everything)、共享内存(Shared Memory)、共享磁盘(Shared Disk)和无共享(Shared Nothing)四种。完全共享模式针对单个主机，拥有完全透明共享CPU、内存和磁盘，并行处理能力较差；共享磁盘和共享内存模式允许增加节点提高并行处理能力，但是随着数据量级的扩大，内存访问和网络带宽之间冲突增强，系统处理速度反而变慢。无共享模式下数据库的每个处理单元独立运行，并控制自己的内存和磁盘资源，相互之间通过协议通信。无共享架构并行处理和扩展能力较好，数据库通过增加低成本的计算设备作为系统的节点，获得了无限线性扩展的可能性，因而得到了广泛的应用。来源：艾瑞咨询研究院自主研究及绘制。无共享（Shared nothing）共享磁盘（Shared disk）共享内存（Shared memory）完全共享（Shared everything）CPU磁盘内存分布式架构创新：不同层次的数据共享网络网络网络182021.5 iResearch I分布式架构创新（二）:计算存储分离为分布式数据库资源弹性扩展的诉求提供了新思路除了基于无共享模式进行分区分片，在云计算时代，一种新的创新架构被提出，即计算-存储分离架构（大多NewSQL数据库采用此种架构）。近十年互联网的发展，网络的性能得到了大幅度的提升，高效压缩算法和存储结构的优化也减少了IO数量，在数据本地化优化较好的数据计算集群中，大量网络带宽处于闲置状态，然而存储和计算耦合的架构不能很好的实现弹性。云计算提供了解决思路，它的核心思想包括分层和虚拟化：对IT架构分层后，每一层可以按各自的能力进行极限扩展；虚拟化后按租户隔离，可以提供高效率的弹性计算，降低了成本。计算-存储分离架构即“云”的模式和形态之一，将数据计算和存储进行分层，并通过高速网络连接。在这种架构下，数据库可以更加充分的利用不对称的存储资源和计算资源，让不同层都可以按照各自最优的模式进行横向扩展。来源：公开资料，专家访谈，艾瑞咨询研究院自主研究及绘制。计算存储分离架构计算存储集群计算存储耦合节点1计算存储耦合节点2查询数据存储分析挖掘处理查询数据存储分析挖掘处理计算集群存储集群查询分析挖掘处理计算节点1查询分析挖掘处理计算节点1数据存储存储节点1数据存储存储节点2比较：计算和存储在一个集群里，性能表现较好比较：架构灵活、易扩展；优化利用率，有效的降低了成本192021.5 iResearch I分布式数据库 vs 单机数据库单机数据库是企业的最初选择，它可以利用位于系统中心的服务器统一管理所有的共享资源，并处理来自用户的请求。单机数据库积累了大量的实践经验，在强一致性、稳定性、迁移成本和运维管理方面都更胜一筹，而且各资源独立，应用隔离性好，数据安全性高。分布式数据库在灵活性和扩展性方面具有优势，一方面分布式给予了每个部门根据其应用程序的特定需求选择软硬件的自由，不必因为共享IT架构而做出妥协；另一方面分布式IT架构天生自带可扩展属性，能够根据业务规模实现无限弹性扩展。来源：公开资料，专家访谈，艾瑞咨询研究院自主研究及绘制。分布式数据库 vs 单机数据库单机分布式优点弹性扩展：通过横向扩展解决了单机性能上限和业务数据量增长不匹配的问题；高度可用：即使系统中的某些节点不可用（断电、系统崩溃等），也不影响其他节点正常工作，保证了面向用户的高可用；成本控制：企业可以选取较低配置的硬件。缺点复杂性：多节点横向分布提升了架构设计、运维、迁移的难度；安全性：远距离访问和网络通信传输带来了安全和保密方面的风险；数据完整性：多节点读写对事务性提出挑战。分别适用于海量数据场景和核心系统的高性能高可靠处理简单性：数据集中存储和处理，无需处理多个节点之间的协作，架构设计简单，易满足ACID事务需求；可靠性：集中式数据库发展时间长，产品在容灾设计、系统运维等方面都有较成熟的解决方案，稳健可靠易维护。优点性能扩展：面对海量的数据存储需求，集中式数据库想要提升性能只能依赖硬件的提升（纵向扩展），在扩展空间方面具有局限性；成本高昂：高性能的硬件（服务器等）意味着高价，这为企业增添了成本负担。缺点20按部署模式分类 云数据库 本地数据库212021.5 iResearch I云数据库包括云厂商托管的开源数据库和云原生数据库云数据库是在云计算的大背景下发展起来的一种新兴的共享基础架构的方法，它极大地增强了数据库的存储能力，消除了人员、硬件、软件的重复配置，让软、硬件升级变得更加容易。现阶段云数据库主要包括两种：一种是托管在云厂商上的“传统”数据库，例如阿里云、腾讯云上的MySQL、PostgreSQL、MongoDB、Redis等；一种是基于云环境的云原生数据库，例如AWS的Aurora、阿里云的Lindorm和PolarDB等。来源：公开资料，专家访谈，艾瑞咨询研究院自主研究及绘制。云数据库类型云数据库云厂商托管的数据库云原生数据库云基础资源MySQLPostgreSQLMariaDBRedis企业用户在该模式下，云服务厂商负责管理与维护基础设施，并提供优化、备份、恢复、监控等全套解决方案。企业用户无需购买服务器、交换机等软硬件，后续也无需投入大量的人力成本去运维，可以更专注于企业的应用开发。云托管数据库与开源版和商业版数据库相比，是一种“开箱即用、弹性扩展、省钱省力、高度可用”的解决方案。随着云计算和数据库技术的进一步结合，2015年左右云原生数据库诞生，它是基于云环境设计的新型数据库，天生匹配云环境和分布式事务。其核心是存储与计算分离，同时还具备高性能、高可扩展、一致性、容错、易于管理和多云支持等特性。各家云厂商在提供托管服务的同时都在加快自研速度，开发自己的云原生数据库。计算存储分离高可用一致性高性能分布式多云管理支持云原生数据库 阿里云-RDS MySQL版 腾讯云-云数据库MySQL AWS-Amazon RDS 阿里云-PolarDB 腾讯云-TDSQL AWS-Aurora 华为云-GaussDB 222021.5 iResearch I上云迁移“迁移”成为企业数据库上云最不容忽视的隐性成本云模式下企业可以降低自己从头建设数据库及后期运维的成本，吸引了大批企业规划上云。但实际应用中，绝大部分企业都并非从零开始，都具有一定的数据库基础。对于想要应用云数据库的企业，“上云迁移”成为了其最大的门槛。“如何保证数据安全完整，如何建立失败回滚标准，如何对数据库重新进行设计，如何进行数据模型的转换，如何对新架构做调优”，这些问题都需要企业谨慎考虑，具备一定的难度。虽然各公有云厂商针对上云迁移都提供了相应的工具，但由于迁移的复杂性，也催生了许多提供咨询、选型、规划、迁移、运维、优化等服务的中间厂商，近年来发展迅速。来源：公开资料，专家访谈，艾瑞咨询研究院自主研究及绘制。数据库上云迁移步骤根据企业自身具体需求判断选择云数据库还是自建数据库：对于一些大型企业，出于安全性和个性化的考虑，通常采用自建本地数据库的方式 对于一些IT预算有限的中小企业，云数据库提供了可行的解决方案Step1:判断 收集需求 判断解决需求需要哪些能力 评估哪些数据库需要迁移（建议从非关键业务系统、非核心生产系统入手）评估应用程序配合迁移数据库需要作出的改变 建立成功的评判标准和失败回滚原则Step2:计划 数据库备份（热备份or冷备份、部分备份or全部备份）重新设计数据库（可选）复制并将数据（包括备份后对原始数据的更改）重新存储在云中 移交后检查：数据验证、端到端测试（验证基本功能）、性能测试、安全评估Step3:迁移 性能优化：负载测试、分布优化 可用性优化：容灾恢复计划、日志和系统检测、变更检测、系统测试 Step4:优化232021.5 iResearch I云端部署vs本地部署云数据库极大地利用了云计算“资源池化”的优势，在成本、可用性、易用性、扩展性和并行处理方面较传统数据库有绝对优势。云数据库即开即用，用户可以根据自身的业务情况弹性开支、灵活调整；无需从头采购基础软硬件，无需考虑专业人员（DBA）部署，节省了人力物力；同时云数据库大多支持热备架构，可以实现故障秒级自动切换，备份、恢复更加灵活。但同时，由于云环境的特性、产品的不成熟性和市场的混合部署需求，云数据库在数据质量、数据迁移、数据融合、性能优化和规范标准方面仍有改进的空间。来源：公开资料，专家访谈，艾瑞咨询研究院自主研究及绘制。云数据库在成本、易用性等方面具有优势，近年来快速增长云管理系统应用程序SQLJSON客户端节点1节点2节点n物理磁盘负载均衡容灾分区加密索引备份复制服务化云数据库的核心优势与改进空间-虚拟化低成本多租户模式，用户之间共享资源且只用按需付费，节省了成本高可用高水平的容错能力，一个节点崩溃，其他节点也可以继续工作动态可扩展具有无限可扩展性，可以满足不断增加的数据存储需求大规模并行处理并行处理能力强，面对海量数据，几乎可以做到实时的响应易用性不需要关心底层服务器、系统等的部署和运维，开箱即用数据质量云数据库在大数据环境下，容易产生脏数据，影响事务一致性数据迁移将大量、复杂的企业内部数据库数据迁移上云存在一定困难数据融合本地数据与云数据长期并存，需要有效的融合机制，统一管理性能优化云环境为动态负载均衡、资源分配管理提出了新的要求规范标准各大厂商独立发展云数据库，在查询语言、语言模型和安全等方面缺乏统一的规范标准242021.5 iResearch I混合部署部分企业出现反向迁移情况，混合部署成为未来常态一方面，尽管上云是大势所趋，但是由于数据库基础软件的特性和公司战略考虑，在一定时间内，云数据库很难完全替代本地数据库，混合部署成为企业的必然选择。现阶段绝大部分企业都具有一定的IT基础，业务数据都存储在本地自建的数据库里，经过了几十年的积累，具有复杂和海量的特点。短时间内让企业放弃原本投入了大量成本的本地数据库，把海量复杂的数据全面迁移上云，是不现实且不划算的。另一方面，企业私有云部署成为当下的热门选择，公有云数据库市场增速放缓。当企业业务发展到一定规模，对核心系统自主可控的要求也相应地提升，这一阶段的企业反而出现了反向迁移的现象，更多地考虑把部分业务数据从公有云迁移到私有云部署的环境里。来源：公开资料，专家访谈，艾瑞咨询研究院自主研究及绘制。云数据库在企业发展各阶段的应用情况初期中期后期稳定型企业公有云数据库初创型企业扩张型企业 企业具有数据量少、业务简单、预算较紧、IT力量薄弱的特点，对公有云数据库持积极态度，从而实现成本控制。乐于把新业务以及非核心业务部署到“开箱即用”的公有云数据库上，把基础设施搭建等步骤外包，从而配合企业快速的业务扩张。企业更看重IT系统的自主性和安全性，部分公司反而考虑从公有云部署环境迁向自有机房，混合部署成为常态。适用性：适用性：适用性：公有云私有云物理机部署环境变化变化1：传统行业客户将数据库由本地部署环境转向公有云/私有云环境变化2：部分大型企业将公有云环境部署的数据库迁移至私有环境（私有云）25按功能分类 OLTP事务型数据库 OLAP分析型数据库 HTAP混合型数据库262021.5 iResearch IOLTPOLAP产品定位支持实时交易数据的存储、更新、共享通过数据分析现状，发现趋势，支持决策操作基于INSERT,UPDATE,DELETE命令基于SELECT命令聚合数据用以分析数据量实时数据，通常较小聚合历史数据，较大并发访问量高低响应时间毫秒秒，分钟或者小时（取决于处理的数据量）存储结构通常为行存储通常为列存储备份需要定期备份以确保业务连续性可以从OLTP数据库重新加载丢失的数据，以代替常规备份可视化日常业务交易列表视图多维视图满足分析需求典型适用场景快速处理高并发、小批量的数据使用复杂的查询处理大量数据主要用户银行柜员、收银员、仓库管理员等数据分析师、业务分析师、高管等OLTP(事务型)vs OLAP(分析型)分别满足企业联机交易和分析决策的需求，适用范围不同面对事务处理和分析决策的需求，OLTP(Online Transactional Processing)事务型数据库和 OLAP(Online analyticalprocessing)分析型数据库应运而生。OLTP系统主要使用关系模型，保证强一致性，面向一线业务人员，支持多并发、实时、快速地增删查改，例如银行交易、零售电商、车票预订等；OLAP系统可以高速多维分析来自数据仓库、数据集市或者数据湖的数据，可使用关系型或者非关系型的数据库，主要面向分析师和管理者，支持对历史数据的复杂分析操作，从而赋能企业商业智能决策。来源：公开资料，专家访谈，艾瑞咨询研究院自主研