NoSQL 概述

一、为什么用 NoSQL

1.1 单机 MySQL 的美好时代

        在90年代，一个网站的访问量一般不大，用单个数据库完全可以轻松应付。在那个时候，更多的都是静态网页，动态交互类型的网站不多。架构图如下所示，其中 DAL 表示数据库访问层。

        在上述架构下，我们来分析下此时网站可能存在的瓶颈可能是什么？

        1、数据量如果太大的话，一台 mysql 可能就放不下了

        2、mysql 数据库的索引（B+ Tree）太大，一个机器的内存放不下时

        3、访问量太大（读写混合），一个服务器承受不了

        如果出现上面的三种情况之一，那么该如何解决呢？

1.2 Memcached（缓存）+ MySQL + 垂直拆分（读写分离）

        后来，随着访问量的上升，几乎大部分使用 MySQL 架构的网站在数据库上都开始出现了性能问题，web 程序不再仅仅专注在功能上，同时也在追求性能。

        程序猿们开始大量使用缓存技术来缓解数据库的压力，优化数据库的结构和索引，开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台 web 机器通过文件缓存不能共享，大量的小文件缓存也带了比较高的 IO 压力，在这个时候，Memcached 就自然的成为一个非常时尚的技术产品。

1.3 分库分表 + 水平拆分 + MySQL 集群

        在 Memcached 的高速缓存，MySQL 的主从复制，读写分离的基础之上，这时 MySQL 主库的写压力开始出现瓶颈，而数据量的持续猛增，由于 MyISAM（早期 MySQL 的引擎） 使用表锁，在高并发下会出现严重的锁问题，大量的高并发 MySQL 应用开始使用 InnoDB 引擎代替 MyISAM。

        同时，开始流行使用分表分库来缓解写压力和数据增长的扩展问题，这个时候，分表分库成了一个热门技术，是面试的热门问题，也是业界讨论的热门技术问题。也就是在这个时候，MySQL 推出了还不太稳定的表分区，这也给技术实力一般的公司带来了希望。虽然 MySQL 推出了 MySQL Cluster 集群，但性能也不能很好满足互联网的需求，只是在高可靠性上提供了非常大的保证。

1.4 MySQL 的扩展性瓶颈

        MySQL 数据库也经常存储一些大文本的字段，导致数据库表非常的大，在做数据库恢复的时候就导致非常的慢，不容易快速恢复数据库，比如 1000万 4KB 大小的文本就接近 40GB 的大小，如果能把这些数据从 MySQL 省去，MySQL 将变的非常的小，关系数据库很强大，但是它并不能很好的应付所有的应用场景，MySQL 的扩展性差（需要复杂的技术来实现），大数据下 IO 压力大，表结构更改困难，正是当前使用 MySQL 的开发人员面临的问题。

1.5 今天是什么样子？

1.6 为什么用NoSQL？

        今天我们可以通过第三方平台（如：Google，FaceBook 等）可以很容易的访问和抓取数据。用户的个人信息，社交网络，地理位置，用户生成的数据和用户操作日志已经成倍的增加、我们如果要对这些用户数据进行挖掘，那 SQL 数据库已经不适合这些应用了，而 NoSQL 数据库的发展却能很好的处理这些大的数据！

二、什么是 NoSQL

2.1 NoSQL 概念

        NoSQL = Not Only SQL，意思：不仅仅是 SQL。

        泛指非关系型的数据库，随着互联网 Web2.0 网站的兴起，传统的关系数据库在应付 Web2.0 网站，特别是超大规模和高并发的社交网络服务类型的 Web2.0 纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展，

        NoSQL 数据库的产生就是为了解决大规模数据集合多种数据种类带来的挑战，尤其是大数据应用难题，包括超大规模数据的存储。（例如谷歌或 Facebook 每天为他们的用户收集万亿比特的数据）。这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展）。

2.2 NoSQL 特点

2.2.1 易扩展

        NoSQL 数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展，也无形之间，在架构的层面上带来了可扩展的能力。

2.2.2 大数据量高性能

        NoSQL 数据库都具有非常高的读写性能，尤其是在大数据量下，同样表现优秀。这得益于它的非关系性，数据库的结构简单。

        一般 MySQL 使用 Query Cache，每次表的更新 Cache 就失效，是一种大力度的 Cache，在针对 Web2.0 的交互频繁应用，Cache 性能不高，而 NoSQL 的 Cache 是记录级的，是一种细粒度的 Cache，所以 NoSQL 在这个层面上来说就要性能高很多了。

        官方记录：Redis 一秒可以写8万次，读11万次！

2.2.3 多样灵活的数据性能

        NoSQL 无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式，而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是噩梦。

2.2.4 传统的 RDBMS VS NoSQL

传统的关系型数据库 RDBMS

        - 高度组织化结构化数据
        - 结构化查询语言（SQL）
        - 数据和关系都存储在单独的表中
        - 数据操纵语言，数据定义语言
        - 严格的一致性
        - 基础事务

NoSQL
        - 代表着不仅仅是SQL
        - 没有声明性查询语言
        - 没有预定义的模式
        - 键值对存储，列存储，文档存储，图形数据库
        - 最终一致性，而非ACID属性
        - 非结构化和不可预知的数据
        - CAP定理
        - 高性能，高可用性 和 可伸缩性

三、NoSQL 四大分类

分类	相关产品	典型应用	数据模型	优点	缺点
键值(key-value)	Redis等	内容缓存、主要用于处理大量数据的高访问负载	一系列键值对	快速查询	存储的数据缺少结构化
列存储数据库	HBase、Riak	分布式的文件系统	以列簇式存储，将同一列数据存在一起	查找速度快，可扩展性强，更容易进行分布式扩展	功能相对局限
文档型数据库	CouchDB、MongoDB	Web应用(与Key-value类似，value是结构化的)	一系列键值对	数据结构要求不严格	查询性能不高，而且缺乏统一的查询语法
图形数据库	Neo4j、InfoGrid等	社交网络，推荐系统等，专注于构建关系图谱	图结构	利用图结构相关算法	需要对整个图做计算才能得出结果，不容易做分布式的集群方案