《HBase权威指南》一1.3 非关系型数据库系统Not

  • 时间:
  • 浏览:1
  • 来源:决战梭哈棋牌APP下载_决战梭哈棋牌APP官网

RDBMS提供了也不同类的操作(将会它是也不集中式的面向单服务器的系统),但那此操作在分布式系统中较难实现,那此操作还可不能否帮助用户出理 线程造成的资源竞争,里还可不能否帮助用户完成无共享应用服务器的设计。有了那此比较并交换(compare and swap,CAS)操作,将会说检查并设置(check and set)操作,在设计系统的也不 能是是是不是效地降低客户端的冗杂度。

一致性模型

最终一致性:在这样更新数据的一段时间里,系统将通过广播保证副本之间的数据一致性。

这使得通过统计原始的短网址标识refShortId,就还可不能否统计任意也不短网址映射到同也不长网址的使用率。shortId和refShortId利用散列ID的方法被唯一地分配给了短网址。同类:

机器会崩溃是也不客观处于的难题图片,只能有一套数据迁移方案来应对你有一种 情況(关于你有一种 点还可不能否参考在“一致性模型”中讨论的CAP定理)。每个数据存储要怎样进行服务器故障出理 ?故障出理 完毕也不 是是是不是还可不能否正常工作?这与也不 讨论的“一致性模型”维度有关系,将会失去一台服务器将会会造成数据存储的空洞(hole),甚至使整个数据存储不可用。将会替换掉故障服务器,这样恢复30%服务的难度有多大?从也不正在提供服务的集群中卸载一台服务器时,也会遇到同类的难题图片。

过去的四五年时间里,为了出理 难题图片,创新的前进步伐由缓慢变得出奇得快,好像每周回会发布新的框架和项目来满足需求。这样人都歌词 歌词 歌词 看后了所谓的NoSQL出理 方案问世了,NoSQL是Eric Evans针对Johan Oskarsson提出的“为新兴的新数据存储空间⑫命名”难题图片而创造的也不名词。

因果一致性:客户端以因果关系顺序观察到数据的改变。

用户只能了解自己的应用线程的访问模式。是读多写少?还是读写相当?将会是写多读少?是用范围扫描数据好,还是用随机读请求数据更好?也不系统仅仅对那此情況中的有一种支持得非常好,也不系统则对各种情況都提供了很好的支持。

系统回会在后台下载链接到的页面,并提取也不TITLE同类的HTML标签。将整个页面保存下来的目的是,供后续的异步任务进行出理 和分析。那此内容都由url表存储。

众所周知,冗杂的事务出理 ,如两阶段提交,会增加多个客户端竞争同也不资源的将会性。最糟糕的情況也不死锁,你有一种 情況也很难出理 。用户只能支持的系统采用哪种锁模型?你有一种 锁模型还可不能否出理 等候和死锁?

一致性还可不能否按照严格程度由强到弱分类,将会是按照对客户端的保证程度分类,下面是也不非正式的分类列表。

顺序一致性:每个客户端看后的数据依照它们操作执行的顺序而变化。

要怎样让,完整回会也不工具为NoSQL数据存储提供了SQL语言的入口,用于执行也不关系数据库中常用的冗杂条件查询。要怎样让,从查询方法上的限制来说,关系型数据库和非关系型数据库并这样严格的区分。

正是将会同类新产品还这样大慨的名称,NoSQL一举成名。在激烈的讨论中,它被认为是“SQL”的克星_,将会说,它给仍旧考虑使用传统RDBMS的人带来了瘟疫……也不开个玩笑!

故障出理

物理模型

原子操作的读-修改-写

只要用户有高读写吞吐率的需求,就要考虑配置一套还可不能否随着负载变化自动均衡出理 能力的系统。觉得 也不 只能完整出理 该难题图片,要怎样让里还可不能否帮助用户设计高读写吞吐量的线程。

只要连Memcached也不 的项目都划入到NoSQL范畴句子,那就成了只要完整回会RDBMS就还可不能否认为是NoSQL。你有一种 说法由于了错误的二分法,二分法掩盖了那此系统提供的令人振奋的技术可行性。在NoSQL范畴内,还有也不的维度还可不能否区分系统的特定优势所在。

负载均衡

有非常多的方法来转换一对一、一对多、多对多的关系,以适应HBase的底层架构。你有一种 简单的例子有多种实现方法,用户只能充分理解HBase存储设计的潜在能力,要怎样让深思熟虑地决定用哪有一种实现方法。

更糟糕的是,RDBMS的等候和死锁的出显 频率,与事务和并发的增加并完整回会线性关系,准确地说,与并发数目的平方以及事务规模的3次方甚至5次方相关⑮。分区通常是也不不切合实际的出理 方案,将会它只能客户端采用非常冗杂的方法和较高的代价来维护分区信息。

严格一致性:数据的变化是原子的,一经改变即时生效,这是一致性的最高形式。

这样人都歌词 歌词 歌词 歌词 来挑几种维度简单介绍一下。只能注意的是,列举的那此维度之也不全面,要怎样让这也完整回会唯一的区分方法。

分布式模式还是单机模式?你有一种 架构看起来像那此?是仅仅运行在单个机器上,还是分布在多台机器上,但分布及扩展规则由客户端管理,换句话说,由用户自己的代码管理?这样人都歌词 歌词 歌词 说分布式模式仅仅是个事后的工作,要怎样让只会在用户只能扩展系统时产生难题图片。将会系统提供了一定的扩展性,这样只能用户采取特定的操作吗?最简单的出理 方案也不一次增加一台机器,要怎样让设置好分区(这点对于不支持虚拟分区的系统非常重要),设置时只能考虑共同提高每个分区的出理 能力,将会系统的每个要素都只能提供均衡的性能。

采用最终一致性策略的系统还还可不能否细分为哪几块子类,要怎样让那此子策略还还可不能否共存。亚马逊的首席技术官Werner Vogels在一篇名为“Eventually Consistent”的文章中列举了这哪几块子类。这篇文章还谈到了CAP定理(CAP theorem)⑬,其中指出,也不分布式系统只能共同实现一致性、可用性和分区容忍性(或分区容错性)中的也不。CAP定理是热点话题,不过它完整回会区分分布式系统的唯一方法,但CAP定理指出了,开发一套共同满足以上需求的分布式系统是比较困难的。同类,Vogels提到:

弱一致性:这样做出保证的情況下,所有的更新会通过广播的形式传递,展现给不同客户端的数据顺序将会不一样。

在这本书里,这样人都歌词 歌词 歌词 时不回会提到一致性难题图片,也不有必要在这里对它稍加介绍。一现在刚开始了了的一致性是保证数据库客户端操作的正确性,数据库只能保证每一步操作完整回会从也不一致的情況到下也不一致的情況。系统这样明确地指定要怎样实现你有一种 功能,以便系统能是是是不是多种选则。最终,系统要选则是进入下也不一致的情況,还是回退到上也不一致的情況,从而保证一致性。

你有一种 主题在第9章里有更完整的介绍,主要阐述了要怎样充分利用HBase的形态去出理 实际难题图片。这样人都歌词 歌词 歌词 歌词 来看也不例子,理解传统的关系数据库模型转到列式存储的HBase的几点基本原则。

每个链接页面只存储一份,不过,将会也不用户将会会链接同也不长网址,要怎样让还想保存这样人都歌词 歌词 歌词 自己的完整信息,同类,使用统计信息,要怎样让会在短链接表中创建多个项来加以区分。通过这段逻辑,将url表、shorturl表和click表关联在了共同。

短网址存储在shorturl表中,用户还可不能否点击短网址来链接到完整网址。系统会跟踪每次点击,记录该网址的使用次数,回会记录也不也不信息,同类,点击该链接的用户所在的国家。那此信息会记录在click表中,你有一种 表的功能同类于也不计数器,以天为周期统计每天的访问量。

实际上两者在底层上是有区别的,尤其涉及到模式将会ACID事务形态时,将会这与实际的存储架构是相关的。也不你有一种 类的新系统首先做的事情是:失去也不限制因素以提升扩展性(你有一种 点会在1.3.1节讨论)。同类,它们通常不支持事务或辅助索引。更重要的是,你有一种 类系统是这样固定模式的,还可不能否随着应用的改变而灵活变化。

放宽一致性来提高系统可用性是也不非常有效的提议。不过你有一种 方案会强制让应用层去出理 一致性的难题图片,要怎样让也会增加系统的冗杂度。

各种非关系型数据库有也不共同的形态,共同这其中的也不形态与传统的存储方案完整回会也不共同点。要怎样让新系统并完整回会革命性的产品,从工程的淬硬层 来看更像是产品的进化。

系统通过user-shorturl表还可不能否快速查到指定用户的所有短网址标识。你有一种 功能被用在用户主页中,只要用户一登录就会被记录下来。user表存储觉得 际用户的完整信息。

觉得 表的数量相同,完整回会也不,但表的含义处于了变化:clicks表被合并到了shorturl表中,统计列使用日期为列键,格式为YYYYMMDD,同类,20110302,也不 用户还可不能否顺序访问数据。新增的user-shorturl表代替了外键,使查询用户相关信息变得更为快捷。

数据有多种存储的方法,包括键/值对(同类于HashMap)、半形态化的列式存储和文档形态存储。用户的应用要怎样存取数据?共同数据模式是是是不是随着时间而变化?

还可不能否用也不有趣的词来形容你有一种 情況——阻抗匹配(impedance match),意思也不要为也不给定难题图片找到也不理想的出理 方案,除了使用通用的出理 方案,还应该知道有那此可用的出理 方案,从而找到最适合于出理 该难题图片的系统。

用户信息存储在user表中,用户还可不能否在Hush网站上注册并创建自己短网址列表,共同里还可不能否在此网站上增加描述。user表与shorturl表之间维护了也不外键关系。

再来看看HBase短网址,即Hush,Hush允许用户将长网址映射为短网址(short URL),见图1-2表示的实体关系图(entity relationship diagram,ERD,简称ER图)。在附录E⑰ 中还可不能否查看后整的SQL模式。

内存还是持久化?坦率来说做出你有一种 决定之也不难,其主要由于是,这样人都歌词 歌词 歌词 还可不能否将其与RDBMS进行对比,它们通常持久化存储数据到磁盘中。即使只能的是纯粹的内存模式,也仍旧有也不方案。一旦考虑持久化存储,就只能考虑选则的方案是是是不是会影响到访问模式?

严格一致性还是最终一致性?难题图片是存储系统要怎样实现它的目标:只能降低一致性要求吗?觉得 你有一种 难题图片很粗浅,要怎样让在特定的场景中会产生巨大影响。将会一致性将会会影响操作延时,即系统响应读写请求的速度。这只能权衡投入和产出后得到也不折中结果。⑭

读/写性能

本节书摘来异步社区《HBase权威指南》一书中的第1章,第1.3节,作者: 【美】Lars George 译者: 代志远 , 刘佳 , 蒋杰 责编: 杨海玲,更多章节内容还可不能否访问云栖社区“异步社区”公众号查看。

在上述地址中,散列ID是a23eg。

也不商业RDBMS也出理 过同类的难题图片,但它们往往也不特定地出理 了难题图片的某哪几块方面,更重要的是,它们非常非常的昂贵。而也不开源的RDBMS出理 方案中,往往放弃了其中的也不甚至完整的关系型形态,如辅助索引,来换取更高的性能拓展能力。

标示符号化(tagword)实际上是也不不错的选则:最新的存储系统不提供通过SQL查询数据的手段,只提供也不比较简单的、同类于API接口的方法来存取数据。

图像说明文字 稍后这样人都歌词 歌词 歌词 会回顾那此维度,看看HBase适合用在哪里,其优势何在。现在只能指出的是,一定要根据实际的需求来仔细选则最适合的维度。按照实际情況来设计出理 方案,要知道这样硬性规定说:RDBMS只能很好地出理 的难题图片,NoSQL就能完美出理 。重要的是正确地评估需求,要怎样让再做出明智的选则,有只能句子甚至还可不能否采用混合使用的方案。

要素原则是采用反范式化模式,同类将数据群克隆到多张表中,也不 在读取的也不 就不需从多张表中聚合数据了。将会预先物化所需的视图,一次优化从而出理 进一步的出理 来提高读取性能。

辅助索引

加锁、等候和死锁

对稀疏矩阵、宽表、列式存储的支持使得数据在存储的也不 我越多 范式化,共同里还可不能否出理 查询时采用开销很大的JOIN操作聚合数据。使用智能的主键还可不能否控制数据要怎样去存储以及存储在那此位置。将会还可不能否使用行键的要素内容进行范围检索,行键作为组合键设计时,与字典序左要素为头的索引效果同类。要怎样让,正确的设计还可不能否使性能我越多 将会数据增长而下降,同类当数据条目从10条增加到30万条时,系统仍旧还可不能否保持相同的读写性能。

数据模型

RDBMS非常适合事务性操作,但不见长于超大规模的数据分析出理 ,将会超大规模的查询只能进行大范围的数据记录扫描或全表扫描。分析型数据库还可不能否存储数百或数千TB的数据,在一台服务器上做查询工作的响应时间,会远远超过用户可接受的合理响应时间。垂直扩展服务器性能,即增加CPU核数和磁盘数目,也之也不能很好地出理 该难题图片。

难题图片是,为了性能而时不时放弃以上关系型形态是是是不是值得?用户还可不能否反范式化(见1.3.3节)数据模型来出理 等候,要怎样让还可不能否通过降低锁粒度的方法来尽量出理 死锁。数据增长时,我越多 重新分区迁移数据并内嵌水平扩展性的方法。最后,用户只能面对容错和数据可用性难题图片,采用提高扩展性的机制,用户最终会得到也不NoSQL的出理 方案,更确切地说,HBase还可不能否满足以上多种需求。

图1-3展现了Hush应用在HBase中的对应模式。每个短网址都存储在独立的表shorturl中,表中还蕴藏了使用统计信息,按统计时间范围不同,存放于不同的列族中,共同每个值完整回会其生存期(time-to-live)。列名是日期和也不可选维度后缀的组合,同类国家代码,列值则是对应计数器的值。

文字实际上,为特定的难题图片制定差异化的专用出理 方案的想法之也不新鲜。像Berkeley DB、Coherence、GT.M也不 的系统,以及面向对象的数据库系统都将会出显 了好多年,也不甚至都还可不能否追溯到20世纪30年代初,从定义上来看,它们都属于NoSQL。

辅助索引支持用户按不同的字段和排序方法来访问表。你有一种 维度覆盖了也不完整这样辅助索引支持且不保证数据排序的系统(同类于HashMap,即用户只能知道数据对应键的值),到也不将会通过结构手段简单支持那此功能的系统。将会存储系统不提供这项功能,用户的应用还可不能否应对或自已模拟辅助索引吗?

一致性模型

“在一系列的研究结果里发现,在较大型的分布式系统中,将会网络分隔,一致性与可用性只能共同满足。这由于分析也不要素最多只能共同实现也不,不将会三者兼顾;放宽一致性的要求会提升系统的可用性……提升一致性由于分析系统只能牺牲一定的可用性。”

不同的规模,时不时只能设计不同的系统形态,对你有一种 原则的最佳描述是:反范式化、群克隆和智能的主键(Denormalization, Duplication, and Intelligent Keys,简称DDI ⑯)。这就只能重新思考在同类BigTable的存储系统中要怎样还可不能否高效合理地存储数据。

压缩

存储模型

当用户只能存储TB级的数据时,尤其当那此数据差异性很小或由可读性文本组成时,压缩会带来非常好的效果,即能节省少许的原始数据存储。也不压缩算法还可不能否将此类的数据压缩到原始文件大小的十分之一。有可选则的压缩组件吗?又有那此压缩算法可用?

下载下来的页面和提取的完整信息存储在url表中,要怎样让要通过压缩最大限度地减少存储量,将会存储的页面主也不HTML,你有一种 格式有一种冗余量大,要怎样让蕴藏了少许文本。