大数据求索(11): 为什么选择NoSQL
一、背景
1.1 单机MySQL
起初互联网网站访问量一般都不打，用单个数据库可以轻松应付。此外，刚开始的网站大多数是静态网页，动态交互类型的网站不多。
在此种架构模式下，数据存储的瓶颈是什么呢？
- 数据量的总大小，一个机器放不下时
- 数据的索引（B+Tree）一个机器的内存放不下时
- 访问量（读写混合）一个实例不能承受时
这种情况下，就需要进行改进。
1.2 Memcached(缓存)+MySQL+垂直拆分
随着访问量上升，单机mysql架构开始出现性能问题。此时的web程序不再仅仅关注功能，同时也追求性能。
此时，缓存技术出现了。程序员开始大量使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能共享，大量的小文件也带来了极高的IO压力，此时，Memcached成为解决问题的新的技术。
Memcached作为一个独立的分布式的缓存服务器，为多个web服务器提供了一个共享的高性能缓存服务。在Memcached服务器上，又发展了根据hash算法来进行多台Memcached缓存服务的扩展，然后又出现了一致性hash来解决增加或减少缓存服务器导致重新hash带来的大量缓存失效的弊端。
一致性hash算法可参考博文五分钟理解一致性哈希算法(consistent hashing)
1.3 MySQL主从复制和读写分离
由于数据库的写入压力增加，Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负，大部分网站开始使用主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性。MySQL的master-slave模式成为这个时候的网站标配。
了解主从复制和读写分离可以参考博文10分钟了解读写分离的作用
实践读写分离可以参考博文数据库读写分离，主从同步实现方法
1.4 分库分表+水平拆分+MySQL集群
在Memcached的高速缓存，MySQL的主从复制，读写分离的基础之上，这时MySQL主库的写压力开始出现瓶颈，而数据量的持续猛增，由于MyISAM使用表锁，在高并发下会出现严重的锁问题，大量的高并发MySQL应用开始使用InnoDB引擎代替MyISAM。
同时，开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候，分表分库成了一个热门技术，是面试的热门问题也是业界讨论的热门技术问题。也就在这个时候，MySQL推出了还不太稳定的表分区，这也给技术实力一般的公司带来了希望。虽然MySQL推出了MySQL Cluster集群，但性能也不能很好满足互联网的要求，只是在高可靠性上提供了非常大的保证。
1.4.1 垂直分表
垂直分表在日常开发和设计中比较常见，通俗的说法叫做**“大表拆小表”**，拆分是基于关系型数据库中的“列”（字段）进行的。
1.4.2 垂直分库
垂直分库在“微服务”盛行的今天已经非常普及了。基本的思路就是按照业务模块来划分出不同的数据库，而不是像早期一样将所有的数据表都放到同一个数据库中。
1.4.3 水平分表
水平分表也称为横向分表，比较容易理解，就是将表中不同的数据行按照一定规律分布到不同的数据库表中（这些表保存在同一个数据库中），这样来降低单表数据量，优化查询性能。最常见的方式就是通过主键或者时间等字段进行 Hash 和取模后拆分。
1.4.4 水平分库分表
水平分库分表与上面讲到的水平分表的思想相同，唯一不同的就是将这些拆分出来的表保存在不同的数据中。这也是很多大型互联网公司所选择的做法。
分表分库参考博文分库分表的几种常见形式以及可能遇到的难题
MySQL集群问题参考高性能、高可用、可扩展的MySQL集群如何组建？
脑裂问题参考Namenode HA原理详解（脑裂）
1.5 MySQL的扩展性瓶颈
MySQL数据库也经常存储一些大文本字段，导致数据库表非常的大，在做数据库恢复的时候就导致非常的慢，不容易快速恢复数据库。比如1000万4KB大小的文本就接近40GB的大小，如果能把这些数据从MySQL省去，MySQL将变得非常的小。关系数据库很强大，但是它并不能很好的应付所有的应用场景。MySQL的扩展性差（需要复杂的技术来实现），大数据下IO压力大，表结构更改困难，正是当前使用MySQL的开发人员面临的问题。
1.6 今天的架构
二、NoSQL诞生
NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，
**泛指非关系型的数据库。**随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题，包括超大规模数据的存储。（例如谷歌或Facebook每天为他们的用户收集万亿比特的数据）。这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。
三、NoSQL数据库的四大分类
3.1 键值(Key-Value)存储数据库
这一类数据库主要会使用到一个哈希表，这个表中有一个特定的键和一个指针指向特定的数据。Key/value模型对于IT系统来说的优势在于简单、易部署。但是如果DBA只对部分值进行查询或更新的时候，Key/value就显得效率低下了。举例如：Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB.
3.2 列存储数据库
这部分数据库通常是用来应对分布式存储的海量数据。键仍然存在，但是它们的特点是指向了多个列。这些列是由列家族来安排的。如：Cassandra, HBase, Riak.
3.3 文档型数据库
文档型数据库的灵感是来自于Lotus Notes办公软件的，而且它同第一种键值存储相类似。该类型的数据模型是版本化的文档，半结构化的文档以特定的格式存储，比如JSON。文档型数据库可 以看作是键值数据库的升级版，允许之间嵌套键值。而且文档型数据库比键值数据库的查询效率更高。如：CouchDB, MongoDB. 国内也有文档型数据库SequoiaDB，已经开源。
3.4 图形(Graph)数据库
图形结构的数据库同其他行列以及刚性结构的SQL数据库不同，它是使用灵活的图形模型，并且能够扩展到多个服务器上。NoSQL数据库没有标准的查询语言(SQL)，因此进行数据库查询需要制定数据模型。许多NoSQL数据库都有REST式的数据接口或者查询API。如：Neo4J, InfoGrid, Infinite Graph.
因此，我们总结NoSQL数据库在以下的这几种情况下比较适用：1、数据模型比较简单；2、需要灵活性更强的IT系统；3、对数据库性能要求较高；4、不需要高度的数据一致性；5、对于给定key，比较容易映射复杂值的环境。
参考博文《NoSQL入门》关于NoSQL