共计 2896 个字符，预计需要花费 8 分钟才能阅读完成。
随着互联网大潮的到来，越来越多网站，利用零碎须要海量数据的撑持，高并发、低提早、高可用、高扩大等要求在传统的关系型数据库中曾经得不到满足，或者说关系型数据库应答这些需要曾经显得力不从心了。关系型数据库通过几十年的倒退曾经很成熟，弱小的 sql 语句反对，完满的 ACID 属性的反对，使得关系型数据库广泛应用于各种各样的利用零碎中，然而利用的场景宽泛并非意味着完满
- 因为关系型数据库是按行进行存储的，在某些只统计一列的需要场景下，也须要把整行读入内存，导致了一个小小的统计需要高 IO 的毛病
- 关系型数据库无奈存储数据结构，比方：一个商品能够从属于多个分类，业务上的从属关系体现到存储上是一个列表而已，然而关系型数据库须要把这些关系存储为多行，无奈间接存储为一个列表。
- 关系型数据库中的存储单位表的架构是强束缚，操作不存在的列会报出异样，而且增加、更新、删除列必须执行 DDL 语句，如果表的现存数据量比拟大，会呈现长时间锁表的景象。
- 关系型数据库全文搜寻性能一般比拟弱，用 like 去匹配关键词的时候，数据量比拟大的状况下会呈现慢查问的景象。
- 关系型数据库基于表格的关系模型使得很难增加新的或不同品种的关联信息。
因为以上这些诸多问题，便诞生了以“NOSQL”为口号的很多解决方案。在某些关系型数据库不善于的畛域，Nosql 体现的很杰出。入地是偏心的，给你关上了一扇窗户，必会给你关上半扇门，NoSql 是以就义 ACID 某个或者某些个性为代价的。
NoSQL 并不是银弹，更多的时候是关系型数据库一个无力补充，或者是特定场景下优于关系型数据库的一种解决方案
NoSQL
NoSQL，泛指非关系型的数据库。当初大家更喜爱翻译成：not only sql
依据 NoSQL 的存储等个性，大体能够分为以下几类
- 键值 (Key-Value) 存储数据库。相干的产品：Redis、Riak、SimpleDB、Chordless、Scalaris、Memcached。次要解决关系数据库无奈存储数据结构的问题。
- 列存储数据库。相干产品：BigTable、HBase、Cassandra、HadoopDB、GreenPlum、PNUTS。解决关系数据库大数据场景下的 I/O 问题
- 文档数据库。相干产品：MongoDB、CouchDB、ThruDB、CloudKit、Perservere、Jackrabbit。解决关系数据库强 schema 束缚的问题。
- 图形数据库。相干产品：Neo4J、OrientDB、InfoGrid、GraphDB。次要解决大量简单、互连贯、低结构化的图构造场合，如社交网络、举荐零碎等
- 全文搜索引擎。相干产品：Elasticsearch。次要解决关系数据库的全文搜寻性能问题。
由此可见，没有哪一种 NoSql 是完满的，每一种 Nosql 都有本人善于的畛域，这也是咱们做零碎架构中要思考的重要因素。
场景 1
电商的商品设计过程中，每种商品的属性都不同，属性数目不同，属性名不同，同一个商品有可能会属于多个分类，而且随着业务的倒退，很多商品会减少新的属性，而且最令程序员头疼莫过于每种属性都有可能有搜寻的可能性（当然搜寻能够利用搜索引擎来实现）。遇到这样的需要场景，如果利用关系型数据库来存储的话，表的字段会十分多，而且字段的定义十分令人头疼。
这样的场景非常适合 NOsql 中的文档型数据库，比方 MongoDB。文档型数据库新增字段非常简单，不像关系型数据库须要先执行 DDL 来减少字段，间接能够利用程序来进行读写，历史数据就算是没有相应的字段也不会有异样的状况产生。最重要的一点，文档型数据库很善于存储简单构造的数据，个别状况下业务上能够利用体现能力很强的 json 数据结构。
{
"Id":1,
"ProductName":"杜蕾斯加强版",
"Price":100,
"Type":[
1,
2,
4
],
"Length":20,
"Height":2
}如果所有商品信息都用 mongodb 来存储的话，有的场景并不是非常完满。比方商品被胜利购买之后扣库存的问题，联结查问的问题，因为 Nosql 天生对 ACID 反对有余的起因，一个事务性的操作很难在 Nosql 中实现，所以设计零碎的时候在很多状况下是关系数据库 +Nosql 来独特实现业务。
场景 2
很多具体的业务中都有记录数据而后进行统计的需要场景，比方那些统计 uv，pv 的零碎。日志型的数据量十分大，而且还有可能有峰值的呈现，如果用关系型数据库来存储，很有可能在 IO 上会呈现瓶颈，而且有可能会影响其余失常的业务，更可怜的是当执行统计语句的时候，性能更是差强人意。这样的日志型统计业务很适宜 HBase 这样的列式 Nosql，业务上要统计一天的 uv，pv 数据，HBase 很适宜统计某一列数据的场景，因为只须要把对应的列进行统计即可，不像关系型数据库那样须要把所有行都加载进内存，而且列式存储个别比行式存储领有更大的压缩比例，占用的磁盘空间会更少。
列式存储的利用场景有肯定的限度，个别用于统计和大数据的剖析中。
场景 3
在少数高并发零碎中都存在缓存的设计，而缓存的个别数据结构都是 K - V 构造。缓存是一种进步零碎性能的无效伎俩，因其须要提供快速访问的个性，个别缓存都搁置于内存当中。比方当初咱们要设计一个用户管理系统，每个用户信息能够做缓存以便提供高速的拜访，因为很多零碎都采纳分布式的部署形式，所以采纳过程内的缓存形式并不可取，这个时候就须要有一种高速的内部存储来提供这种业务，这正是 kv 型 Nosql 的典型利用场景之一。其中以 redis 为代表，具体的业务中能够以用户 id 为 key，用户的信息为 value 存储在 redis 中，而且 redis 在 3.0 之后能够做集群了，在高可用和扩大上更能助力业务方。redis 反对的数据类型很多，在不同的场景下抉择不同的数据类型。
场景 4
当一个零碎有搜寻的业务时候，如果搜寻的条件是一些简略的类型搜寻，关系型数据库还能够满足，然而如果有全文搜寻，就是咱们平时 sql 写的 like‘%xx%’这样的搜寻，关系型数据库可能并不是最好的抉择，全文搜索引擎类型的 Nosql 兴许是一个更好的解决方案，其中以 Elasticsearch 为代表。全文搜索引擎的搜寻的条件能够随便排列组合，并且能够实现关系型数据库 like 形式的含糊匹配。
全文搜索引擎的技术原理称为“倒排索引”（inverted index），是一种索引办法，其基本原理是建设单词到文档的索引。与之绝对是，是“正排索引”，其基本原理是建设文档到单词的索引。
场景 5
在社交零碎中最常见例子就是社会网络中人与人之间的关系。关系型数据库用于存储“关系型”数据的成果并不好，其查问简单、迟缓、超出预期，而图形数据库的独特设计恰好补救了这个缺点，解决关系型数据库存储和解决简单关系型数据性能较弱的问题。其中以 Neo4j 为代表。想深入研究的同学请移步百度。
无论是关系型数据库还是 nosql 数据库都不是银弹，每一种事物都有它最善长的畛域。设计一个好的零碎，须要综合思考各种因素，依据具体的业务场景来抉择最合适的解决方案。
更多精彩文章
- 分布式大并发系列
- 架构设计系列
- 趣学算法和数据结构系列
- 设计模式系列
