在键值类数据存储中，数据被表示为键- 值对的集合。键- 值模型是最简单的非基本数据模型之一，而其他更复杂的数据模型则都是在它的基础上构建的。
这些数据库提供 RESTful API 和协议缓冲区（Protocol Buffer）接口用于数据访问。而诸如 Riak 等键值数据存储还支持以下额外特性：
- 搜索：分布式、完全基于文本的搜索引擎，并带有一套查询语言。
- 二级索引：存储标签对象时附加了额外的值，可以通过确切匹配或范围进行查询。
- MapReduce：针对大型数据结合进行不基于键的查询。
在使用键值数据库的过程中，数据建模的工作聚焦在访问模式上。
InfoQ 邀请了出品开源 KV 数据库 Riak 的 Basho 公司的专业服务总经理 Casey Rosenthal，针对使用 NoSQL 数据库进行数据管理时的数据建模理念，以及最佳实践进行了访谈。
InfoQ：对于哪些类型的数据来说，它的存储并不适合采用关系型数据库，而是适宜选择键值数据库？
Casey：当数据具有以下三类特征的时候，我们更适宜选用键值存储而不是关系型存储：
- 数据的格式不固定。以 HTML 页面为例，各个页面有着互不相同的结构。某些页面有 header 标签部分，某些页面使用了表格（table 标签），而某些页面则拥有图片。HTML 页面中的结构多样性，使得很难为它们构建一套通用模式，但对关系型数据库来说，这却是必不可少的。而键值数据库并不需要定义模式，因此它能够存储类似 HTML 页面这样具有不确定格式的数据。
- 数据的规模或数量非常大。关系型数据库是针对少量行数进行优化的，需要其行数足够少，以便一张数据表可以安置在一个服务器上。键值数据库存储大型对象会更容易；而当大型对象的数量非常庞大时，我们还必须将它们分布存储在多台服务器上。
- 数据之间不存在相关性。书、作者、出版商这三类信息是相关的，因此在某个单一应用里，它们可能适合采用关系型数据库。然而，大型文件和缓存的应用数据，则可能互不相干，然而其存储可能依旧需要满足同一个应用对其同时分别使用的需求。在键值数据库中存储这些不相关的数据类型，可能要比使用关系型数据库容易许多，因为在这些数据之间将不会存在需要进行建模的关联关系。
InfoQ：与关系型数据库相比，我们使用键值数据库，能够享受到哪些优势？
Casey：一般来说，数据库查询引擎的复杂度，与扩展该数据库的难度相对应。大部分关系型数据库拥有非常复杂的查询引擎。相反，大部分键值数据库甚至根本就没有真正的查询引擎——如果我们对查询路径进行跟踪，就会发现它仿佛是一条从查询请求，到内存或硬盘上某个地方存储的对象之间的直线。因此，大部分键值数据库比关系型数据库更容易扩展，特别是对于被设计成存在于多台服务器上的分布式数据库来说，更是如此。关系型数据库所具有的一些根本限制，制约了它们能够扩展到什么程度。这些限制结合了以下方面的考虑：关系索引存储在哪里，系统中有多少数据，分布式系统内部的网络速度如何，以及其他一些因素。而键值数据库则无需面对这样的根本限制，因为查询引擎不需要考虑数据之间的关系。
InfoQ：从概念上来说，所有的非关系型数据库在存储数据时，都会选择使用键值的模式。其中，值的部分要么使用 JSON 格式，要么使用列族数据集的形式。那么，“真正的键值数据库”与其他非关系型数据库（例如文档或列族数据库）相比，有哪些优势？
Casey：其他非关系型数据库，限定了只能处理使用 JSON 或列族格式存储的数据，这意味着需要考虑系统中如何存储数据，以及查询引擎必须用什么样的方式来处理请求。这些限制和隐含的制约，将对这些数据库配置文件的扩展工作带来进一步的影响。键值数据库不具有这些限制，它们基于应用代码来解析数据。因此，无论用来存储何种类型的数据，对键值数据库进行扩展都会更容易。同样地，这一点在分布式数据库上尤为突出。
InfoQ：能否请你与我们探讨一下，在使用键值数据库过程中的经典的数据建模过程？
Casey：键值数据建模中的最佳实践，是专注于访问模式。它鼓励开发者站在从系统外部应用获取数据的角度，来处理问题。如果数据写入的时候，能够确保它将匹配应用获取数据所需要的格式，那么在这种方式下数据模型几乎是透明的。良好的键值数据模型会从访问模式方法的设计中“淡出”。
InfoQ：使用非关系型数据库的时候，应该在哪里进行建模，数据库还是应用层？
Casey：对于键值数据库，应该在应用层里进行建模。对于拥有更具限制性的 API 的非关系型数据库（例如图数据库仅处理节点和边），则应该在数据库中建模。
InfoQ：能否探讨一下键值数据管理要求方面，在设计上的考虑？
Casey：除了访问模式外，设计方面的考虑还包括：是否将对数据进行加密、进行版本管理或是在持久化之后进行修改，数据操作更倾向于读取还是写入，以及是否将永远不会被修改。永远都不会被修改的数据，被称为“不可变”数据，而不可变数据往往会为系统的架构带来一些便利。
InfoQ：在使用键值数据的时候，是否有一些反模式？
Casey：把键值数据当作关系型数据来对待，就是一种反模式。将数据归一化, 并尝试构建仅仅用来表示元数据之间关系的对象，是这类反模式中的两个例子。
InfoQ：你能否为我们介绍一些键值数据库中的陷阱或限制？
Casey：键值数据库并不具有诸如 SQL 这样的查询语言所提供的“丰富性”。开发者如果期望在键值数据库上使用类似 SQL 的查询语言，那么将会发现实际并非如此。
InfoQ：键值数据管理方面，在数据查询、便利、分析等领域中是否已经确立了一些标准？
Casey：REST 风格 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 Rosenthal是Basho 公司的专业服务总经理，他安装并测试 Riak 集群，并向客户提供培训，以帮助他们能够具备相应的能力。作为 Port Forty Nine 的首席软件工程师，Casey 为美国宇航局、加州理工和喷气推进实验室设计了存储并分发太空望远镜（例如哈勃、斯皮策、钱德拉等）图像存档的系统。他在哥本哈根举行的 BotPrize 2k 竞赛中取得了第四名的成绩，其作品狄斯科耳狄亚是一个用 jRuby 编写的软件机器人，凭借全新的人工智能算法，它能够像人类选手一样在虚幻竞技场游戏中大杀四方。他还曾经从缅因州理工学院赢得了一份种子基金，用来将一套使用 Ruby 编写的离散事件模拟框架商业化。他的 Twitter ID 是 @caseyrosenthal 。
查看英文原文： Data Modeling with Key Value NoSQL Data Stores – Interview with Casey Rosenthal
评论