go4it

just do it

从myspace数据库看分布式系统数据结构变迁

从myspace数据库看分布式系统数据结构变迁

http://smb.pconline.com.cn/database/0808/1403100.html
[08-29 14:33:40]出处:pconline作者:责任编辑:heyaorong
  MySpace已经成为全球众口皆碑的社区网站之王。尽管一流和营销和管理经验自然是每个IT企业取得成功的首要因素,但是我们却抛弃这一点,而主要着眼于探讨在数次面临系统扩张的紧急关头MySpace是如何从技术方面采取应对策略的。
  MySpace信息系统发展历程:
  第一代架构—添置更多的Web服务器
  MySpace最初的系统很小,只有两台Web服务器(分担处理用户请求的工作量)和一个数据库服务器(所有数据都存储在这一个地方)。那时使用的是 Dell双CPU、4G内存的系统。在早期阶段,MySpace基本是通过添置更多Web服务器来对付用户暴增问题的。但到在2004年早期,在 MySpace用户数增长到五十万后,其数据库服务器已经开始疲于奔命了。
  第二代架构—增加数据库服务器
  与增加Web服务器不同,增加数据库并没那么简单。如果一个站点由多个数据库支持,设计者必须考虑的是,如何在保证数据一致性的前提下让多个数据库分担压力。
  MySpace运行在三个SQL Server数据库服务器上—一个为主,所有的新数据都向它提交,然后由它复制到其它两个;另两个数据库服务器全力向用户供给数据,用以在博客和个人资料栏显示。这种方式在一段时间内效果很好——只要增加数据库服务器,加大硬盘,就可以应对用户数和访问量的增加。
  这一次的数据库架构按照垂直分割模式设计,不同的数据库服务于站点的不同功能,如登录、用户资料和博客。垂直分割策略利于多个数据库分担访问压力,当用户要求增加新功能时,MySpace只需要投入新的数据库加以支持。在账户到达二百万后,MySpace还从存储设备与数据库服务器直接交互的方式切换到SAN(存储区域网络)—用高带宽、专门设计的网络将大量磁盘存储设备连接在一起,而数据库连接到SAN。这项措施极大提升了系统性能、正常运行时间和可靠性。然而,当用户继续增加到三百万后,垂直分割策略也变得难以维持下去。
  第三代架构—转到分布式计算架构
  几经折腾,最终,MySpace将目光移到分布式计算架构——它在物理上分布的众多服务器,整体必须逻辑上等同于单台机器。拿数据库来说,就不能再像过去那样将应用拆分,再以不同数据库分别支持,而必须将整个站点看作一个应用。现在,数据库模型里只有一个用户表,支持博客、个人资料和其他核心功能的数据都存储在相同数据库。
  既然所有的核心数据逻辑上都组织到一个数据库,那么MySpace必须找到新的办法以分担负荷——显然,运行在普通硬件上的单个数据库服务器是无能为力的。这次,不再按站点功能和应用分割数据库,MySpace开始将它的用户按每百万一组分割,然后将各组的全部数据分别存入独立的SQL Server实例。目前,MySpace的每台数据库服务器实际运行两个SQL Server实例,也就是说每台服务器服务大约二百万用户。据MySpace的技术人员说,以后还可以按照这种模式以更小粒度划分架构,从而优化负荷分担。
  第四代架构—求助于微软方案
  2005年早期,账户达到九百万,MySpace开始用微软的C#编写 ASP.NET程序。在收到一定成效后,MySpace开始大规模迁移到ASP.NET。用户达到一千万时,MySpace再次遭遇存储瓶颈问题。SAN 的引入解决了早期一些性能问题,但站点目前的要求已经开始周期性超越SAN的I/O容量——即它从磁盘存储系统读写数据的极限速度。
  第五代架构—增加数据缓存层并转到支持64位处理器的SQL Server 2005
  2005年春天,MySpace账户达到一千七百万,MySpace又启用了新的策略以减轻存储系统压力,即增加数据缓存层——位于Web服务器和数据库服务器之间,其唯一职能是在内存中建立被频繁请求数据对象的副本,如此一来,不访问数据库也可以向Web应用供给数据。
  2005年中期,服务账户数达到两千六百万时,MySpace因为我们对内存的渴求而切换到了还处于beta测试的支持64位处理器的SQL Server 2005。升级到SQL Server 2005和64位Windows Server 2003后,MySpace每台服务器配备了32G内存,后于2006年再次将配置标准提升到64G。
  事实上,MySpace的Web服务器和数据库仍然经常发生超负荷,其用户频繁遭遇“意外错误”和“站点离线维护”等告示,他们不得不在论坛抱怨不停……
  MySpace正是在这样不断重构站点软件、数据库和存储系统中,才一步步走到今天。事实上,MySpace已经成功解决了很多系统扩展性问题,其中存在相当的经验值得我们借鉴。MySpace系统架构到目前为止保持了相对稳定,但其技术人员仍然在为SQL Server支持的同时连接数等方面继续攻坚,尽可能把事情做到最好。
  虽然自2005年早期,站点账户数超过7百万后,系统架构到目前为止保持了相对稳定,但MySpace仍然在为SQL Server支持的同时连接数等方面继续攻坚。
  里程碑一:50万账户
  MySpace最初的系统很小,只有两台Web服务器和一个数据库服务器。那时使用的是Dell双路CPU、4G内存的系统。
  单个数据库就意味着所有数据都存储在一个地方,再由两台Web服务器分担处理用户请求的工作量。但就像MySpace后来的几次底层系统修订时的情况一样,三服务器架构很快不堪重负。此后一个时期内,MySpace基本是通过添置更多Web服务器来对付用户暴增问题的。
  但到在2004年早期,MySpace用户数增长到50万后,数据库服务器也已开始汗流浃背。
  但和Web服务器不同,增加数据库可没那么简单。如果一个站点由多个数据库支持,设计者必须考虑的是,如何在保证数据一致性的前提下,让多个数据库分担压力。
  在第二代架构中,MySpace运行在3个SQL Server数据库服务器上——一个为主,所有的新数据都向它提交,然后由它复制到其他两个;另两个全力向用户供给数据,用以在博客和个人资料栏显示。这种方式在一段时间内效果很好——只要增加数据库服务器,加大硬盘,就可以应对用户数和访问量的增加。

        里程碑二:1-2百万账户
  MySpace注册数到达1百万至2百万区间后,数据库服务器开始受制于I/O容量——即它们存取数据的速度。而当时才是2004年中,距离上次数据库系统调整不过数月。用户的提交请求被阻塞,就像千人乐迷要挤进只能容纳几百人的夜总会,站点开始遭遇"主要矛盾",Benedetto说,这意味着MySpace永远都会轻度落后于用户需求。
  有人花5分钟都无法完成留言,因此用户总是抱怨说网站已经完蛋了。这一次的数据库架构按照垂直分割模式设计,不同的数据库服务于站点的不同功能,如登录、用户资料和博客。于是,站点的扩展性问题看似又可以告一段落了,可以歇一阵子。
  垂直分割策略利于多个数据库分担访问压力,当用户要求增加新功能时,MySpace将投入新的数据库予以支持它。账户到达2百万后,MySpace还从存储设备与数据库服务器直接交互的方式切换到SAN(Storage Area Network,存储区域网络)——用高带宽、专门设计的网络将大量磁盘存储设备连接在一起,而数据库连接到SAN。这项措施极大提升了系统性能、正常运行时间和可靠性。
  里程碑三:3百万账户
  当用户继续增加到3百万后,垂直分割策略也开始难以为继。尽管站点的各个应用被设计得高度独立,但有些信息必须共享。在这个架构里,每个数据库必须有各自的用户表副本——MySpace授权用户的电子花名册。这就意味着一个用户注册时,该条账户记录必须在9个不同数据库上分别创建。但在个别情况下,如果其中某台数据库服务器临时不可到达,对应事务就会失败,从而造成账户非完全创建,最终导致此用户的该项服务无效。
  另外一个问题是,个别应用如博客增长太快,那么专门为它服务的数据库就有巨大压力。
  2004年中,MySpace面临Web开发者称之为"向上扩展"对"向外扩展"(译者注:Scale Up和Scale Out,也称硬件扩展和软件扩展)的抉择——要么扩展到更大更强、也更昂贵的服务器上,要么部署大量相对便宜的服务器来分担数据库压力。一般来说,大型站点倾向于向外扩展,因为这将让它们得以保留通过增加服务器以提升系统能力的后路。
  但成功地向外扩展架构必须解决复杂的分布式计算问题,大型站点如Google、Yahoo和Amazon.com,都必须自行研发大量相关技术。以Google为例,它构建了自己的分布式文件系统。
  另外,向外扩展策略还需要大量重写原来软件,以保证系统能在分布式服务器上运行。"搞不好,开发人员的所有工作都将白费",Benedetto说。因此,MySpace首先将重点放在了向上扩展上,花费了大约1个半月时间研究升级到32CPU服务器以管理更大数据库的问题。Benedetto说,"那时候,这个方案看似可能解决一切问题。"如稳定性,更棒的是对现有软件几乎没有改动要求。
  糟糕的是,高端服务器极其昂贵,是购置同样处理能力和内存速度的多台服务器总和的很多倍。而且,站点架构师预测,从长期来看,即便是巨型数据库,最后也会不堪重负,Benedetto说,"换句话讲,只要增长趋势存在,我们最后无论如何都要走上向外扩展的道路。"
  因此,MySpace最终将目光移到分布式计算架构——它在物理上分布的众多服务器,整体必须逻辑上等同于单台机器。拿数据库来说,就不能再像过去那样将应用拆分,再以不同数据库分别支持,而必须将整个站点看作一个应用。现在,数据库模型里只有一个用户表,支持博客、个人资料和其他核心功能的数据都存储在相同数据库。
  既然所有的核心数据逻辑上都组织到一个数据库,那么MySpace必须找到新的办法以分担负荷——显然,运行在普通硬件上的单个数据库服务器是无能为力的。这次,不再按站点功能和应用分割数据库,MySpace开始将它的用户按每百万一组分割,然后将各组的全部数据分别存入独立的SQL Server实例。目前,MySpace的每台数据库服务器实际运行两个SQL Server实例,也就是说每台服务器服务大约2百万用户。Benedetto指出,以后还可以按照这种模式以更小粒度划分架构,从而优化负荷分担。
  当然,还是有一个特殊数据库保存了所有账户的名称和密码。用户登录后,保存了他们其他数据的数据库再接管服务。特殊数据库的用户表虽然庞大,但它只负责用户登录,功能单一,所以负荷还是比较容易控制的。
  里程碑四:9百万到1千7百万账户
  2005年早期,账户达到9百万后,MySpace开始用Microsoft的C#编写ASP.NET程序。C#是C语言的最新派生语言,吸收了C++ 和Java的优点,依托于Microsoft .NET框架(Microsoft为软件组件化和分布式计算而设计的模型架构)。ASP.NET则由编写Web站点脚本的ASP技术演化而来,是 Microsoft目前主推的Web站点编程环境。
  可以说是立竿见影, MySpace马上就发现ASP.NET程序运行更有效率,与ColdFusion相比,完成同样任务需消耗的处理器能力更小。据技术总监 Whitcomb说,新代码需要150台服务器完成的工作,如果用ColdFusion则需要246台。Benedetto还指出,性能上升的另一个原因可能是在变换软件平台,并用新语言重写代码的过程中,程序员复审并优化了一些功能流程。
  最终,MySpace开始大规模迁移到 ASP.NET。即便剩余的少部分ColdFusion代码,也从Cold-Fusion服务器搬到了ASP.NET,因为他们得到了 BlueDragon.NET(乔治亚州阿尔法利塔New Atlanta Communications公司的产品,它能将ColdFusion代码自动重新编译到Microsoft平台)的帮助。
  账户达到1千万时,MySpace再次遭遇存储瓶颈问题。SAN的引入解决了早期一些性能问题,但站点目前的要求已经开始周期性超越SAN的I/O容量——即它从磁盘存储系统读写数据的极限速度。
  原因之一是每数据库1百万账户的分割策略,通常情况下的确可以将压力均分到各台服务器,但现实并非一成不变。比如第七台账户数据库上线后,仅仅7天就被塞满了,主要原因是佛罗里达一个乐队的歌迷疯狂注册。
  某个数据库可能因为任何原因,在任何时候遭遇主要负荷,这时,SAN中绑定到该数据库的磁盘存储设备簇就可能过载。"SAN让磁盘I/O能力大幅提升了,但将它们绑定到特定数据库的做法是错误的。"Benedetto说。
  最初,MySpace通过定期重新分配SAN中数据,以让其更为均衡的方法基本解决了这个问题,但这是一个人工过程,"大概需要两个人全职工作。"Benedetto说。
  长期解决方案是迁移到虚拟存储体系上,这样,整个SAN被当作一个巨型存储池,不再要求每个磁盘为特定应用服务。MySpace目前采用了一种新型SAN设备——来自加利福尼亚州弗里蒙特的3PARdata。
  在3PAR的系统里,仍能在逻辑上按容量划分数据存储,但它不再被绑定到特定磁盘或磁盘簇,而是散布于大量磁盘。这就使均分数据访问负荷成为可能。当数据库需要写入一组数据时,任何空闲磁盘都可以马上完成这项工作,而不再像以前那样阻塞在可能已经过载的磁盘阵列处。而且,因为多个磁盘都有数据副本,读取数据时,也不会使SAN的任何组件过载。
  当2005年春天账户数达到1千7百万时,MySpace又启用了新的策略以减轻存储系统压力,即增加数据缓存层——位于Web服务器和数据库服务器之间,其唯一职能是在内存中建立被频繁请求数据对象的副本,如此一来,不访问数据库也可以向Web应用供给数据。换句话说,100个用户请求同一份资料,以前需要查询数据库100次,而现在只需1次,其余都可从缓存数据中获得。当然如果页面变化,缓存的数据必须从内存擦除,然后重新从数据库获取——但在此之前,数据库的压力已经大大减轻,整个站点的性能得到提升。
  缓存区还为那些不需要记入数据库的数据提供了驿站,比如为跟踪用户会话而创建的临时文件——Benedetto坦言他需要在这方面补课,"我是数据库存储狂热分子,因此我总是想着将万事万物都存到数据库。"但将像会话跟踪这类的数据也存到数据库,站点将陷入泥沼。
  里程碑五:2千6百万账户
  2005年中期,服务账户数达到2千6百万时,MySpace切换到了还处于beta测试的SQL Server 2005。转换何太急?主流看法是2005版支持64位处理器。但Benedetto说,"这不是主要原因,尽管这也很重要;主要还是因为我们对内存的渴求。"支持64位的数据库可以管理更多内存。
  更多内存就意味着更高的性能和更大的容量。原来运行32位版本的SQL Server服务器,能同时使用的内存最多只有4G。切换到64位,就好像加粗了输水管的直径。升级到SQL Server 2005和64位Windows Server 2003后,MySpace每台服务器配备了32G内存,后于2006年再次将配置标准提升到64G。

意外错误促进系统健康成长
  如果没有对系统架构的历次修改与升级,MySpace根本不可能走到今天。但是,为什么系统还经常吃撑着了?很多用户抱怨的"意外错误"是怎么引起的呢?
  原因之一是MySpace对Microsoft的Web技术的应用已经进入连Microsoft自己也才刚刚开始探索的领域。比如11月,超出SQL Server最大同时连接数,MySpace系统崩溃。Benedetto说,这类可能引发系统崩溃的情况大概三天才会出现一次,但仍然过于频繁了,以致惹人恼怒。一旦数据库罢工,"无论这种情况什么时候发生,未缓存的数据都不能从SQL Server获得,那么你就必然看到一个'意外错误'提示。"他解释说。
  去年夏天,MySpace的Windows 2003多次自动停止服务。后来发现是操作系统一个内置功能惹的祸——预防分布式拒绝服务攻击(黑客使用很多客户机向服务器发起大量连接请求,以致服务器瘫痪)。MySpace和其他很多顶级大站点一样,肯定会经常遭受攻击,但它应该从网络级而不是依靠Windows本身的功能来解决问题——否则,大量 MySpace合法用户连接时也会引起服务器反击。
  "我们花了大约一个月时间寻找Windows 2003服务器自动停止的原因。"Benedetto说。最后,通过Microsoft的帮助,他们才知道该怎么通知服务器:"别开枪,是友军。"
  紧接着是在去年7月某个周日晚上,MySpace总部所在地洛杉矶停电,造成整个系统停运12小时。大型Web站点通常要在地理上分布配置多个数据中心以预防单点故障。本来,MySpace还有其他两个数据中心以应对突发事件,但Web服务器都依赖于部署在洛杉矶的SAN。没有洛杉矶的SAN,Web服务器除了恳求你耐心等待,不能提供任何服务。
  Benedetto说,主数据中心的可靠性通过下列措施保证:可接入两张不同电网,另有后备电源和一台储备有30天燃料的发电机。但在这次事故中,不仅两张电网失效,而且在切换到备份电源的过程中,操作员烧掉了主动力线路。
  2007年中,MySpace在另两个后备站点上也建设了SAN。这对分担负荷大有帮助——正常情况下,每个SAN都能负担三分之一的数据访问量。而在紧急情况下,任何一个站点都可以独立支撑整个服务,Benedetto说。
  MySpace仍然在为提高稳定性奋斗,虽然很多用户表示了足够信任且能原谅偶现的错误页面。
  "作为开发人员,我憎恶Bug,它太气人了。"Dan Tanner这个31岁的德克萨斯软件工程师说,他通过MySpace重新联系到了高中和大学同学。"不过,MySpace对我们的用处很大,因此我们可以原谅偶发的故障和错误。" Tanner说,如果站点某天出现故障甚至崩溃,恢复以后他还是会继续使用。
  这就是为什么Drew 在论坛里咆哮时,大部分用户都告诉他应该保持平静,如果等几分钟,问题就会解决的原因。Drew无法平静,他写道,"我已经两次给MySpace发邮件,而它说一小时前还是正常的,现在出了点问题……完全是一堆废话。"另一个用户回复说,"毕竟它是免费的。"Benedetto坦承100%的可靠性不是他的目标。"它不是银行,而是一个免费的服务。"他说。
  换句话说,MySpace的偶发故障可能造成某人最后更新的个人资料丢失,但并不意味着网站弄丢了用户的钱财。"关键是要认识到,与保证站点性能相比,丢失少许数据的故障是可接受的。"Benedetto说。所以,MySpace甘冒丢失2分钟到2小时内任意点数据的危险,在SQL Server配置里延长了"checkpoint"操作——它将待更新数据永久记录到磁盘——的间隔时间,因为这样做可以加快数据库的运行。
  Benedetto说,同样,开发人员还经常在几个小时内就完成构思、编码、测试和发布全过程。这有引入Bug的风险,但这样做可以更快实现新功能。而且,因为进行大规模真实测试不具可行性,他们的测试通常是在仅以部分活跃用户为对象,且用户对软件新功能和改进不知就里的情况下进行的。因为事实上不可能做真实的加载测试,他们做的测试通常都是针对站点。

总结一点:从myspace看更加验证,数据库是软件系统的瓶颈,而且最不可伸缩,一旦数据库成为系统瓶颈,就得动大手术,实现架构上的变迁,这是伤筋动骨,变迁人员压力巨大的。另外由于是社区,就是变迁数据丢失也没什么大不了,如果是企业那就......

http://www.jdon.com/jivejdon/forum/messageList.shtml?thread=34551&message=23116484#23116484

我最欣赏Gavin King的这句话,狠狠煽了那些曾经跟随Gavin King人的耳光:
数据库成为了大多数企业应用的主要瓶颈,也成为了运行环境中最不具伸缩性的层。
PHP/Ruby的用户会说什么都不共享(share nothing)的架构照样具有很好的伸缩性,这些傻瓜真正想的是“除了数据库以外什么都不共享(Share nothing except for the database)”的架构
我先来翻译一下上面这段意思:经过大量实践证明:数据库已经成为企业计算主要性能瓶颈,因为我们大量业务计算依赖数据库,虽然,数据库可以集群,但是代价昂贵,效率不高,而且最多两台或几台,因此,数据库已经成为运行环境中最不scalable的环节。
所谓伸缩性,就是弹性,整个软件架构既支持小负载运行,也支持大负载支持,只要增加服务器(PC服务器价格是便宜)即可;没有伸缩性意思这个软件小负载可以运行,到大负载,就有天花板了,即使进行数据库性能调优(这也是不少人觉得数据库技术很重要的原因),也只是缓口气,性能调优也有天花板,单台机器挖潜力总是有限的,向下死挖的概念就造成现在很多人对数据库调优技术的依赖;其实这些人为什么不向上想想,一台不够,我再增加一台,只要配置一下即可,经过权威测试:websphere/weblogic的20台PC服务器集群性能不亚于一台SUN/IBM的中型机,性价比已经一目了然了。
跟随PHP/Ruby的那些傻瓜用户认识到这点,就开始回避,宣称:share nothing,其实这是不可能的,应用中的很多数据都是依靠反复访问同一个数据库来达到共享,所以,实质是:Share nothing except for the database,类似鸵鸟把头插入沙子,认为就可以解决问题。
那么我们看看EJB或分布式缓存是如何解决这个共享问题:因为软件业务逻辑都是基于对象的,而这些对象可以在多台websphere/weblogic/jboss之间传输,通过分布式缓存就解决了共享问题,应用逻辑不必每次都要通过数据库来分享数据,应用逻辑之间本身可以直接传输业务对象数据,以达到分享。
所以,PHP/Ruby运行环境的架构特点还都是依赖数据库的,虽然他们打着Evans DDD口号,并且声称Ruby On Rails还是最适合DDD的,到时到最后落实代码时,就露出马脚,披着羊皮的狼,批着DDD,实则是以数据库中心。这也是为什么一些程序员既认为分析设计是要采取DDD,但是数据库技术依然重要的原因,这些都是不彻底的对象程序员,他们必然遭遇对象/关系数据库带来的复杂性,然后他们错以为是语言问题,转而追寻ROR这样动态语言,希望这个新语言能解救他们,虽然ROR有类似Hibernate之类ActiveRecord等ORM框架,由于运行环境还是依赖不伸缩的数据库,当系统复杂时,他们又会碰到OO/db的不匹配,真是傻瓜了。
当然,这种畸形也许适合一些中庸的中国程序员(对象和数据库两个都要)。不是我在大喊数据库时代过去时,那么多人反对,反对弱化数据库,因为他们脑子里数据库为王已经根深蒂固,就像一个保皇派,保数据库这个皇帝,大权不能旁落。
另外:我一直提出的Open Session In View是一个在Spring中无法解决的问题,是一个反模式,这点在Seam中也得到了解决,这说明是一个真理,我喜欢在Jdon说真话,很多言论都可以查询,2003年至今我没有发现严重的错误观点和预测,唯一没料到的是:PHP比我想象中顽强。

posted on 2009-07-15 21:31  cxccbv  阅读(1484)  评论(0编辑  收藏  举报

导航