与冯大辉谈数据库架构

视屏地址:

受访人 冯大辉  采访人 李明（nasi）、Jason Lai（赖翥翔）  发布于 2008年6月9日 上午2时42分

概要
在上个月阿里巴巴举办的网侠大会上，InfoQ中文站有幸与著名的DBA冯大辉在一起，谈了谈网站/数据库架构、数据库性能调优、数据关系映射以及DBA个人职业发展等方面的话题。

个人简介
冯大辉，就职于阿里巴巴集团?**Ц侗Γㄖ泄?）网络科技有限公司（Alipay.com），担任数据库架构师，负责支付宝数据库架构规划、解决方案等相关工作。2007 年国内首批 Oracle ACE. 网上 ID 为“Fenng”，业余时间关注 Web 2.0 网站架构技术。个人Blog：
InfoQ中文站的读者们，大家好，今天我们有幸请到冯大辉先生参加我们的这个采访，大辉你好，请跟大家介绍一下你是谁，在做些什么？
大家好，我叫冯大辉，是支付宝网络中国科技有限公司的DBA。现在主要是负责支付宝相关的数据库架构的工作，在工作之余，我也比较关注Web2.0的一些发展情况，会在BLOG上写一些架构相关的文章，和大家分享，BLOG的地址是DBAnotes.net
作为一名资深的DBA，大辉却在自己的BLOG上边写了不少关于网站架构这方面的一些文章，能不能谈谈DBA跟网站架构这方面的关系呢？
好多朋友和我开玩笑，说我做一个DBA，却总去写一些架构相关的东西，“是不是这个厨子不看菜谱，看兵法了？”其实二者之间我觉得是有些关系的。因为像数据库的维护，甚至于设计、架构相关的工作，做到一定程度上觉得自己还是要向前再走几步，也就是说一定要把我们架构相关的一些事情融合进来，但是作为一个 DBA没必要一定要像我们的相关架构师这样，去做一些编码之类的实际工作。但是一些和DB结合的比较紧密的东西是一定要关注一下的，这也是我在BLOG上写了不少与架构相关文章的一个主要原因。
一般来说要提升网站的性能，瓶颈主要都有那些，如果要解决这些瓶颈，又都存在哪些最佳实践呢？
在以前，可能很大的一个瓶颈，我觉得还是在数据库上，最后会落在实际的IO上面。但是现在随着一些Web2.0技术的出现，当前我觉得一个网站真正能否应付大流量、高并发，主要的问题还在于Cache的相关使用上，这点十分重要。
一个要经受住大规模、高并发、访问量考验的成功Web2.0网站在设计的架构中要注意哪些东西呢？
这个我想在前期的规划中肯定是需要做一些预防性的措施，比如说选择适合的技术架构啊，这个绝对是在第一步应该必须要考虑的事情。另外还有一些像包括在产品设计上也会有很多需要注意的地方，现在我们的很多Web2.0网站，包括国内的这些新兴的一些Web2.0网站，在产品设计上，我认为多多少少存在一些过度设计的现象。但这些设计不经意之间可能会对后台带来灾难性的影响，那么这对开发人员、架构师，甚至维护人员都带来很大的压力。

另一方面呢，我想参考当前业界上一些已经相对比较成熟的技术，还是很关键的。我们做一个网站就好比造汽车一样，不一定非要造得像奔驰这样顶级豪华的，我们只需造一辆能跑起来，跑得很好的汽车，这可能就已经达到成功的一半了。
那刚才在网站性能和调优这方面，你刚才也提到了，缓存的作用是非常重要的，那么他到底处于怎么样一个重要的地位呢？如何对缓存进行优化从而提升性能？
就我以前的相关经验，在Oracle的一些实践上，一方面是在高并发的设计上会有一些注意的事项。另外一个就是能否充分利用Oracle自己的内存，最后实质上看其是能否充分利用自己的Cache机制。在Web2.0网站，可能很少有使用Oracle这样的场景。但在MySQL上，一方面MySQL自己的 Cache机制应该说还做得不错，再一个就是，绝大多数网站都会考虑使用，像Memcached 这样的外部组件进来，然后在这个地方，其实我们最后考量的是命中率，衡量命中率的高低，这是大家必须要注意的地方。

命中丢失实际上最后压到我们的数据库上，数据库的命中再丢失有可能会压到最下面的磁盘上。磁盘一定要能支撑住我们当前的最低需求，举个最简单的例子，我们的应为：memcached，可能前面的命中率是80%，那么有20%会压到后面的DB上，这个DB的命中率有可能达到95%，剩下的5%，加上前面那个 20%，最后我们把所有的乘起来，这个比例会打到最后端的硬盘上，我们硬盘的整体响应能力又是有限的…我们可以去做RAID，甚至可以出现单块硬盘这样的情况。那么硬盘承载能力是有限的，我们把它反上去乘，一点点的乘，乘到前面去，就能计算出我们当前的系统能承载Cache的瓶颈。在设计的时候，一定要考虑到这样的情况，否则当压力确实突然增加到我们不能承受的时候，临时做一些扩展的手段，可能就会比较麻烦。
你刚才说到Cache命中率，那对于一个比较成功的这种网站，它Cache命中率一般会在多少呢？
拿Oracle来说，我觉得它本身的命中率做到90%多，甚至是99.99这样的情况，在MySQL的环境下可能做不到这样， Memcached一般，据我所知，可能70%、80%已经不错了，但是命中率只是一个表面的现象，我们还要看实际真正的外部应用到底是怎样，有的可能不同的Web应用类型，他所能承载的访问频率也不大一样，所以并没有固定的比例，只能是凭一些经验，但总体来说肯定是命中率越高，会越好一些。
在Web2.0的时代，海量数据对于越来越多的开发者来说，已经不再是一个遥不可及的话题了，可能随便哪一个访问量很大的Web2.0网站都有可能拥有令人咂舌的数据量，那么对于这种网站，除了对数据库存储进行优化，除了缓存，然后还有那些策略？
我觉得可能主要是在存储方面会有一些大的挑战，比如存储的可靠性。像以前我们就曾经遇到过这样的BSP服务商，对客户的数据居然没有备份，导致了很多用户损失了一段时间之内的数据，这样总体来说对网站的声誉、对用户的资源都是很糟糕的。

随着我们现在互联网的飞速发展，数据总体来说是趋于膨胀性的，在这个过程中，我们如何把数据有效的存储，并且有效的获取，便是个比较复杂的问题，像一方面我们前面说了太多Web2.0相关的话题。还有一个是像，比如说我所在的公司支付宝，当然我们也面临着这样的大数据量、海量数据的挑战，当前我们的一个策略，也是沿袭公司这SOA战略化思想，就是数据库相关的，对后台的相关数据进行一定的SOA化处理，然后另外一个比较重要的策略就是数据生命周期的管理，我们对这样的，在数据生命已经达到这样的周期之后，就相关的数据做一些归档化的处理，进行二级存储或者分级存储。那么话说回来，对一些Web2.0网站，我觉得也可以运用这样的思想机制，对用户已经不大可能访问或者访问频率比较小的（数据），采用分级存储，或者说额外做一些访问策略的制订，应该也是有必要的。
我们也听说过另外一种分片数据库机制，那么请你谈谈分片这种策略是怎么样一种策略？
分片总的来说，它不是一种比较新的技术，我们现在像MySQL在 5 点几之后，有了分区功能。其实在这之前，MySQL是没有分区能力的。当时如果需要处理一些比较大的数据量。比方说要对数据随着时间进行历史化处理，那么就会比较麻烦，人们可能是因地制宜，就产生Sharding这样技术策略。严格来说，数据分片呢，其实在我们以前也有一些相关的实践，在其他的数据库上，我们也会有一些历史策略，只是当时这个名词没有完全定义下来。据我所知，这个词是从大型专线游戏中发展出来的，大部分用户会集中在某个区域。那么这一部分集中在某个区域的用户，会把他们放在特定的服务器上。不同区域之间的用户之间的关联度可能不大，这个场景和我们现在的数据库分片策略其实是非常非常相似的，我们当前如果对数据库做一些分片，也会采用这样的基本思想，比如说根据不同的用户ID范围，或者说不同的地区，如果建的是商务网站，可能根据产品的类型，我们会把不同的数据扔到不同的DB上，这些不同DB之间的关联度是很小的。然后我们在不同DB之间，可能相对来说会有一个分装层，在这个封装层之外，对这个应用程序用户来说，就像是透明的，那么就达到了我们数据库上高度扩展化的目标。谢谢。
那分片这种策略有什么利弊吗？
分片首先他的好处还是很容易看到的，起码我们的DB能达到不依赖于某个单点，而这样能做到平滑的扩展，就像大家常说的Scale Out横向扩展机制。它的弊端也是比较明显，对于事务高速处理这样的网站，它有它的自己的缺点，事实上我们好多朋友也应该知道，一个事务如果跨数据库，这样对设计者，对编码人员来说，还是比较棘手。那么如果一个事务如果跨两个甚至多个DB，Sharding复杂度就会很高。Sharding在业界的应用场景基本上也就是这种读应用比较重的情况，而且对事务的安全性要求不高，这样的场景会非常适合。
目前在许多网站的架构设计中有绝大多数的项目在持久化方面就是采用数据关系映射（ORM）的方式。大家对于这种高负载的大规模网站应用来说，你觉得存在哪些应用呢？
首先一点呢，我想拿我们支付宝来说，ORM是大家觉得用得非常好的，但在一个相对比较大的开发环境，对开发团队来说，它的弊端可能就不大容易看出来。因为我们用得是ORM，就很容易把中间DB这层完全隔离出来。然后把这一层的处理交给专门的DB职员——我们这边还有专门的开发DBA，由他们来专门对这层进行集中的监控管理，甚至做一些规划类的工作。这样呢，开发工程师还有架构师这边，实际上他们可以集中精力在其他方面做更多的投入，一个比较大的团队我觉得像ORM这些还是很容易能看到好处的。

在另一方面，我们看一下它的弊端，因为像一些Web，回头我们说一些，Web中小网站，他可能相对人手也比较少，大家 用得工具呢，可能像PHP、 ROR这些东西，也是在开发上，上手又比较容易的。那么这个时候，事实上一个潜在的问题是，当代码规模到一定程度，如果没有去做一些OR映射，那么可能会给网站带来一些潜在的比如说代码管理上的问题，这一点只是我的个人看法，实际上大家在具体的应用场景可能会有各自头疼的问题，我在这方面不是专家，也仅供大家参考。
那你所做的支付宝，其实是企业级别的应用，在企业级别应用所采用的这种架构策略和，一般Web 2.0所采用的这种架构策略会有什么异同？
事实上一个从很明显的一个特点说，支付宝其实业务是非常复杂的，这和我们很多的Web2.0公司不大一样，Web2.0它可能从一个点切入进去。在这一点上，我觉得做得比较透。支付宝呢，它可能有点像我们以前做的一些通用软件，他要考虑不同的行业、不同的用户、还有像买卖之间，与这么多银行之间的关系等等，这个复杂度还是很大的。

这实际上就从一定程度上决定了我们和Web2.0公司截然不同的应用解决方案，像当前我们在支付宝，在一年之前，甚至两年之前就已经考虑，把我们的整个网站SOA化、组件化。在这个过程中，也考虑了一些像Web2.0中的技术元素，但总体的思路呢，还是说向SOA化，向面向服务这方面大步的跨进，然后就从 SOA这一点，事实上很多Web2.0公司，他们未必能完全的实现，完全的做到这样的面向服务化，我觉得这可能是两者截然不同的一个表面特点。

另外，像支付宝也在尝试做一些，对外部客户、服务提供一些接口，甚至完全开放的一个平台，这一点又和我们当前这些像FaceBook，或者是说，像美国的MySpace这样的社交区、SNS网络了有一些共通之处。
那目前在Web2.0网站这个领域里面，网站的架构主要有哪些趋势，下边还将有怎么样一个走向呢？
其实作为一个技术人员，每当要谈到趋势，肯定要给大家笑。从中长期来看，国内的一些Web2.0服务逐渐又涌现出来了，那么随着这样的业务发展，我相信会有更多的商业化元素加进来。像以前是好多Web2.0公司是完全使用开源的技术，那么随着规模的兴起，一些以前提供开源技术的组织或个人他们会尝试进行一些商业化的运作，商业化并不是个坏事情，一方面给我们提供更好的服务。另一方面，他们得到了足够的商业支持，反过来之后他们又会对整体的开源开发环境、发展环境起到很好的促进，我相信在未来的两到三年之内，会有一部分的商业公司涌到Web2.0的发展生态圈里面。然后从技术方面来讲，像前面几个月 MySQL被Sun收购了。那么起码是在Web.2.0这样的软件链条中的一个重要环节，有些人可能会感觉，出了一些问题。但现在像在数据库这一层呢，也不排除像PostgresSQL这些其他的数据库，他们趁这个机会被商业公司所拥抱，他们也会做出一些更大规模的应用场景出来。在数据库这方面可能会限制大家，几家开源数据库形成一个僵局，Sun在……这个有些扯远了，还是绕回来。像现在很多的Web2.0公司，他们对Web服务器这方面也会采用一些比较新的，像Nginx我觉得在，起码在接下来的一段时间内会吸引绝大多数公司长期的去使用它、去拥抱它，甚至为它开发一些更激动人心的新特性。
那最后作为一个由DBA成长为DB Architect（应为：Architect），同样都是A，但这个A已经有一个变化，那么你对后来者有哪些建议呢？

[ 本帖最后由 Roc.Ken 于 2008-6-16 12:14 编辑 ]　　　　　　
--------------------next---------------------