为什么使用NoSQL？
关系型数据库以MySQL为例
单机MySQL时代
基本上网站的访问量不大，用一个MySQL数据库实例就可应对。系统的架构往往是应用=>DAO=>数据库实例
问题:
- 当系统业务发展较快时，数据量的不断增加，可能出现一个数据库服务器放不下这么多数据的情况
- 为了检索便利，通常会设置索引，但是索引是以一个文件的方式存放到磁盘上，如果索引和数据都存在在一起，而随着数据量不断增加，会加剧数据库服务器放不下这么多数据的情况发生
- 上述这种数据库架构是读写混合的(即读写均是一个实例)，随着访问量的不断增加，一个实例可能承受不了这么多的访问量
访问量的不断增加，这种架构就出现了性能问题，于是衍生出了新的架构
Memcached(缓存)+MySQL+数据库垂直拆分
数据库垂直拆分：一个数据库由很多表构成，每个表对应着不同的业务，垂直拆分是指按照业务将表进行分类，分布到不同的数据库上面，这样就将数据或者压力分担到不同的库上面了。
随着访问量的上升，大部分使用MySQL架构的网站在数据库上开始出现了性能问题。将网站中频繁查询的数据放到缓存中，并且将数据库进行了垂直拆分，将数据的压力分担到不同的库上面，这样相较于第一种架构也能存储更多的数据了。
MySQL主从读写分离
由于数据库的写入压力增加，缓存只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负。大部分网站开始使用主从复制技术来达到读写分离(主从库之间通过某种通讯机制进行数据的同步)，以提高读写性能和读库的可扩展性以及容灾。主库主要完成增删改，从库主要完成读取操作
分库分表+水平拆分+MySQL集群
上述架构中，MySQL读写分离通常采用一主两从的机制来建立主从库的，随着业务体量的不断增加，MySQL主库的写压力开始出现瓶颈，这个时候开始使用分库分表来缓解写压力和数据增长的问题。而MySQL集群在高可靠性上可以提供很大的保证。
分库分表可分为数据库的水平拆分、垂直拆分和数据表的水平拆分、垂直拆分。
数据表的垂直拆分与数据库的垂直拆分思想很类似，就是纵向地把表中的列分成多个表，常遵循以下几点进行拆分：
- 冷热分离，把常用的列放在一个表，不常用的放在一个表
- 大字段列独立存放
- 关联关系紧密的列放在一起
数据表的水平拆分与数据库的水平拆分思想也很类似，就是横向地把表中的数据拆分成多个表，如原表有1000W数据，拆分之后有5个200W数据的该表。
MySQL的扩展性瓶颈
MySQL数据库经常存储一些大文本字段，导致数据库表非常大，在作数据库恢复的时候就会非常慢，不容易快速恢复数据库。
MySQL扩展性差，大数据下IO压力大，表结构更改困难(尤其是数据较大时)等。
为什么使用NoSQL?
随着网络的发展，社交网络等逐渐兴起，传统的关系型数据库的一行一列不足以支撑这些复杂的关系网络
NoSQL是什么?
NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题，包括超大规模数据的存储。（例如谷歌或Facebook每天为他们的用户收集万亿比特的数据）。这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。
NoSQL的特性
-
易扩展
NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。
-
大数据量下的高性能
NoSQL数据库都具有非常高的读写性能，尤其是在大数据量下。虽然MySQL某些版本下存在Query Cache，但是每次表的更新Cache就会失效，不利于使用。而NoSQL的Cache是记录级别的,是一种细粒度的Cache。
-
灵活的数据模型
NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。但是在关系数据库中，增删字段是件很麻烦的事，尤其是数据量很大的表。
NoSQL数据库的分类
-
KV键值，如Redis
-
文档型数据库(bson格式)，如MongoDB
MongoDB是一个基于分布式文件存储的数据库，可以为WEB应用提供可扩展的高性能数据存储解决方案。
MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库中功能最丰富，最像关系数据库的。
-
列存储数据库，如HBase 以列族存储数据，分布式文件系统
-
图关系数据库，它不是放图形的，专注于构建关系图谱，如Neo4J，InfoGrid
NoSQL数据库对比
| 分类 | 举例 | 应用场景 | 数据模型 | 优点 | 缺点 |
|---|---|---|---|---|---|
| 键值(key-value) | Redis/Oracle BDB | 内容缓存，主要用于处理大量数据的高访问负载，也用于一些日志系统等 | key指向value的键值对，通常用hashtable来实现。 | 查找速度快 | 数据无结构化，通常只被当做字符串或二进制数据 |
| 列存储数据库 | HBase/Riak | 分布式文件系统 | 以列簇式存储，将统一列数据存在一起 | 查找熟读快，可扩展性强，更容易进行分布式扩展 | 功能相对局限 |
| 文档型数据库 | MongoDB | web应用 | Key-Value对应的键值对，Value为结构化的数据 | 数据结构要求不严格，表结构可变，不需要像关系型数据库一样需要预先定义表结构 | 查询性能不高，而且缺乏统一的查询语法 |
| 图形数据库 | Neo4J/InfoGrid | 社交网络、推荐系统等，专注于构建关系图谱 | 图结构 | 利用图结构相关算法 | 很多时候需要对整个图做计算才能得到需要的信息，而且这种结构不太适合做分布式的集群 |
CAP原理
传统的ACID分别是Atomicity(原子性)、Consistency(一致性)、Isolation(独立性)、Durability(持久性)
CAP名词解释：
- C:Consistency(强一致性)
- A:Availability(可用性)
- P:Partition tolerance(分区容错性)
CAP理论
CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较好的满足两个。
因此，根据CAP原理将NoSQL数据库分成了满足CA原则、满足CP原则和满足AP原则三大类.
- CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大
- CP - 满足一致性，分区容错性的系统，通常性能不是特别高
- AP - 满足可用性、分区容错性的系统，通常对一致性要求低一些，追求最终一致性。
而由于当前的网络硬件肯定会出现延迟丢包等问题，因此分区容错性是必须满足的。所以我们只能在一致性和可用性之间进行权衡。
分布式架构中必须有所取舍，在一致性和可用性之间取一个平衡。其实大多数web应用并不需要强一致性，因此AP是目前架构的一个方向。
BASE理论
BASE就是为了解决因强一致性导致的可用性降低问题而提出的解决方案。
BASE名词解释：
- Basically Available 基本可用
- Soft state 软状态
- Eventually consistent 最终一致
它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上的改观。
