什么是NoSQL，为什么要使用NoSQL？
1 为什么用 NoSQL？
1.1 单机 MySQL 的美好时代
在90年代初期至1990年代末期之间的一段时间里（即所谓的"90年代"），一个网站的访问规模通常有限，并且完全可以通过单一数据库来实现基本功能而不必担心复杂的数据架构设计。那时候的网站多以静态页面为主（即所谓的"静态网页"），而真正具备动态交互功能的网站则相对较少。
上述架构下，我们来看看数据存储的瓶颈是什么？
DAL : Data Access Layer（数据访问层 – Hibernate，MyBatis）
- 当数据规模总量超出机器存储能力时。
- 当数据以B+树结构存在时，如果内存容纳不了，则会触发溢出。
- 系统在处理综合业务需求下的负载时会遇到性能瓶颈。
如果满足了上述1 or 3个时，只能对数据库的整体架构进行重构。
1.2 Memcached(缓存)+MySQL+垂直拆分
随后
作为专为分布式系统设计的高度并行化缓存引擎，Memcached 通过提供统一级别的高性能缓存服务支持多台Web服务器之间的高效数据共享。随着对分布式架构需求的增长，在现有的 Memcached 服务器基础上发展出了基于哈希算法实现多台 Memcased 并行扩展的技术。为了应对动态调整节点数时带来的哈希失效问题，在此基础上进一步演进出了一致性哈希算法。
1.3 Mysql主从读写分离
随着数据库 writes（write requests）的压力上升，Memcached 则主要负责缓存逻辑并无法处理 writes 问题。将 read 和 write 集中在一个数据库会导致过载现象愈发严重，在这种情况下，“read-write isolation（读写隔离）”策略逐渐成为必须采用的技术手段。为了实现 read 和 write 分离策略，“read-write partitioning（读写分离）”架构逐渐取代了传统的单库模式成为主流设计选择。通过 MySQL 的 master_slave 模式实现了这一技术方案在实际应用中的可靠性和可扩展性需求。
1.4 分库分表+水平拆分+mysql集群
基于Memcached的缓存技术、MySQL的主从复制策略以及实现读写分离的基本架构之上，在MySQL主库承受着持续增长带来的巨大 write 压力时（随着数据量急剧攀升），这一限制逐渐显现出来。由于MyISAM在处理事务锁定机制时存在明显不足，在面对高强度并发 writes 的情况下容易陷入严重的性能瓶颈（大量高并发的应用开始转向InnoDB引擎作为默认选择）。
ps：这就是为什么 MySQL 在 5.6 版本之后使用 InnoDB 做为默认存储引擎的原因 – MyISAM 写会锁表，InnoDB 有行锁，发生冲突的几率低，并发性能高。
同时随着人们越来越意识到数据管理的重要性。
分表分库逐渐成为主流的解决方案。
在那个阶段，
分表分库成为了大家讨论的焦点，
同时也是各大公司的面试题。
MySQL在那个阶段发布了还不太稳定的表分区技术，
这一技术为那些技术实力尚且不足的企业提供了一线希望。
尽管MySQL随后推出了MySQL Cluster集群，
但其性能仍无法完全满足互联网的需求，
只能在可靠性和稳定性方面提供极大的保障。
1.5 MySQL的扩展性瓶颈
MySQL常用于存储一些大型文本字段，在这种情况下会导致数据库表占用较大的存储空间，在进行数据库恢复时效率显著降低，并且难以迅速恢复整个数据库的状态。这一特性使得在处理大规模数据时存在挑战。尽管关系型数据库在很多方面表现优异，但在某些应用场景下却无法提供理想的支持。MySQL的主要缺陷包括其扩展性较差（通常需要复杂的技术实现），面对大数据量时会面临较大的I/O压力，并且表结构修改较为复杂等问题。
1.6 今天是什么样子？
采用企业级防火墙作为基础防护机制；后端则采用负载均衡主机进行任务分配（其中软负载为Nginx、硬负载为F5），负责将任务分配至web服务器集群中；具体应用层服务器（如Tomcat）则负责缓存接入及数据库交互。
1.7 为什么用NoSQL?
今天我们可以利用第三方平台（例如：Google、Facebook等）来方便地访问和获取数据。用户的个人信息、社交网络、地理位置、生成的数据以及操作日志已大幅增加。如果我们希望深入分析这些海量数据，则传统的SQL数据库已无法满足需求；而NoSQL数据库则能够很好地应对这一挑战。
2. 什么是NoSQL？
2.1 NoSQL 概述
Non-Relational Databases (NRDBs, Non-Relational Databases, NRDs)，即"不仅仅是SQL"（Not Only SQL），
指的是非关系型数据库系统的一种扩展形式。随着互联网（web2.0）网站的兴起以及对大规模、高并发、复杂社交网络（SNS）等纯动态网站的需求不断增加，在处理这些网页应用时传统的关系型数据库表现出了明显的不足与局限性，并逐渐暴露出了难以克服的技术瓶颈。而基于其自身的优势特点发展起来的非关系型数据库，则能够有效地满足这些需求并获得了快速的进步与发展。Non-Relational Databases (NRDBs) 的出现正是为了应对由海量数据集中的多类型数据所引发的巨大挑战以及解决大数据应用中所面临的难题（包括但不限于超大规模数据存储问题）。
根据研究显示，谷歌和Facebook等公司每天从各自的用户那里收集着海量的比特数据。
这些数据存储的方式没有预先设定的模式，并且能够通过无需额外操作的方式实现横向扩展。
2.2 NoSQL代表
MongDB、 Redis、Memcache
3. 关系型数据库与NoSQL的区别？
3.1 RDBMS
- 高度结构化的组织化数据
- 结构化的查询语言（SQL）
- 所有数据及其关联信息均存储于独立的数据表中。
- 数据操纵语言与数据定义语言
- 严格的统一性
- 基本事务操作
- ACID特性（包括原子性、一致性、隔离性和持久性）
关系型数据库严格遵守ACID规则
在英语中被称为Transaction，在现实生活中与交易行为非常相似。它具备A/C/I/ durability（原子性、一致性、隔离性和持久性）四个基本特性。
A (Atomicity) 原子性
说起来简单易懂吧？原子性意味着在一个数据库事务中所有的修改行为必须完全执行或者都不执行才算作该事务的成功。换句话说，在一个事务中所有的操作必须全部成功才算作成功；只有当事务中的每一步操作都顺利完成时才算成功；只要有任何一个操作未能完成就会导致整个事务失败从而需要进行重 rolled回滚（回滚）。比如说存款转账业务流程中的某个典型场景：比如说存款转账业务流程中的某个典型场景：比如说存款转账业务流程中的某个典型场景：比如说存款转账业务流程中的某个典型场景：比如说存款转账业务流程中的某个典型场景：比如说存款转账业务流程中的某个典型场景：比如说存款转账业务流程中的某个典型场景：比如说存款转账业务流程中的某个典型场景：比如说存款转账业务流程中的某个典型场景：比如说存款转账业务流程中的某个典型场景：比如说存款转账业务流程中的某个典型场景
C (Consistency) 一致性
consistency也相对容易理解。这表示数据库必须始终保持一致的状态，在事务操作下不会破坏原有的一致性约束。
I (Isolation) 独立性
Isolation: 独立性是指并发的事务之间互不影响。即若某一事物试图读取数据时发现另一事物已对该数据进行修改，则该数据不受另一事物未提交状态的影响。例如，在某笔交易中将A账户中的金额转入B账户时，在此笔交易尚未完成的情况下（即另一事物尚未提交），若此时B查询其账户，则无法看到新增加的100元金额。
D (Durability) 环境中的 durability 是一种特性。
durability is characterized by the fact that once a transaction is successfully committed, all its modifications are permanently stored in the database, regardless of any subsequent failures.
3.2 NoSQL
- 不仅仅局限于传统的SQL。
- 不支持传统的声明式查询语言。
- 不具有预先定义的标准数据模式。
- 键-值对存储、列存储、文档存储以及图形数据库。
- 最终的一致性。
- 非结构化的、不可预测的数据。
- CAP定理指出，在分布式系统中无法同时满足强一致性（strong consistency）、分区容忍（partition tolerance）和高可用性（high availability）三项要求中的任意两项。
- 系统必须是高性能、高可用性和可伸缩性的统一体现。
分布式数据库中的CAP原理(了解)
CAP定理：
- 一致性方面，在数据的一致更新过程中进行同步处理。
- 可用性方面，系统能够迅速响应。
- 系统能够容忍分区错误，并运行稳定。
P: 任何信息丢失或故障都不会影响系统的持续运行。
定理：任何分布式系统只可同时满足二点，没法三者兼顾。
CAP理论的核心观点指出：一个分布式系统无法同时较好地实现一致性、可用性和分区容错性这三个关键特性。
基于此，在遵循 CAP 理论的基础上，NoSQL 数据库被划分为符合 CA 标准、符合 CP 标准以及符合 AP 标准的三大类
- CA - 单一节点集群具备高的一致性和良好的可用性特征，在可扩展性方面表现相对较弱。
- CP - 该系统的高一致性和较高的分区容忍度。
- AP - 该系统的高分区容忍度和较低的一致性要求。
CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。
然而由于当前网络硬件必然会导致延迟丢包等问题的存在因此我们必须要实现分区容忍性
我们不得不在一致性与可用性之间进行权衡取舍，并无任何NoSQL系统能够同时满足这三个条件。
说明：C：强一致性 A：高可用性 P：分布式容忍性
举例：
CA：传统Oracle数据库
AP：大多数网站架构的选择
CP：Redis、Mongodb
注意：分布式架构的时候必须做出取舍。
在保证一致性和可用性的前提下找到一种折中方案。虽然大多数web应用，并不需要采用强一致性策略。
因此牺牲C换取P，这是目前分布式数据库产品的方向。
4. 当下NoSQL的经典应用
当下的应用采用 SQL 和 NoSQL 的结合使用。
主要项目：阿里巴巴商品信息的存储。
实现 IOE 化。
ps: I指的是IBM的小型机系统, 系列产品的售价都不菲; O指的是Oracle数据库, 同样价格高昂; M指的是EMC的数据存储设备, 也是不菲之笔。
难点：
- 数据类型丰富性。
- 数据源的多样性与动态调整能力。
- 通过优化数据源结构提升效率... 平台服务保持原有功能。