程序员修神之路--用NOSql给高并发系统加速（送书）

随着互联网大潮的到来，愈来愈多网站，应用系统须要海量数据的支撑，高并发、低延迟、高可用、高扩展等要求在传统的关系型数据库中已经得不到知足，或者说关系型数据库应对这些需求已经显得力不从心了。关系型数据库通过几十年的发展已经很成熟，强大的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数据库都不是银弹，每一种事物都有它最善长的领域。设计一个好的系统，须要综合考虑各类因素，根据具体的业务场景来选择最合适的解决方案。

领取福利

记得微信扫码识别，领取技术书籍哦