概述
当网站的访问量不大时，用单个数据库完全可以轻松应付。
数据存储的瓶颈：
- 数据量的总大小导致一个机器放不下
- 数据的索引(B+Tree)一个机器的内存放不下时
- 访问量(读写混合)一个实例承受不了
Memcached和MySQL垂直拆分
随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都出现了性能问题，开始使用缓存技术缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量增大时，多台web机器通过文件缓存不能共享，大量的小文件缓存也带来了比较高的IO压力。这个时候，Memcached就自然的成为了非常时尚的技术产品
MySQL主从读写分离
由于数据库写入压力增加，Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不勘重负，大部分网站开始使用主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性。这就是MySQL的master-salve模式。
分表分库+水平拆分+MySQL集群
在Memcached的高速缓存，MySQL的主才复制，读写分离的基础上，这时MySQL主库的写压力开始出现瓶颈，而数据量的持续猛增，由于MyISAM使用表锁，在高并发下会出现严重的锁问题，大量的高并发MySQL应用开始使用InnoDB引擎。
同时，开始流行使用分表分库来缓解写压力和数据增长的扩展问题。此时，MySQL推出了还不太稳定的表分区
MySQL的扩展性瓶颈
MySQL数据库也经常村粗一些大文本字段，导致数据库表非常大，在做数据库恢复的时候就导致非常慢，不容易快速恢复数据库。比如1000万4KB大小的文本就接近40G，如果能把这些数据从MySQL删去，MySQL将变得非常小。关系型数据库很强大，但是它并不能很好地应付所有应用场景。MySQL的扩展性差，大数据下IO压力大，表结构更改困难。
NoSQL是什么
NoSQL(NoSQL== Not Only SQL) ，意即"不仅仅是SQL"
泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库已经显得力不从心。NoSQL数据库的产生就是为了解决大规模数据集合多重数据库种类带来的挑战。
易扩展
NoSQL数据库种类繁多，但是一个共同点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。
大数据量高性能
NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache。在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的Cache的记录是记录级的，是一种细粒度的Cache，所有NoSQL在这个层面上性能就要高很多。
多样灵活的数据模型
NoSQL无需事先为要存储的字段建立字段，随时可以存储自定义得数据格式。而在关系型数据库里，增删字段是一件非常麻烦的事情。
NoSQL
- 代表着不仅仅是SQL
- 没有声明性查询语言
- 没有预定义的模式
- key-value存储，列存储，文档存储，图形数据库
- 最终一致性，而非ACID
- CAP定理
- 高性能，高可用性和可伸缩性
NoSQL聚合模型
- KV键值
- Bson
- 列族
- 图形
NoSQL数据库的四大分类
- KV键值
- 文档型数据库
- 列存储数据库
- 图关系数据库
| 分类 | Example | 典型应用场景 | 数据模型 | 优点 | 缺点 |
|---|---|---|---|---|---|
| 键值(key-value) | Redis,Oracle BDD | 内容缓存，主要用于处理大量数据的高访问负载，也用于一些日志系统 | key指向value的键值对，通常用hash table实现 | 查找速度快 | 数据无结构化，通常只被当作字符串或者二进制数据 |
| 列存储数据库 | Riak，HBase | 分布式的文件系统 | 以列簇式存储，将同一列数据存在一起 | 查找速度快 | 功能相对局限 |
| 文档型数据库 | CounchDB，MongoDb | Web应用(与key value类似，value是结构化的，不同的是数据库能够了解value的内容) | key-value对应的键值对，value为结构化数据 | 数据结构要求不严格，表结构可变，不需要像关系型数据库一样需要预先定义表结构 | 查询性能不高，而且缺乏统一的语法 |
| 图形数据库 | Graph | 社交网络，推荐系统等，专注于构建关系图谱 | 图结构 | 利用图结构相关算法查询 | 很多时候需要对整个图计算才能得出结果 |
数据库CAP原理
CAP
- C:Consistency(强一致性)
- A:Availability(可用性)
- P:Partition tolerance(分区容错性)
一致性就是数据保持一致，在分布式系统中，可以理解为多个节点中数据的值是一致的。而一致性又可以分为强一致性与弱一致性。强一致性可以理解为在任意时刻，所有节点中的数据是一样的。同一时间点，你在节点A中获取到key1的值与在节点B中获取到key1的值应该都是一样的。弱一致性包含很多种不同的实现，目前分布式系统中广泛实现的是最终一致性。所谓最终一致性，就是不保证在任意时刻任意节点上的同一份数据都是相同的，但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化。也可以简单的理解为在一段时间后，节点间的数据会最终达到一致状态。
对于非关系型数据库，CAP中只能3选2，无法全部满足CAP。
CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较好的满足两个。
因此，根据CAP原理，NoSQL数据库分成了满足CA原则，CP原则，AP原则三大类
- CA：单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大
- CP：满足一致性，分区容错性的系统，通常性能不是特别高
- AP：满足可用性，分区容错性的系统，通常对一致性要求低一些
分区容错性是我们必须实现的，所以我们只能在一致性和可用性之间进行权衡。
AP是大多数网站架构的选择(很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，允许实现最终一致性)
BASE
BASE就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案
- Basically Available-基本可用
- Soft state-软状态
- Eventually consisitent-最终一致性
它的思想就是通过让系统放松对某一适合数据一致性的要求来换取系统整体性能的改观。大型系统往往由于地域分布和极高的性能要求，不可能采用分布式事务来完成这些指标，要想获得这些指标，我们必须采用另外一种方式来完成，这里的BASE就是解决这个问题的方法。