|
|
你需要知道的关于NoSQL数据库的10件事
By Guy Harrison , Translated By Jametong
关系数据模型已经流行了几十年了,但是一种新型的数据库(即NoSQL)正在吸引各大企业的关注.下面是对其优势与劣势的一个简单总结.
在过去的1/4世纪中,关系型数据库(RDBMS)一直是数据库管理系统的主导模型.但是,今天,非关系型,”云,”或者”NoSQL”数据库正以数据库管理系统的替代模型而获得认知.在本文中,我们将考察这些非关系型NoSQL数据库的10个关键因素:最重要的5个优势以及5个挑战.
可以通过此链接下载本文的PDF格式.
NoSQL的5个优势
1. 弹性扩展
多年来,数据库管理员一直依赖于向上扩展(scale up)－随着数据库负载的增加购买更大的数据库服务器―而不是向外扩展－随着负载的增加将数据库分不到多个不同的主机上.然而,随着每秒事务数与可用性需求的提高,以及数据库往云或虚拟环境的迁移,向外扩展到廉价硬件的经济优势越来越难以抵挡.
RDBMS或许比较难以在廉价的集群上进行向外扩展,但是,NoSQL数据库的新品从设计之初就是为了利用新节点的优势进行透明扩展,他们通常在设计时就考虑使用低成本的廉价硬件.
2. 大数据量
在过去10年,与每秒事务数的增长超出了认知一样,存储的数据的规模也出现了极大的增长.O’Reilly明智的称此为”数据的工业革命.”RDBMS的容量也在增长以匹配这些数据的增长,但是,与每秒事务数一样,单个RDBMS可有效管理的数据规模限制让部分企业越来越难以忍受.今天,大规模数据量可以交由NoSQL系统来处理,比如Hadoop,超过目前最大的RDBMS可以管理的数据规模.
3. 再见了,DBA(回头见,DBA?)
这些年,虽然RDBMS的提供商宣称推出了很多的可管理性方面的改进,高端的RDBMS系统还是只能交由昂贵的、高度受训的DBA来进行维护.高端RDBMS系统从设计到安装以及后续的调优，都需要DBA们深度介入.
从理论上，通常，NoSQL数据库的最初的设计目标就是更少的管理介入:自动修复、数据分布以及更简单的数据模型，从而更少的管理与调优需求.实际上，关于DBA将死的谣言很可能被略微放大了.对于任何关键的数据存储,总是需要有人来关心它的性能以及可用性.
4. 经济性
NoSQL数据库通常使用廉价服务器集群来管理暴增的数据与事务规模,而RDBMS倾向于依赖昂贵的专有服务器与存储系统.其结果是,NoSQL数据库的每GB数据或每秒事务数的成本要远远低于RDBMS,使得你可以以更低的价格来存储与处理更多的数据.
5. 灵活的数据模型
在大量的生产环境数据库中,变更管理是一个非常棘手的问题.哪怕是对数据模型的很小的变更,在RDBMS中也需要进行小心的管理,甚至还需要停机或降低服务级别.
在数据模型的限制这一点上，NoSQL数据库要宽松的多，或者完全不存在. NoSQL的键值存储(Key value Store)与文档数据库(Document Database)允许应用在一个数据单元中存入它想要的任何结构.即使是定义更加严格的基于BigTable的NoSQL数据库,通常也允许创建新的字段而不致带来麻烦.
其结果是,应用的变更与数据库结构的变更不需要绑定在一个变更单元中进行管理.理论上,这可以提高应用的迭代速度,然而,显然,如果应用无法管理数据的完整性,它将带来不良的副作用.
NoSQL的5个挑战
NoSQL数据库的可能性空间引发了大量的关注,但是,在它们成为企业级应用的主流之前,还有大量的障碍有待克服.下面是几个主要的挑战.
1. 成熟度
RDBMS已经存在了很长一段时间. NoSQL的支持者认为它们的年纪是它们过时的象征,但是,对于大部分CIO(首席信息官)来讲,RDBMS的成熟度是可以让人放心的.通常,RDBMS系统都很稳定,功能也很丰富.相比而言,大部分NoSQL的替代品都还处于前-生产环境阶段,还有大量的关键特性有待实现.
生活在科技前沿对于大部分开发人员来讲,是令人兴奋的,但是,企业在实施时必须非常谨慎.
2. [...]
为什么Flowdock从Cassandra迁移到MongoDB
by Otto Hilska @mutru Translated by Jametong
Flowdock是一个基于Web的团队通讯工具.所有的软件开发人员都应该使用它进行沟通,而不是使用Campfires、Skype Chats或IRC等工具.因为它可以更好的的支持他们的真实工作流.
上周,我们对Flowdock的数据库服务做了一次切换,聪从Cassandra迁移到了另一种NoSQL工具-MongoDB.由于我们的技术选择已经引起了大家的部分兴趣,我将在此向公众说明下我们的决策理由.
我们的部分客户一定对下面这个图片记忆犹新:
从一定程度上讲,我们遭遇到了Cassandra的稳定性问题.所有的节点都陷入无线无限循环(infinite loop),运行垃圾回收工作(GC, Garbage Collection)并尝试压缩数据文件-并偶尔导致集群瘫痪.除了对集群进行重启并经常性的手工对节点做压缩工作以让其稳定一会外,我们无计可施.其他人也报告过类似的问题.在前面几周的时间里,我们的Cassandra节点总是会吃掉给他分配的所有资源,而导致Flowdock运行缓慢.
由于我们刀口嗜血式的数据库选择(James注: 这是我不认同的地方,可能对于一些Startup的公司来讲,这是一种不得已的选择.),这已经不是我们第一次遇到此类问题了.从Cassandra 0.4升级到0.5的时候,我们被迫关闭了整个集群,仅仅是为了将所有的数据刷新到磁盘上(虽然,我们已经按照文档进行了手工刷新的操作).这个操作导致我们丢失了几分钟的讨论内容,以及我们手工创建的索引出现严重的不一致,以致于需要做完全的重建.我想,我们最后离开办公室的时间已经是凌晨4点了.
从我们最初选择Cassandra到现在,NoSQL社区已经出现了很大的变化.MongoDB已经发生了很大的改变,最近新增的自动分片(auto-sharding)与副本集(replica set)使得它可以作为Cassandra的有力的替代品.因此,我们决定试试MongoDB.
写从Cassandra往MongoDB的数据迁移的脚本耗费我一天的时间.在一周左右的时间内,我们已经可以完全在MongoDB上运行Flowdock了.在生产环境部署MongoDB之前,内部测试持续进行了好几个星期.
目前,我们已经完成这个调整,
1. 智能(多键)索引. 手工维护的索引令人生厌,MongoDB可以自动帮我们维护所需的索引.例如,我们的消息包含标签(tag),例如下面这个格式的document:
{ content: “Write a blog post about #mongodb.”,
workspace: ‘myflow’,
tags: ["mongodb", "todo", "@Otto"] }
这样,如果仅检索自己的任务,Flowdock的后台只需要做下面这个查询:
db.messages.find({
workspace: ‘myflow’,
tags: { $all: ["todo", "@Otto"] }
})
2. 查询.无论数据模型多么简单,每当需要执行一个查询的时候,你都不需要提前规划此事.在MongoDB中,你可以直接在控制台定制复杂的查询,这一点非常类似于SQL数据库.它会据此执行一次顺序扫描,这比在客户端手工处理上百万的记录要更快捷也更便利.
3. Map-Reduce. 这是分析人员的利器啊.MongoDB的Map-Reduce功能支持虽然不是非常完美,但它起码很易用.
4. GridFS让我们的文件存储操作变得非常容易.它的存储能力可以随着我们的MongoDB集群的扩展一起增长.
我们也遭遇到部分轻微的限制:
1. 我们发现了一个JSON解析的bug,不过我们在10分钟内就解决了此bug.
2. BSON的Document键中不支持点(dot).通常,这或许不是个问题,但是我们必须在数据迁移中解决此问题.
3. Document有4MB的大小限制.这对于我们的数据模型来讲不是问题,由于MongoDB对在位的原子更新(atomic in-place updates)有非常好的支持,所以,你需要关注,Document不要超过4MB的限制.
4. 增加新的节点没有在Cassandra中那么容易.然而,Cassandra在新增节点的负载均衡上有它自己的问题.
到目前为止,它的运行还非常平稳.开发人员与数据库管理员的工作也因此减轻了很多.
这份笔记最初只是个便条,直到我认识到它的意义不仅与此,从而决定将此便条拓展成一份完整的说明,我计划在接下来的2个星期发表完下面四个部分.
1. 介绍 — 此文
2. 磁盘与表空间碎片
3. 表碎片
4. 索引碎片
介绍
By Jonathan Lewis Translated By Jametong
单词“fragmentation”（碎片）的涵义是某些东西被分成多个片段,不过,有时也隐含表示被拆成了大量的小片段.在Oracle的语境下,需要仔细考虑你所说的“片段”,片段的粒度大小,以及其对性能产生的可能影响.由于可以在(逻辑)磁盘层面、文件层面、表空间(tablespace)层面、段(segment)层面、区间(extent)层面以及块(block)层面来讨论碎片,当你在评论种说出类似于“我的表空间有碎片”或“我的索引有碎片”时,需要仔细想清楚你到底想要说明什么.
让我从一个例子开始:我创建了一个新的表空间,并移入了一张表.当我检查dba_extents视图,将发现此表空间有100个区间.很明显,从这个单词的基本涵义看,它被“分成多片”了,它有100个不同的片段组成.另一方面,因为此表是我在此表空间内创建的第一个对象,我可以发现所有的区间都相邻,你可以说此表“逻辑上分成多片”但是“物理上连续”.
这个碎片的例子会不会影响你的系统的性能呢？由于大部分Oracle IO都是在块级别上完成(我们将数据块读入到数据库高速缓冲区,我们将数据块写入到数据文件),任何特定区间内的数据块的位置都是无关的,答案或许是no.但有些时候,当我们在一个单一读请求(全表扫描 (TableScan)或者索引快速全扫描(Index Fast Full Scan))中尝试读取多个相邻的数据块时;如果我们的“物理上连续”的表却是“逻辑上被拆分”到了很多个区间,这会不会有问题呢?
假如说,每个区间都只能是64K,这会限制我们将发起的“db file multiblock read”请求的大小吗或者这些请求可以跨越区间边界读取吗?如果这个表空间是有两个(或多个)数据文件组成,而这些区间又是以“轮流”在两个文件之间分配的,这会影响读操作的方式吗?如果我们尝试进行并行表扫描,这些限制在“direct path read”上会不会有所不同呢?如果你的运行系统是一个数据仓库,需要花费大量的时间运行这种操作,那么这些就是你需要回答的问题.(例如,参见我3年前写的关于运行并行查询时的部分IO异常的记录,以及Christian Antognini在大约几年后描述的Oracle 11g中的一个相关改进.)
只有当你开始想清楚你理解“碎片”到底是什么,你才可以理解它可能导致的问题,以及为什么它会(或不会)对你的系统造成问题的理由. 在第二部分中,我将讨论你该如何考虑表级别以及表空间级别的碎片问题.
Cassandra vs HBase
By Vaibhav Puranik Translated By Jametong
我们是一家广告网络公司.我们需要存储展示与点击信息.我们在为我们的新项目评估多个不同的大批量数据(或nosql,或任何你喜欢的称呼)系统.过去8个月中,我们一直在一个测试产品上使用HBase,并且满意它的表现,但是,最近Cassandra的风头很高,因此,我们决定对它做个测试.我认为,从某些角度讲,Cassandra团队的推广做的很不错.你将发现,在Santa Monica，哪怕是非技术人员(诸如风险投资商、CEO以及产品经理)也会相互推荐使用Cassandra.
Cassandra给人的第一印象很好.它们的首页看上去比HBase更加专业也更加友好.安装并运行它也很简单.这个网站的文档很丰富.说实在话,安装并让其工作只花费了我5分钟的时间.
真正的挑战是理解Cassandra的数据模型,并尝试在我们的使用场景中实现它.我们很清楚如何在HBase中实现它,因为我们对HBase有相当不错的使用经验.虽然Cassandra也是从BigTable出继承了同样的数据模型,Cassandra与HBase之间还是有一些根本性的不同的.我试图用表格整理了两个系统之间的差异,如下:
Cassandra
HBase
缺少类似于表的概念.所有的文档都告诉你,有多个Keyspace的情况不常见.这意味着你必须在一个集群中共享同一个key space.另外,新增keyspace需要重启集群才能生效.
存在表相关的概念.每个表都有它自己的key space. 这一点对我们来说很重要.添加/删除表都很容易,跟在RDBMS中一样.
使用字符串的Key.通常使用uuid作为Key.如果希望你的数据按照时间排序,可以使用TimeUUID.
使用二进制Key.通常将三个不同的项目组合在一起来构建一个Key.这意味着你可以搜索一个给定表中的多个键.
即使使用TimeUUID,也不会发生热点问题,因为Cassandra会对客户端请求做负载均衡.
如果Key的第一部分是时间或者序列数,就会发生热点问题.所有新的Key都会被插入同一个区域,一直到此区域被塞满(因而导致出现热点问题).
支持列排序
不支持列排序
超列(Super Column)概念使得你可以设计非常灵活也非常复杂的表结构.
不支持超列.不过可以设计一个类似与超列的结构,不过列名称与值都是二进制的.
没有便捷的方法来自增长一个列的值.实际上,最终一致性的不同特性使得更新/写入一条记录并在更新后立即读出非常困难.必须确保使用R+W>N来实现强一致性.
由于设计上就是一致性.提供了一个非常便捷的方法来自增计数器.非常适合做数据汇总.
刚开始支持Map Reduce接口.还需要有一个hadoop集群来运行它.需要将数据从Cassandra集群迁移到Hadoop集群.不适合对大型数据运行map reduce任务.
对Map Reduce的支持是原生的.HBase构建在Hadoop集群上.数据不需要做迁移.
如果不需要Hadoop的话,维护相对简单.
由于包含多个诸如Zookeeperr、Hadoop以及HBase本身的可活动组件，维护相对复杂.
到目前为止,还没有本地化的Java Api支持.没有Java文档.虽然是使用Java编写的,你还是必须用Thrift接口来与集群进行通讯.
有友好的本地Java API.比Cassandra更像是Java系统.由于我们的应用是基于Java的,这一点对我们很重要.
没有主节点,因此也没有单点故障.
虽然在概念上有一个主节点服务,HBase本身对它的依赖并不严重.即使在主节点宕机的情况下,HBase集群仍然可以正常提供数据服务.Hadoop的Namenode是一个单点故障.
在按照这种方式比较过数据模型与相关特性后,对我们来讲,HBase是明显的优胜者.我的看法是,如果你确实需要一致性,HBase是一个明显的选择.更进一步,本地化的Map Reduce支持、表概念以及可修改而且不用重启集群的简单的表结构是你不可忽略的加分项.HBase是一个更加成熟的平台.当人们说Twitter、Facebook在使用Cassandra时,他们忘记了这些公司同时也在使用HBase.实际上,Facebook最近雇用了一个HBase的代码提交者(Commiter),这清楚地表明Facebook对HBase的兴趣.
总之,我们全力支持HBase!!
扩展Facebook到5亿用户以及以上
By Robert Johnson Translated By Jametong
今天对Facebook来讲,我们达到了Facebook的一个非常重要的里程碑-5亿的用户数.这对于我们这些从事技术与运维的工程师来讲尤其令人激动,是我们构建了有能力处理如此巨大规模的增长的系统.当我在4年前来到Facebook的时候,我们有700万用户(在当时看似已经是非常的数量了),这一路走来遇到的挑战远远超出我们的想像.
下面是我们处理的部分大数字(the Big Numbers):
5个亿的活跃用户数
每天1000亿的点击数
500亿的图片数
2万亿的缓存对象,每秒亿级的请求数
每天130TB的日志量
这些年,我们在此页面写了部分关于我们如何处理这么大规模数据的技术方案.今天,我将退后一步,来谈谈一些我们关于扩展(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)有了完全不同的理解.
|
|
最近评论