最近看到的另外一个介绍Twitter技术的视频[Slides] [Video (GFWed)],这是Twitter的John Adams在Velocity 2009的一个演讲,主要介绍了Twitter在系统运维方面一些经验。 本文大部分整理的观点都在Twitter(@xmpp)上发过,这里全部整理出来并补充完整。
Twitter没有自己的硬件,都是由NTTA来提供,同时NTTA负责硬件相关的网络、带宽、负载均衡等业务,Twitter operations team只关注核心的业务,包括PerfoRMANce,Availability,Capacity PlAnning容量规划,配置管理等,这个可能跟国内一般的互联网公司有所区别。
运维经验
@H_696_1106@metricsTwitter的监控后台几乎都是图表(critical metrics),类似驾驶室的转速表,时速表,让操作者可以迅速的了解系统当前的运作状态。联想到我们做的类似监控后台,数据很多,但往往还需要浏览者 做二次分析判断,像这样满屏都是图表的方法做得还不够,可以学习下这方面经验。 据John介绍可以从图表上看到系统的瓶颈-系统最弱的环节(web,mq,cache,db?)
根据图表可以科学的制定系统容量规划,而不是事后救火。
@H_696_1106@配置管理
每个系统都需要一个自动配置管理系统,越早越好,这条一整理发到Twitter上去之后引起很多回应。
@H_696_1106@Darkmode配置界面可以enable/disable 高计算消耗或高I/O的功能,也相当于优雅降级,系统压力过大时取消一些非核心但消耗资源大的功能。
@H_696_1106@进程管理Twitter做了一个”Seppaku” patch,就是将Daemon在完成了n个requests之后主动kill掉,以保持健康的low memory状态,这种做法据了解国内也有不少公司是这样做。
@H_696_1106@硬件Twitter将cpu由AMD换成Xeon之后,获得30%性能提升,将cpu由双核/4核换成8核之后,减少了40%的cpu,不过John也说,这种升级不适合自己购买硬件的公司。
代码协同经验
@H_696_1106@RevIEw制度Twitter有上百个模块,如果没有一个好的制度,容易引起代码修改冲突,并把问题带给最终用户。所以Twitter有一强制的source code revIEw制度,如果提交的代码的svn comment没有”revIEwed by xxx”,则pre-commit脚本会让提交失败,revIEw过的代码提交后会通过自动配置管理系统应用到上百台服务器上。 有@xiaomics同学在Twitter上马上就问,时间成本能否接受?如果有紧急功能怎么办?个人认为紧急修改时有两人在场,一人修改一人 revIEw也不是什么难事。
@H_696_1106@部署管理从部署图表可以看到每个发布版本的cpu及latency变化,如果某个新版本latency图表有明显的向上跳跃,则说明该发布版本存在问题。另外在监控首页列出各个模块最后deploy版本的时间,可以清楚的看到代码库的现状。
@H_696_1106@团队沟通Campfire来协同工作,campfire有点像群,但是更适合协同工作。对于Campfire就不做更多介绍,可参考Campfire官方说明。
Cache
-
@H_784_2@memcache key hash,使用FNV hash 代替 MD5 hash,因为FNV更快。
- 开发了Cache Money plugin(Ruby),给应用程序提供read-through,write-through cache,就像一个db访问的钩子,当读写数据库的时候会自动更新cache,避免了繁琐的cache更新代码。
- “evictions make the cache unreliable for important configuration data”,Twitter使用memcache的一条经验是,不同类型的数据需放在不同的mc,避免eviction,跟作者前文Memcached数据被踢(evictions>0)现象分析中的一些经验一致。 @H_784_2@memcached SEGVs,Memcached崩溃(cold cache problem)据称会给这种高度依赖Cache的Web 2.0系统带来灾难,不知道Twitter具体怎么解决。
- 在Web层Twitter使用了Varnish作为反向代理,并对其评价较高。
云计算架构
@H_2_3874@ @H_674_377@
作者认为,金字塔概念最能说明每一层的大小,它也表达了每 个层是依赖前层的消息传递。在概念上,硬件是基础和广泛层。SaaS层是顶峰,也是最轻层。这种观点是来自于将购买SaaS的的最终用户角度。对于一个非 常大的企业内部,PaaS平台层将是顶峰。使用内部开发的软件的内部各部门将实现他们的顶峰SaaS。还要注意:大小和层位置并不一定等同于重要性。硬件 层可能是最重要的,因为它是所有超过一定点的商品。
硬件层The HarDWare Layer
必须考虑容错和冗余,大部分人认为没有容错硬件廉价商品。冗余和容错处理在软件层内,硬件预计要失败的,当然故障多电源容错服务器,RAID磁盘阵列也是必要的。
虚拟层The Virtualization Layer
基于操作系统OS的虚拟化层,虚拟资源能够在线即时增加拓展,允许供应商提供基础设施作为服务(SaaS),VMware,Citrix公司,Sun都提供虚拟化产品。
The IaaS Layer
提 供和控制的基于虚拟层的计算方式,终端用户能够精确控制每个虚拟机没分钟每小时耗费多少钱。比如提供一个共同的接口,如门户网站暴露的API,允许最终用 户创建和配置虚拟机模板的需求。最终用户还可以控制何时打开或破坏虚拟机,以及如何在虚拟机互相联网。在这个领域的主要竞争者例子是亚马逊网络服务的 EC2,S3和数据库服务。
The PaaS Layer
这一层的目的是尽量减少部署云的复杂性和麻烦,最终用户 利用和开发的这层的API和编程语言。两个很好的例子是谷歌的App ENGIne 和Force.com平台,在App ENGIne中,谷歌公开云存储,平台和数据库,以及使用Python和Java编程语言的API。开发人员能够编写应用程序并部署到这一层中,后端可伸缩性架构设计完全交给谷歌负责,最终用户完全不必担心管理基础设施。Force.com平台类似,但采用了自定义的编程语言名为Apex。如果你是一个大型企业寻求内部开发应用的部署,这层是你的顶峰。
The SaaS Layer
如 果您是中小型企业(SME)和大企业不希望开发自己的应用程序时,SaaS的层是你的顶峰(是你将直接面对的)。您只是进行有兴趣地采购如电子邮件或客户 关系管理服务,这些功能服务已经被供应商开发成功,并部署到云环境中了,您只需验证的应用是否符合你的使用需要,帐单可以基于包月租费等各种形式,,作为 最终用户的您不会产生开发和维护拓展应用程序软件的任何成本。越来越多的企业订阅Salesforce.com和Sugar CRM的SaaS产品。
反模式
单点失败(Single Point of Failure)
大部分的人都坚持在单一的设备上部署@R_667_9616@,因为这样部署的费用会比较低,但是我们要清楚任何的硬件设备都会有失败的风险的,这种单点失败会严重的影响用户体验甚至是拖垮你的应用,因此除非你的应用能容忍失败带来的损失,否则得话应该尽量的避免单点风险,比如做冗余,热备等。
同步调用
同步调用在任何软件系统中都是不可避免的,但是我们软件工程师必须明白同步调用给软件系统带来的问题。如果我们将应用程序串接起来,那么系统的可用性就会低于任何一个单一组件的可用性。比如组件A同步调用了组件B,组件A的可用性为99.9%,组件B的可用性为99.9%,那么组件A同步调用组件B的可用性就是99.9% * 99.9%=99.8%。同步调用使得系统的可用性受到了所有串接组件可用性的影响,因此我们在系统设计的时候应该清楚哪些地方应该同步调用,在不需要同步调用的时候尽量的进行异步的调用(而我这里所说的异步是一种基于应用的异步,是一种设计上的异步,因为J2EE目前的底层系统出了JMS是异步API以外,其它的API都是同步调用的,所以我们也就不能依赖于底层J2EE平台给我们提供异步性,我们必须从应用和设计的角度引入异步性)
不具备回滚能力
虽然对应用的每个版本进行回滚能力测试是非常耗时和昂贵的,但是我们应该清楚任何的业务操作都有可能失败,那么我们必须为这种失败作好准备,需要对系统的用户负责,这就要求系统一定要具有回滚的能力,当失败的时候能进行及时的回滚。(说到回滚大家可能第一时间想到的是事务的回滚,其实这里的回滚应该是一种更宽泛意义的回滚,比如我们记录每一次的失败的业务操作,这样在出现错误的时候就不是依靠于事务这种技术的手段,而是通过系统本身的回滚能力来进行回滚失败业务操作)。
@L_559_403@不记录日志
日志记录对于一个成熟稳定的系统是非常重要的,如果我们不进行日志记录,那么我就很难统计系统的行为。
@L_134_404@无切分的数据库
随着系统规模的慢慢变大,我们就需要打破单一数据的限制,需要对其进行切分。
无切分的应用
系统在规模小的时候,也许感觉不出无切分的应用带来的问题,但是在目前互联网高速发展的时代,谁能保证一个小应用在一夜或者是几夜以后还是小应用呢?说不定哪天,我们就发现应用在突如其来的访问量打击的支离破碎。因此我们就需要让我们的系统和我们一样具有生命力,要想让系统具有应付大负载的能力,这就要求@R_667_9616@具有很好的伸缩性,这也就要求应用需要被良好的切分,只有进行了切分,我们才能对单一的部门进行伸缩,如果应用是一块死板的话,我们是没有办法进行伸缩的。就好比火车一样,如果火车设计之初就把他们设计为一体的,那么我们还怎么对火车的车厢进行裁剪?因此一个没有切分的应用是一个没有伸缩性和没有可用性的应用。
将伸缩性依赖于第三方厂商
如果@R_667_9616@系统的伸缩性依赖于第三方的厂商,比如依赖于数据库集群,那么我们就为系统的伸缩性埋下了一个定时炸弹。因为只有我们自己最清楚我们自己的应用,我们应该从应用和设计的角度出发去伸缩@R_667_9616@,而不是依赖于第三方厂商的特性。
olAP
联机分析处理 (olAp) 的概念最早是由关系数据库之父E.F.Codd于1993年提出的,他同时提出了关于olAP的12条准则。olAP的提出引起了很大的反响,olAP作为一类产品同联机事务处理 (olTp) 明显区分开来。
olAP报表产品最大的难点在哪里?
目前报表工具最大的难点不在于报表的样式(如斜线等),样式虽较繁琐但并非本质困难。最根本的难点在于业务 部门知道报表代表的真正含义,却不知道报表的数据统计模型模型;而IT部门通过理解业务部门的描述,在数据库端进行设置数据统计模型,却对报表本身所代表 的价值很难理解。说起来有点深奥,其实并不复杂,olAP最基本的概念只有三个:多维观察、数据钻取、CUBE运算。
关于CUBE运算:olAP分析所需的原始数据量是非常庞大的。一个分析模型,往往会涉及数百万、数千万条数据,甚至更多;而分析模型中包含多个维数据,这些维又可以由浏览者作任意的提取组合。这样的结果就是大量的实时运算导致时间的延滞。
我们可以设想,一个1000万条记录的分析模型,如果一次提取4个维度进行组合分析,那么实际的运算次数将 达到4的1000次方的数量。这样的运算量将导致数十分钟乃至更长的等待时间。如果用户对维组合次序进行调整,或增加、或减少某些维度的话,又将是一个重 新的计算过程。
从上面的分析中,我们可以得出结论,如果不能解决olAP运算效率问题的话,olAP将是一个毫无实用价值的概念。那么,一个成熟产品是如何解决这个问题的呢?这涉及到olAP中一个非常重要的技术——数据CUBE预运算。
一个olAP模型中,度量数据和维数据我们应该事先确定,一旦两者确定下来,我们可以对数据进行预先的处理。在正式发布之前,将数据根据维进行最大
限度的聚类运算,运算中会考虑到各种维组合情况,运算结果将生成一个数据CUBE,并保存在 服务器上。
这样,当最终用户在调阅这个分析模型的时候,就可以直接使用这个CUBE,在此基础上根据用户的维选择和维组合进行复运算,从而达到实时响应的效果。
NOsql们背后的共有原则
几个星期之前,我写了一篇文章描述了常被称作 NOsql 的一类新型数据库的背后驱动。几个星期之前,我在Qcon上发表了一个演讲,其中,我介绍了一个可伸缩(scalable)的 twitter 应用的构建模式,在我们的讨论中,一个显而易见的问题就是数据库的可扩展性问题。要解答这个问题,我试图寻找隐藏在各种 NOsql 之后的共有模式,并展示他们是如何解决数据库可扩展性问题的。在本文中,我将尽力勾勒出这些共有的原则。
假设失效是必然发生的
与我们先前通过昂贵硬件之类的手段尽力去避免失效的手段不同,NOsql实现都建立在硬盘、机器和网络都会失效这些假设之上。我们需要认定,我们不 能彻底阻止这些时效,相反,我们需要让我们的系统能够在即使非常极端的条件下也能应付这些失效。Amazon S3 就是这种设计的一个好例子。你可以在我最近的文章 Why ExisTing Databases (RAC) are So Breakable! 中找到进一步描述。哪里,我介绍了一些来自 Jason McHugh 的讲演的面向失效的架构设计的内容(Jason 是在 Amazon 做 S3 相关工作的高级工程师)。
对数据进行分区
通过对数据进行分区,我们最小化了失效带来的影响,也将读写操作的负载分布到了不同的机器上。如果一个节点失效了,只有该节点上存储的数据受到影响,而不是全部数据。
保存同一数据的多个副本
大部分 NOsql 实现都基于数据副本的热备份来保证连续的高可用性。一些实现提供了 API,可以控制副本的复制,也就是说,当你存储一个对象的时候,你可以在对象级指定你希望保存的副本数。在 GigaSpaces,我们还可以立即复制一个新的副本到其他节点,甚至在必要时启动一台新机器。这让我们不比在每个节点上保存太多的数据副本,从而降低 总存储量以节约成本。
你还可以控制副本复制是同步还是异步的,或者两者兼有。这决定了你的集群的一致性、可用性与性能三者。对于同步复制,可以牺牲性能保障一致性和可用 性(写操作之后的任意读操作都可以保证得到相@R_544_11197@的数据,即使是发生失效也会如此)。而最为常见的 GigaSpaces 的配置是同步副本到被分界点,异步存储到后端存储。
动态伸缩
要掌控不断增长的数据,大部分 NOsql 实现提供了不停机或完全重新分区的扩展集群的方法。一个已知的处理这个问题的算法称为一致哈希。有很多种不同算法可以实现一致哈希。
一个算法会在节点加入或失效时通知某一分区的邻居。仅有这些节点受到这一变化的影响,而不是整个集群。有一个协议用于掌控需要在原有集群和新节点之间重新分布的数据的变换区间。
另一个(简单很多)的算法使用逻辑分区。在逻辑分区中,分区的数量是固定的,但分区在机器上的分布式动态的。于是,例如有两台机器和1000个逻辑 分区,那么每500个逻辑分区会放在一台机器上。当我们加入了第三台机器的时候,就成了每 333 个分区放在一台机器上了。因为逻辑分区是轻量级的(基于内存中的哈希表),分布这些逻辑分区非常容易。
第二种方法的优势在于它是可预测并且一致的,而使用一致哈希方法,分区之间的重新分布可能并不平稳,当一个新节点加入网络时可能会消耗更长时间。一个用户在这时寻找正在转移的数据会得到一个异常。逻辑分区方法的缺点是可伸缩性受限于逻辑分区的数量。
更进一步的关于这一问题的讨论,建议阅读 Ricky Ho 的文章 NOSQL Patterns 。
@L_255_419@查询支持
在这个方面,不同的实现有相当本质的区别。不同实现的一个共性在于哈希表中的 Key/value 匹配。一些市县提供了更高级的查询支持,比如面向文档的方法,其中数据以 blob 的方式存储,关联一个键值对属性列表。这种模型是一种无预定义结构的(scheR_277_11845@a-less)存储,给一个文档增加或删除属性非常容易,无需考虑文档结 构的演进。而 GigaSpaces 支持很多 sql 操作。如果 SQL查询没有指出特定的简直,那么这个查询就会被并行地 map 到所有的节点去,由客户端完成结果的汇聚。所有这些都是发生在幕后的,用户代码无需关注这些。
使用 Map/Reduce 处理汇聚
@H_337_998@map/Reduce 是一个经常被用来进行复杂分析的模型,经常会和 Hadoop 联系在一起。 map/reduce 常常被看作是并行汇聚查询的一个模式。大部分 NOsql 实现并不提供 map/reduce 的内建支持,需要一个外部的框架来处理这些查询。对于 GigaSpaces 来说,我们在 sql 查询中隐含了对 map/reduce 的支持,同时也显式地提供了一个称为 executors 的 API 来支持 map/reduce。在质疑模型中,你可以将代码发送到数据所在地地方,并在该节点上直接运行复杂的查询。这方面的更多细节,建议阅读 Ricky Ho 的文章 Query Processing for NOSQL DB 。
基于磁盘的和内存中的实现
NOsql 实现分为基于文件的方法和内存中的方法。有些实现提供了混合模型,将内存和磁盘结合使用。两类方法的最主要区别在于每 GB 成本和读写性能。
最近,斯坦福的一项称为“The Case for RAMCloud”的调查,对磁盘和内存两种方法给出了一些性能和成本方面的有趣的比较。总体上说,成本也是性能的一个函数。对于较低性能的实现,磁盘方 案的成本远低于基于内存的方法,而对于高性能需求的场合,内存方案则更加廉价。
仅仅是炒作?
近来我见到的最多的问题就是 “NOsql 是不是就是炒作?” 或 “NOsql 会不会取代现在的数据库?”
我的回答是——NOsql 并非始于今日。很多 NOsql 实现都已经存在了十多年了,有很多成功案例。我相信有很多原因让它们在如今比以往更受欢迎了。首先是由于社会化网络和云计算的发展,一些原先只有很高端的 组织才会面临的问题,如今已经成为普遍问题了。其次,已有的方法已经被发现无法跟随需求一起扩展了。并且,成本的压力让很多组织需要去寻找更高性价比的方 案,并且研究证实基于普通廉价硬件的分布式存储解决方案甚至比现在的高端数据库更加可靠。(进一步阅读)所有这些导致了对这类“可伸缩性优先数据库”的需求。这里,我引用 AWS团队的接触工程师、VP, James Hamilton 在他的文章 One Size Does Not Fit All 中的一段话:
总结一下——我认为,现有的 sql 数据库可能不会很快淡出历史舞台,但同时它们也不能解决世上的所有问题。NOsql 这个名词现在也变成了 Not Only sql,这个变化表达了我的观点。
附
本书不求利,只图学术之便。感谢诸位大牛写了那么多的资料,如果您不愿意被引用,学生会重写相应的章节。引用网志多篇,由于涵盖太广难以一一校队,特此致歉。
感谢
感谢Jdon,dbanotes,infoq和Timyang.您们分享和撰写了那么多有用的资料。版本志
V0.1版本在2010.2.21发布,提供了本书的主题框架v0.2版本在2010.2.24发布,因为一些外界原因,提前发布。完善各个示例,勘误,翻译部分内容。
v0.3版本将在3月份或之后发布
引用
http://www.jdon.com/jivejdon/thread/37999 http://queue.acm.org/detail.cfm?ID=1413264 http://www.dbanotes.net/arch/five-minute_rule.HTML http://www.infoq.com/cn/news/2009/09/Do-Not-delete-Data http://www.infoq.com/cn/news/2010/02/ec2-oversubscribed http://timyang.net/architecture/consistent-hashing-practice http://en.wikipedia.org/wiki/Gossip_protocol http://horicky.blogspot.com/2009/11/nosql-patterns.HTML http://snarfed.org/space/transactions_across_datacenters_io.HTML http://research.microsoft.com/en-us/um/people/lamport/pubs/lamport-paxos.pdf http://en.wikipedia.org/wiki/diStributed_hash_table http://hi.baIDu.com/knuthocean/blog/item/cca1e711221dcfcca6ef3f1d.HTML http://zh.wikipedia.org/wiki/MapReduce http://labs.Google.com/papers/mapreduce.HTML http://nosql-database.org/ http://www.rackspacecloud.com/blog/2009/11/09/nosql-ecosystem/ http://www.infoq.com/cn/news/2008/02/ruby-mapreduce-skynet http://s3.amazonaws.com/AllThingsdiStributed/sosp/amazon-dynamo-sosp2007.pdf http://labs.Google.com/papers/bigtable.HTML http://www.allthingsdiStributed.com/2008/12/eventually_consistent.HTML http://www.rackspacecloud.com/blog/2009/11/09/nosql-ecosystem/ http://timyang.net/tech/twitter-operations/ http://blog.s135.com/read.php?394 http://www.progrAMMer.com.cn/1760/大佬总结
以上是大佬教程为你收集整理的NoSQL数据库笔谈全部内容,希望文章能够帮你解决NoSQL数据库笔谈所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错,欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ:384754419,请注明来意。