当前位置：
四大非关系型数据库类型，你知道多少
发布时间：
浏览次数：
这篇文章的内容是摘自《Introducing Data Science》，我们在这里将要想大家介绍四种NoSQL数据库的类型，坚持读下去你会获得更多有用的信息。
目前对于非关系型数据库主要有四种数据存储类型：键值对存储（key-value），文档存储（document store），基于列的数据库（column-oriented），还有就是图形数据库（graph database）。每一种都会解决相应的问题，这些问题是关系型数据库所不能解决的。而在实际应用中都会将这几种情况结合起来实现相应的功能。例如：OrientDB就是一种多类型的数据库，它整合了NoSQL的几种存储类型。OrientDB是一个图形数据库其每个节点都是一个文本。
在开始介绍NoSQL数据库之前，我们先来回顾一下关系型数据库，这样我们可以对非关系数据库和关系型数据库做一个深入的比较。在数据建模上面，很多方法都是有可能被使用的。关系型数据库会严格的按照标准化去建模（也就是常说的第一范式、第二范式、第三范式等等）：确保每一条数据都只被存储一次。标准化是其结构设置的规范。例如：如果你想存储一个人的信息和这个人的爱好这样的数据，你可以创建两个表：一个用来存储这个人的信息，另一个表用来存储这个人的爱好。正如你在图一中看到的，你必须有一张额外的映射表，这张表将人的信息表和爱好表建立其对应的关系。这是因为他们的关系是多对多的关系，一个人可以有多个爱好，并且多个人可能会有相同的爱好。
一个完整的关系型数据库会由很多的实体表和关系映射表构成，现在你已经有了和NoSQL数据库进行比较的东西了，下面让我们看看这些不同的存储类型。
基于列的数据库（column-oriented）
传统的关系型数据库时基于行（row-oriented）的，每一行都带有一个行id并且行中的每一个字段都存储在一张表中。假如说上面的例子中没有单独用一张表来存储人的爱好，我们仅用一张表来存储个人信息和爱好，如图二所示。这里你就需要注意了，这种请款下你已经有一点违反关系型数据库严格遵循的标准化了，因为爱好是有重复的。如果爱好是描述一个人很好的一条额外信息但是对你的用例没有什么重要性，那你可以将其列在Hobbies这一列中，这是可以接受的一种方法。但是如果这条信息对你根本不重要，那这些数据还有没有必要存呢？
在基于行的数据库中进行查找的时候，每次都会对每一行进行遍历，不管某一列数据是否是你需要的都会进行遍历。假如你只需要生日是九月的人的数据，基于行的数据库会对这张表从上到下从左至右遍历一遍，正像你在图三中看到的那样，最后再返回你需要的那些数据。
对特定列的数据进行索引能有效的提高查找速度，但是索引每一列同样会带来额外的负载，并且数据库同样也是会遍历所有的列来取得要查找的数据。
基于列的数据库会将每一列分开单独存放，当查找一个数量较小的列的时候其查找速度是很快的。其结构如图四所示
这种设计看起来很像基于行的数据库在每一列上都加了索引一样。数据库索引这种数据结构以牺牲存储空间和更多的写文件（索引更新）为代价使查找速度得到提升。索引是将行号映射到数据上，而基于列数据库是将数据映射到行号上面，这样的方式用于计算是很简单的。例如上面的例子，查找有多少人的爱好包含archery（箭术）是很容易计算出来的。除此之外将每一列单独存放可以优化压缩因为每张表中只存一类数据。
说了这么多，那应该在什么时候使用基于行的数据库，在什么时候使用基于列的数据库呢？在基于列的数据库中要想增加一列新的数据是很容易的，因为现有的那些列是不会受新增列的影响的。但是要想增加一整条记录就需要适应所有的表，防止各个表的数据之间对应关系出现错误。因此这使得基于行的数据库在事务处理的时候要优胜于基于列的数据库，因为它很好的实现了数据的实时更新。
基于列的数据库的优势在于分析数据和对数据形成一个报告方面，例如对值求和、计算整条记录等。基于行的数据库经常被应用于实际交易中（例如销售业务）。夜间批处理作业就可以使基于列数据库更新，并且还支持快速查找还有使用MapReduce技术聚合数据形成报告。现在使用基于列的数据库存储数据的有Apache HBase，Facebook&s Cassandra，Hypertable和grandfather of wide-column stores，Google BigTable。
键值对存储（Key-Value Stores）
键值对的存储方式在NoSQL数据库中是最简单的一种，其结构就像其名字所示，是一个key-value的集合。如图五所示的那样。这种方式在NoSQL数据库类型中是最可扩展的一种类型，并且可以存储大量的数据。
键值对中存储的数据的类型是不受限制的，可以是一个字符串，也可以是一个数字，甚至是由一系列的键值对封装成的对象等。图六向我们展示了一个比较复杂的键值对结构。使用价值对存储的数据库有Redis，Voldemort，Riak，和Amazon&s Dynamo。
文档存储（Document Stores）
文档存储是基于键值对存储的，其结构较之于键值对存储更为复杂，可以说在键值对的基础上更深入了一步。文档存储是假定一个特定文档的结构可以使用一种特定的模式来说明，它的出现较之于其他的NoSQL数据库类型来说是最自然的，因为设计这种方式的最初的目的就是用来存储日常文档的，并且这种方式支持对于那些通常已经聚合的数据进行复杂的查询和计算。使用关系型数据库存储数据的方式在标准化的角度看是很有意义的：每条数据只被存储一次并且通过外键来进行联系。文档存储不会去关心那些所谓的标准化，只要数据在该结构下是有意义的就可以。所以说关系型数据库不能很好的适应特定企业的案例，只能用来做那些比较通用的案例。
例如：报纸和杂志包含有文章，如果想在关系型数据库中存储这些文章，首先你需要将这些文章给拆分开来，文章的内容在一个表中，文章的作者以及关于作者的信息要存在另一张表中，对于发布在网络上的文章的评论也需要额外的一张表来存储。正如图七所展示的那样，报纸上的一篇文章可以被存储为一个实例，这样在处理那些总是被查看的数据时可以减少查找的时间。使用文档存储的NoSQL数据库包含MongoDB和CouchDB。
图形数据库（Graph Database）
现在剩下的是最后一个NoSQL数据库存储类型，也是最复杂的一个，主要使用一种高效的方式来存储各个实体之间的关系。当数据之间是紧密联系的，例如社会关系、科学论文的引文抑或是资本资产定价模型等等，使用图形数据库时最好的选择。图形或者网络数据有两部分组成：
Node-：实体本身，在一个社会关系中可以认为是一个人。
Edge-：实体之间的关系。这个关系可以用一条线来表示，这条线有它自己的属性。这条线可以有方向，箭头可以表明谁是谁的上级。
如果给予足够的关系和实体类型，图形会变得非常的复杂，其发杂程度简直难以置信。图八已经展示了仅有有限几个实体的复杂图形。像Neo4j图形数据库声称支持ACID，然而文档存储数据库和键值对数据库坚持BASE。
非关系型数据库的潜力是无限的，当今世界关系正变得越来越紧密，图形存储类型很可能会在地理上胜过其他的存储类型数据库，包括现在仍然占绝对优势的关系型数据库。当今最流行的数据库的排名和他们是如何发展的在/en/ranking中都可以找到。
图九列出了在九条记录中，关系型数据库在写这本书的时候在前15中仍然占主导地位。并且随着NewSQL的出现，我们还没有重新计算排名。Neo4j&&当下最流行的图形存储数据库，在写本书的时候可以发现其处在23名的位置上，而Titan在53的位置上。
翻译原文：
除非注明转载，本站文章均为原创，欢迎转载，转载请以链接形式注明出处
本文地址：
评论列表（网友评论仅供网友表达个人看法，并不表明本站同意其观点或证实其描述）
扫一扫，关注我们哦！
Design By 迹忆非关系型数据库中的「关系」实现 - 推酷
非关系型数据库中的「关系」实现
Knowledge Dependence：阅读文本前，你需要了解基本的关系型数据库与非关系型（NoSQL）数据库的概念和区别，以及 MongoDB（Mongoose）的简单实践。
这两三年来，伴随着大数据（Big Data）的空前火热，无论是在工程界还是科研界，非关系型数据库（NoSQL）都已经成为了一个热门话题。
相比于传统的关系型数据库，非关系型数据库天生从理念上就给数据存储提供了一种新的思路。而在实际应用中，它往往更轻巧灵活、扩展性高，并且更能胜任高性能、大数据量的场景。
值得一提的是，NoSQL并不是 &No SQL& 的意思，而是 &Not Only SQL& 的简写。
尽管非关系型数据库没有关系型数据库中很多预定义的死板模式的限制，但自然数据间总是充满联系的，所以在数据库中我们势必需要抽象出这种数据之间的联系。
本文就个人实践经验，总结一下 NoSQL 数据库中表现数据关系的常见办法，并且结合一个实践项目来举例说明（样例为Node.js项目，使用常用的文档型数据库MongoDB（Mongoose来操作）来举例）。
方法如下：
得益于非关系型数据库的灵活数据类型，我们可以直接将 Schema A 中的某个属性设置为「数组」类型，用以存储所有与它有 1：N 关系的其他数据对象。
举例如下：
var commentSchema = new Schema({
type: Date,
default: new Date()
content: String
var messageSchema = new Schema({
content: String,
type: Date,
default: new Date()
comments: {
type: [commentSchema],
default: []
在上例中，一个 message 文档可能包含很多 comment 文档，所以在 messageSchema 的 comments 属性中用一个数组来存储某个 message 的所有 comment。
值得注意的是，这里 commentSchema 并不实际对应一个数据集合，它只用于在这里帮助定义 messageSchema。
相比于下面要讲到的引用的办法，这个方法适合于查询频繁（少了引用查询）、有强逻辑联系的1：N关系（即每次显示 A 文档都需要显示众多 B 文档）、且 B 文档改动较少（毕竟嵌套操作相对复杂一些）的场景。
这种方法也是NoSQL数据库相比于传统的关系型数据库的优势所在。
NoSQL数据库中并不存在传统关系型数据中类似于 join 的方法，所以这使得我们的复杂查询可能会变得相对困难，好在很多封装好的数据库包提供了很多便利。
引用方法又可分为两种：
Ⅰ. 手动引用
手动引用很简单，就是在 Schema A 中定义一个 Schema B 中唯一（unique）的属性（一般为_id），每次当查询 A 后又需要查询 B 时，需要自己根据 A 中定义的 _id 值手动去查询 B 的完整数据。
方法简单，不再举例赘述。
不过，在实践中唯一值得注意的是：A 中定义的与 B 相关的属性应该不具备业务语义，且基本不会被改动，否则当你对 B 中的相应属性进行改动的时候，所有引用此 B 文档的 A 文档，都需要对定义的引用属性进行更新，这是绝对需要避免的！这也是为什么一般引用 _id shu x的原因（一般在生命期内都不会被业务需求改变）。
Ⅱ. 自动引用
自动引用是借助于类似关系型数据库中定义的 Reference key 或 Foreign key 进行预先的引用定义。在查询时，数据库可以根据事先定义的「引用键」进行解引用，找到引用到的另一个集合中的文档。
在有一些封装好的数据库操作包中，可以实现自动解引用的功能，即凡是检测到引用键就自动的去查询对应的文档进而解引用。不过即便不是自动解引用，手动解引用也会花费开销进行查询，这也是为什么使用引用查询次数会更多的原因。试想如果对于「嵌套」方法中的样例，每次都进行自动解引用，那么在嵌套方法中可能进行的 1 次查询，在这里可能就需要 N+1 次了（N 为 message 中 comments 数组的长度）。
样例如下：
在 user.js 中定义：
var userSchema = new Schema({
type: String,
unique: true
password: {
type: String,
required: true
type: String,
required: true
type: String,
required: true
在 msgboard.js 中定义：
var messageSchema = new Schema({
user_id: {
type: mongoose.Schema.ObjectId,
ref: 'User'
content: String,
type: Date,
default: new Date()
这里，我们在 messageSchema 中定义了一个引用键 user_id 引用到 userSchema 中 _id 字段。注意：MongoDB会自动为文档创建唯一的_id字段！
如此，便在 Schema 层次上定义好了引用。具体在查询时，我们可以根据具体使用的包的特性来决定如何进行解引用的操作。
在 Mongoose 里，可以使用 populate 方法。详细的使用方法可以参考 Mongoose API 文档，这里仅给出一个样例：
Message.find(query)
.populate('user_id', 'name')
.skip((page - 1) * NUM_EACH_PAGE)
.limit(NUM_EACH_PAGE)
.sort({time: -1}).exec()
.then(function (messages) {
// do something with messages
console.log(messages);
这里用 Promise（异步流程控制方式的一种） 链式操作的方进行对 messages 进行查询，同时 skip 和 limit 用于翻页。
重点可关注 populate 方法，我们在这里获取了引用到的 user 文档 name 字段的值。
对于引用方式而言，由于在同等数据量的情况下查询次数一般要多，所以适用于查询不大频繁、具有相对更弱逻辑性的数据关系之间（不是 A 出现 B 一定需要出现的关系），而且用它既定义了数据之间的关系，也方便对数据进行各种 CURD 操作（没有嵌套或少嵌套了）。
对于本文的示例在完整项目中的展示，以及用 Express4 构建 Web 应用的其他内容，可以参考本博客上一篇文章的内容及源码，重点可关注 /models 下定义的数据模型以及 /controllers 目录下的业务代码。
注：本文在NoSQL数据库中使用关系型数据库中的「字段」的概念，实际是表示NoSQL数据库文档中的属性。
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致关系型数据库与非关系型数据库到底有什么区别呀，能举个具体的例子吗？各位大侠
关系型数据库与非关系型数据库到底有什么区别呀，能举个具体的例子吗？各位大侠
非关系数据库只实现了关系数据库一部分的功能，但因此很大程度上扩充了某些功能的性能。一般用关系数据库就够了。严格说mysql在关系数据库兄是实现得也不是很完整的一类，从而在某些查询上，mysql有超出严格关系数据库很多的性能。具体应用需要权衡，特别是关联条件很多的数据，非关系数据库一般不合适，有时候甚至mysql也不合适。NoSQL非关系数据库简介
在计算机科学中，非关系型数据库（NoSQL）是一个和之前的关系型数据库（RDBM）有很大不同的另一类数据结构化存储管理系统。非关系型数据库通常没有固定的表结构，并且避免使用join操作。和关系型数据库相比，非关系型数据库特别适合以SNS为代表web
2.0应用，这些应用需要极高速的并发读写操作，而对数值一致性要求却不甚高。
关系型数据库的特点
关系型数据库最大特点就是事务的一致性：传统的关系型数据库读写操作都是事务的，具有ACID（原子性Atomicity、一致性Consistency、隔离性Isolation、持久性Durability）的特点，C就是一致性（Consistency），这个特点是关系型数据库的灵魂（其他三个AID都是为其服务的），这个特性使得关系型数据库可以用于几乎所有对一致性有要求的系统中，如典型的银行系统。
但是，在网页应用中，尤其是SNS应用中，一致性却不是显得那么重要，用户A看到的内容和用户B看到同一用户C内容更新不一致是可以容忍的，或者说，两个人看到同一好友的数据更新的时间差那么几秒是可以容忍的，因此，关系型数据库的最大特点在这里已经无用武之地，起码不是那么重要了。
相反的，关系型数据库为了维护一致性所付出的巨大代价就是其读写性能比较差，而像微博，facebook这类SNS的应用，对并发读写能力要求极高，关系型数据库已经无法应付（在读方面，传统上为了克服关系型数据库缺陷，提高性能，都是增加一级memcache来静态化网页，而在SNS中，变化太快，memcache已经无能为力），因此，必须用新的一种数据结构化存储来来代替关系数据库。
关系数据库的另一个特点就是其具有固定的表结构，因此，其扩展性极差，而在SNS中，系统的升级，功能的增加，往往意味着数据结构巨大改动，这一点关系型数据库也难以应付，需要新的结构化数据存储。
于是，非关系数据库（NoSQL）应运而生，由于不可能用一种数据结构化存储方式应付所有的新的需求，因此，非关系型数据库严格上不是一种数据库，应该是一种数据结构化存储方法的集合。
必须强调的是，数据的持久存储，尤其是海量数据的持久存储，还是需要关系数据库这员老将。
非关系型数据库分类
由于关系型数据库本身天然的多样性，以及出现的时间较短，因此，不像关系型数据库，有几种数据库能够一统江山，关系型数据库的非常多，并且大部分都是开源的，这里列出一些：Redis,Tokyo
Cabinet,Cassandra,Voldemort,MongoDB,Dynomite,HBase,CouchDB,Hypertable,Riak,Tin,
Flare,Lightcloud,KiokuDB,Scalaris,Kai,ThruDB…
这些数据库中，其实实现大部分都比较简单，除了一些共性外，很大一部分都是针对某些特定的应用需求出现的，因此，对于该类应用，具有极高的性能。依据结构化方法以及应用场合的不同，主要分为以下几类：
面向高性能并发读写的Key-Value数据库：Key-Value数据库的主要特点就是具有极高的并发读写性能，Redis,Tokyo
Cabinet,Flare就是这类的代表。
面向海量数据访问的面向文档数据库（Document
store）：这类数据库的特点是，可以在海量的数据中快速的查询数据。典型代表为MongoDB以及CouchDB。
面向可扩展性的分布式数据库(Object
Store)：这类数据库想解决的问题就是传统数据库在可扩展性上的缺陷，这类数据库可以适应数据量的增加以及数据结构的变化，Google
Appengine的Big Table就是这类的典型代表，并且，BigTable特别适用于处理。
这里只对这几类数据库简要的介绍，需要详情可以看：
有空的话，以后也扯扯各类的具体差别，另外，个人感觉RAM
Database挺有前途的，果如此，memcache就几乎不用了。最后附上一张图：
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。}