在分布式数据库中，SQL和事务是两个重要的技术门槛。不同数据库在支持事务时的原理各有不同，而OceanBase作为一种分布式数据库，其事务具有独特的特点。本文将详细介绍OceanBase事务的原理，并解答OceanBase事务适合各种规模的事务、事务的一致性、隔离性、持久性等问题。

在传统关系数据库中，ACID特性被广泛应用，而在分布式数据库的环境下，实现ACID特性会面临新的挑战。事务的原子性要求事务要么全部成功要么全部失败，而这在分布式环境中更显复杂。OceanBase通过使用两阶段提交协议(2PC)，来确保事务的原子性，保证跨多台机器的事务要么全部提交成功，要么全部回滚。

一致性是指业务对数据定义了某种规则，并通过事务来实现这种一致性。隔离性描述了并发事务读写相同数据时的特点，不同的隔离级别会导致不同的结果或问题。OceanBase在隔离级别上支持读已提交和可序列化两种级别。持久性是指一旦事务提交成功，数据修改不会丢失，即使发生硬件故障或数据库崩溃。OceanBase通过特殊的机制来保证持久性，如事务日志在COMMIT时生成并落盘，数据修改不立即落盘等。

在OceanBase中，写操作并不直接在数据块上进行修改，而是在增量内存中存放数据的变化。这种读写分离的设计决定了OceanBase事务的特点，支持不同的隔离级别。事务版本号等基本概念也在实际操作中起到重要作用。通过深入了解OceanBase的事务原理，我们可以更好地理解其在分布式环境下的优势和特点。

---

大家为什么都说说OceanBase4.0开启了国产数据库新的里程碑？

OceanBase 4.0重新审视数据库与分布式系统两个领域最基础的设计，全新推出业内首个单机分布式一体化架构。在单机部署时，自适应日志流技术将只触发一个日志流，用户操作不需要分布式事务，不损失性能。需要分布式部署时，自适应日志流技术将会为每台机器触发专属的日志流。实现多机性能自动扩展。可以说OceanBase 4.0打破了分布式技术的不可能，实现了首个单机分布式体化架构，真正做到可以像单机数据库一样使用。

针对这一现状，有这么一群人从开始放弃了在互联网大厂的高薪工作，历经十余年在分布式数据库的深耕取得了一个又一个突破。从0到1开创原生分布式数据库，坚持自主研发，坚持长期主义，坚持开放，从根本上去解决海量数据管理的问题。历经12年时间，OceanBase4.0通过海量的业务场景打磨，产品不断选代，使用成本得到极大降低，部署更加便捷。OceanBase4.0开启了国产数据库新的里程碑。可单机可分布，可大可小，跟火影忍者一样，可合体可分散。

一、十年积累，厚积薄发：OceanBase发展回顾

在科技互联网时代，芯片和操作系统是大家熟知的技术高峰，而数据库由于概念难懂，大众对其认知并不深刻。实际上数据库在我们的生产和生活中发挥着重要的作用，大到银行要存放所有客户的信息，小到我们身边的一个小超市要存储每件商品的信息，这些都离不开数据库在背后作为支撑。然而，国内企业的数据库大多数都是采用国外的Oracle和IBM的传统关系型数据库，仅Oracle一家在全球市场占据了超过50%的份额。根据科技日报发布的制约我国工业发展的35项技术中，数据库管理系统名列其中，由此可见数据库也是我国亟待解决得“卡脖子”技术之一。

二、曾经的分布式。是为了处理海量业务场景应运而生

面对当今数据爆炸的时代，数据库是实现海量数据管理最核心的底座。以OceanBase为代表的分布式数据库的应运而生有着其强大的时代背景。首先是数据需求鼓励升级，移动支付和大数据带来的数据体量增长和数据形态变化，要求数据库底层能够处理选代升级的新技术。随着国内信息终端规模的扩大和网上购物的高覆盖率给数据库发展提供了沃土，反过来要求数据库具备处理海量业务的能力。还有一点值得一提的是各监管机构、政策制定方均重点布局针对数据库分布式转型、应用创新战略重点行业用户逐步增强数据库应用创新意识，防范潜在安全风险，这进一步标志着分布式数据库的产业持续壮大。

三、而现如今的单机分布式一体化架构，引领行业发展

一个产品雄厚的技术实力是必不可少的支撑，但是最终还是要面向客户需求的。Oceanbase4.0真正实现在单机性能、灵活性，成本和故障恢复等方面全面的突破。可以说OceanBase4.0开启了国产数据库新的里程碑。可单机部署，可分布，可大可小，可扩容可缩容

一个产品雄厚的技术实力是必不可少的支撑，但是最终还是要面向客户需求的。我们国家的一大特点就是中小企业特比多。那么针对这种情况，可单机可分布，可大可小，可合体可分散的特性就非常便于中小企业的灵活部署。在以往使用传统分布式数据库为实现分布式特性，往往付出很多额外的代价，使得业务在仅需要单机部署时，功能和性能大打折扣。典型场景如在业务修改的数据仅涉及到单机时，仍需要付出分布式事务的开销，导致整体性能低下。或无法支持大事务，业务使用场景受限等。

与oracle等国外数据库相比，没有大的技术创新，也不会出现弯道技术上的超车。 最大的贡献：越来越普遍。 不要小看“一般”这个词，它代表了一个公司的技术能力、质量体系、服务能力都达到了很高的水平。 也可以逐步服务于各行业的一些核心业务。 综上所述，这个领域的中国人在路上。 从技术上讲，这并不意味着国产数据库一定落后很多。 国内数据库的重点是先服务国内重要客户，先蚕食国外数据库的市场，从而拥有主动权和话语权。 现在是什么阶段，就像过去一样，国产手机正在逐渐赶超国外手机厂商。 现在，你可以先用小米一代。 来日本久一点吧。

在成本上比传统数据库低50-70%大大降低中小企业的替换成本近年来数字经济迅猛发展，中小企业更加迫切的需要进行数字化转型。如何降低数字化进程中的成本，不仅是中小企业考虑的重要问题，也是OceanBase力求达到的目的。基于LSM-Tree的高压缩引擎，OceanBase 4.0实现存储成本降低70%-90%；以支付宝为例，用OceanBase原生分布式数据库替代Oracle数据库之后，单副本数据可以做到Oracle的1/7，其计算资源投入也降低为原来的1/12，相比Oracle，仅存储一项，相比Oracle节省存储成本约20亿元，相当于每账户成本节省了90%。

首次将故障恢复时间从30秒降低到8秒现在的数据中心对业务的连续性有苛刻要求，但是故障往往是不可避免的。一旦发生了故障就需要启动备份机制，确保业务的连续性。OceanBase4.0首次实现了RTO<8s，真正将故障恢复时间从分钟级（30s）降低到秒级（8s），帮助业务系统更快恢复，最大程度减少业务影响，给业务带来持续可用的能力。

数据库为什么要分库分表

1 基本思想之什么是分库分表？从字面上简单理解，就是把原本存储于一个库的数据分块存储到多个库上，把原本存储于一个表的数据分块存储到多个表上。 2 基本思想之为什么要分库分表？数据库中的数据量不一定是可控的，在未进行分库分表的情况下，随着时间和业务的发展，库中的表会越来越多，表中的数据量也会越来越大，相应地，数据操作，增删改查的开销也会越来越大；另外，由于无法进行分布式式部署，而一台服务器的资源（CPU、磁盘、内存、IO等）是有限的，最终数据库所能承载的数据量、数据处理能力都将遭遇瓶颈。 3 分库分表的实施策略。 分库分表有垂直切分和水平切分两种。 3.1 何谓垂直切分，即将表按照功能模块、关系密切程度划分出来，部署到不同的库上。 例如，我们会建立定义数据库workDB、商品数据库payDB、用户数据库userDB、日志数据库logDB等，分别用于存储项目数据定义表、商品定义表、用户数据表、日志数据表等。 3.2 何谓水平切分，当一个表中的数据量过大时，我们可以把该表的数据按照某种规则，例如userID散列，进行划分，然后存储到多个结构相同的表，和不同的库上。 例如，我们的userDB中的用户数据表中，每一个表的数据量都很大，就可以把userDB切分为结构相同的多个userDB：part0DB、part1DB等，再将userDB上的用户数据表userTable，切分为很多userTable：userTable0、userTable1等，然后将这些表按照一定的规则存储到多个userDB上。 3.3 应该使用哪一种方式来实施数据库分库分表，这要看数据库中数据量的瓶颈所在，并综合项目的业务类型进行考虑。 如果数据库是因为表太多而造成海量数据，并且项目的各项业务逻辑划分清晰、低耦合，那么规则简单明了、容易实施的垂直切分必是首选。 而如果数据库中的表并不多，但单表的数据量很大、或数据热度很高，这种情况之下就应该选择水平切分，水平切分比垂直切分要复杂一些，它将原本逻辑上属于一体的数据进行了物理分割，除了在分割时要对分割的粒度做好评估，考虑数据平均和负载平均，后期也将对项目人员及应用程序产生额外的数据管理负担。 在现实项目中，往往是这两种情况兼而有之，这就需要做出权衡，甚至既需要垂直切分，又需要水平切分。 我们的游戏项目便综合使用了垂直与水平切分，我们首先对数据库进行垂直切分，然后，再针对一部分表，通常是用户数据表，进行水平切分。 4 分库分表存在的问题。 4.1 事务问题。 在执行分库分表之后，由于数据存储到了不同的库上，数据库事务管理出现了困难。 如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价；如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。 4.2 跨库跨表的join问题。 在执行了分库分表之后，难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上，这时，表的关联操作将受到限制，我们无法join位于不同分库的表，也无法join分表粒度不同的表，结果原本一次查询能够完成的业务，可能需要多次查询才能完成。 4.3 额外的数据管理负担和数据运算压力。 额外的数据管理负担，最显而易见的就是数据的定位问题和数据的增删改查的重复执行问题，这些都可以通过应用程序解决，但必然引起额外的逻辑运算，例如，对于一个记录用户成绩的用户数据表userTable，业务要求查出成绩最好的100位，在进行分表之前，只需一个order by语句就可以搞定，但是在进行分表之后，将需要n个order by语句，分别查出每一个分表的前100名用户数据，然后再对这些数据进行合并计算，才能得出结果。

标签： OceanBase、 分布式数据库、 分布式事务、

本文地址： https://yihaiquanyi.com/article/243b1d1cfe23f359d987.html

上一篇：探寻VLDB13的未知之谜探寻中国茶一片树叶的...
下一篇：优化IPC探讨CPU性能的关键起因优化iPhone储...