掘金 AMA：听蚂蚁金服 OceanBase 团队的技术专家– 庆涛聊数据库那些事

第十四期 AMA，掘金团队请来了蚂蚁金服 OceanBase 团队的技术专家– OB庆涛做了为期三天的 Ask Me Anything (AMA) 活动（活动已结束）。

我们在此精选了一些来自用户的提问及庆涛的回答。

关于庆涛

下面内容来自他的自白

大家好，我是蚂蚁金服 OceanBase 团队的技术专家梅庆（花名：庆涛）。目前主要负责 OceanBase 数据库技术和解决方案的对外推广，在阿里工作了 8 年多，目前工作地点在杭州

社区小伙伴精选提问–纯技术

请问 ob 关注的是速度还是可靠性呢？ ─ @Lanwy

请问 ob 关注的是速度还是可靠性呢？到底是快速处理大量任务重要，还是保证遇到灾难时仍能够提供服务重要？数据库优化重点是在读还是写呢？问题有些多，期待您的回复，谢谢

感谢您对OB的关注。 OB的定位是一款通用的分布式的关系型数据库。对于大部分用户而言这是一个新的数据库，你说的哪个重要在用户而言都很重要。OB的特点如下：

1. 可用性：OB的多副本使用paxos协议同步数据和自动选举这个设计实现了部分机器节点故障时只有部分数据短暂不可读写，并能迅速内部切换恢复访问（时间在30s以内，俗称RTO），恢复后对业务而言还没有数据丢失（俗称RPO=0）。
2. 可靠性：OB目前内部版本主要有1.x和2.0. 其中1.x版本的OB集群自上线后就没有再停服过。这得益于OB的扩展性很方便，可以在线扩容/缩容/更换服务器。性能方面是个逐步改进的结果，业务早期会根据数据库能力适当分配压力到OB上。如今蚂蚁金服很多业务（核心和非核心的）都运行在OB上，并经历多次双十一考验。
3. 性能：OB的架构是基于LSM-Tree（Log-Structured Merging Tree)，数据存储格式是SSTable（Sorted String Table）。应用写表的一行数据时，OB会将该行数据所在块读入内存的Block cache中（保持只读），然后在另外一块内存中记录该行的修改的数据（增量数据，即memtable）。同一行数据多次修改的时候，相应的增量会以类似链表的结构串起来。这部分增量数据会一直在内存里不落盘。在事务提交的时候，事务日志时会即时落盘并同时发往该数据其他副本所在节点落盘。数据读的时候通常会将block cache中的基线数据（sstable）跟对应的增量数据（memtable）合并就是业务需要的数据。OB会有机制去保证同一行数据的增量链条不会太长（即minor compaction事件）以保证读性能不会受链条长度影响。所以，OB的这种“读写分离”的设计，天然对写友好，对读也友好。OB后期的性能优化重点在通过强化优化器能力，让复杂的SQL的读性能尽可能的更好。

再补充几点。MySQL常用sql在OB里都兼容，oracle部分sql也兼容。目前内部在全力研发兼容oracle更多功能。明年很快就会推出对存储过程，游标和包，统计分析函数等高级功能的兼容。

处理的数据量级不大的情况下，OB相较别的数据库它的优势在哪？ -@Hodmin

OceanBase作为一个分布式数据库，在保持数据的一致性这块是如何处理的？还有一个问题，看你描述的都是千万级别的业务，对于小公司，处理的数据量级不大的情况下，OB相较别的数据库它的优势在哪呢？

1.OceanBase是多副本(N=3,5,7…)。副本之间的数据同步是通过复制事务日志(redo)并应用实现。以三副本架构为例，每个表的三副本角色有一个leader副本和两个follower副本。默认只有leader提供写入和读取。当事务提交的时候关键一步是事务日志持久化。不仅要持久化到本机硬盘还要持久化到其他follower副本所在主机硬盘。但又不必等待所有成员落盘成功。每个副本把事务日志落盘成功就有个类似投票的动作。投票决议的协议是multi-paxos.只要leader副本收到一半以上成员投票确认持久化事务日志成功就会返回继续走完commit.应答应用。另外一个成员只是持久化略微晚了,不是可以不成功。所以这里的三副本跟传统一主两备并不完全相同，在不考虑应用redo延时的情况下，这里三副本是绝对强一致的。

2.业务规模不特别大情况下，如果买了oracle，说明这数据对业务还是很重要的。那OceanBase就是一个新的选择项，成本比oracle低，兼容oracle(目前还不是完全兼容，取决于业务怎么用). 相比Oracle，OceanBase的高可用和容灾是自动的，不需要dba及时在线处理。OceanBase可以在线扩容，缩容，更换机器。这些运维操带给dba的工作量很少，对业务的影响也相对小一些。OceanBase就是为故障设计的，所以自身”反脆弱性”很强，对运维人员要求也就低一些。 当然前期会有一定学习成本。此外，如果有扩展性需求，容灾或多活需求，那不需要再单独去设计新方案了，OceanBase擅长做这个。

相对于pgsql说，OceanBase具备哪些优势呢？ ─ @古大官人

大佬好，先给大佬递茶。作为阿里云的客户，我们目前在使用RDS for pgsql,相对于pgsql说，OceanBase具备哪些优势呢？

PG我不是很懂。我就说OB吧，然后你对比一下。

OceanBase是分布式数据库，体现在下面几点上：

1. 支持分区表。不同分区可以分布在不同机器上。理论上解决了单库单表的空间瓶颈和性能瓶颈。分区策略参照oracle做，支持二级分区和全局索引。（个别功能点还在完善）。
2. 高可用最小粒度是分区。每个分区有多副本，其中一个leader提供读写。同一个分区的多副本是分布在不同可用区的机器内，不同表的分区可以混布在同一个机器内。换句话说每个机器内既有leader副本又有follower副本。没有单纯说哪个机器是主或是备。这个好处就是限制少，机器利用率充分。真正的分布式数据库都可以做到这个程度。
3. 数据负载均衡时迁移的最小粒度也是分区。通过调整leader副本的分布来改变各个机器的压力。不需要运维做数据迁移等事情。自然也没有数据不一致担忧。真正的分布式数据库也可以做到这点。
4. 完全的分布式架构下，不同表的leader分布很散，对业务来说并不友好。业务上表之间是有联系的（表连接），业务也希望就近访问数据，以及不希望跨节点取数据。所以OB提供对分区分布规则的控制策略。这种策略主要是分区亲和性设置，或者默认优先locality设置。这个用到极致就是单元化架构。
5. OB的弹性伸缩能力很强，可以在线做，在线替换服务器。不用担心高可用问题和数据一致性问题。

此外，OB对Oracle的兼容性有了，还没有做到PG那个水平，只是时间问题。

大佬，再问个问题，OceanBase主打分布式，这个分布式具体是如何实现的呢？在前面的提问中有看到是保持一致性的工作原理，但是针对分布式实现原理这块，能否做一个大概的介绍，方便我们了解OceanBase粗略的工作原理？

前面回答你的那个“分区”对理解OB的分布式很重要。详细一点的你可以看公众号里技术文章，或者直接参加周末我们在上海的线下活动。了解分布式数据库产品可以从下面几点入手：数据模型，多副本技术，拆分技术，高可用技术，事务，弹性扩展能力等。

不知道 ob 和 scylladb、tidb 相比如何呢？ ─ @楚阳

不知道 ob 和 scylladb、tidb 相比如何呢

Scylladb了解不多，似乎是NoSql数据库。tidb是架构最接近OB的数据库，不过二者定位和场景也不完全一样，功能上也有一些区别。OB定位是一款通用的分布式关系型数据库，完全自主研发，不依赖任开源组件或产品，同时尽可能的规避其他公司专利。性能方面可以看公众号里文章，或者看这个 m.aliyun.com/bbs/read/58…

OB 是如何实现智能运维？─ @吃提子不吐葡萄籽

终于来了个运维大佬，我之前读过你们的技术文章，某篇文章提到过智能运维的概念，可以具体地讲一讲 OB 是如何实现智能运维的吗？

【智能运维】是理想，可以无限接近。现实中更多体现为自动化运维，彼此自动化程度上不一样。我这里就说【自动化运维】方面的。

运维最基础的功能就是监控和告警。OB内部性能指标非常丰富（不比Oracle的性能指标少），这为运维提供了很丰富的素材（信息）。告警的目的是提前发现异常，【异常】的定义取决于业务要求和运维人员经验。以前是靠为监控指标定义范围或者波动范围去识别异常，近几年可以通过机器学习去识别以查。 个人认为理论上不会有一个统一的标准能适应所有的业务，机器学习也是一门不确定性技术。所以【漏报】和【误报】永远是运维人员的痛。

数据库告警问题如果是资源相关，有两个处理思路，都可以自动化做。

一是优化SQL，降低SQL对CPU/内存的消耗。自动获取DB运行的所有SQL，并及时分析其执行计划，应用DBA的经验和相关运行时性能数据，程序自动初步判断SQL是否有性能问题，并给出初步的索引优化建议，这个是SQL自动优化的方向。准确率不会太高，但是只要高于绝大部分研发人员水平，在数据库规模很大的公司内，这个是自动化诊断对研发和运维都是很有意义的。OB的所有SQL都可以计入审计，有详细的运行时性能数据。这是源材料。怎么加工发挥就是运维产品的水平了。

二是资源扩容或迁移，提升数据库享用的资源或者数据库迁移到压力很小的主机上。云数据库就是在资源管理方面做的比较好。RDS的mysql和sqlserver都是这个思路。不过这个数据迁移是靠运维产品用数据库自身的备份恢复技术去做（搭建级联备库，然后切换应用的数据库连接等）。OB在这方面做的自动化程度非常高。OB是支持多租户管理。资源有集群和租户两个维度。租户是提供给业务的实例。租户资源不足就对租户扩容，一个命令瞬间完成，前提是集群资源有余量；集群资源不足就加机器，也是一个命令。扩容命令结束后会引起租户以及内部Unit的负载均衡（详情请关注OB微信公众号，看历史文章【负载均衡】）。均衡操作会有数据重分布动作，都是OB内部异步完成，不依赖外部运维产品，不用担心数据不一致，不用担心中间出现异常或可用性故障等。当然，决策是否扩容目前还是运维人员判断的。原因也一样，没有一个统一的标准适合所有的业务场景，还是人把关比较靠谱。

【监控】-【告警】-【处理】-【反馈】。当形成闭环后，这个自动化的运维产品的价值就体现了。反馈就是能跟踪SQL在【处理】之后的改进情况。这还是要依赖数据库的性能指标和SQL的运行时信息等。这个反馈也是对开发做的处理的正向反馈，让他知道应用的性能状况，优化状况，知道哪里做的好哪里做的不好，数据库开发设计方面的能力也得到提升。

社区小伙伴精选提问–非技术直接相关类

只是写业务代码的程序员该如何去学习分布式系统方面的知识？ ─ @Chatc鲸鱼

大佬好，平时只是写业务代码的程序员该如何去学习分布式系统方面的知识技能呢

先了解一些理论基础，推荐看书《数据密集型应用系统设计 》。英文ok的话看原版。 介绍 book.douban.com/subject/303…