本文是《非关系型数据库》的开篇，按照我在之前文章说的，对于具体的内容，我会分两篇文章。如果只是想要拓展自己的视野，可以只看这一篇。如果看了之后想要有更进一步了解，可以静待下一篇文章。当然如果看了这一篇有什么想法也欢迎私信我。针对好的问题，我会在下一篇文章中进行更详细的解答。背景
目前随着互联网的发展，数据已经变得越来越多，而且形式也各种各样，除了文本数据，还有多媒体数据，实时数据等。即使是文本数据，也有各种各样的格式。同时对于数据的查询需求也多种多样。因此诞生了很多类型的数据库。比如目前比较流行的Redis，etcd，TDengine等。
另一方面，随着面试要求的提高，针对数据库的问题也不再仅仅局限于MySQL了，很多时候会要求有其他数据库的开发经验。
基于此，我想用这篇文章写一下非关系型数据库和关系型数据库的区别。
数据库的核心问题
数据库技术从本质上来说，主要是为了解决一个问题：数据的查询。
无论是数据的增加、更新还是删除，其目的都是为了更好的查询数据或者基于内部的查询机制。同时为了满足数据库的查询需要，不同的数据库内部的数据存储方式也不同。这里不做详细的说明。这也是关系型数据和非关系型数据库甚至不同数据库的产生原因：现有的数据库无法满足自己的查询需要。
而数据库的查询问题，其主要分为两个部分：
精确查询
范围查询
所以基于对这两个问题的认识不同，不同的数据库在设计上也做了相应的取舍。比如MongoDB相比于MySQL就认为用于范围查询不是用户的高频需求，所以抛弃了MySQL原有的B+树索引结构，采用了B树结构（这个MongoDB采用B树的原因之一）。
而像时序数据库，则认为用户对于范围查询更为需要，更准确的是对最近的数据做聚合查询的需求更为强烈，所以在设计上采用了冷热分离，自动聚合等。
因此我们得出关系型和非关系型数据的第一个区别：非关系型数据库因为关系型数据库无法满足某些特定的数据需求而重新进行了设计。其目的是为了更好的支持自己适用的业务场景。
发展
基于对上面的核心问题的理解，数据库的发展历史也很有趣。
数据库并不是一开始就是关系型数据库，而是根据对于数据组织的方式的不同理解，出现了三种数据库模型：网状型，层次型和关系型。从字面很容易理解，网状型认为数据的组织方式更像是图状结构一样一个节点一个节点相互连接而成。层次型则认为数据更像是树状结构，每个节点都有其父节点（除了一个根节点）。
这两种乍一看好像和我们现实的对象一样，能够很好的描述不同的数据。但是细细想来都有一些问题，比如网状型，由于数据都是相互关联的，那么一旦数据规模大起来，那么修改其中一个数据造成的改动成本就会很大。而层级结构则默认数据之间都是1:n的关系，但是现实中很多都是m:n的关系，层次型在这方面如果需要描述更为复杂的场景就需要调整自己的设计，而这无疑会带来更多的复杂度。
所以关系型数据库应运而生，关系型认为数据不仅仅有数据本身，还定义了数据的关系如何描述。也就是使用一种通用的方式来描述数据和数据之间的关系，现在我们知道这种方式是表。这种设计方式在当时无疑更为抽象，也更能描述各种各样的数据。因为一举碾压了其他数据模型，成为数据库设计的主流指导。
但是随着数据的膨胀和关系型数据库的历史包袱，关系型数据在很多方面效率都出现了问题，虽然关系型数据库发展到可以描述几乎所有的数据场景。但是却无法满足这些场景的性能需求。比如对于社交关系，由于关系本身就具有很多属性，同时查询要支持更为复杂的关系聚合查询。这样使用关系型数据库查询的话，无论是写SQL语句还是性能都是不小的挑战。而这个在社交关系场景中是个高频需求。所以图数据库应运而生。
因此在现在，很多新型的数据库开始变得流行起来。
因此我们进一步得出关系型和非关系型数据的第二个区别：非关系型数据库能够在某些特点的场景中比关系型数据库有更高的性能。
非关系型数据库
主流的非关系型数据库大致可以分为四类：
键值(key/value)数据库
列存储数据库
文档型数据库
图数据库
他们的区别主要在于：
我们从上面的比较可以看出，非关系型数据库不再像关系型数据库那样为了追求能够使用更多的场景，而是针对自己要处理的场景做了取舍。他们能够在特定的场景上面达到远超于其他数据库的表现。
因此我们进一步得出关系型和非关系型数据的第三个区别：非关系型数据库只是为了解决某些特定场景，优劣势很明显，只在自己
