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

  • 时间:
  • 浏览:2

每个链接页面只存储一份,不过,不可能 其他用户不可能 会链接同另一有一个 多长网址,但会 还想保存亲戚亲戚朋友自己的删改信息,相似,使用统计信息,但会 会在短链接表中创建多个项来加以区分。通过这段逻辑,将url表、shorturl表和click表关联在了同时。

数据有多种存储的土办法,包括键/值对(相似于HashMap)、半底部形态化的列式存储和文档底部形态存储。用户的应用怎么才能 才能 存取数据?同时数据模式是是是不是随着时间而变化?

下载下来的页面和提取的删改信息存储在url表中,但会 要通过压缩最大限度地减少存储量,不可能 存储的页面主也不HTML,你一种生活 格式一种生活 冗余量大,但会 含高了絮状文本。

内存还是持久化?坦率来说做出你一种生活 决定虽然难,其主要导致 是,亲戚亲戚朋友时需将其与RDBMS进行对比,它们通常持久化存储数据到磁盘中。即使时需的是纯粹的内存模式,也仍旧有其他方案。一旦考虑持久化存储,就时需考虑确定的方案是是是不是会影响到访问模式?

物理模型

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

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

当用户时需存储TB级的数据时,尤其当那些数据差异性很小或由可读性文本组成时,压缩会带来非常好的效果,即能节省絮状的原始数据存储。其他压缩算法时需将此类的数据压缩到原始文件大小的十分之一。有可确定的压缩组件吗?又有那些压缩算法可用?

故障补救

不同的规模,老是时需设计不同的系统底部形态,对你一种生活 原则的最佳描述是:反范式化、基因重组和智能的主键(Denormalization, Duplication, and Intelligent Keys,简称DDI ⑯)。这就时需重新思考在相似BigTable的存储系统中怎么才能 才能 不都还都都可以 高效合理地存储数据。

但会 我连Memcached后来的项目都划入到NoSQL范畴句子,那就成了但会 我都不 RDBMS就时需认为是NoSQL。你一种生活 说法导致 了错误的二分法,二分法掩盖了那些系统提供的令人振奋的技术可行性。在NoSQL范畴内,还有统统的维度时需区分系统的特定优势所在。

一致性时需按照严格程度由强到弱分类,不可能 是按照对客户端的保证程度分类,下面是另一有一个 多非正式的分类列表。

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

短网址存储在shorturl表中,用户时需点击短网址来链接到删改网址。系统会跟踪每次点击,记录该网址的使用次数,都会记录其他其他信息,相似,点击该链接的用户所在的国家。那些信息会记录在click表中,你一种生活 表的功能相似于另一有一个 多计数器,以天为周期统计每天的访问量。

存储模型

放宽一致性来提高系统可用性是另一有一个 多非常有效的提议。不过你一种生活 方案会强制让应用层去补救一致性的问题 ,但会 也会增加系统的比较复杂度。

各种非关系型数据库有其他同时的底部形态,同时这其中的其他底部形态与传统的存储方案都不 统统同时点。但会 新系统并都不 革命性的产品,从工程的淬硬层 来看更像是产品的进化。

系统都会在后台下载链接到的页面,并提取其他TITLE相似的HTML标签。将整个页面保存下来的目的是,供后续的异步任务进行补救和分析。那些内容都由url表存储。

过去的四五年时间里,为了补救问题 ,创新的前进步伐由缓慢变得出奇得快,好像每周都会发布新的框架和项目来满足需求。亲戚亲戚朋友看完了所谓的NoSQL补救方案问世了,NoSQL是Eric Evans针对Johan Oskarsson提出的“为新兴的新数据存储空间⑫命名”问题 而创造的另一有一个 多名词。

主次原则是采用反范式化模式,相似将数据基因重组到多张表中,后来在读取的后来就不需从多张表中聚合数据了。不可能 预先物化所需的视图,一次优化从而补救进一步的补救来提高读取性能。

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

加锁、等待图片和死锁

众所周知,比较复杂的事务补救,如两阶段提交,会增加多个客户端竞争同另一有一个 多资源的不可能 性。最糟糕的情况报告也不死锁,你一种生活 情况报告也先要补救。用户时需支持的系统采用哪种锁模型?你一种生活 锁模型时需补救等待图片和死锁?

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

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

读/写性能

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

文字实际上,为特定的问题 制定差异化的专用补救方案的想法虽然新鲜。像Berkeley DB、Coherence、GT.M后来的系统,以及面向对象的数据库系统都不 可能 老是再次出现了好多年,其他甚至时需追溯到20世纪80年代初,从定义上来看,它们都属于NoSQL。

这使得通过统计原始的短网址标识refShortId,就时需统计任意另一有一个 多短网址映射到同另一有一个 多长网址的使用率。shortId和refShortId利用散列ID的土办法被唯一地分配给了短网址。相似:

压缩

严格一致性还是最终一致性?问题 是存储系统怎么才能 才能 实现它的目标:时需降低一致性要求吗?虽然你一种生活 问题 很粗浅,但会 在特定的场景中会产生巨大影响。不可能 一致性不可能 会影响操作延时,即系统响应读写请求的速率。这时需权衡投入和产出后得到另一有一个 多折中结果。⑭

机器会崩溃是另一有一个 多客观发生的问题 ,时需有一套数据迁移方案来应对你一种生活 情况报告(关于你一种生活 点时需参考在“一致性模型”中讨论的CAP定理)。每个数据存储怎么才能 才能 进行服务器故障补救?故障补救完毕后来是是是不是时需正常工作?这与后来讨论的“一致性模型”维度有关系,不可能 一蹶不振 一台服务器不可能 会造成数据存储的空洞(hole),甚至使整个数据存储不可用。不可能 替换掉故障服务器,这样 恢复80%服务的难度有多大?从另一有一个 多正在提供服务的集群中卸载一台服务器时,也会遇到相似的问题 。

RDBMS提供了统统相似的操作(不可能 它是另一有一个 多集中式的面向单服务器的系统),但那些操作在分布式系统中较难实现,那些操作时需帮助用户补救多应用线程造成的资源竞争,也时需帮助用户完成无共享应用服务器的设计。有了那些比较并交换(compare and swap,CAS)操作,不可能 说检查并设置(check and set)操作,在设计系统的后来时需有效地降低客户端的比较复杂度。

更糟糕的是,RDBMS的等待图片和死锁的老是再次出现频率,与事务和并发的增加并都不 线性关系,准确地说,与并发数目的平方以及事务规模的3次方甚至5次方相关⑮。分区通常是另一有一个 多不切合实际的补救方案,不可能 它时需客户端采用非常比较复杂的土办法和较高的代价来维护分区信息。

一致性模型

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

问题 是,为了性能而老是放弃以上关系型底部形态是是是不是值得?用户时需反范式化(见1.3.3节)数据模型来补救等待图片,但会 时需通过降低锁粒度的土办法来尽量补救死锁。数据增长时,无需重新分区迁移数据并内嵌水平扩展性的土办法。最后,用户时需面对容错和数据可用性问题 ,采用提高扩展性的机制,用户最终会得到另一有一个 多NoSQL的补救方案,更确切地说,HBase时需满足以上多种需求。

在这本书里,亲戚亲戚朋友老是会提到一致性问题 ,统统必要在这里对它稍加介绍。一开始英文的一致性是保证数据库客户端操作的正确性,数据库时需保证每一步操作都不 从另一有一个 多一致的情况报告到下另一有一个 多一致的情况报告。系统这样 明确地指定怎么才能 才能 实现你一种生活 功能,以便系统时需有多种确定。最终,系统要确定是进入下另一有一个 多一致的情况报告,还是回退到上另一有一个 多一致的情况报告,从而保证一致性。

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

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

系统通过user-shorturl表时需快速查到指定用户的所有短网址标识。你一种生活 功能被用在用户主页中,但会 我用户一登录就会被记录下来。user表存储虽然际用户的删改信息。

对稀疏矩阵、宽表、列式存储的支持使得数据在存储的后来无需范式化,同时也时需补救查询时采用开销很大的JOIN操作聚合数据。使用智能的主键时需控制数据怎么才能 才能 去存储以及存储在那些位置。不可能 时需使用行键的主次内容进行范围检索,行键作为组合键设计时,与字典序左主次为头的索引效果相似。但会 ,正确的设计无需都还都都可以 使性能无需不可能 数据增长而下降,相似当数据条目从10条增加到800万条时,系统仍旧时需保持相同的读写性能。

有非常多的土办法来转换一对一、一对多、多对多的关系,以适应HBase的底层架构。你一种生活 简单的例子有多种实现土办法,用户时需充分理解HBase存储设计的潜在能力,但会 深思熟虑地决定用哪一种生活 实现土办法。

原子操作的读-修改-写

图像说明文字 稍后亲戚亲戚朋友会回顾那些维度,看看HBase适合用在哪里,其优势何在。现在时需指出的是,一定要根据实际的需求来仔细确定最适合的维度。按照实际情况报告来设计补救方案,要知道这样 硬性规定说:RDBMS不都还都都可以 很好地补救的问题 ,NoSQL就能完美补救。重要的是正确地评估需求,但会 再做出明智的确定,有时需句子甚至时需采用混合使用的方案。

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

但会 我我用户有高读写吞吐率的需求,就要考虑配置一套无需都还都都可以 随着负载变化自动均衡补救能力的系统。虽后来来不都还都都可以 删改补救该问题 ,但会 也时需帮助用户设计高读写吞吐量的应用线程。

数据模型

让亲戚亲戚朋友来挑几种维度简单介绍一下。时需注意的是,列举的那些维度虽然全面,但会 这也都不 唯一的区分土办法。

但会 ,都不 其他工具为NoSQL数据存储提供了SQL语言的入口,用于执行其他关系数据库中常用的比较复杂条件查询。但会 ,从查询土办法上的限制来说,关系型数据库和非关系型数据库并这样 严格的区分。

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

其他商业RDBMS也补救过相似的问题 ,但它们往往也不特定地补救了问题 的某几块方面,更重要的是,它们非常非常的昂贵。而其他开源的RDBMS补救方案中,往往放弃了其中的其他甚至删改的关系型底部形态,如辅助索引,来换取更高的性能拓展能力。

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

时需用另一有一个 多有趣的词来形容你一种生活 情况报告——阻抗匹配(impedance match),意思也不要为另一有一个 多给定问题 找到另一有一个 多理想的补救方案,除了使用通用的补救方案,还应该知道有那些可用的补救方案,从而找到最适合于补救该问题 的系统。

虽然表的数量相同,就另一有一个 多多,但表的含义发生了变化:clicks表被合并到了shorturl表中,统计列使用日期为列键,格式为YYYYMMDD,相似,20110802,后来用户时需顺序访问数据。新增的user-shorturl表代替了外键,使查询用户相关信息变得更为快捷。

用户时需了解自己的应用应用线程的访问模式。是读多写少?还是读写相当?不可能 是写多读少?是用范围扫描数据好,还是用随机读请求数据更好?其他系统仅仅对那些情况报告中的一种生活 支持得非常好,其他系统则对各种情况报告都提供了很好的支持。

一致性模型

标示符号化(tagword)实际上是另一有一个 多不错的确定:最新的存储系统不提供通过SQL查询数据的手段,只提供其他比较简单的、相似于API接口的土办法来存取数据。

“在一系列的研究结果里发现,在较大型的分布式系统中,不可能 网络分隔,一致性与可用性不都还都都可以 同时满足。这导致 另一有一个 多主次最多不都还都都可以 同时实现另一有一个 多,无需可能 三者兼顾;放宽一致性的要求会提升系统的可用性……提升一致性导致 系统时需牺牲一定的可用性。”

用户信息存储在user表中,用户时需在Hush网站上注册并创建自己短网址列表,同时也时需在此网站上增加描述。user表与shorturl表之间维护了另一有一个 多外键关系。

辅助索引

辅助索引支持用户按不同的字段和排序土办法来访问表。你一种生活 维度覆盖了其他删改这样 辅助索引支持且不保证数据排序的系统(相似于HashMap,即用户时需知道数据对应键的值),到其他不可能 通过内部人员手段简单支持那些功能的系统。不可能 存储系统不提供这项功能,用户的应用时需应对或自已模拟辅助索引吗?

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

负载均衡

你一种生活 主题在第9章里有更删改的介绍,主要阐述了怎么才能 才能 充分利用HBase的底部形态去补救实际问题 。让亲戚亲戚朋友来看另一有一个 多例子,理解传统的关系数据库模型转到列式存储的HBase的几点基本原则。