MySQL面试题：关系型数据库SQL和非关系型数据库NoSQL

参考文章（金文）：四大非关系型数据库类型，你知道多少
参考文章：“行式存储”和“列式存储”的区别
参考文章：干货 | SQL 与 NoSQL还在傻傻分不清？
参考文章：Aerospike领跑NoSQL数据库，靠什么碾压国产数据库？
参考文章：百度NoSQL
参考文章：【独家】一文读懂非关系型数据库（NoSQL）

一、四大非关系型数据库与关系型数据库的对比

目前对于非关系型数据库主要有四种数据存储类型：键值对存储（key-value），文档存储（document store），基于列的数据库（column-oriented），还有就是图形数据库（graph database）。每一种都会解决相应的问题，这些问题是关系型数据库所不能解决的。而在实际应用中都会将这几种情况结合起来实现相应的功能。

1. 关系型数据库

确保每一条数据都只被存储一次。标准化是其结构设置的规范。例如：如果你想存储一个人的信息和这个人的爱好这样的数据，你可以创建两个表：一个用来存储这个人的信息，另一个表用来存储这个人的爱好。正如下图中看到的，你必须有一张额外的映射表，这张表将人的信息表和爱好表建立其对应的关系。这是因为他们的关系是多对多的关系，一个人可以有多个爱好，并且多个人可能会有相同的爱好。

一个完整的关系型数据库会由很多的实体表和关系映射表构成，现在你已经有了和NoSQL数据库进行比较的东西了，下面让我们看看这些不同的存储类型。

2. 基于列的数据库

基于列的数据库出现的原因
实操中我们会发现，行式数据库在读取数据的时候，会存在一个固有的“缺陷”比如，所选择查询的目标即使只涉及少数几项属性，但由于这些目标数据埋藏在各行数据单元中，而行单元往往又特别大，应用程序必须读取每一条完整的行记录，从而使得读取效率大大降低**，对此，行式数据库给出的优化方案是加“索引”，在OLTP类型的应用中，通过索引机制或给表分区等手段，可以简化查询操作步骤，并提升查询效率。

但针对海量数据背景的OLAP应用(例如分布式数据库、数据仓库等等)，行式存储的数据库就有些“力不从心”了，行式数据库建立索引和物化视图，需要花费大量时间和资源，因此还是得不偿失，无法从根本上解决查询性能和维护成本等问题，也不适用于数据仓库等应用场景，所以后来出现了基于列式存储的数据库。

对于数据仓库和分布式数据库来说，大部分情况下它会从各个数据源汇总数据然后进行分析和反馈，其操作大多是围绕同一列属性的数据进行的，而当查询某属性的数据记录时，列式数据库只需返回与列属性相关的值，在大数据量查询场景中，列式数据库可在内存中高效组装各列的值，最终形成关系记录集，因此可以显著减少IO消耗，并降低查询响应时间，非常适合数据仓库和分布式的应用。

---

基于列的数据库的概念模型
基于列的数据库会将每一列分开单独存放，当查找一个数量较小的列的时候其查找速度是很快的。

这种设计看起来很像基于行的数据库在每一列上都加了索引一样。数据库索引这种数据结构以牺牲存储空间和更多的写文件（索引更新）为代价使查找速度得到提升。索引是将行号映射到数据上，而基于列数据库是将数据映射到行号上面，这样的方式用于计算是很简单的。例如上面的例子，查找有多少人的爱好包含archery（箭术）是很容易计算出来的。除此之外将每一列单独存放可以优化压缩因为每张表中只存一类数据。

---

应用场景

基于行的数据库

• 适合随机的CRUD操作
• 需要在行中选取所有属性的查询操作
• 需要频繁插入或更新，其操作与索引和行的大小更为相关

基于列的数据库

• 在数据量巨大的数据表中，大部分操作都是查询操作

---

3. 键值对存储

键值对中存储的数据的类型是不受限制的，可以是一个字符串，也可以是一个数字，甚至是由一系列的键值对封装成的对象等。下图向我们展示了一个比较复杂的键值对结构。使用价值对存储的数据库有Redis，Voldemort，Riak，Amazon’s Dynamo。

4. 文档存储

文档存储是基于键值对存储的，其结构较之于键值对存储更为复杂，可以说在键值对的基础上更深入了一步。文档存储是假定一个特定文档的结构可以使用一种特定的模式来说明，它的出现较之于其他的NoSQL数据库类型来说是最自然的，因为设计这种方式的最初的目的就是用来存储日常文档的，并且这种方式支持对于那些通常已经聚合的数据进行复杂的查询和计算。使用关系型数据库存储数据的方式在标准化的角度看是很有意义的：每条数据只被存储一次并且通过外键来进行联系。文档存储不会去关心那些所谓的标准化，只要数据在该结构下是有意义的就可以。所以说关系型数据库不能很好的适应特定企业的案例，只能用来做那些比较通用的案例。

例如：报纸和杂志包含有文章，如果想在关系型数据库中存储这些文章，首先你需要将这些文章给拆分开来，文章的内容在一个表中，文章的作者以及关于作者的信息要存在另一张表中，对于发布在网络上的文章的评论也需要额外的一张表来存储。正如图七所展示的那样，报纸上的一篇文章可以被存储为一个实例，这样在处理那些总是被查看的数据时可以减少查找的时间。使用文档存储的NoSQL数据库包含MongoDB和CouchDB。

5. 图形数据库

现在剩下的是最后一个NoSQL数据库存储类型，也是最复杂的一个，主要使用一种高效的方式来存储各个实体之间的关系。当数据之间是紧密联系的，例如社会关系、科学论文的引文抑或是资本资产定价模型等等，使用图形数据库时最好的选择。图形或者网络数据有两部分组成：

Node-：实体本身，在一个社会关系中可以认为是一个人。

Edge-：实体之间的关系。这个关系可以用一条线来表示，这条线有它自己的属性。这条线可以有方向，箭头可以表明谁是谁的上级。

如果给予足够的关系和实体类型，图形会变得非常的复杂，其复杂程度简直难以置信。图八已经展示了仅有有限几个实体的复杂图形。像Neo4j图形数据库声称支持ACID，然而文档存储数据库和键值对数据库坚持BASE。