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

阅读数:1482 2014 年 7 月 24 日

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

这些数据库提供 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 发表评论