四⼤⾮关系型数据库类型，你知道多少
这篇⽂章的内容是摘⾃《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。redis支持的五种数据类型
键值对存储（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。
图⼋
图九
图九列出了在九条记录中，关系型数据库在写这本书的时候在前15中仍然占主导地位。并且随着NewSQL的出现，我们还没有重新计算排名。Neo4j——当下最流⾏的图形存储数据库，在写本书的时候可以发现其处在23名的位置上，⽽Titan在53的位置上。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。