1. NoSQL入门概述
1.1 NoSQL数据库的发展历程
互联网时代背景下，也并非直接出现NoSQL数据库的，而是经过了一些演变过程，随着数据量的不断增大，诞生了许多的技术。
1.1.1 单机MySQL的时代
90年代，大部分网站访问量都不大，且使用的都是静态页面，用单个数据库完全可以轻松应付；架构一般为：App-->DAL-->单MySQL实例。
上述架构下，数据库的瓶颈如下：
- 数据量的总大小太大，一台机器放不下时；
- 数据的索引一个机器内存放不下时；
- 访问量（读写混合）太大一个实例无法承受时。
当发生上述1个以上情况时，就需要升级。
DAL（Data Access Layer）：数据访问层的缩写，主要功能是负责数据库的访问。
1.1.2 Memcached（缓存）+MySQL+垂直拆分
随着访问量的上升，大部分使用单MySQL架构的网站在数据库上开始出现了性能问题，Web程序不再仅仅专注于功能上，同时也开始追求性能。程序员开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力，但是随着访问量的持续增大时，多台web服务器之间文件缓存不能共享，大量的小文件缓存也带来的较高的IO压力，这时，Memcached就自然的成为了当时非常流行的技术产品。
Memcached作为一个独立的分布式缓存服务器，可以为多台Web服务器提供一个共享的高性能缓存服务，在Memcached服务器上，又发展出了根据hash算法来进行多台Memcached缓存服务的扩展，随后又出现了一致性hash来解决增加或减少缓存服务器导致重新hash带来的大量缓存失效的弊端。
1.1.3 MySQL主从复制读写分离
随着数据库的写入压力增加，Memcached只能缓解数据库的读取压力，当读写集中在一个数据库上时会导致数据库不堪重负，大部分网站开始使用主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性。MySQL的master-slave模式成为主流。
1.1.4 分库分表+水平拆分+MySQL集群
在Memcached的高速缓存，MySQL的主从复制，读写分离技术的基础上，这时的MySQL主库的写压力开始出现瓶颈，而当数据量的持续猛增，由于MyISAM使用表锁，在高并发下就会出现严重的锁问题，大量的高并发MySQL应用开始使用InnoDB引擎替代MyISAM。
同时，也开始流行使用分库分表来缓解写压力和数据增长的扩展问题，此时，分库分表成为了一个热门技术，是面试的热门问题也是业界讨论的热门技术点。就在这时，MySQL推出了还不太稳定的表分区技术，这也给技术实力一般的公司带来了希望。虽然MySQL推出了MySQL Cluster集群，但性能不足以满足互联网的需求，只是在高可靠性上提供了非常大的保证。
1.1.5 MySQL的扩展性瓶颈
MySQL数据库也经常存储一些大文本字段，导致数据库表非常大，在做数据库恢复时就会导致非常的慢，不容易快速恢复数据库。比如1000万4KB大小的文本就接近40GB的大小，如果能把这些数据从MySQL中省去，MySQL将变得非常的小。关系数据库很强大，但是它并不能很好的应付所有的应用场景。MySQL的扩展性差（需要复杂的技术来实现），大数据下IO压力大，表结构更改困难，正是当前使用MySQL的开发人员面临的问题。
1.1.6 为什么使用NoSQL？
今天我们可以通过第三方平台（如：Google,Facebook等）可以很容易的访问和抓取数据。用户的个人信息，社交网络，地理位置，用户生成的数据和用户操作日志已经成倍的增加。我们如果要对这些用户数据进行挖掘，那SQL数据库已经不适合这些应用了, NoSQL数据库的发展也却能很好的处理这些大的数据。
1.2 是什么？
NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”。
泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题，包括超大规模数据的存储。
（例如谷歌或Facebook每天为他们的用户收集万亿比特的数据）。这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。
1.3 能干嘛？
1.3.1 易扩展性
NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。
1.3.2 大数据量高性能
NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。
1.3.3 灵活多样的数据模型
NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。
1.3.4 传统RDBMS VS NoSQL
RDBMS： 关系数据库管理系统（ Relational Database Management System ）简称RDBMS。
- RDBMS
- 高度组织化结构化数据；
- 结构化查询语言（SQL）；
- 数据和关系都存储在单独的表中；
- 数据操作语言，数据定义语言；
- 严格的一致性；
- 基础事务。
- NoSQL
- 代表不仅仅是SQL；
- 没有声明性查询语言；
- 没有预定义的模式；
- 键值对存储，列存储，文档存储，图形数据库;
- 最终一致性，而非ACID属性；
- 非结构化和不可预知的数据；
- CAP定理；
- 高性能，高可用性和可伸缩性。
1.4 如何下？
2. 3V和3高
- 大数据时代的3V
- 海量（Volume）
- 多样（Variety）
- 实时（Velocity）
- 互联网需求的3高
- 高并发
- 高性能
- 高可扩
2.1 NoSQL数据模型
NoSQL的聚合模型可以使用KV键值，Bson，列簇，图形等方式。
BSON是一种类似JSON的二进制形式的存储格式，简称Binary JSON，它和JSON一样，支持内嵌的文档对象和数组对象。
{
"customer":{
"id":1136,
"name":"Z3",
"billingAddress":[{"city":"beijing"}],
"orders":[
{
"id":17,
"customerId":1136,
"orderItems": [{"productId":27,"price":77.5,"productName":"thinking in java"}],
"shippingAddress":[{"city":"beijing"}]
"orderPayment":[{"ccinfo":"111-222-333","txnid":"asdfadcd334","billingAddress":{"city":"beijing"}}],
}
]
}
3. NoSQL数据库的四大分类
3.1 KV键值
- 新浪：BerkeleyDB+Redis
- 美团：Redis+Tair
- 阿里、百度：Memcached+Redis
3.2 文档型数据库
使用Bson格式的较多，例如CouchDB和MongoDB。
MongoDB是一个基于分布式文件存储的数据库，由C++语言编写，旨在为Web应用提供可扩展的高性能数据存储解决方案；它是一款介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。
3.3 列存储数据库
Cassandra，HBase，分布式文件系统。
3.4 图关系数据库
存放关系网络，例如：朋友圈社交网络，广告推荐系统等，专注于构建关系图谱。相关数据库有Neo4J，InfoGrid等。
3.5 四者对比
| 分类 | 举例 | 应用场景 | 数据模型 | 优点 | 缺点 |
|---|---|---|---|---|---|
| 键值 | Tokyo、Redis、Oracle BDB | 内容缓存，主要用于处理大量数据的高访问负载，也用于一些日志系统等。 | Key指向Value的键值对，通常用hashTable来实现 | 查找速度快 | 数据无结构化，通常只被当做字符串或二进制数据 |
| 列存储数据库 | Cassandra、HBase、Riak | 分布式文件系统 | 以列簇式存储，将同一列数据存在一起 | 查找速度快，可扩展性强，更容易进行分布式扩展 | 功能相对局限 |
| 文档型数据库 | CouchDB、MongoDB | Web应用（与键值对类似，Value是结构化的，不同的是数据库能够了解Value的内容） | key对应值，Value为结构化数据 | 数据结构要求不严格，表结构可变，无需像关系型数据库一样需要预先定义表结构 | 查询性能不高，且缺乏统一的查询语法 |
| 图形数据库 | Neo4J、InfoGird、Infinite Graph | 社交网络，推荐系统等，专注于构建关系图谱 | 图结构 | 利用图结构相关算法，比如最短路径寻址，N度关系查找等 | 很多时候需要对整个图做计算才能得出需要的信息，且这种结构不太好做分布式集群方案 |
4. 分布式数据库中CAP原理
4.1 传统的ACID
关系型数据库遵循ACID原则，具有以下四个特性：
- A（Atomicity）原子性
- C（Consistency）一致性
- I（Isolation）隔离性
- D（Durability）持久性
4.2 CAP
CAP原则又称CAP定理，指的是在一个分布式系统中的如下要素。
- C（Consistency）：强一致性
- A（Availability）：高可用性
- P（Partition tolerance）：分区容错性
4.2.1 CAP理论
CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较好的满足两个。
因此，根据CAP原理将NoSQL数据库分成了满足CA原则、满足CP原则和满足AP原则三大类：
- CA：单点集群，满足一致性，可用性的系统，通常可扩展性不太强；
- CP：满足一致性和分区容错性的系统，通常性能不是特别高；
- AP：满足可用性和分区容错性的系统，通常对一致性要求低一些。
4.2.2 CAP的3选2
CAP理论对应在分布式存储系统中，上面三个要素最多只能同时实现两点，不可能三者兼顾；考虑到当前网络硬件肯定会出现的延迟丢包等问题，所以分区容错性必须要实现。
接下来只能在C一致性和A可用性之间进行权衡，有如下选择：
- AP：大多数网站架构的选择
- CP：Redis、MongoDB
分布式架构系统中，大多web应用并不需要强一致性，因此牺牲C换取P，是目前分布式数据库产品的方向。
4.2.3 BASE
BASE就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案。
BASE是三个术语的缩写：
- 基本可用（Basically Available）
- 软状态（Soft State）
- 最终一致性（Eventually consistent）
BASE的基本思想就是通过让系统放松对某一时刻数据一致性的要求，来换取系统整体伸缩性和性能上的改观，就是上面的牺牲C换取AP。
其原因在于大型系统往往由于地域分布和极高性能的要求，不可能采用分布式事务来完成这些指标，想要获取这些指标，就必须采用另外一张方式，BASE就是解决这个问题的方法。
4.3 分布式+集群
分布式系统（distributed system）是由多台计算机和通信的软件组件通过计算机网络连接（局域网或广域网）组成，分布式系统是建立在网络之上的软件系统；正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的区别更多的在于高层软件（特别是操作系统）而不是硬件。分布式系统可以应用在不同的平台上如：PC、工作站、局域网和广域网上等等。
简单来说：
- 分布式：不同的多台服务器上面部署不同的服务模块（工程），他们之间通过RPC/PMI通信和调用，对外提供服务和组内协作。
- 集群：不同的多台服务器上面部署相同的服务模块，通过分布式调度软件进行统一的调度，对外提供服务和访问。
