这是我准备今天下午给部门兄弟介绍的Enqueue Lock的ppt, 前面介绍部分纯理论部分没有做充分的测试,后半部分常用Enqueue Type的介绍, 都在以下环境做过测试.
OS : Windows XP (Intel T7250 ,3G mem) +
soft : Oracle 9201 32位
dbthink1
http://www.dbthink.com/?paged=5
| <!-- / Header -->
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| <!-- / Left Sidebar --><!-- Main Column --> |
Cassandra vs HBase 我们是一家广告网络公司.我们需要存储展示与点击信息.我们在为我们的新项目评估多个不同的大批量数据(或nosql,或任何你喜欢的称呼)系统.过去8个月中,我们一直在一个测试产品上使用HBase,并且满意它的表现,但是,最近Cassandra的风头很高,因此,我们决定对它做个测试.我认为,从某些角度讲,Cassandra团队的推广做的很不错.你将发现,在Santa Monica，哪怕是非技术人员(诸如风险投资商、CEO以及产品经理)也会相互推荐使用Cassandra. Cassandra给人的第一印象很好.它们的首页看上去比HBase更加专业也更加友好.安装并运行它也很简单.这个网站的文档很丰富.说实在话,安装并让其工作只花费了我5分钟的时间. 真正的挑战是理解Cassandra的数据模型,并尝试在我们的使用场景中实现它.我们很清楚如何在HBase中实现它,因为我们对HBase有相当不错的使用经验.虽然Cassandra也是从BigTable出继承了同样的数据模型,Cassandra与HBase之间还是有一些根本性的不同的.我试图用表格整理了两个系统之间的差异,如下:
在按照这种方式比较过数据模型与相关特性后,对我们来讲,HBase是明显的优胜者.我的看法是,如果你确实需要一致性,HBase是一个明显的选择.更进一步,本地化的Map Reduce支持、表概念以及可修改而且不用重启集群的简单的表结构是你不可忽略的加分项.HBase是一个更加成熟的平台.当人们说Twitter、Facebook在使用Cassandra时,他们忘记了这些公司同时也在使用HBase.实际上,Facebook最近雇用了一个HBase的代码提交者(Commiter),这清楚地表明Facebook对HBase的兴趣. 总之,我们全力支持HBase!! 以下内容摘自Eric Evans在OSCON上的ppt (Hands On Cassandra) 1. 设置Java的Heap Size.
2. 设置memtable flush的策略.
3. 缓存设置策略
4. 磁盘访问策略.
访问模式.
(buffer相关参数包含SlicedBufferSizeInKB,FlushDataBufferSizeInMB,FlushIndexBufferSizeInMB) 5. 相关内容监控
扩展Facebook到5亿用户以及以上 今天对Facebook来讲,我们达到了Facebook的一个非常重要的里程碑-5亿的用户数.这对于我们这些从事技术与运维的工程师来讲尤其令人激动,是我们构建了有能力处理如此巨大规模的增长的系统.当我在4年前来到Facebook的时候,我们有700万用户(在当时看似已经是非常的数量了),这一路走来遇到的挑战远远超出我们的想像. 下面是我们处理的部分大数字(the Big Numbers):
这些年,我们在此页面写了部分关于我们如何处理这么大规模数据的技术方案.今天,我将退后一步,来谈谈一些我们关于扩展(Scaling)的常用方法,以及部分我们用来解决此类扩展性问题的原则.如在Facebook本身一样,这些原则既涉及到技术也涉及到人.实际上,下面将要讨论的原则只有部分是完全技术相关的.在这一天结束的时候,是这些构建此系统并使其运转的人,我们用来扩展这些系统的最佳工具是我们可以处理任何问题的技术与运营团队.我最感到自豪的扩展统计指标是我们的每个工程师可以服务100万的用户,并且这个指标还在稳定地增长.
纵向扩展 它不是万能的,不过,它确实很重要.如果什么东西出现了爆发性的增长,处理它的唯一明智可行的方法就是将其分布到任意多数量的机器上.切记,计算机世界只有三个数字:0,1和n. 例如,考虑这样一种情况,用户数据库无法处理此负载.我们可以将其拆分成两个功能-比如说,账户与概要—并将他们放到不同的数据库中.这可能耗费掉我们一整天的时间,不过,也可能需要花费更多的工作,而且它只能扩展到两倍的容量.一旦完成此项工作,我们还必须开始下一步新的工作,而且下一步的工作会更加困难.相反,我们可以花费部分额外的时间来编写代码,以解决当两个用户不在同一个数据库中的情况.这可能比将代码拆成两半要耗费更多的工作时间,不过它可以在后续的很长时间都给我们带来收益. 注意,这样做并不会提高效率,实际上,它可能让情况变得更糟糕.效率是非常重要的,但是,我们认为它与扩展性(Scaling)是相互独立的项目. 快速响应 如果你查看我们的增长曲线,你将发现不到它有平稳的时候.我们从来就没有坐下来深呼吸、自我恭维一番、并考虑下一步该如何做的时间.每周,我们都会遭遇更大的挑战. 当然,我们对此图的最终走向有不错的注意,但是,每个规模级别上都会有惊喜.我们可用来处理这些惊喜的最佳方式是,拥有可以灵活应对并快速解决问题的技术与运维团队.快速响应也使得我们可以尝试更多的事情,来检验哪个才是在实践中真正可用的.我们发现,保持这种灵活性要远远比任何其他技术决定来的重要. 渐进变更 我们发现,保持快速移动的最好方式是进行大量的小的变更,并衡量做了这些变更后系统的反应.这并不意味着我们不去做大事,它仅仅表示只要有可能,我们都将其拆分成大量的独立的小块.与此相反,很多开发哲学尝试做批量变更. 即使有些东西无法在功能上对其进行拆分,我们也尝试逐步地推出.这可能意味着一次迁移一部分用户或者一部分机器,甚或构建一个与老系统完全并行的系统,并在我们衡量效果的时候缓慢地将流量切换过来. 渐进变更的伟大之处在于,只要有东西与你期望的不一致,你立刻就能发现.与直觉不同,这样做最终让保持系统稳定变更更加容易. 当生产环境有问题时,修复它的最困难的部分可能就是问题定位了.如果只有一个变更的话,问题的定位就简单多了.在传统模型中,当你有几个星期甚至几个月的变更一起生效时,定位具体哪个变更导致了问题可能是个梦魇. 度量一切 只有当你确实有能力监控系统在做什么时,你才可以做大量的小的变更,并监控系统在做什么.在Facebook,我们收集巨量的数据,任一特定的服务器都会输出几十上百个可制作成图表的指标.这不仅仅包含类似于CPU与内存等系统级别的内容,还包含应用级别的统计信息,我们可以据此判断为什么发生这样的事情. 当他们有问题时(真正有趣的问事情只会出现在生产环境),统计信息来自真实的发生问题的生产环境机器这一点非常重要.这些统计必须来自所有的机器,因为大量重要的影响都被平均数隐藏了,只是出现在分布图上,特别是95%或99%的百分位上. 我们构建了多个用来收集、分析这些数据的工具,并已经将它们发布到了开源社区,其中包含Hive与Scribe. 小而独立的团队 当我开始在Facebook工作时,我是图片处理模块团队的两个人之一.这很疯狂,但是,现在我们已经是一个”大”公司了.我们图片处理模块有三个人.我们每个人都了解图片处理模块的所有底细,都可以独立地做相关决定.因此,当需要对图片处理模块做什么变更时,都可以快速而准确地做好此变更.
控制权与责任 如果没有开发与运营团队地无缝合作，以及他们如同事一个团队一样的去解决问题，上述原则都将无法实施.对于这一点，说易行难,但是,我们有一个非常有用的基本原则. 对一件事情负责的人必须对这件事有控制权. 这一点看似非常明显,但实际情况通常不是这样.经典的例子是一个人发布另一个人写的代码.发布代码的人好像对此负责,但实际上是写这个代码的对此有控制权.这就将发布此代码的人置于一个艰难的境地,他们仅有的选择是要么发布此代码,要么对冒险对可能出现的问题承担责任,因此,他们有强烈的动机拒绝发布.另一方面,如果写此代码的人感觉自己并不负责此功能是否有效,这个功能很可能就无法有效工作. 在Facebook,我们每天都会往网站发布代码,是写这些代码的人对此具体负责.看到自己创建的东西被5亿的人使用是令人振奋并震撼人心的.看到它出问题就更加震撼人心了. 关于如果给这5亿的用户带来伟大的软件,我们所知道的最好的方式是让对此事的重要性有深刻理解,对此事有深刻理解并有控制权的人来做正确的决定. 5亿之外 我们非常自豪,我们创建了一个5亿人想要使用的网站,这个5亿人正在使用的网站仍然在工作.但这确实仅仅是一个开始. 我们希望在不远的将来,我们会有另外5个亿的用户,这些原则将帮助我们克服后面将要面对的任何新的挑战. Bobby, 技术总监, 比他4年前对大数字(Big Numbers)有了完全不同的理解.
Quora是一家做互动问答的网站, 他们最近在自己的网站上提出了一个问题,即标题所示: 为什么Quora不使用NoSQL来做数据存储? 我这边简要的翻译并总结以下: from Adam D’Angelo, MySQL user since 2004
| <!-- / Main Column --><!-- Right Sidebar --> 转自
最近评论