NoSQL introduction

前言

NoSql是一种新的数据存储和计算的方法，NoSql(NotOnlySQL)。Sql是数据库的一个概念，它是一个数据库的查询语言，能够让不能够编写代码的数据分析师，通过一些抽象和高级的语言进行数据处理。今天通过下面几个模块给大家介绍在大数据的背景下，设计大数据的数据库使用的一些基本思路，以及我们通过一些流行系统，来给大家介绍NoSql的一些基本原理和它的设计上的一些挑战。

回顾与引入

1).数据库的这个概念，其实已经有了几十年的时间。数据库用来存储结构化的信息，然后给用户提供高效
这种一致，比较复杂的数据查询的一个方法。

2).数据库的一个概念从最开始几十年前提出到今天，实际上已经发生了比较大的演化。今天的数据库已经可以处理更为复杂，超越了原来的结构化，或者说schema要求的数据，达到了今天对各种类型数据处理的一个能力；同时它也能够横跨很多的这个数据处理的节点，达到可扩展性。

3).关系数据库它得到蓬勃发展，实际上和web技术的这个发展有关，尤其是处理Transaction这种，和交易
和规划相关的这种数据，带来了关系数据库的迅速发展。

4).那么今天的关系数据库，又和其它的子系统进行了整合，比如说和前端的这个内存，和后端的这个分布式
文件系统，进行有效的整合，实现了非常复杂的数据处理的一个数据库的一个模式。

5).数据库在最开始设计的时候，它的思路实际上和scaleout的概念是匹配的，人们希望搭一个非常非常大的一个系统，这个系统是一个完整，是一个单机的。在这样一个很大的系统，它拥有很多CPU，很大的内存，那这样一个一致性可以有效得到保证的一个环境下，我们去做sql的这样一个支撑。

6).这种思路底下随着数据计算的复杂性，对分布式要求越来越高的趋势下，实际上数据库面临的一个核心挑战，就是它怎么样去做这个扩容，怎么样使它能够在更多的机器，或者更多的设备上去运行。不得不回到scaleout的这样一个思路下，怎么样通过更多的服务器使得原来的这个数据库运行的范围更大，处理的数据的规模也更大。

传统对关系数据库的scalability进行扩展，使用的技术通常可以划分成两类：

第一类就是对整个架构进行扩容，通过masterslave方式

1).我们通过中心的节点，进行关键性的控制，slave的节点进行进行大规模请求的一个响应。或者我们对数据进行一个扩展，通过sharding或是partition的方式。我们能够将原来打算放在一个数据库里的这些数据，把它切分成若干小的这个数据，放在不同的数据库里面，这些不同的数据库能在物理上就可以得到天然的切分。

2).基于masterslave，我们对关系数据库进行一个切分会是什么样的一个情况？
它通常的思路是这样的：我们会非常重视一致性，关系数据库我们会将写的过程给通过master进行一个同步，这是一般性的设计思路。而在数据库里面，我们更多的请求，可能是读的请求，我们会将读，把它这个distribute到所有的slave节点上，使得读的响应可以从原来的一台机器的容量扩大到n台机器的一个容量。由于把读和写进行了这样一个切分，(读写分离)，master这样的切分，实际上我们必然会面临一次性的困扰。比如说我们数据没有写完，那这时候发生的读，我们应该怎么样去处理？或者说我们这个写和读，并不是写很少而读很多，而是写和读的比例差不多的时候，这种切分到底还管不管用，那这是在masterslave底下我们面临的一些问题。

第二类就是在数据上进行可扩展性操作，通过partition(sharding)方式

1).我们可以对数据进行partition，使得数据能够备份到(分割到)很多的服务器上。partition原本的思路就是要将用户不去考虑数据的独立性，在系统中体现出来，那我们来看它怎么做的？

2).它可以很好的支持读，很好的支持写，因为本质上就是把原来的一个大数据库变成了很多的小的数据库。我们需要程序去知道我们做了这样的切分，因为如果程序不知道，或者是你的service不知道这个过程的话，实际上，它没法在每个小的数据库访问到它可能想要的另外一个数据库的数据。然后对于数据库和数据库之间的操作，在这样的模式下可能做不到了，比如说join，我们想对两个数据库进行数据的联合操作，那这是做不到的。所以它的优点是能够在小范围、单一数据库上，很好的支持原来的操作，但是在大范围上，我们缺失了很多功能。

3).那这是masterslave和sharding两种方式，对关系数据库，它存在的优点和缺点，当然在这个数据库的发展历程中还有一些其他的方法，也对这个可扩展进行了提升。比如我们可以在masterslave的框架底下，进一步提出了multimaster这样的一个概念，当master，单一的master出现问题的时候我们可以通过其他备份的master，得到对系统的一个支撑。当然在这里面，我们也同样会面临一系列的缺陷，这是我们在数据库的场景底下，主要了解它在支持大数据的历程里面，经历了哪些发展。到今天为止，实际上依然有很多数据库专家在研究怎么样将数据库进行扩容，使数据库能够支撑更大规模的数据、更复杂的请求以及更简单的操作，那么他的思路已经从原来的masterslave，或者是数据的partition扩展到更多其它的这种方法上。

NoSQL

但是也有另外一个思路，就是放弃一些关系数据库里面对数据的严格要求，而把它变成类似于hadoop或者是mapreduce这种操作,能够从scalability，本质对它进行一个提升。nosql就是在这样的一个背景下产生的，它希望借助已有的分布式文件系统，已有的这种大数据处理框架mapreduce或spark，来提供到类似于原来关系数据库的数据查询、数据分析的方法。

1).它是在非关系数据库上搭建了一个存储系统，它的本质是一个存储系统。在它存储系统上，人们模拟出了很多sql操作。通常它并不需要一个数据的schema，也就是说它不需要结构化的数据描述，它可以是一系列key value的一个数据存储(比如说在hadoop里面的这种)的一个模式。

2).当然它也不能支持在关系数据库里严格的basic的。属性一致性、完整性、数据准确性，在nosql里面，这些特性是没有办法得到完全的保障。

3).那么在nosql中，当我们想要保证它的一致性，我们需要保证它的这个原子操作，然后我们需要保证它的availablitity，以及它的partition的特性的时候，实际上做这种nosql研究的人员，在这里面实际上对这几种属性进行了分析。这里面比较出名的是CAP定理(consistency, availability and partitions)。

3.1.这个定理，它描述的是这样一件事情，在我们要对数据进行切分，切分到不同的服务器上的时候，那么CAP是没有办法同时保证的，C代表的是数据的一致性，A代表的是数据的可用性，P代表的是我们需要对整个系统进行切分。

3.2.那我们来举个例子，看看这个是为什么会造成这样的一个结果。
假设我们要对数据进行切分，这是我们最本质的一个scalability要求的一个前提，那我们来看C和A，为什么是矛盾的？

当我们需要数据有高的可能性，也就是说当一个读的请求到达的时候，要给它这个数据满足的时候，实际上我们的C是，没有办法得到保证的。比如说我们现在正有两个并发请求，一个是需要对数据进行修改，另一个是对数据进行读取，那么修改它不可能同时在我们集群中所有的服务器上达到，它必须是从服务器到服务器，有一个逐渐或者说接近完成的这样一个过程。那在这个过程中，不管什么时候发生，只要这个过程没有完成，当用户需要去访问数据的时候，他获得的数据可能就会产生不一致性。那么当你要保证这个数据的可用性的时候，那么你数据的一致性，也就没有办法得到保证。所以C和A在我们的这个例子中，是很难得到保证。

4).CAP是没有办法同时保证的，这是nosql它天然不能去解决的一个问题，但是设计nosql工程人员和科研人员，实际上就把nosql里面的优势或者特性进行了relax，得到了一个新的一组，它能保证的好处，那么我们把它叫做eventual的consistency，我们保证了可用性。那我们来看它的一致性是怎么样，慢慢的能够达得到的。那么这个过程，就像我们刚刚描述的，你对整个系统的修改，实际上它是可以不断的，在系统中进行扩散的，比如说在HDFS(分布式文件系统)中，我们对一个数据进行协助的时候，大家可以回想我们使用pipeline机制，那么这个数据让用户开始对一个replica进行填充的时候，那么这个server会将数据收到，然后发送给下一个需要存的replica的节点，然后进一步传到第三个节点，假设系统中的容量是三，replication的容量是三的话，那么这个过程始终会完成的。因为它会得到namenode的监管，以及这3个服务器，它对自身数据的一个验证，所以这个数据最终会扩散到系统当中。那么所谓的eventual就是说，在今天分布式文件系统背景下，实际上数据最终会被提交到所有的节点上，用户只要能够等足够长的时间，它最终能够看到系统给它提供最新的数据的拷贝，这就是nosql一个底层的理论知识。

---

tests

summary

1).目前世界上主流的存储系统大部分还是采用了关系型数据库，其主要的优点有：事务处理上能够保持数据的一致性；以标准化为前提，数据更新的开销很小；可以进行Join等复杂的查询。 虽然关系型数据库已经在产业界的数据存储方面占据了强大的地位，但是它也有一些缺点，它的缺点主要在以下几个方面：扩展困难，由于存在类似join这样的多表查询机制，使得数据库在扩展方面很难；读写慢，这种情况主要发生在数据量达到一定规模的时由于关系型数据库的系统逻辑非常复杂，使得其非常容易发生死锁等并发问题，所以其读写速度下滑非常严重；成本高，企业级数据库的价格很高，而且随着系统规模的增大而不断上升；有限的支撑容量。

2).总体来说，“NoSQL”系列数据库非常关注对数据高并发地读写和对海量数据的存储等，与传统的关系型数据库相比，主要体现在如下几点：简单的扩展，典型的例子是Cassandra，由于其架构是类似于经典的P2P，所以能够通过轻松地添加新的节点来扩展这个集群；快速的读写，主要例子有PaleVioletRed is，由于其逻辑简单，而且纯内存操作，使得其性能非常出色，单节点每秒可以处理超过10万次读写操作；低廉的成本，由于其开源特性，没有价格。 NoSQL数据库还存在着很多的不足，主要在以下几个方面：不提供对SQL的支持。支持的特性不够丰富；现有的产品不够成熟。

3).关系型数据库所使用的定义严格、基于模式的方式是无法快速容纳新的数据类型的，对于非结构化或是半结构化的数据更是无能为力。NoSQL提供的数据模型则能很好地满足这种需求。很多应用都会从这种非结构化数据模型中获益，比如说CRM、ERP、BPM等等，他们可以通过这种灵活性存储数据而无需修改表或是创建更多的列。这些数据库也非常适合于创建原型或是快速应用，因为这种灵活性使得新特性的开发变得非常容易。

4).针对传统的关系型数据库来说，动态的可伸缩性是难以实现的，而在NoSQL上就很容易实现动态的可伸缩性。 在三层互联网架构的Web/应用层上，多年来向上扩展已经成为默认的扩展方式了。随着应用使用人数的激增，我们需要添加更多的服务器，性能则是通过负载均衡来实现的，这时的代价与用户数量成线性比例关系。在NoSQL数据库之前，数据库层的默认扩展方式就是向上扩展。为了支持更多的并发用户以及存储更多的数据，你需要越来越好的服务器，更好的CPU、更多的内存、更大的磁盘来维护所有表。然而，好的服务器意味着更加复杂、私有、并且也更加昂贵。这与Web/应用层所使用的便宜的硬件形成了鲜明的对比。由于NoSQL数据库是分布式、水平扩展的，非常容易实现动态的可伸缩性。