基于湖库一体架构，统一管理结构化、半结构化与非结构化等多模态数据，一个系统承载事务处理、实时分析与 AI 工作负载。
OLTP（联机事务处理）数据库
OLTP（On-Line Transaction Processing，联机事务处理），是专门设计用于处理事务性工作的系统，支撑 OLTP 事务处理业务的数据库则被称为 OLTP 数据库。
本文将介绍 OLTP 的定义、特点，与 OLAP 的区别，当前 OLTP 数据库面临的挑战，及相较于传统数据库，分布式数据库如 OceanBase 在 OLTP 中的应用优势与实践案例。
本文将介绍 OLTP 的定义、特点，与 OLAP 的区别，当前 OLTP 数据库面临的挑战，及相较于传统数据库，分布式数据库如 OceanBase 在 OLTP 中的应用优势与实践案例。
内容更新时间：2026.10.10
什么是 OLTP（Online Transaction Processing）
OLTP 的全称是 On-Line Transaction Processing，中文为联机事务处理，是指专门设计用于处理事务性工作的系统。OLTP 系统通常处理大量的短事务，这些事务往往是短时间内、频繁发生的操作，例如银行的记账、电商网站的订单处理、库存的进出记录等业务，其主要目的是快速、准确地处理大量的日常业务操作。这些事务涉及单条记录的插入、更新或删除操作，因此要求 OLTP 系统能够快速响应，并保证数据的一致性和完整性。
支撑 OLTP 工作负载的数据库被称为 OLTP 数据库，一般为关系型数据库，如 Oracle、MySQL、OceanBase 等。OLTP 关系型数据库一般基于表格的形式存储数据，表格之间通过主键和外键建立关联。OLTP 数据库通常具备以下特征：
支撑 OLTP 工作负载的数据库被称为 OLTP 数据库，一般为关系型数据库，如 Oracle、MySQL、OceanBase 等。OLTP 关系型数据库一般基于表格的形式存储数据，表格之间通过主键和外键建立关联。OLTP 数据库通常具备以下特征：
事务管理功能
OLTP 数据库具备强大的事务管理功能来确保数据的一致性和完整性。它通过数据库的事务机制来实现 ACID 特性（原子性、一致性、隔离性、持久性）。如果在执行过程中出现任何错误（如网络故障、系统崩溃等），数据库可回滚事务，即撤销已经执行的部分操作，保证数据的一致性。
索引机制
为了保障业务处理时数据查询的速度，OLTP 数据库广泛使用索引。索引就像是一本书的目录，它可以帮助数据库快速定位到需要的数据。
并发控制机制
为了解决多个用户同时访问和修改数据时可能出现的冲突问题，OLTP 数据库采用并发控制机制。常见的并发控制方法有锁机制和乐观并发控制。锁机制是指当一个事务在访问或修改某一数据对象时，给该对象加上锁，其他事务必须等待锁释放后才能访问。乐观并发控制则是假设事务之间很少发生冲突，在事务提交时才检查数据是否被其他事务修改过，如果没有修改则提交成功，否则需要进行相应的处理（如重新执行事务或合并修改）。
OLTP 数据库在现代业务中非常重要，它们能够高效地处理日常业务型操作，确保业务的顺利进行和数据的准确性。
OLTP 与 OLAP 的区别
OLTP（On-Line Transaction Processing，联机事务处理）和 OLAP（On-Line Analytical Processing，联机分析处理）是两种不同类型的工作负载，它们在应用场景和目的、数据模型、数据处理方式和性能要求上有明显的区别。
两者的应用场景和目的
OLTP：OLTP 主要用于处理日常业务中的事务，如订单交易、库存更新、银行转账等需要频繁交互和实时更新数据的业务场景。OLTP 系统强调的是事务的实时性和数据的准确性。例如，在银行系统中，当客户进行转账操作时，OLTP 系统需要立即处理这笔交易，更新账户余额，并保证交易的准确性和安全性。
OLAP：OLAP 则主要侧重于对大量数据进行多维度的查询和分析，以支持业务的决策。OLAP 处理的数据通常是经过汇总和聚合的，用于生成报表或看板，并进行数据分析。例如，零售企业可以通过 OLAP 系统分析销售数据，了解不同地区、不同产品的销售情况，制定相应的营销和库存策略。
OLAP：OLAP 则主要侧重于对大量数据进行多维度的查询和分析，以支持业务的决策。OLAP 处理的数据通常是经过汇总和聚合的，用于生成报表或看板，并进行数据分析。例如，零售企业可以通过 OLAP 系统分析销售数据，了解不同地区、不同产品的销售情况，制定相应的营销和库存策略。
数据处理方式
OLTP：处理的是实时的、短小的、频繁的事务操作。数据通常是细粒度的，如单条记录的插入、更新或删除。多个用户可能同时对数据进行读写操作，系统需要能够处理大量的并发事务。
OLAP：是对大量数据的批量读取和分析。数据通常是聚合的，如对大量数据进行汇总、统计和分析。系统主要进行读操作，用于查询和分析数据，写操作相对较少。
OLAP：是对大量数据的批量读取和分析。数据通常是聚合的，如对大量数据进行汇总、统计和分析。系统主要进行读操作，用于查询和分析数据，写操作相对较少。
两者的数据模型
OLTP：通常采用规范化的数据模型，以减少数据冗余和提高数据一致性。
OLAP：通常采用非规范化的数据模型，如星型模型或雪花模型，以优化查询性能和数据聚合。
OLAP：通常采用非规范化的数据模型，如星型模型或雪花模型，以优化查询性能和数据聚合。
性能要求
OLTP：对响应时间要求高，通常要求在毫秒级别完成事务处理。系统需要支持高并发，确保每个事务能够快速完成。
OLAP：一般对响应时间的要求相对宽松，通常允许较长的查询时间。系统需要支持复杂的查询和大规模的数据处理。
OLAP：一般对响应时间的要求相对宽松，通常允许较长的查询时间。系统需要支持复杂的查询和大规模的数据处理。
OLTP（Online Transaction Processing）的典型应用领域
银行、证券等金融系统
电商与零售系统
银行的日常运营依赖于高效、准确的事务处理，如账户查询、转账、存款、取款等。这些操作要求系统具备高并发处理能力、实时数据更新以及严格的数据一致性。例如，在一个大型银行中，每天可能有数百万笔交易同时发生，OLTP 系统需要能够快速响应每个客户的请求，确保账户余额的实时更新和交易的正确性。根据相关数据，银行系统中 OLTP 事务的平均响应时间需控制在毫秒级，以满足客户对金融服务的高效率需求。银行还需要处理大量的客户信息，包括个人资料、账户状态、交易记录等，这些数据的准确性和安全性都很重要。
OceanBase 分布式数据库 在中国工商银行、交通银行、北京银行、南京银行等近百家银行的核心业务系统中得到了广泛应用。例如，OceanBase 作为交通银行分布式信息系统建设关键“底座”和核心，帮助交通银行整体IT体系向新一代云平台、分布式架构全面转型起到了关键作用，助力交通银行实现金融 TPS（每秒处理事务数）提升 6 倍，跑批效率提升超过 7 倍；节省大机资源超过 15000MIPS，贷记卡核心系统从大型主机下移到自研 x86 服务器，加上前后台运营、消保人力等，合计节省约 7 亿元。
更多银行系统进行数据库升级的案例和最佳实践，可下载《金融核心系统数据库升级路径与场景实践》
传统数据库在 OLTP 中的挑战
随着信息技术的快速发展，企业产生的数据量呈爆炸式增长。
在 OLTP 系统中，这种数据量的增长给传统数据库带来了巨大的挑战。传统数据库通常采用集中式架构，所有数据都存储在单一的服务器或数据库实例中。这种架构在数据量较小、业务规模有限的情况下能够正常工作，但随着数据量的不断增加，性能瓶颈逐渐显现。
在 OLTP 系统中，这种数据量的增长给传统数据库带来了巨大的挑战。传统数据库通常采用集中式架构，所有数据都存储在单一的服务器或数据库实例中。这种架构在数据量较小、业务规模有限的情况下能够正常工作，但随着数据量的不断增加，性能瓶颈逐渐显现。
实例数量多
传统的单体数据库遇到扩容瓶颈，大多选择分库分表策略缓解业务压力，导致实例数多达几十上百甚至上千，运维及稳定性提出挑战。
资源成本高
随着业务发展，实例数量和存储资源与日俱增，数据库授权/订阅费用高昂，存储成本居高不下。
使用碎片化
大量实例根据场景差异，资源利用率不均，有的实例资源捉襟见肘，有的资源大量闲置。资源无法“池化”，无法进行统一调度管理，存在严重的资源碎片浪费。
运维繁琐复杂
不同业务大量实例，每个实例独立监控管理，管理效率低，运维复杂度高，需要投入大量人力物力管控。
技术栈不统一
不同云厂商和本地部署数据库内核存在种种差异，无法统一管理界面，且云厂商方案存在技术绑定风险，业务想实现多云、跨云架构需要投入大量精力进行重构。
为了解决这些 OLTP 的问题，越来越多的企业越来倾向于采用分布式数据库，如 OceanBase 来替代传统数据库。分布式数据库通过水平扩展、高可用性和强一致性等特性，能够更好地满足 OLTP 场景的需求。
分布式数据库在 OLTP 中的应用
OceanBase 作为一款原生分布式数据库，其分布式架构在 OLTP 场景中具备多项优势，能够有效应对传统数据库面临的诸多挑战。
弹性扩展能力
OceanBase 采用分布式架构，支持水平、垂直方式的进行扩缩容。水平扩展方式具有更好的灵活性和经济性。例如，当企业业务增长导致数据量和事务请求量大幅增加时，OceanBase 可以轻松地通过添加新的节点或可用区来扩展系统，无需对现有系统进行大规模的升级和改造。与传统的垂直扩展相比，水平扩展可以根据业务需求灵活调整，还能有效降低成本，避免因一次性大规模投资而导致的资源浪费。
高性能事务处理
OceanBase 在事务处理上进行了大量优化，能够支持高并发的事务请求。通过 MVCC （多版本并发控制）技术，OceanBase可以实现读写分离，避免读写冲突，提高并发处理能力。OceanBase 通过全局索引和并行执行等技术，提升查询性能，缩短延迟。在 OLTP 系统中，事务的实时性和高并发性是关键需求。OceanBase 的这些优化措施使其能够快速响应用户的请求，保证数据的一致性和完整性，同时提高系统的整体性能。例如，在电商网站的购物高峰期，大量的用户同时进行浏览、下单、支付等操作，OceanBase 可以高效地处理这些并发事务，确保用户的购物体验不受影响。
多副本机制，保障高可用性
为了保证数据的高可用性和一致性，OceanBase 采用多副本机制和 Paxos 协议。每个数据分片都有多个副本，分布在不同的物理节点上。当某个节点出现故障时，系统可以自动切换到其他副本，保证服务的连续性。OceanBase 通过 Paxos 协议来确保副本间的数据强一致性。即使在部分节点发生故障的情况下，用户仍然可以正常访问和操作数据，不会对业务造成中断。例如，在金融行业的核心交易系统中，数据的准确性和可用性至关重要。OceanBase 能够确保交易数据在任何情况下都能被正确处理和存储，保障金融业务的稳定运行。目前，OceanBase 可实现 RPO=0 和业界领先的 RTO<8 秒。
多租户支持，提升资源利用率
OceanBase 数据库支持多租户架构，不同租户的资源可以相互隔离，避免资源争用。通过资源池和Unit的配置，可以为每个租户分配独立的计算和存储资源，确保关键业务的性能不受其他租户的影响。这种多租户架构能力使得 OceanBase 能够在一个集群通过多个租户同时服务于多个业务线，提升整体的资源利用率，并降低运维复杂度。
数据高压缩，降低存储成本
OceanBase 的存储引擎基于 LSM-Tree 架构，通过 MemTable 和 SSTable 的结合，可有效降低存储成本 70%-90%。
综上所述，OceanBase 的分布式架构在 OLTP 场景中通过高可用性、弹性扩展、分布式事务处理、多租户、数据压缩等特性，可显著提升系统的性能、可用性和可扩展性，并降低成本，能够更好地满足现代 OLTP 业务的需求。
OceanBase 在 OLTP 场景的实践
为了支持 OLTP 场景的越来越高的需求，OceanBase 进行了大量的技术自主研发和创新，并提供包括数据迁移与评估、性能监控、性能优化、自动化运维等的全周期工具与服务。以下为 OceanBase 的典型应用技术场景：
异地多活高可用
高并发场景
传统数据库上云
大存储数据库降本
多数据库实例整合
分库分表一体化升级
业务挑战
传统 IT 系统高可用系统的实现主要是以主备的方式进行部署，这类方案虽然已经过长时间的验证，但仍然无法很好解决例如故障发生后切换数据不丢失的需求。传统的双活架构，由于异步复制机制问题，主中心故障发生后不敢切、不能切的情况时有发生。故障切换的决策成本高，业务影响时间进一步被拉长。由于传统架构下业务系统整体强耦合，数据库层面也经常发生单点故障（机房单点、地域单点、网络单点、实例部署单点等）影响全站用户的情况，严重影响业务连续性。
OceanBase 高可用方案
OceanBase 首创“三地五中心”城市级故障自动无损容灾解决方案，满足国标金融 6 级容灾标准，零数据丢失，RTO 小于 8 秒，即使城市级故障也能在 1 分钟内自动恢复。
通过仲裁多活方案，还可采用两地三中心、同城三中心等更低成本的高可用部署，满足不同的业务高可用需求。
OceanBase 还可满足海量数据处理的需要，结合原生分布式的并发读写能力，大幅提高批处理性能吞吐，每个批次查询超过百万条，每批次可并发处理百亿账户。数据量达到 PB 级。
查看详情OceanBase 的 OLTP 场景应用案例
高德地图
亿级 DAU 的高德，每时每刻都在生产大量的数据，如何处理这些数据并降低后续扩容迁移成本、存储成本，成为了摆在高德面前的重要问题。其中数据的存储、加密、快速检索和绝对安全就非常重要，目的是让用户在任何时刻、不同的端设备上都能快速的获得自己想要的真实世界的信息，让用户出行更美好。同时，也需要在业务发展期提前做好技术布局，保障现在和未来服务可用性、稳定性，以应对未来业务的飞速成长。
经过长时间的调研和测试对比，高德决定采用性价比极高的 OceanBase 来迎接高德万亿（条）数据的挑战。
在引入 OceanBase 数据库后，业务稳定性极大提升，利用 OceanBase “三地五中心”的部署和强一致特性，业务可实现城市级别的容灾，保证数据不丢。利用 OceanBase 的分布式特性，业务系统的数据存储具备了动态扩容的能力，业务无感知的平滑扩容，保证业务不停机，同时节省了业务提量猛增后的数据库扩容和迁移成本，极大降低了数据库容量不足的风险；OceanBase 使用的 LSM-Tree 结构存储最大可压缩数据至原大小的 35%，减少数据占用的存储容量，降低存储费用成本。此外，相比 MySQL，迁移至 OceanBase 后读性能平均提升 2 倍，写性能平均提升 3 倍。以云同步业务为例，读单单元 8wqps，三单元 24wqps，写 2.8wtps，读 in 查询，写批量写入，平均 RT 均在 2～3ms。
经过长时间的调研和测试对比，高德决定采用性价比极高的 OceanBase 来迎接高德万亿（条）数据的挑战。
在引入 OceanBase 数据库后，业务稳定性极大提升，利用 OceanBase “三地五中心”的部署和强一致特性，业务可实现城市级别的容灾，保证数据不丢。利用 OceanBase 的分布式特性，业务系统的数据存储具备了动态扩容的能力，业务无感知的平滑扩容，保证业务不停机，同时节省了业务提量猛增后的数据库扩容和迁移成本，极大降低了数据库容量不足的风险；OceanBase 使用的 LSM-Tree 结构存储最大可压缩数据至原大小的 35%，减少数据占用的存储容量，降低存储费用成本。此外，相比 MySQL，迁移至 OceanBase 后读性能平均提升 2 倍，写性能平均提升 3 倍。以云同步业务为例，读单单元 8wqps，三单元 24wqps，写 2.8wtps，读 in 查询，写批量写入，平均 RT 均在 2～3ms。
查看详情
网商银行
网商银行致力于为小微企业、三农用户、大众消费者、中小金融机构提供普惠金融服务，从成立之初，就对业务系统提出了低成本、高可用、高弹性的要求。依托于阿里巴巴及蚂蚁集团多年来沉淀的云计算和分布式底层平台技术，网商银行从筹建之初就将所有核心业务系统以分布式的架构创建于云平台之上，是中国第一家将核心系统架构在云计算和分布式数据库上的银行。随着互联网金融业务的发展，网商银行的数据量和并行访问量成倍增长，对于承接数据的数据库来讲，它需要具有城市级的灾难恢复才能满足监管要求。考虑数据库的高可用和高弹性，其次是低成本。此外，还需要一个标准、安全、高效的多租户相互隔离的数据库和相应的管理工具，以方便银行各应用系统的管理和使用，例如存款核心系统、传输和加载服务。
网商银行目前集群规模 100 多套，数据量达到 PB 级。通过 OceanBase“三地五中心”的逻辑架构部署，实现了 RPO = 0，RTO < 30s。一旦其中一到两个中心发生故障，甚至一个城市出现问题，业务也能够实现在 30 秒内自动恢复，提升了全行业务的容灾能力。在技术应用场景，实现分库分表与分区相结合，提高并发跑批的能力，每个批次查询 5千～100 万条，每批次并发最大可处理 130 亿账户。此外，实现数据从金融网关进入网商那一刻起就变成密文，密文传输、密文存储，符合金融级数据隐私保护的要求。混合云的弹性架构，实现大促期间在一朵云资源耗尽的情况下，弹出 20% 的流量到新云上，保证了负载的跨云弹性伸缩。
网商银行目前集群规模 100 多套，数据量达到 PB 级。通过 OceanBase“三地五中心”的逻辑架构部署，实现了 RPO = 0，RTO < 30s。一旦其中一到两个中心发生故障，甚至一个城市出现问题，业务也能够实现在 30 秒内自动恢复，提升了全行业务的容灾能力。在技术应用场景，实现分库分表与分区相结合，提高并发跑批的能力，每个批次查询 5千～100 万条，每批次并发最大可处理 130 亿账户。此外，实现数据从金融网关进入网商那一刻起就变成密文，密文传输、密文存储，符合金融级数据隐私保护的要求。混合云的弹性架构，实现大促期间在一朵云资源耗尽的情况下，弹出 20% 的流量到新云上，保证了负载的跨云弹性伸缩。
图匠数据
伴随着 2023 年上半年零售业务的复苏，图匠的核心业务迎来大规模增长，线下货柜布点增多，货品进出频率提升导致数据量急剧上升。一方面，导致数据存储成本日益攀升；另一方面，原数据库难以稳定支撑高并发。经过多方调研、测试、分析，图匠最终选择 OceanBase 为其“数货宝”、“数智柜”两大核心业务提供云数据库服务。
OB Cloud 云数据库具备规模化降本、快速云上迁移等关键优势，与图匠现阶段对云数据库的需求不谋而合。迁移至 OceanBase 后，图匠的系统性能整体提升了 1-3 倍。选择 OceanBase 作为 AI SaaS 平台“数货宝”的实时数据库，借助 HTAP 能力，让图匠无需使用两套系统，仅用一套系统即可完成 OLTP 与 OLAP，涵盖了配置、流程处理、业务结果等数据，显著提升该业务的系统整体性能。此外，图匠借助 OceanBase 的高级压缩技术，降低海量数据存储空间占用，实现数据存储成本降低 50% 的显著成效。以图匠 50 余套数据库中的某套数据库为例，数据压缩达 10 倍，原库 15TB，经 OceanBase 压缩后仅剩 1.5TB。
OB Cloud 云数据库具备规模化降本、快速云上迁移等关键优势，与图匠现阶段对云数据库的需求不谋而合。迁移至 OceanBase 后，图匠的系统性能整体提升了 1-3 倍。选择 OceanBase 作为 AI SaaS 平台“数货宝”的实时数据库，借助 HTAP 能力，让图匠无需使用两套系统，仅用一套系统即可完成 OLTP 与 OLAP，涵盖了配置、流程处理、业务结果等数据，显著提升该业务的系统整体性能。此外，图匠借助 OceanBase 的高级压缩技术，降低海量数据存储空间占用，实现数据存储成本降低 50% 的显著成效。以图匠 50 余套数据库中的某套数据库为例，数据压缩达 10 倍，原库 15TB，经 OceanBase 压缩后仅剩 1.5TB。
总结
通过本主题的内容诠释，想必大家已经了解 OLTP（Online Transaction Processing）即联机事务处理的概念及应用。OLTP 系统作为企业日常业务运营的核心支撑系统，广泛应用于银行、电商、零售、医疗等多个行业，支持着例如订单处理、库存更新、支付交易等日常业务操作，具备事务的实时性、高并发性和数据的准确一致性等特点。
传统数据库在 OLTP 场景面对海量数据增长与高并发事务处理需求时，面临着数据增长与性能瓶颈、高并发事务处理压力等诸多挑战。OceanBase 的原生分布式架构在 OLTP 场景中通过高可用性、弹性扩展、分布式事务处理、多租户、数据压缩等特性，可显著提升系统的性能、可用性和可扩展性，并降低成本，能够更好地满足现代 OLTP 业务的需求，并在高并发、异地多活、数据库技术降本、多实例整合等场景得到应用和众多行业客户的认可。
传统数据库在 OLTP 场景面对海量数据增长与高并发事务处理需求时，面临着数据增长与性能瓶颈、高并发事务处理压力等诸多挑战。OceanBase 的原生分布式架构在 OLTP 场景中通过高可用性、弹性扩展、分布式事务处理、多租户、数据压缩等特性，可显著提升系统的性能、可用性和可扩展性，并降低成本，能够更好地满足现代 OLTP 业务的需求，并在高并发、异地多活、数据库技术降本、多实例整合等场景得到应用和众多行业客户的认可。
