作者介绍：沈炼，蚂蚁数据部数据库内核负责人。2014年入职蚂蚁，承担蚂蚁集团的数据库架构职责，先后负责了核心链路上OceanBase、OceanBase高可用体系建设、NoSQL数据库产品建设。沈炼对互联网金融、数据库内核、数据库高可用体系等领域有着深厚的理解。沈炼秉承“止于至善”的理念，深耕互联网金融和数据库两个专业方向，保持着十年如一日的热情与专注。

背景

何为“在线业务”，即 OLTP(联机事务处理)。OLTP 在互联网时代至关重要，主要应用场景有金融、电子商务、社交网络、医疗、公共事业等，一颦一笑对民生有着直接且巨大的影响。在线业务首要特征是在线，需要提供“持续可用”的服务，对应的技术诉求是服务高可用和数据高可靠;在线业务直面终端用户，重“用户体验”，耗时需要可控，在预期的时间内返回结果，对应的技术诉求是响应实时。现代在线业务必定是Web端或者移动端，流量具有海量性和周期性，对应的技术诉求是高并发性和水平伸缩性。因此在线业务具有一些基本特征：高并发、响应实时、服务持续可用、数据必须可靠，其他的重要特征还包括成本可控、安全合规等，对应用和数据库具有非常大的挑战。

何为“数据库服务”，我的理解是一种交付形态。数据库产品是指用于存储和管理数据的计算机软件系统，软件是其交付形态，在线业务常用的数据库产品包括关系型数据库和 NoSQL。而数据库服务指将数据库产品以访问接口的形态交付到用户(也就是在线业务)，并维持其稳定且安全的运行。相比于数据库产品，数据库服务具有更长的生命周期和更多的技术内涵，除了数据库产品本身的可靠性，还需要接入的简易性、运行的稳定性、数据的安全性和合规性、成本的可控性等。

因此，互联网“在线业务”对“数据库服务”有着独特的技术诉求，需要对业务工作负载和数据库产品特性有着深刻的理解。然而脱离于互联网平台之外，很少有这方面的专门阐述，本文正是试图弥补这一缺憾。我们将围绕蚂蚁业务场景阐述什么是对互联网“在线业务”友好的“数据库服务”，本文的技术主张也适用于其他的互联网平台业务。

水平伸缩

随着互联网的持续爆发和移动互联网的兴起，支付宝作为一款优秀的国民 App，流量屡创新高，极大考验了整套后端系统的水平伸缩性。

蚂蚁的应用架构经历了数代发展，从第一代的集中式架构，到第二代的分布式架构，再到第三代的自研平台的架构、第四代的云平台架构、第五代的云原生架构，每代架构都有着不同的业务使命和技术使命，但“弹性”始终作为基本课题贯穿其中。蚂蚁也长出了 SOFAStack 这样的代表应用层的分布式产品，使得应用代表的无状态服务层具备了可伸缩、可扩展的能力。但数据库代表的有状态服务层的伸缩性具有着更高的难度和技术挑战，需要解决扩展性、一致性、高可用、高性能等难题。

关系数据库最显著的特征是 ACID，给应用程序提供了数据一致性、数据完整性和数据持久性的语义。在海量流量的冲击下，单机数据库受限于单机资源很快出现性能瓶颈和容量瓶颈，分布式中间件和分布式数据库提供了不同层次的解决方案。

分布式中间件位于应用系统和数据库集群之间，遵循数据库通信协议和 SQL 标准。截获客户端发往数据库的 SQL 请求，并进行解析和转发，根据数据的分布规则发送到对应的数据库实例。接受数据库实例返回的执行结果，解析后转发至对应的客户端。分布式中间件通过这种解析并转发请求的方式，将应用流量分发到多个数据库实例上，减轻了每个数据库实例上的应用流量，从而突破了单数据库实例的性能瓶颈和容量瓶颈。业界的分布式中间件产品有 Cobar、MyCAT、DRDS 等，蚂蚁的中间件产品则是 ZDAL、DDS。

分布式数据库则是在数据库内部实现了水平伸缩性。分布式数据库的设计有一套共性：通过数据分区以支持水平扩展，但会引入跨分区协调问题，通过 2PC 解决;通过多副本复制机制以支持高可用，但会引入数据一致性问题，通过分布式共识协议 Paxos/Raft 解决;集群拓扑关系、数据分区和多副本会引入海量元数据管理和客户端路由的问题，分布式架构会引入了成员变更、动态负载均衡、资源隔离、爆炸半径等问题，因此分布式数据库必须有一套复杂架构和众多优化技术以解决上述难题，扩展阅读可参考 《OceanBase存储引擎介绍》(https://open.oceanbase.com/blog/8600130)和《OceanBase高可用技术介绍》(https://open.oceanbase.com/blog/8600134)。

在分布式数据库的具体实现中，关系型数据库和 NoSQL 有着不同的技术路径和不同的对应用层的语义呈现：

• 关系型数据库必须对应用程序提供 ACID 语义，因此需要实现分布式事务以解决单一事务跨节点时的数据一致性问题，需要实现多副本数据同步以解决硬件故障时的强一致性问题，分布式事务和多副本数据一致性是分布式关系型数据库的最大技术挑战。业界的分布式数据库产品有 Spanner，蚂蚁内部有 OceanBase

• NoSQL 则是选择了提升系统吞吐的另一条技术路径 —— 更弱的隔离机制，也就是牺牲了一定的数据一致性，最终对应用程序提供 BASE 的语义，因此可以通过可配置的放松的数据一致性达到极致的水平伸缩性和可用性。业界的分布式 NoSQL 产品有 Dynamo、HBase，蚂蚁内部有 PolygonStore、UCS

分布式数据库在解决了水平伸缩性的同时，还提供了更好的高可用能力。例如 OceanBase，能够在少数派副本故障时提供 RPO=0、RTO<30秒的高可用 SLA，这是传统关系型数据库完全无法想象的。

对于蚂蚁的在线业务，端到端的水平伸缩性是一个必选项，蚂蚁的数代应用架构演进也体现了这点。对于数据库服务，必须从设计之初就把水平伸缩性纳入设计目标之中。不具备水平伸缩性的数据库服务一定不业务友好。

应用敏捷

蚂蚁包罗万象的业务场景产生了丰富多样的数据库服务诉求。金融业务产生的交易数据;搜广推业务产生的圈人数据;安全业务产生的用户行为数据;消费金融业务产生的风控数据;AI 业务产生的训练数据;小程序云业务产生的社交数据和移动应用数据;短视频业务产生的多模态内容数据;监控业务产生的指标数据等。多样化数据产生的诉求是灵活的数据模型和数据操作，关系型数据库提供的关系模型面对这种场景时举步维艰。

我们不能也不应该淹没在各种业务数据的细节里，却忽视了对问题本质的思考和理解。多样化数据的存储诉求的底层逻辑是“数据不应该被存储形式束缚”，传统的关系型数据库定义了关系模型和 SQL 接口，这种范式并不能适用于所有的数据场景，新型数据模型、访问接口和数据架构呼之欲出。应用程序需要新的数据范式来解放自身，就像半个世纪前关系模型将应用程序从处理数据的物理存储结构的繁文缛节中解放出来一样，这就是应用敏捷性。

数据模型

数据模型是对数据库的存储结构和语义的描述，是对现实世界数据特征的抽象。数据模型在应用程序和数据库之间建立了一座桥梁，屏蔽了数据在数据库如何储存的细节，并向应用程序提供数据的抽象视图。恰当的数据模型能够极大简化应用程序的数据逻辑，避免应用开发者陷于处理业务数据与数据库数据模型之间不匹配的问题。传统关系型数据库提供了关系模型的数据语义，而现代 NoSQL 则提供了很多非关系模型的数据语义，包括 KV模型、宽表模型、文档模型、图模型、时序模型等。数据库的数据语义突破数据模型的束缚以更匹配业务数据表示的形式呈现是一种应用敏捷性。

基础技术栈

数据模型是一种应用敏捷性，基础技术栈(包括应用开发栈和应用工具栈)是另一种应用敏捷性。基础技术栈提供了标准构建模块，使得应用开发可以直接在其上构建应用程序，免去了使用胶水组件将多种独立组件粘合在一起的额外投入，我们以 MEAN Stack 和 TICK Stack 来举例。

• MEAN Stack 是基于 JavaScript 的应用开发栈，可快速构建易扩展的 Web 应用程序。MEAN 是四个开发组件的首字母：MongoDB、Express、Augular、Node，分别是文档数据库、后端框架、前端框架、Web服务器等开发框架。MEAN Stack 的所有组件都是基于 JavaScript 和 JSON，因此组件之间能够无缝交互和集成。MEAN 是构建 Node.JS 应用程序的理想技术栈，在 Web 领域得到了广泛运用

• TICK Stack 是面向时序数据的开源工具栈，可快速构建高性能的监控解决方案。TICK 是四个工具的首字母：Telegraf、InfluxDB、Chronograf、Kapacitor，分别是指标数据采集、时序数据库、数据处理引擎、数据可视化等工具。TICK Stack 是面向时序数据的一整套开源解决方案，覆盖了时序数据生命周期的方方面面。TICK Stack 在物联网领域得到了广泛运用

我们上面介绍的基础技术栈都是以 NoSQL 作为核心的(MongoDB@MEAN、InfluxDB@TICK)，面向特定场景或特定行业的整套解决方案，具有全栈、易迁移、易扩展、社区生态丰富等优点，从而使得应用开发/应用搭建能够专注于业务逻辑，是一种应用敏捷性的体现。

数据分析

OLTP 作为面向在线交易的场景，往往具有短事务和小数据量的特点，专注于事务处理的并发性和快速性。与 OLTP 对应的是 OLAP，面向数据分析和决策支持的场景，往往涉及大量数据的分析，专注于查询的复杂性。然而，现代 OLTP 往往会有数据分析的需求，基于事务数据实时提供分析视图，因此数据分析能力也是一种应用敏捷性。典型的数据分析流派有 Lambda、HTAP、HSAP，代表了若干着不同的设计理念。

• Lambda架构：离线分析指不在在线系统上直接做数据分析，而是把在线系统的数据导入另一个专门做数据分析的环境——数据仓库或者大数据系统。分析环境的数据存储格式面向批处理而设计，与在线系统的面向事务处理是迥然不同的设计路径。分析环境产生的数据需要回流在线系统供业务访问，往往由擅长高吞吐高性能的点查负载的 NoSQL 承担。由于数据导入、数据计算、数据回流都需要时间，分析环境的数据不是实时的，因此在线系统往往会搭配一套实时计算引擎做近期数据的实时分析，或者直接由在线数据库承担轻量 AP 负载。批处理对历史数据进行分析，实时计算对近期数据进行分析，两种分析模式相结合的方式称为 Lambda 架构

• HTAP：Lambda架构存在两套环境，分别是离线分析环境和实时计算环境，引入了架构复杂度和开发复杂度。HTAP 为上述问题提供了一种思路，将 TP 和 AP 的能力由统一的系统对外提供。HTAP 在同一套系统同时保存了面向事务处理的数据格式和面向数据分析的数据格式，从而能够同时服务于多种业务负载。蚂蚁的 OceanBase 4.3.0 的里程碑特性就是提供了 HTAP 能力 —— “基于 LSM-Tree 架构推出列存引擎，实现行存、列存数据存储一体化，同时推出基于 Column 数据格式描述的新版向量化引擎和基于列存的代价模型，支持高效处理大宽表，显著提升 AP 场景查询性能，并兼顾 TP 业务场景”

• HSAP：HTAP 适合处理交易数据，不太适合处理非交易数据，例如日志数据，而日志数据往往也是数据分析所必需的数据源。因此，HTAP 虽然有了数据分析的能力，但并不能解决所有的问题，HSAP 可以弥补 HTAP 的某些缺陷，两者形成非常好的特性互补。HSAP 同时提供了数据服务能力和数据分析能力，数据服务指简单点查，数据分析指复杂查询，HSAP 是提供服务分析混合负载的系统。HTAP 是从数据处理的角度划分，分别是事务处理和数据分析，而 HSAP 则是从数据价值角度划分，分别是简单点查和复杂查询。除了提供混合负载的能力，HSAP 还提供了海量数据的实时写入吞吐量，从而可以承担大数据写入流量，且这些数据对于后续的查询负载实时可见

灵活检索

在线业务往往有着数据检索的需求，一个成熟的解决方案是在主数据库之外联合查询引擎一起提供数据服务，两者之间的数据通过业务主键关联。主数据库用于存储原始数据，同时把待检索字段和业务主键写入查询引擎里面建立索引，查询时先基于检索字段去查询引擎获取业务主键，再基于业务主键去主数据库获取完整的原始数据。多存储架构会引入数据一致性的问题，例如应用在主数据库写入成功，但在查询引擎写入失败，此时会发送一个补偿消息到消息队列用于异步重试，从而达到数据的最终一致性。一个被广泛使用的产品组合为 HBase + ElasticSearch + MQ，其架构图如下：

多产品组合引入了架构复杂度，增加了硬件成本，且应用程序需要处理多产品之间数据一致性的问题。对，数据一致性是分布式系统的设计关键，从水平扩展性到容灾设计，再到现在的多产品组合架构，我们始终绕不过数据一致性的话题。对于数据一致性有几种解决方案：2PC、Total order broadcast、最终一致性，或者终极大招 —— 容忍不一致。数据一致性的语义应该由数据库服务屏蔽掉，并通过灵活的接口语义呈现出来，这就是应用敏捷性。

因此对于在线业务的数据检索需求，一个业务友好的解决方案是数据库服务同时提供原始数据存储和数据检索的功能，且提供可配置的数据一致性语义。数据检索特性应该尽量多元化，包括地理位置检索、全文检索、向量检索等。

总结

我们说数据库服务应该给应用程序提供应用敏捷性，其本质是某种易用性，尽量使得应用程序减少实现数据逻辑的投入，更专注于业务逻辑自身。易用性有多种理念，例如我们本文介绍的数据模型、基础技术栈、数据分析、灵活检索等，数据库服务不需要也无法践行所有这些理念，需要的是把这些理念融入到日常的架构设计和服务交付中去，如果能够以合理的 ROI 践行一两个理念，那也就达到对业务友好的目的了。

安全合规

安全合规是在线业务一项非常基本的诉求，可以帮助企业更好的保护其数据资产，保障业务运行的连续性，降低法律风险。安全合规的方案设计需要从数据的生命周期入手，遍历所有流程，分析其风险敞口并针对性防护。数据库的入口主要有两个，分别是应用程序和运维人员/运维系统。应用程序通过数据库协议与数据库进行通信和数据交换，涉及到认证鉴权、数据传输、数据存储等流程。

• 数据透明加密：对敏感数据进行加密，以确保传输和存储过程中的安全性

• 密钥托管及认证：将访问数据库的账密加密托管到机密信息管控平台，应用程序通过专用 SDK 基于身份信息去机密信息管控平台获取账密，应用程序自身对账密零接触

• 访问权限精细化管控：权限管控需要尽量细粒度化，可用的管控级别包括数据库实例、database、table/bucket、分区，并支持应用程序标识，以支持业务上灵活、多变、精细化的管控诉求

• 日志记录及异常监控：监控数据的访问和操作记录，支持离线归档，便于日志审计及安全事件追踪

数据库服务提供者应该尽量把安全合规的功能产品化和SLA化。SLA是面向应用程序而言，能够提供清晰的接口语义和安全合规相关的保障指标;产品化是面向数据库产品而言，能够尽量把安全合规的能力以中间件的产品形态提供，使得一次投入能够适用于更多的数据库产品，使得安全合规能力能够有序、独立、且连续的演进。

蚂蚁业务具有金融属性，完备的安全合规能力是一个必选项。对于数据库服务，必须从设计之初就把安全合规纳入设计目标之中，并保持跟随业务安全合规诉求提高而演进的初心和能力。不具备安全合规能力，或者安全合规能力不能演进的数据库服务对于业务系统，是不可承受之重。

成本优化

现代数据具有4V特性，其中有个是规模性(Volume)，规模性表示数据量的爆炸性增长，对性能和存储容量提出了很高的诉求，最后都会直观反应到数据库成本上，高昂的成本最后会成为企业继续发展的拦路虎，尤其是当前的存量时代。因此随着数据库服务的发展，成本优化是必须纳入考虑的事情，否则会阻碍数据库服务的进一步发展。

业务数据库架构优化是成本收益最大的优化措施。我们前面介绍了各种多产品架构，包括 Polyglot Persistence、CQRS、Lambda 架构等，多产品架构会引入多份数据存储的开销、应用代码适配多产品引入的代码复杂度开销、多产品的运维开销、建站的交付开销等。我们作为数据库服务提供者，本着帮助业务收敛其数据库架构的目标，需要尽可能促进数据库产品丰富其特性。多种技术可以达到收敛数据库架构的目标：多模数据库，一份数据提供多种数据模型服务，避免可能的 Polyglot Persistence 和 CQRS 架构;HTAP & HSAP，一套系统同时提供数据写入和数据分析的职责，避免可能的 Lambda 架构;具有检索特性的持久化数据库，一套系统同时提供数据持久化和数据检索的职责，避免可能的 Polyglot Persistence 和 CQRS 架构。

数据库产品架构优化涉及多个层面。首先是计算层面，计算弹性是云原生数据库的核心优势，其能力来源于资源分离架构，从而能够独立对单个资源进行伸缩。On-Premises 部署的数据库服务也可以采用资源分离架构，非资源分离架构的数据库服务也可以通过多租户方案实现计算弹性。资源分离架构可以是计算存储分离，甚至是更彻底的计算、内存、存储的三级分离架构。计算弹性能够有效降低计算成本，可以基于业务流量预测对业务租户自动伸缩，可以基于 Serverless 的极致弹性技术进一步提升资源利用率。然后是存储层面，数据存储是数据库的首要功能，随着业务数据的持续增长必然会面临存储成本飙升的问题，冷热数据分层存储是最有效的优化措施。可以在数据库产品内部实现冷热分层，冷热数据分别采用不同的存储介质，热数据存放于热介质 ，冷数据存放于冷介质。数据冷热判断可以根据数据使用频率、耗时敏感度等指标自动判断，也可以由业务方指定规则，常用的一个规则是基于时间区分冷热数据。可以在数据库产品之外实现冷热分层，分为在线库和历史库，在线库采用热介质部署，历史库基于冷介质部署，通过业务规则将冷数据从在线库迁移至历史库，查询时需要基于规则在在线库和历史库之间路由。

数据库产品特性优化与产品成熟度息息相关，产品成熟度越高，越需要在成本优化上投入精力。一个优化手段是数据压缩技术，采用合适的编码+压缩技术能够进一步提升数据压缩比，或者面向数据类型而优化，例如面向列存的优化技术，面向时序数据的优化技术。另一个优化手段是优化副本数，现代数据库往往采用多副本技术以提升容灾能力，在产品早期往往采用相对成熟的方案快速验证市场，此时副本数不一定是最优的，但随着产品发展，冗余副本会极大增加业务的数据库成本负担，此时必须将副本数优化提上日程。

总之，成本优化对企业有着非常积极的意义，但同时对业务自身也可能产生巨大的改造成本，需要数据库服务提供方跟业务方齐心协力，一起缔造优秀的 ROI 和 TCO。成本优化对于数据库服务提供方可能是一个懈怠的事情，需要有企业成本控制小组从整体资源层面进行审计，以做到整体最优。

轻量交付

蚂蚁是一个多站点的业务环境，经常会有新建站点而交付数据库服务的需求。轻量交付能力能够显著缩短建站周期、提升建站体验、优化建站成本，具备轻量交付能力的数据库服务能够有效提升其业务友好性。

轻量交付首先离不开数据库产品的管控成熟度。数据库服务依赖的硬件设施需要能够适配企业当前普适的硬件形态，例如硬件设施经历了从物理机形态到虚拟机形态的演进，再到当前的容器形态，数据库产品需要积极去适配，积极适配当前企业普适的硬件形态能够有效降低交付前置事项对人肉的依赖;服务搭建流程需要能够接口化且具备原子动作的可重入能力和回滚能力，这对管控平台的成熟度提出了要求，从而能够被上层系统所集成，能够最大限度的规范化、自动化，并最终无人化;数据库服务需要具有完备的健康自检能力，完整覆盖服务自身的所有组件与接口，及依赖的第三方服务，从而保证交付质量。

轻量交付也离不开数据库产品的架构轻量化，架构轻量化表示对第三方组件的依赖尽可能少，从而能够有效降低站点的“重量”，避免引入一些又大又重的组件，这对于站点的成本控制有着非常积极的意义。

轻量交付也意味着面向更高一层的 Programming model 交付，积极的主动或跟随推高应用程序的思考层次。例如云计算的发展使得计算资源被不断推高，从物理机到云服务器，再到容器，使得应用程序对计算资源的适配越来越轻量化。数据库服务也同样随着云计算的发展而发展，从 On-Premises 到云托管，再到 Serverless，应用程序的 Programming model 也在不断推高，其专注点越来越回归到业务逻辑自身。因此数据库服务的轻量交付必须积极拥抱应用程序的 Programming model。

总之，轻量交付是一个系统化工程，囊括了数据库产品的架构轻量化、管控成熟度、交付层次等方面，而管控成熟度又是以产品成熟度为前提的。能够轻量交付的数据库服务一定是一款比较成熟的数据库产品且拥有成熟的配套管控体系，从而是对业务友好的数据库服务。数据库产品往往受限于自身的生命周期，很难做到超出自身成熟度的轻量交付，但我们应该把轻量交付作为终态目标而不断逼近。

总结

从业务视角需要的是数据库服务，而不仅仅是数据库产品，数据库服务提供者必须从业务视角审视自己如何提供更好的数据库服务。数据库服务相比于数据库产品有着更多的技术内涵，囊括了数据库内核产品、数据库管控产品、访问中间件、数据库部署架构、业务数据存储架构等整套技术栈，囊括了从服务交付、稳定运行、成本优化、合规整改等完整的数据生命周期，需要从业务编程模型、业务工作负载和数据库特性等多角度分析和优化，从而做到整体最优。对业务友好的数据库服务能够极大简化业务层在数据库逻辑上的投入，能够更专注于业务逻辑自身，对企业发展有着巨大的价值。

科技在进步，业务在演进，数据库服务也必须与时俱进，才能持续对业务友好。