NoSQL初识

1，    为什么要使用NoSQL

1.1什么是关系型数据库

像我们熟悉的mysql，oracle等都是关系型数据库。在传统的关系型数据库中，一个数据组织是由二维表以及其之间的联系组成的，给人更容易理解的直观感受。

1.2什么是NoSQL

      随着web2.0的快速发展，非关系型、分布式数据存储得到了快速的发展，它们不保证关系数据的ACID特性。NoSQL概念在2009年被提了出来。NoSQL最常见的解释是“non-relational”，“Not Only SQL”（看到有网上这么解释Not Only SQL：适用关系型数据库的时候就使用关系型数据库，不适用的时候也没有必要非使用关系型数据库不可，可以考虑使用更加合适的数据存储）也被很多人接受。（“NoSQL”一词最早于1998年被用于一个轻量级的关系数据库的名字。）

1.3为什么会有NoSQL

在90年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。在那个时候，更多的都是静态网页，动态交互类型的网站不多。到了最近10年，网站开始快速发展, 随着访问量的上升，几乎大部分网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能共享，大量的小文件缓存也带了了比较高的IO压力。在这个时候，Memcached就自然的成为一个非常时尚的技术产品。Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负，大部分网站开始使用主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性。随着数据量的进一步增大。在Memcached的高速缓存，主从复制，读写分离的基础之上流行使用分表分库来缓解写压力和数据增长的扩展问题。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站上暴漏许多问题
        High performance - 对数据库高并发读写的需求

Huge Storage - 对海量数据的高效率存储和访问的需求

High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求

因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应运而生。

1.4 NoSQL的主要分类

       按照存储方式NoSQL可以大致上分为下面几类

       a.key-value存储

Examples	Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB
典型应用场景	内容缓存，主要用于处理大量数据的高访问负载，也用于一些日志系统等等。
数据模型	Key 指向 Value 的键值对，通常用hash table来实现
强项	查找速度快
弱项	数据无结构化，通常只被当作字符串或者二进制数据

             b,列式数据库

Examples	Cassandra, HBase, Riak
典型应用场景	分布式的文件系统
数据模型	以列簇式存储，将同一列数据存在一起
强项	查找速度快，可扩展性强，更容易进行分布式扩展
弱项	功能相对局限

c.文档型数据库

Examples	CouchDB, MongoDb
典型应用场景	Web应用（与Key-Value类似，Value是结构化的，不同的是数据库能够了解Value的内容）
数据模型	Key-Value对应的键值对，Value为结构化数据
强项	数据结构要求不严格，表结构可变，不需要像关系型数据库一样需要预先定义表结构
弱项	查询性能不高，而且缺乏统一的查询语法。

d.图结构数据库

Examples	Neo4J, InfoGrid, Infinite Graph
典型应用场景	社交网络，推荐系统等。专注于构建关系图谱
数据模型	图结构
强项	利用图结构相关算法。比如最短路径寻址，N度关系查找等
弱项	很多时候需要对整个图做计算才能得出需要的信息，而且这种结构不太好做分布式的集群方案。

 

2，关系型数据库和NoSQL对比

2.1关系型数据库优势

传统的关系数据库具有不错的性能，高稳定型，久经历史考验，而且使用简单，功能强大，同时也积累了大量的成功案例。具体来说：

1.保持数据的一致性（事务处理）

2,由于以标准化为前提，数据更新的开销很小（相同的字段基本上都只有一处）

3. 可以进行Join等复杂查询

其中能够保持数据的一致性是关系型数据库的最大优势。

2.2 NoSQL的优势

易扩展

NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。

大数据量，高性能

NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。

灵活的数据模型

NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。

高可用

NoSQL在不太影响性能的情况，就可以方便的实现高可用的架构。

2.3关系型数据库 ——ACID

原子性（atomicity）：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。

一致性（consistency）：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的默认规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。

隔离性（isolation）：当两个或者多个事务并发访问（此处访问指查询和修改的操作）数据库的同一数据时所表现出的相互关系。事务隔离分为不同级别，包括读未提交（Readuncommitted）、读提交（readcommitted）、可重复读（repeatableread）和串行化（Serializable）。

持久性（durability）：在事务完成以后，该事务对数据库所作的更改便持久地保存在数据库之中，并且是完全的。

2.4 NoSQL——CAP, 最终一致性，基本的可用性

CAP，BASE和最终一致性是NoSQL数据库存在的三大基石

CAP

C: Consistency一致性

A: Availability可用性(指的是快速获取数据)

P: Tolerance ofnetwork Partition 分区容忍性(分布式)

CAP理论告诉我们，一个分布式系统不可能满足一致性，可用性和分区容错性这三个需求，最多只能同时满足两个。

熊掌与鱼不可兼得也。关注的是一致性，那么您就需要处理因为系统不可用而导致的写操作失败的情况，而如果您关注的是可用性，那么您应该知道系统的read操作可能不能精确的读取到write操作写入的最新值。因此系统的关注点不同，相应的采用的策略也是不一样的。

最终一致性

一言以蔽之：过程松，结果紧，最终结果必须保持一致性

为了更好的描述客户端一致性，我们通过以下的场景来进行，这个场景中包括三个组成部分：

·        存储系统

存储系统可以理解为一个黑盒子，它为我们提供了可用性和持久性的保证。

·        Process A

ProcessA主要实现从存储系统write和read操作

·        Process B 和ProcessC 

ProcessB和C是独立于A，并且B和C也相互独立的，它们同时也实现对存储系统的write和read操作。

下面以上面的场景来描述下不同程度的一致性：

·        强一致性

强一致性（即时一致性）假如A先写入了一个值到存储系统，存储系统保证后续A,B,C的读取操作都将返回最新值

·        弱一致性

假如A先写入了一个值到存储系统，存储系统不能保证后续A,B,C的读取操作能读取到最新值。此种情况下有一个“不一致性窗口”的概念，它特指从A写入值，到后续操作A,B,C读取到最新值这一段时间。

·        最终一致性

最终一致性是弱一致性的一种特例。假如A首先write了一个值到存储系统，存储系统保证如果在A,B,C后续读取之前没有其它写操作更新同样的值的话，最终所有的读取操作都会读取到最A写入的最新值。此种情况下，如果没有失败发生的话，“不一致性窗口”的大小依赖于以下的几个因素：交互延迟，系统的负载，以及复制技术中replica的个数（这个可以理解为master/salve模式中，salve的个数），最终一致性方面最出名的系统可以说是DNS系统，当更新一个域名的IP以后，根据配置策略以及缓存控制策略的不同，最终所有的客户都会看到最新的值。

BASE-基本的可用性

Basically Availble --基本可用

Soft-state --软状态/柔性 事务

Eventual Consistency --最终一致性

最终一致性， 也是是 ACID 的最终目的。

BASE模型反ACID模型，完全不同ACID模型，牺牲高一致性，获得可用性或可靠性：Basically Available基本可用。支持分区失败(e.g.sharding碎片划分数据库) Softstate软状态 状态可以有一段时间不同步，异步。Eventually consistent最终一致，最终数据是一致的就可以了，而不是时时一致。