BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Casey Rosenthal访谈:使用键值类NoSQL数据存储时的数据建模

| 作者 Srini Penchikala 关注 34 他的粉丝 ,译者 李彬 关注 1 他的粉丝 发布于 2014年7月25日. 估计阅读时间: 10 分钟 | 都知道硅谷人工智能做的好,你知道 硅谷的运维技术 也值得参考吗?QCon上海带你探索其中的奥义

键值类数据存储中,数据被表示为键-值对的集合。键-值模型是最简单的非基本数据模型之一,而其他更复杂的数据模型则都是在它的基础上构建的。

这些数据库提供RESTful API和协议缓冲区(Protocol Buffer)接口用于数据访问。而诸如Riak等键值数据存储还支持以下额外特性:

  • 搜索:分布式、完全基于文本的搜索引擎,并带有一套查询语言。
  • 二级索引:存储标签对象时附加了额外的值,可以通过确切匹配或范围进行查询。
  • MapReduce针对大型数据结合进行不基于键的查询。

在使用键值数据库的过程中,数据建模的工作聚焦在访问模式上。

InfoQ邀请了出品开源KV数据库Riak的Basho公司的专业服务总经理Casey Rosenthal,针对使用NoSQL数据库进行数据管理时的数据建模理念,以及最佳实践进行了访谈。

InfoQ:对于哪些类型的数据来说,它的存储并不适合采用关系型数据库,而是适宜选择键值数据库?

Casey:当数据具有以下三类特征的时候,我们更适宜选用键值存储而不是关系型存储:

  1. 数据的格式不固定。以HTML页面为例,各个页面有着互不相同的结构。某些页面有header标签部分,某些页面使用了表格(table标签),而某些页面则拥有图片。HTML页面中的结构多样性,使得很难为它们构建一套通用模式,但对关系型数据库来说,这却是必不可少的。而键值数据库并不需要定义模式,因此它能够存储类似HTML页面这样具有不确定格式的数据。
  2. 数据的规模或数量非常大。关系型数据库是针对少量行数进行优化的,需要其行数足够少,以便一张数据表可以安置在一个服务器上。键值数据库存储大型对象会更容易;而当大型对象的数量非常庞大时,我们还必须将它们分布存储在多台服务器上。
  3. 数据之间不存在相关性。书、作者、出版商这三类信息是相关的,因此在某个单一应用里,它们可能适合采用关系型数据库。然而,大型文件和缓存的应用数据,则可能互不相干,然而其存储可能依旧需要满足同一个应用对其同时分别使用的需求。在键值数据库中存储这些不相关的数据类型,可能要比使用关系型数据库容易许多,因为在这些数据之间将不会存在需要进行建模的关联关系。

InfoQ:与关系型数据库相比,我们使用键值数据库,能够享受到哪些优势?

Casey一般来说,数据库查询引擎的复杂度,与扩展该数据库的难度相对应。大部分关系型数据库拥有非常复杂的查询引擎。相反,大部分键值数据库甚至根本就没有真正的查询引擎——如果我们对查询路径进行跟踪,就会发现它仿佛是一条从查询请求,到内存或硬盘上某个地方存储的对象之间的直线。因此,大部分键值数据库比关系型数据库更容易扩展,特别是对于被设计成存在于多台服务器上的分布式数据库来说,更是如此。关系型数据库所具有的一些根本限制,制约了它们能够扩展到什么程度。这些限制结合了以下方面的考虑:关系索引存储在哪里,系统中有多少数据,分布式系统内部的网络速度如何,以及其他一些因素。而键值数据库则无需面对这样的根本限制,因为查询引擎不需要考虑数据之间的关系。

InfoQ:从概念上来说,所有的非关系型数据库在存储数据时,都会选择使用键值的模式。其中,值的部分要么使用JSON格式,要么使用列族数据集的形式。那么,“真正的键值数据库”与其他非关系型数据库(例如文档或列族数据库)相比,有哪些优势?

Casey其他非关系型数据库,限定了只能处理使用JSON或列族格式存储的数据,这意味着需要考虑系统中如何存储数据,以及查询引擎必须用什么样的方式来处理请求。这些限制和隐含的制约,将对这些数据库配置文件的扩展工作带来进一步的影响。键值数据库不具有这些限制,它们基于应用代码来解析数据。因此,无论用来存储何种类型的数据,对键值数据库进行扩展都会更容易。同样地,这一点在分布式数据库上尤为突出。

InfoQ:能否请你与我们探讨一下,在使用键值数据库过程中的经典的数据建模过程?

Casey键值数据建模中的最佳实践,是专注于访问模式。它鼓励开发者站在从系统外部应用获取数据的角度,来处理问题。如果数据写入的时候,能够确保它将匹配应用获取数据所需要的格式,那么在这种方式下数据模型几乎是透明的。良好的键值数据模型会从访问模式方法的设计中“淡出”。

InfoQ:使用非关系型数据库的时候,应该在哪里进行建模,数据库还是应用层?

Casey对于键值数据库,应该在应用层里进行建模。对于拥有更具限制性的API的非关系型数据库(例如图数据库仅处理节点和边),则应该在数据库中建模。

InfoQ:能否探讨一下键值数据管理要求方面,在设计上的考虑?

Casey除了访问模式外,设计方面的考虑还包括:是否将对数据进行加密、进行版本管理或是在持久化之后进行修改,数据操作更倾向于读取还是写入,以及是否将永远不会被修改。永远都不会被修改的数据,被称为“不可变”数据,而不可变数据往往会为系统的架构带来一些便利。

InfoQ:在使用键值数据的时候,是否有一些反模式?

Casey把键值数据当作关系型数据来对待,就是一种反模式。将数据归一化,并尝试构建仅仅用来表示元数据之间关系的对象,是这类反模式中的两个例子。

InfoQ:你能否为我们介绍一些键值数据库中的陷阱或限制?

Casey键值数据库并不具有诸如SQL这样的查询语言所提供的“丰富性”。开发者如果期望在键值数据库上使用类似SQL的查询语言,那么将会发现实际并非如此。

InfoQ:键值数据管理方面,在数据查询、便利、分析等领域中是否已经确立了一些标准?

CaseyREST风格API的准则已经相沿成习,并且大部分开发者也都充分理解了它。大体上,REST风格API的语义与大部分键值数据库相匹配。但是针对特定键值API或键值查询语言的正式共识(标准)尚未确立。

InfoQ:对于键值数据库领域来说,它的未来将何去何从?对Riak来说,其路线图又是如何规划的?

Casey总体来说,键值数据库正在朝着与其他类型的数据库共存的方向前进。具体来说,Riak是一个具有高可用性、容错性并支持数据扩展的可靠的平台。Riak里面的键值数据库就是这个平台本身,同时也是这样一个可靠的基础。而在未来,Basho将利用这一优势,向开发者们提供其他非键值API。以大型对象S3和Swift API为例,Riak平台上已经以Riak CS的形式提供了。在Riak 2.0中,我们将在数据平台上提供Solr API。在未来的版本中,我们还将继续扩展Riak平台提供的API集。

针对键值数据库,Casey还提到了以下关于数据建模和最佳实践的内容。

键值数据库是各种数据库中最基本的一类,因为它们表示起来最简单,而且并不要求查询规划器。正因为如此,键值数据库为构建更加复杂的数据平台提供了最佳基础。数据平台可以为了不同的使用场景类型来构建,例如高可用性系统,或是容错系统。如果这些数据平台能够在坚实的基础上正确地构建,那么对数据模型的选择将取决于如何为开发者提供便利,而不是对运营操作方面的折衷。我们有理由期待,未来的数据平台将基于优秀的键值数据库构建,它们拥有更丰富的数据模型和查询语言,并随着时间的推移不断开放API。

关于受访者

Casey RosenthalBasho公司的专业服务总经理,他安装并测试Riak集群,并向客户提供培训,以帮助他们能够具备相应的能力。作为Port Forty Nine的首席软件工程师,Casey为美国宇航局、加州理工和喷气推进实验室设计了存储并分发太空望远镜(例如哈勃、斯皮策、钱德拉等)图像存档的系统。他在哥本哈根举行的BotPrize 2k竞赛中取得了第四名的成绩,其作品狄斯科耳狄亚是一个用jRuby编写的软件机器人,凭借全新的人工智能算法,它能够像人类选手一样在虚幻竞技场游戏中大杀四方。他还曾经从缅因州理工学院赢得了一份种子基金,用来将一套使用Ruby编写的离散事件模拟框架商业化。他的Twitter ID是@caseyrosenthal

查看英文原文:Data Modeling with Key Value NoSQL Data Stores – Interview with Casey Rosenthal

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT