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