NoSql 简述

NoSQL(NoSQL = Not Only SQL )，意即”不仅仅是SQL”。
NoSQL，泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题。

---

传统关系数据库的瓶颈

传统的关系数据库具有不错的性能，高稳定型，久经历史考验，而且使用简单，功能强大，同时也积累了大量的成功案例。在互联网领域，MySQL成为了绝对靠前的王者，毫不夸张的说，MySQL为互联网的发展做出了卓越的贡献。

在 互联网，大部分的MySQL都应该是IO密集型的，事实上，如果你的MySQL是个CPU密集型的话，那么很可能你的MySQL设计得有性能问题，需要优 化了。大数据量高并发环境下的MySQL应用开发越来越复杂，也越来越具有技术挑战性。分表分库的规则把握都是需要经验的。虽然有像淘宝这样技术实力强大 的公司开发了透明的中间件层来屏蔽开发者的复杂性，但是避免不了整个架构的复杂性。分库分表的子库到一定阶段又面临扩展问题。还有就是需求的变更，可能又 需要一种新的分库方式。

MySQL数据库也经常存储一些大文本字段，导致数据库表非常的大，在做数据库恢复的时候就导致非常的慢，不容易快速恢复数据库。比如1000万4KB大小的文本就接近40GB的大小，如果能把这些数据从MySQL省去，MySQL将变得非常的小。

随着互联网的不断发展，各种类型的应用层出不穷，所以导致在这个云计算的时代，对技术提出了更多的需求，主要体现在下面这四个方面：

• 低延迟的读写速度：应用快速地反应能极大地提升用户的满意度;
• 支撑海量的数据和流量：对于搜索这样大型应用而言，需要利用PB级别的数据和能应对百万级的流量;
• 大规模集群的管理：系统管理员希望分布式应用能更简单的部署和管理;
• 庞大运营成本的考量：IT经理们希望在硬件成本、软件成本和人力成本能够有大幅度地降低;

SQL 与 NOSQL 的优缺点

SQL优点

• 事务处理—保持数据的一致性；
• 由于以标准化为前提，数据更新的开销很小（相同的字段基本上只有一处）；
• 可以进行Join等复杂查询。

SQL缺点

• 扩展困难：由于存在类似Join这样多表查询机制，使得数据库在扩展方面很艰难;
• 读写慢：这种情况主要发生在数据量达到一定规模时由于关系型数据库的系统逻辑非常复杂，使得其非常容易发生死锁等的并发问题，所以导致其读写速度下滑非常严重;
• 成本高：企业级数据库的License价格很惊人，并且随着系统的规模，而不断上升;
• 有限的支撑容量：现有关系型解决方案还无法支撑Google这样海量的数据存储;

NoSql优点

• 易扩展 : NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。
• 大数据量，高性能 : NoSQL 数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的 Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。
• 灵活的数据模型 : NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。这点在大数据量的web2.0时代尤其明显。
• 高可用 : NoSQL在不太影响性能的情况，就可以方便的实现高可用的架构。比如Cassandra，HBase模型，通过复制模型也能实现高可用。

NoSql缺点

• 不提供对SQL的支持：如果不支持SQL这样的工业标准，将会对用户产生一定的学习和应用迁移成本;
• 支持的特性不够丰富：现有产品所提供的功能都比较有限，大多数NoSQL数据库都不支持事务，也不像MS SQL Server和Oracle那样能提供各种附加功能，比如BI和报表等;
• 现有产品的不够成熟：大多数产品都还处于初创期，和关系型数据库几十年的完善不可同日而语;

Nosql的应用场景

NoSQL作为镜像

这种架构在原有基于MySQL数据库的架构上增加了一层辅助的NoSQL存储，代码量不大，技术难度小，却在可扩展性和性能上起到了非常大的作用。只需要程序在写入MySQL数据库后，同时写入到NoSQL数据库，让MySQL和NoSQL拥有相同的镜像数据，在某些可以根据主键查询的地方，使用高效的NoSQL数据库查询，这样就节省了MySQL的查询，用NoSQL的高性能来抵挡这些查询。

NoSQL为镜像（同步模式）

这种不通过程序代码，而是通过MySQL把数据同步到NoSQL中，这种模式是上面一种的变体，是一种对写入透明但是具有更高技术难度一种模式。这种模式适用于现有的比较复杂的老系统，通过修改代码不易实现，可能引起新的问题。同时也适用于需要把数据同步到多种类型的存储中。

MySQL和NoSQL组合

MySQL中只存储需要查询的小字段，NoSQL存储所有数据。这种架构模式把MySQL和NoSQL的作用进行了融合，各司其职，让MySQL专门负责处理擅长的关系存储，NoSQL作为数据的存储。简单的说，就是在mysql中存储1对多/多对多的映射关系，然后根据关系查询出主键，再查nosql。或者在nosql直接维护映射关系，实现范围查询。它有以下优点：

• 节省MySQL的IO开销。由于MySQL只存储需要查询的小字段，不再负责存储大文本字段，这样就可以节省MySQL存储的空间开销，从而节省MySQL的磁盘IO。我们曾经通过这种优化，把MySQL一个40G的表缩减到几百M。
• 提高MySQl Query Cache缓存命中率。我们知道query cache缓存失效是表级的，在MySQL表一旦被更新就会失效，经过这种字段的分离，更新的字段如果不是存储在MySQL中，那么对query cache就没有任何影响。而NoSQL的Cache往往都是行级别的，只对更新的记录的缓存失效。
• 提升MySQL主从同步效率。由于MySQL存储空间的减小，同步的数据记录也减小了，而部分数据的更新落在NoSQL而不是MySQL，这样也减少了MySQL数据需要同步的次数。
• 提高MySQL数据备份和恢复的速度。由于MySQL数据库存储的数据的减小，很容易看到数据备份和恢复的速度也将极大的提高。

纯NoSQL架构

在一些数据库结构经常变化，数据结构不定的系统中，就非常适合使用NoSQL来存储。比如监控系统中的监控信息的存储，可能每种类型的监控信息都不太一样。这样可以避免经常对MySQL进行表结构调整，增加字段带来的性能问题。
这种架构的缺点就是数据直接存储在NoSQL中，不能做关系数据库的复杂查询，如果由于需求变更，需要进行某些查询，可能无法满足，所以采用这种架构的时候需要确认未来是否会进行复杂关系查询以及如何应对。

以NoSQL为数据源的架构

纯NoSQL的架构虽然结构简单，易于开发，但是在应付需求的变更、稳定性和可靠性上，总是给开发人员一种风险难于控制的感觉。为了降低风险，系统的功能不局限在NoSQL的简单功能上，我们可以使用以NoSQL为数据源的架构。
在这种架构中，应用程序只负责把数据直接写入到NoSQL数据库就OK，然后通过NoSQL的复制协议，把NoSQL数据的每次写入，更新，删除操作都复制到MySQL数据库中。同 时，也可以通过复制协议把数据同步复制到全文检索实现强大的检索功能。在海量数据下面，我们也可以根据不同的规则，把数据同步复制到设计好的分表分库的 MySQL中。这种架构：

• 非常灵活。可以非常方便的在线上系统运行过程中进行数据的调整，比如调整分库分表的规则、要添加一种新的存储类型等等。
• 操作简单。只需要写入NoSQL数据库源，应用程序就不用管了。需要增加存储类型或者调整存储规则的时候，只需要增加同步的数据存储，调整同步规则即可，无需更改应用程序的代码。
• 性能高。数据的写入和更新直接操作NoSQL，实现了写的高性能。而通过同步协议，把数据复制到各种适合查询类型的存储中（按照业务逻辑区分不同的存储），能实现查询的高性能，不像以前MySQL一种数据库就全包了。或者就一个表负责跟这个表相关的所有的查询，现在可以把一个表的数据复制到各种存储，让各种存储用自己的长处来对外服务。
• 易扩展。开发人员只需要关心写入NoSQL数据库。数据的扩展可以方便的在后端由复制协议根据规则来完成。

NoSQL 数据库分类

类型 部分代表 特点 列存储 Hbase
Cassandra
Hypertable 顾名思义，是按列存储数据的。最大的特点是方便存储结构化和半结构化数据，方便做数据压缩，对针对某一列或者某几列的查询有非常大的IO优势。 文档存储 MongoDB
CouchDB 文档存储一般用类似json的格式存储，存储的内容是文档型的。这样也就有有机会对某些字段建立索引，实现关系数据库的某些功能。 key-value存储 Tokyo
Cabinet / Tyrant
Berkeley DB
MemcacheDB
Redis 可以通过key快速查询到其value。一般来说，存储不管value的格式，照单全收。（Redis包含了其他功能） 图存储 Neo4J
FlockDB 图形关系的最佳存储。使用传统关系数据库来解决的话性能低下，而且设计使用不方便。 对象存储 db4o
Versant 通过类似面向对象语言的语法操作数据库，通过对象的方式存取数据。

键值(Key-Value)存储数据库

这一类数据库主要会使用到一个哈希表，这个表中有一个特定的键和一个指针指向特定的数据。Key/value模型对于IT系统来说的优势在于简单、易部署。但是如果DBA只对部分值进行查询或更新的时候，Key/value就显得效率低下了。

列存储数据库

这部分数据库通常是用来应对分布式存储的海量数据。键仍然存在，但是它们的特点是指向了多个列。这些列是由列家族来安排的。

文档型数据库

文档型数据库的灵感是来自于Lotus Notes办公软件的，而且它同第一种键值存储相类似。该类型的数据模型是版本化的文档，半结构化的文档以特定的格式存储，比如JSON。文档型数据库可 以看作是键值数据库的升级版，允许之间嵌套键值。而且文档型数据库比键值数据库的查询效率更高。

图形(Graph)数据库

图形结构的数据库同其他行列以及刚性结构的SQL数据库不同，它是使用灵活的图形模型，并且能够扩展到多个服务器上。NoSQL数据库没有标准的查询语言(SQL)，因此进行数据库查询需要制定数据模型。许多NoSQL数据库都有REST式的数据接口或者查询API。

8 种 NoSQL 数据库系统对比

名称 特性 场景 例如 CouchDB -所用语言： Erlang
-特点：DB一致性，易于使用
-使用许可： Apache
-协议：HTTP/REST
- 双向数据复制
- 持续进行或临时处理
-处理时带冲突检查因此，采用的是master-master复制
-MVCC – 写操作不阻塞读操作
-可保存文件之前的版本
-Crash-only（可靠的）设计
-需要不时地进行数据压缩
-视图：嵌入式 映射/减少
-格式化视图：列表显示
-支持进行服务器端文档验证
-支持认证
-根据变化实时更新
-支持附件处理因此， CouchApps（独立的 js应用程序）
-需要 jQuery程序库 适用于数据变化较少，
执行预定义查询，进
行数据统计的应用程序。
适用于需要提供数据版本
支持的应用程序。 CRM、CMS系统。
master-master复制
对于多站点部署是
非常有用的。 Redis -所用语言：C/C++
-特点：运行异常快
-使用许可： BSD
-协议：类 Telnet
-有硬盘存储支持的内存数据库,但自2.0版本以后可以将数据交换到硬盘（注意， 2.4以后版本不支持该特性！）
-Master-slave复制
-虽然采用简单数据或以键值索引的哈希表，但也支持复杂操作，例如 ZREVRANGEBYSCORE。
-INCR & co （适合计算极限值或统计数据）
-支持 sets（同时也支持 union/diff/inter）
-支持列表（同时也支持队列；阻塞式 pop操作）
-支持哈希表（带有多个域的对象）
-支持排序 sets（高得分表，适用于范围查询）
-Redis支持事务
-支持将数据设置成过期数据（类似快速缓冲区设计）
-Pub/Sub允许用户实现消息机制 适用于数据变化快且
数据库大小可遇见
（适合内存容量）
的应用程序。 股票价格、
数据分析、
实时数据搜集、
实时通讯。 MongoDB -所用语言：C++
-特点：保留了SQL一些友好的特性（查询，索引）。
-使用许可： AGPL（发起者： Apache）协议： Custom, binary（ BSON）
-Master/slave复制（支持自动错误恢复，使用 sets 复制）
-内建分片机制
-支持 javascript表达式查询
-可在服务器端执行任意的 javascript函数
-update-in-place支持比CouchDB更好
-在数据存储时采用内存到文件映射
-对性能的关注超过对功能的要求
-建议最好打开日志功能（参数 –journal）
-在32位操作系统上，数据库大小限制在约2.5Gb
-空数据库大约占 192Mb
-采用 GridFS存储大数据或元数据（不是真正的文件系统） 适用于需要动态查询支持；
需要使用索引而不是 map/reduce功能；
需要对大数据库有性能要求；
需要使用 CouchDB,
但因为数据改变太频繁而占满内存的应用程序。 你本打算采用
MySQL或
PostgreSQL，
但因为它们本身
自带的预定义栏
让你望而却步。 Riak -所用语言：Erlang和C，以及一些Javascript
-特点：具备容错能力
-使用许可： Apache协议： HTTP/REST或者 custom binary
-可调节的分发及复制(N, R, W)
-用 JavaScript or Erlang在操作前或操作后进行验证和安全支持。
-使用JavaScript或Erlang进行 Map/reduce
-连接及连接遍历：可作为图形数据库使用
-索引：输入元数据进行搜索（1.0版本即将支持）
-大数据对象支持（ Luwak）
-提供“开源”和“企业”两个版本
-全文本搜索，索引，通过 Riak搜索服务器查询（ beta版）
-支持Masterless多站点复制及商业许可的 SNMP监控 适用于想使用类似
Cassandra（类似
Dynamo）数据库
但无法处理 bloat
及复杂性的情况。
适用于你打算做多
站点复制，但又需
要对单个站点的
扩展性，可用性
及出错处理有要求的情况。 销售数据搜集，
工厂控制系统；
对宕机时间有严格要求；
可以作为易于更新
的 web服务器使用。 Membase -所用语言： Erlang和C
-特点：兼容 Memcache，但同时兼具持久化和支持集群
-使用许可： Apache 2.0
-协议：分布式缓存及扩展
-非常快速（200k+/秒），通过键值索引数据
-可持久化存储到硬盘
-所有节点都是唯一的（ master-master复制）
-在内存中同样支持类似分布式缓存的缓存单元
-写数据时通过去除重复数据来减少 IO
-提供非常好的集群管理 web界面
-更新软件时软无需停止数据库服务
-支持连接池和多路复用的连接代理 适用于需要低延迟数据访问，
高并发支持以及高可用性的
应用程序 低延迟数据访问,
比如以广告为
目标的应用，
高并发的 web 应用.
比如网络游戏
（例如 Zynga） Neo4j -所用语言： Java
-特点：基于关系的图形数据库
-使用许可： GPL，其中一些特性使用 AGPL/商业许可
-协议： HTTP/REST（或嵌入在 Java中）
-可独立使用或嵌入到 Java应用程序
-图形的节点和边都可以带有元数据
-很好的自带web管理功能
-使用多种算法支持路径搜索
-使用键值和关系进行索引
-为读操作进行优化
-支持事务（用 Java api）
-使用 Gremlin图形遍历语言
-支持 Groovy脚本
-支持在线备份，高级监控及高可靠性支持使用 AGPL/商业许可 适用于图形一类数据。
这是 Neo4j与其他nosql
数据库的最显著区别 社会关系，
公共交通网络，
地图及网络拓谱 Cassandra -所用语言： Java
-特点：对大型表格和 Dynamo支持得最好
-使用许可： Apache
-协议： Custom, binary (节约型)
-可调节的分发及复制(N, R, W)
-支持以某个范围的键值通过列查询
-类似大表格的功能：列，某个特性的列集合
-写操作比读操作更快
-基于 Apache分布式平台尽可能地 Map/reduce
-本身的臃肿和复杂性，也因为 Java的问题（配置，出现异常，等等） 当使用写操作多过读操作
（记录日志）.如果每个
系统组建都必须用 Java编写 银行业，金融业
（虽然对于金融
交易不是必须的，
但这些产业对
数据库的要求会
比它们更大）写
比读更快，所以
一个自然的特性
就是实时数据分析 HBase -所用语言： Java
-特点：支持数十亿行X上百万列
-使用许可： Apache
-协议：HTTP/REST （支持 Thrift，见编注4）
-在 BigTable之后建模
-采用分布式架构 Map/reduce
-对实时查询进行优化
-高性能 Thrift网关
-通过在server端扫描及过滤实现对查询操作预判
-支持 XML, Protobuf, 和binary的HTTP
-Cascading, hive, and pig source and sink modules
-基于 Jruby（ JIRB）的shell
-对配置改变和较小的升级都会重新回滚
-不会出现单点故障
-堪比MySQL的随机访问性能 需要对大数据进行随机、实时访问的场合。 Facebook消息
数据库（更多通用的用例即将出现）

参考资料

• NOSQL数据库 : http://www.oschina.net/project/tag/235/nosql
• NoSQL专题讲座 : https://wenku.baidu.com/view/38446b51bed5b9f3f90f1caa.html
• 主流 NoSQL 数据库的对比 : http://blog.jobbole.com/100934/