掘金 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…