【IT名人堂】专访架构师杨传辉：双11支付宝核心数据库OceanBase今世前生

lastwinner · 发表于 2014-11-29 15:47

Alisunshine 发表于 2014-11-28 20:42
挑战很多，最大的挑战还是兼容老的关系数据库的使用方式。关系数据库有一套成熟的生态系统，上下游厂商， ...

建立生态环境不是一件容易的事儿，兼容也做不到100%，取舍与平衡，你们怎么考虑？

Alisunshine · 发表于 2014-11-29 17:40

lastwinner 发表于 2014-11-29 15:47
建立生态环境不是一件容易的事儿，兼容也做不到100%，取舍与平衡，你们怎么考虑？

恩，这个问题非常关键。兼容分成很多维度，首先从应用开发者的角度来看，应该是基本上都能够做到兼容。当然，某个SQL的explain执行计划之类的肯定是不兼容的，而且，极少量的MySQL实现Bug可能也需要区别对待。从DBA的角度来看，其实很多运维功能是不兼容的，MySQL相关的运维工具有些可以直接使用，有些需要做一些修改甚至自建。说实话，这个问题我们还处在摸索阶段，需要大量的同行一起加入探讨。

wolfop · 发表于 2014-11-29 18:37

Alisunshine 发表于 2014-11-28 20:44
目前是三个写节点通过Paxos选举来实现强一致性，以前主、备的模式有数据一致性问题。

既然是有限的写节点，怎么保证写的scale out？
老问题。

wolfop · 发表于 2014-11-29 18:42

Alisunshine 发表于 2014-11-28 20:43
CAP理论真是误导了不少同学，看CAP理论提出者的这篇文章：http://www.infoq.com/cn/articles/cap-twelve- ...

没什么误导的，我只是把大家都知道的严格一致性和写延迟必然二者不可兼得再重复了一遍而已。
这些都是基本的计算机道理，从实际上架构设计来说，OCEAN BASE的三个有限的写节点必然限制了写的scale-out能力，而数据严格一致必然对跨站点的保护的写延迟。谁也突破不了这些基本的技术原理，这就是技术本事的事实，而不是广告的宣传。

vage · 发表于 2014-11-30 14:18

desert_xu 发表于 2014-11-28 21:53
支付宝核心的还是oracle 吧？

记得前年还是去年，最后一台小机下线，阿里还搞了个仪式。如果已经完全去O成功，早就铺天盖地宣传了，还用在这里欲抱琵琶半遮面。

lovehewenyu · 发表于 2014-11-30 15:06

Alisunshine 发表于 2014-11-28 20:39
谢谢关注，说得很对，其实缺点太多了。关系数据库走了这么多年，有太多的经验值得后来者学习。OceanBase的 ...

谢谢大师解惑！

Alisunshine · 发表于 2014-12-1 10:23

vage 发表于 2014-11-30 14:18
记得前年还是去年，最后一台小机下线，阿里还搞了个仪式。如果已经完全去O成功，早就铺天盖地宣传了，还用 ...

刘振飞还透露,今年双十一凌晨,支付宝第一次将核心数据库流量切入到阿里自研的金融级云数据库OceanBase上

Alisunshine · 发表于 2014-12-1 10:29

wolfop 发表于 2014-11-29 18:42
没什么误导的，我只是把大家都知道的严格一致性和写延迟必然二者不可兼得再重复了一遍而已。
这些都是基 ...

一致性带来写延迟，这个说法是对的，不过和CAP一点关系都没有。
实际情况下，如果要至少同步一个备机，在同城机房的情况下，每次提交的延时会增加不到1ms。数据库的事务一般都是多个DML语句，最后做一次commit，增加的1ms对业务根本没有影响。

很多人会有这个疑问还和关系数据库的思维定式有一定关系，关系数据库里面的延时和并发量一般是对应的。延时高了，并发量就低了。不过OceanBase里面在commit增加1ms的情况下，并发量还是一样的。

Alisunshine · 发表于 2014-12-1 10:39

wolfop 发表于 2014-11-29 18:37
既然是有限的写节点，怎么保证写的scale out？
老问题。

单写入节点是一个权衡，开发时间和效果的权衡。单写入节点能够解决阿里大部分的数据库业务，前提是要把性能优化做到极致。也许你的项目规模要大得多，这个我就不得而知了。

不过我们目前确实在去掉单写入节点的限制，OceanBase正式对外服务的时候肯定是没有单写入节点限制的。

wolfop · 发表于 2014-12-1 12:35

本帖最后由 wolfop 于 2014-12-1 12:48 编辑

Alisunshine 发表于 2014-12-1 10:39
单写入节点是一个权衡，开发时间和效果的权衡。单写入节点能够解决阿里大部分的数据库业务，前提是要把性 ...

你这话说的还是比较实在，当年我看过OCEAN BASE设计就是为一次写入多次多设计的。这种设计保证严格一致性确实是其优点，虽然有SCALE-OUT的问题。不过我想对于支付记录，转账记录这样写入后只查询的应用是足够了。
对于客户账户，这种要疯狂更新的，貌似单写入节点就只能靠单节点scale-up了吧。要做多写入节点，难度就不那么简单了，一定会遇到更严重CAP问题。
至于项目规模，阿里即便在双11虽然峰值那下很高但实际的日交易量，也不超过银联支付的1小时的量，也不如好像广东移动这样的大省在线计费1小时的量。所以我不认为阿里支付的交易量真是有多大。