NoSQL 简介
传统关系型数据库存在几个问题：
数据库可容纳数据太小
数据的索引一个机器的内存无法存放
当访问量增大，而且读写混合，会导致一个实例不能承受
Mencached+MySQL+垂直拆分
后来开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力。
MySQL 主从读写分离
再后来，大部分网站开始使用主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性。
具体来说，就是主库进行写操作，从库进行读操作，主库有一条数据之后，会迅速复制到从库。
Mysql的master-slave模式成为这个时候的网站标配了。
分表分库+水平拆分+mysql集群
然后 MySQL 主库的写压力开始出现瓶颈，而数据量的持续猛增，由于MyISAM使用表锁，在高并发下会出现严重的锁问题，大量的高并发MySQL应用开始使用 InnoDB 引擎（即行级锁）代替 MyISAM 。
开始流行使用分表分库来缓解写压力和数据增长的扩展问题。
NoSQL 横空出世
随着数据量的剧增和大数据的出现，传统的关系型数据库已经无法适应应用要求了。
NoSQL 是什么？
NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，泛指非关系型的数据库。
这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。
本质上就是使用 键值对 来进行存储。
核心点：KV、cache、persistence（持久化）
NoSQL 特点
易扩展
去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。
大数据量高性能
一般MySQL使用Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。
多样灵活的数据模型
在关系数据库里，增删字段是一件非常麻烦的事情。NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。
3 V 和 3 高
大数据时代的 3V
海量 Volume
多样 Variety
实时 Velocity
互联网需求 3 高
高并发
高性能
高可扩
扩展分为横向扩展和纵向扩展。在这里是横向扩展。
纵向扩展：用一个比喻就是，处理任务时，电脑性能不够了，给电脑加内存、固态、更换 CPU 等。
横向扩展：用一个比喻就是，处理任务时，电脑性能不够了，加多一台电脑一起处理，并把两台电脑封装起来，对外看起来就像是一台电脑。
统一数据服务层 UDSL
为了解决多数据源多数据的问题，以及各种数据库之前不同映射的问题。淘宝建立了一个 UDSL，也就是在网站应用集群和底层数据源之间，建立了一层代理。
三个特点：
完成各种数据库之间的映射
统一 API
热点缓存
各种数据库应用场景
要注意的是，当下的应用都是 SQL 和 NoSQL 一起运用。
NoSQL 主要应对多数据源、多数据类型的存储问题。
使用 SQL 的场景
一些基本固定不变的数据（即趋冷的数据），如商品的基本信息这些。
使用 NoSQL 的场景
多文字信息描述类（例如商品描述、评价等），IO 读写性能差，使用文档数据库 MongoDB 。
高频信息（商品波段性的热点高频信息），使用内存数据库，即
Redis、Tair、Memcache。高并发的同时进行关联查询，这是不建议的，这时候考虑 NoSQL
分布式事务支持不了太多并发
使用分布式文件系统
商品的图片存放。如淘宝的 TFS、Google 的 GFS 和 Hadoop 的 HDFS。
其他应用场景
商品关键字搜索：ISearch
BSON
BSON（）是一种类 JSON 的一种二进制形式的存储格式，简称Binary JSON，它和JSON一样，支持内嵌的文档对象和数组对象。
NoSQL 聚合模型
一般为四种：KV、BSON、列簇、图形
NoSQL 数据库的四大分类：
KV键值
通常用 hash map 实现。
应用场景：内容缓存，主要用于处理大量数据的高访问负载，也用于一些日志系统。
优点：查找速度快。
缺点：数据无结构化、通常只能被当做字符串或二进制数据
包括的数据库：
BerkeleyDB+redisredis+tairmemcache+redis
文档型数据库（BSON 格式较多）
KV键值对，value 为结构化数据。
应用场景：WEB 应用。
优点：数据要求不严格，表结构可变。
缺点：查询性能不高，缺乏统一的查询语法。
包括的数据库：
MongoDB
CouchDB
列存储数据库
以列簇式存储，将同一列的数据存放在一起。
应用场景：分布式文件系统。
优点：查找速度快，可扩展性强，易于分布式扩展。
缺点：功能相对局限
包括的数据库：
Cassandra, HBase
分布式文件系统
图关系数据库：
图结构，存放社交关系、广告推荐系统等等。
应用场景：社交网络等专注于构建关系图谱的场景
优点：可使用图的算法。
缺点：需要对整个图进行计算。
包括的数据库：
Neo4J
InfoGrid
分布式系统
由多台计算机和通信的软件组件通过计算机网络连接（本地网络或广域网）组成。分布式系统是建立在网络之上的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。
因此，网络和分布式系统之间的区别更多的在于高层软件（特别是操作系统），而不是硬件。
分布式系统可以应用在在不同的平台上如：Pc、工作站、局域网和广域网上等。
分布式和集群的区别
分布式：不同的多台服务器上面部署不同的服务模块（工程），他们之间通过Rpc/Rmi之间通信和调用，对外提供服务和组内协作。
集群：不同的多台服务器上面部署相同的服务模块，通过分布式调度软件进行统一的调度（即负载均衡），对外提供服务和访问。
分布式数据库
分布式数据库的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上改观，即 CAP 中选 AP。
因为大型系统往往由于地域分布和极高性能的要求，不可能采用分布式事务来完成这些指标，要想获得这些指标，我们必须采用另外一种方式来完成，BASE就是解决这个问题的办法。
因此绝大多数情况下都是 CAP+BASE。
CAP
传统的关系型数据库提出 ACID 的理念。因此非关系型数据库提出了属于自身的理念，即 CAP。
CAP 是 Consistency(强一致性)、Availability(可用性)、Partition tolerance(分区容错性) 的缩写。
强一致性：任何一个读操作总是能读取到之前完成的写操作结果，也就是在分布式环境中，多点的数据是一致的。
可用性：每一个操作总是能在确定的时间内返回，也不是系统随时都是可用的。
分区容错性：在出现网络分区（如断网）的情况下，分离的系统也能正常运行。
CAP 三选二
一个分布式系统不能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Tolerance of network Partition）。因此最多只能同时满足两个要求。
因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三大类：
CA ：单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。（传统Oracle数据库）
CP ：满足一致性，分区容错性的系统，通常性能不是特别高。（Redis、Mongodb）
AP ：满足可用性，分区容错性的系统，通常可能对一致性要求低一些。（大多数网站架构的选择）
对于大多数网站来说，因为分布式的存在，分区容错性是必须要实现的。而大多数web应用，其实并不需要强一致性，从性能角度来说：在高并发的情况下很难做到数据的及时精确性，从用户体验的角度来说，说：发一条消息之后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。因此牺牲C换取P，这是目前分布式数据库产品（如电商、秒杀网站、社交网站）的方向。而使用 CP，即 Redis 等，可以减少多表查询的操作，强化了可用性，保证了网站的 AP。
BASE
BASE就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案。
BASE其实是下面三个术语的缩写：
基本可用性（Basically Available）
软状态（Soft state）
最终一致性（Eventually consistent）
它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上改观。为什么这么说呢，缘由就在于大型系统往往由于地域分布和极高性能的要求，不可能采用分布式事务来完成这些指标，要想获得这些指标，我们必须采用另外一种方式来完成，这里BASE就是解决这个问题的办法