Reload Original PagePrint PageEmail Page

平安阿里数据库技术交流日总结

当初阿里用 Oracle 也是很稳定的,业务不能支撑也是预期而已,虽然预期最终成了现实,业务部门达成了业绩的承诺。阿里不是舍不得花钱,而是有钱也买不来 IBM 跟进阿里发展的速度,所以才想自己决定速度。

去 IOE,在阿里也是满城风雨的。结果反对的走人了,无态度的远离技术,主动推的拿了股票也走了。

从业务来看,业务实现了预期的业务增长承诺,使得 IBM 小机支持不住,就去 I 了,E 存储做得太好,反而让人感觉被绑架,找不到替代品,去 E,因为费用矛盾,就顺便去 O 了。

而从技术来看,做技术的人,一方面实现了一次洗牌,另一方面提升了自身的价值,反过来绑架了业务,这就是技术人的价值。这正因此,阿里的人在行业内才趋之若鹜。

为什么会这样呢?因为他们吸取了银行的教训,银行一直用大机,十年都不怎么变,银行就觉得这些搞大机开发和运维的没用了,把人都逼走了,结果没人,也变不了了,算是企业短视导致双输吧。

阿里人去搞技术,用平安的观念来看,似乎有些非理性,好像是在追求梦想一般。

最后,说一下 Oracle 迁移到 MySQL 的技术难点,就是先去 Procedure,Oracle 不去 Procedure,根本无从谈迁移到 MySQL。

1、阿里将系统从 Oracle 移植到 MySQL 上总体规模是多大?投入的资源有多少?

阿里替换 Oracle 为 MySQL,主要不是成本上的考虑。阿里买大机、小机、高端存储、Oracle 也是很舍得花钱的,也是不差钱的主。

但是阿里的业务增长非常迅猛,年增长率 500%。远远超过商业硬件、软件厂商遵从的摩尔定律的发展速度。阿里多次请求商业公司为阿里定制系统,或开放系统接口,以满足业务需要。但商业公司反应迟钝,行动缓慢,导致技术成了业务的严重瓶颈。

阿里从 Oracle 转换到 MySQL,拥抱开源,主要是为了提高自己的技术掌控度,不使自己的技术过度依赖于商业厂商。

2、在一个库的迁移过程中,DBA、开发、测试各自的投入大概是多少?

阿里没有对这种精细化的东西有过计算。决定要做转换,就进行转换了。我个人觉得,阿里是企业家,看重的是战略的东西。先抢占市场先机,市场将百倍千倍回报。平安是商人,精打细算,反复论证,黄花菜都凉了。

3、在迁移过程中,都遇到了哪些问题以及是如何解决的?

(1)技术问题:

主要是根据阿里的业务需要,修改 MySQL 源码,符合自己的需要。

举例:查询排序。修改 MySQL,在数据库内部将查询分为简单查询、复杂查询,对复杂查询做资源限制,防止占用简单查询资源。

根据特定业务的特点,修改 MySQL,特定的更新完成后默认提交,不再需要单独的 commit 语句。

并发复制。MySQL 原有的复制为单线程复制,延迟过大,不能满足需要。修改 MySQL 做并发复制。

(2)现存系统问题:

淘宝系统逻辑简单,数据量大,且数据库要求不使用存储过程,且 SQL 相对简单。应用系统与数据库松耦合,转换难度实际不大。

(3)观念问题:

现有的技术人员在 Oracle 上的学习、经验的投入,如果转到 MySQL 将会损失。如何说服?答:都是关系型数据库,相通的。技术上转换难度不大。另外,需要顺应趋势。

开发部门对 MySQL 不信任,不相信。如何说服?答:规模小,重要性低的系统先转换到 MySQL,运行良好,做为示范。另外,也积累经验。逐步替换重要系统。

(4)人员储备问题:

大量招聘对技术有热情的员工,允许其按兴趣研究技术,不给业务压力,但要求定期有研究结果汇报、交流。做技术储备,不使技术成为业务的瓶颈。

商业模式的创新很容易,只要有个好点子就可以了。但是技术积累需要 3 年、5 年甚至 10 年。举例:业务方想过节秒杀促销,除了阿里等大企业有能力做,其他银行等都做不了。一做系统就挂了。要提前做技术储备,不使技术成为业务的瓶颈。

4、迁移是进行了完整的代码重构还是本着最小化改变原则?

借系统变更、改造等本身就需要做变更的机会,顺便把迁移给做了。

5、也可以问一下对 PostgreSQL 的看法

PostgreSQL 也是相当不错的开源数据库。PostgreSQL 与 MySQL 相比,应用广泛程度与人员熟悉程度远低于 MySQL。因此,阿里选择了 MySQL。

6、怎么对复杂查询做资源限制的?

通过中间件实现,类似于 TDDL 这样自开发的中间件,阿里有很多。

一般情况下,简单查询和复杂查询同时发送到数据库中,数据库并不对这两种查询做区别,总是分配资源进行执行。

阿里通过修改 MySQL,使用一定规则(如:访问的表的数量、子查询嵌套层数等)将 SQL 分为简单查询和复杂查询两类,并统计两类 SQL 的资消耗情况。

复杂 SQL 一般为统计分析类查询,简单 SQL 一般为业务处理类查询。

为避免复杂 SQL 占用过多资源,导致简单 SQL 无法执行,设定了复杂 SQL 的资源消耗阀值。如果复杂 SQL 的资源消耗达到阀值,那么暂停复杂 SQL 的执行,将资源让给简单查询。

http://www.housong.net/pingan_ali_day.html

#sohu-dba#