你是否在为系统的数据库来一波大流量就险些打满CPU，日常CPU居高不下烦恼？你是否在各种NoSql间纠结不定，到底该选用那种最好？本日的你便是昨天的我，这也是写这篇文章的初衷。
这篇文章是我好几个月来一贯想写的一篇文章，也是一贯想学习的一个内容，作为互联网从业职员，我们要知道关系型数据库（MySql、Oracle）无法知足我们对存储的所有哀求，因此对底层存储的选型，对每种存储引擎的理解非常主要。同时也由于过去一段韶光的事情经历，对这块有了一些更多的思考，想通过自己的总结把这块写出来分享给大家。
构造化数据、非构造化数据与半构造化数据
文章的开始，聊一下构造化数据、非构造化数据与半构造化数据，由于数据特点的不同，将在技能上直接影响存储引擎的选型。
首先是构造化数据，根据定义构造化数据指的是由二维表构造来逻辑表达和实现的数据，严格遵照数据格式与长度规范，也称作为行数据，特点为：数据以行为单位，一行数据表示一个实体的信息，每一行数据的属性是相同的。例如：
因此关系型数据库完美契合构造化数据的特点，关系型数据库也是关系型数据最紧张的存储与管理引擎。
非构造化数据，指的是数据构造不规则或不完全，没有任何预定义的数据模型，未便应用二维逻辑表来表现的数据，例如办公函档（Word）、文本、图片、HTML、各种报表、视频音频等。
介于构造化与非构造化数据之间的数据便是半构造化数据了，它是构造化数据的一种形式，虽然不符合二维逻辑这种数据模型构造，但是包含干系标记，用来分割语义元素以及对记录和字段进行分层。常见的半构造化数据有XML和JSON，例如：
<person> <name>张三</name> <age>18</age> <phone>12345</phone></person>
这种构造也被成为自描述的构造。
以关系型数据库的办法做存储的架构演进
首先，我们看一下利用关系型数据库的办法，企业一个别系发展的几个阶段的架构演进（由于本文写的是Sql与NoSql，因此只以存储办法作为切入点，不会涉及类似MQ、ZK这些中间件内容）：
阶段一：企业刚发展的阶段，最大略，一个运用做事器配一个关系型数据库，每次读写数据库。
阶段二：无论是利用MySQL还是Oracle还是别的关系型数据库，数据库常日不会先成为性能瓶颈，常日随着企业规模的扩大，一台运用做事器扛不住上游过来的流量且一台运用做事器会产生单点故障的问题，因此加运用做事器并且在流量入口利用Nginx做一层负载均衡，担保把流量均匀打到运用做事器上。
阶段三：随着企业规模的连续扩大，此时由于读写都在同一个数据库上，数据库性能涌现一定的瓶颈，此时大略地做一层读写分离，每次写主库，读备库，主备库之间通过binlog同步数据，就能很大程度上办理这个阶段的数据库性能问题
阶段四：企业发展越来越好了，业务越来越大了，做了读写分离数据库压力还是越来越大，这时候怎么办呢，一台数据库扛不住，那我们就分几台吧，做分库分表，对表做垂直拆分，对库做水平拆分。以扩数据库为例，扩出两台数据库，以一定的单号（例如交易单号），以一定的规则（例如取模），交易单号对2取模为0的丢到数据库1去，交易单号对2取模为1的丢到数据库2去，通过这样的办法将写数据库的流量均分到两台数据库上。一样平常分库分表会利用Shard的办法，通过一个中间件，便于连接管理、数据监控且客户端无需感知数据库ip
关系型数据库的优点
上面的办法，看似可以办理问题（实际上确实也能办理很多问题），正常对关系型数据库做一下读写分离 + 分库分表，支撑个1W+的读写QPS还是问题不大的。但是受限于关系型数据库本身，这套架构方案依然有着明显的不敷，下面对利用关系型数据库办法做存储的方案的优点前辈行一下剖析，后一部分再剖析一下缺陷，对某个技能的优缺陷的充分理解是技能选型的条件。
易理解由于行 + 列的二维表逻辑是非常贴近逻辑天下的一个观点，关系模型相对网状、层次等其他模型更加随意马虎被理解 操作方便通用的SQL措辞使得操作关系型数据库非常方便，支持join等繁芜查询数据同等性支持ACID特性，可以掩护数据之间的同等性，这是利用数据库非常主要的一个情由之一，例犹如银行转账，张三转给李四100元钱，张三扣100元，李四加100元，而且必须同时成功或者同时失落败，否则就会造成用户的资损数据稳定数据持久化到磁盘，没有丢失数据风险，支持海量数据存储做事稳定最常用的关系型数据库产品MySql、Oracle做事器性能卓越，做事稳定，常日很少涌现宕机非常关系型数据库的缺陷
紧接着的，我们看一下关系型数据库的缺陷，也是比较明显的。
高并发下IO压力大数据按行存储，纵然只针对个中某一列进走运算，也会将整行数据从存储设备中读入内存，导致IO较高为掩护索引付出的代价大为了供应丰富的查询能力，常日热点表都会有多个二级索引，一旦有了二级索引，数据的新增一定伴随着所有二级索引的新增，数据的更新也一定伴随着所有二级索引的更新，这不可避免地降落了关系型数据库的读写能力，且索引越多读写能力越差。有机会的话可以看一下自己公司的数据库，除了数据文件不可避免地占空间外，索引占的空间实在也并不少为掩护数据同等性付出的代价大数据同等性是关系型数据库的核心，但是同样为了掩护数据同等性的代价也是非常大的。我们都知道SQL标准为事务定义了不同的隔离级别，从低到高依次是读未提交、读已提交、可重复度、串行化，事务隔离级别月尾，可能涌现的并发非常越多，但是常日而言能供应的并发能力越强。那么为了担保事务同等性，数据库就须要供应并发掌握与故障规复两种技能，前者用于减少并发非常，后者可以在系统非常的时候担保事务与数据库状态不会被毁坏。对付并发掌握，其核心思想便是加锁，无论是乐不雅观锁还是悲观锁，只要供应的隔离级别越高，那么读写性能一定越差水平扩展后带来的各类问题难处理前文提过，随着企业规模扩大，一种办法是对数据库做分库，做了分库之后，数据迁移（1个库的数据按照一定规则打到2个库中）、跨库join（订单数据里有用户数据，两条数据不在同一个库中）、分布式事务处理都是须要考虑的问题，尤其是分布式事务处理，业界当前都没有特殊好的办理方案表构造扩展未便利由于数据库存储的是构造化数据，因此表构造schema是固定的，扩展未便利，如果须要修正表构造，须要实行DDL（data definition language）语句修正，修正期间会导致锁表，部分做事不可用全文搜索功能弱例如like \公众%中国真伟大%\"大众，只能搜索到\"大众2019年中国真伟大，爱祖国\"大众，无法搜索到\"大众中国真是太伟大了\公众这样的文本，即不具备分词能力，且like查询在\"大众%中国真伟大\"大众这样的搜索条件下，无法命中索引，将会导致查询效率大大降落写了这么多，我的理解核心还是前三点，它反响出的一个问题是关系型数据库在高并发下的能力是有瓶颈的，尤其是写入/更新频繁的情形下，涌现瓶颈的结果便是数据库CPU高、Sql实行慢、客户端报数据库连接池不足等缺点，因此例如万人秒杀这种场景，我们绝对不可能通过数据库直接去扣减库存。
可能有朋友说，数据库在高并发下的能力有瓶颈，我公司有钱，加CPU、换固态硬盘、连续大班事器加数据库做分库不就好了，问题是这是一种性价比非常低的办法，花1000万达到的效果，换其他办法可能100万就达到了，不考虑职员、做事器投入产出比的Leader便是个不合格的Leader，且关系型数据库的办法，受限于它本身的特点，可能花了钱都未必能达到想要的效果。至于什么是花100万就能达到花1000万效果的办法呢？可以连续往下看，这便是我们要说的NoSql。
结合NoSql的办法做存储的架构演进
像上文剖析的，数据库作为一种关系型数据的存储引擎，存储的是关系型数据，它有优点，同时也有明显的缺陷，因此常日在企业规模不断扩大的情形下，不会一味指望通过增强数据库的能力来办理数据存储问题，而是会引入其他存储，也便是我们说的NoSql。
NoSql的全称为Not Only SQL，泛指非关系型数据库，是对关系型数据库的一种补充，特殊把稳补充这两个字，这意味着NoSql与关系型数据库并不是对立关系，二者各有利害，取长补短，在得当的场景下选择得当的存储引擎才是精确的做法。
比较大略的NoSql便是缓存：
针对那些读远多于写的数据，引入一层缓存，每次读从缓存中读取，缓存中读取不到，再去数据库中取，取完之后再写入到缓存，对数据做好失落效机制常日就没有大问题了。常日来说，缓存是性能优化的第一选择也是见效最明显的方案。
但是，缓存常日都是KV型存储且容量有限（基于内存），无法办理所有问题，于是再进一步的优化，我们连续引入其他NoSql：
数据库、缓存与其他NoSql并行事情，充分发挥每种NoSql的特点。当然NoSql在性能方面大大优于关系挺数据库的同时，每每也伴随着一些特性的缺失落，比较常见的便是事务功能的缺失落。
下面看一下常用的NoSql及他们的代表产品，并对每种NoSql的优缺陷和适用场景做一下剖析，便于熟习每种NoSql的特点，方便技能选型。
KV型NoSql（代表----Redis）
KV型NoSql顾名思义便是以键值对形式存储的非关系型数据库，是最大略、最随意马虎理解也是大家最熟习的一种NoSql，因此比较快地带过。Redis、MemCache是个中的代表，Redis又是KV型NoSql中运用最广泛的NoSql，KV型数据库以Redis为例，最大的优点我总结下来就两点：
数据基于内存，读写效率高KV型数据，韶光繁芜度为O(1)，查询速率快因此，KV型NoSql最大的优点便是高性能，利用Redis自带的BenchMark做基准测试，TPS可达到10万的级别，性能非常强劲。同样的Redis也有所有KV型NoSql都有的比较明显的缺陷：
只能根据K查V，无法根据V查K查询办法单一，只有KV的办法，不支持条件查询，多条件查询唯一的做法便是数据冗余，但这会极大的摧残浪费蹂躏存储空间内存是有限的，无法支持海量数据存储同样的，由于KV型NoSql的存储是基于内存的，会有丢失数据的风险综上所述，KV型NoSql最得当的场景便是缓存的场景：
读远多于写读取能力强没有持久化的需求，可以容忍数据丢失，反正丢了再查询一把写入便是了例如根据用户id查询用户信息，每次根据用户id去缓存中查询一把，查到数据直接返回，查不到去关系型数据库里面根据id查询一把数据写到缓存中去。
搜索型NoSql（代表----ElasticSearch）
传统关系型数据库紧张通过索引来达到快速查询的目的，但是在全文搜索的场景下，索引是无能为力的，like查询一来无法知足所有模糊匹配需求，二来利用限定太大且利用不当随意马虎造成慢查询，搜索型NoSql的出身正是为理解决关系型数据库全文搜索能力较弱的问题，ElasticSearch是搜索型NoSql的代表产品。
全文搜索的事理是倒排索引，我们看一下什么是倒排索引。要说倒排索引我们先看下什么是正排索引，传统的正排索引是文档-->关键字的映射，例如\"大众Tom is my friend\公众这句话，会将其切分为\公众Tom\"大众、\"大众is\公众、\"大众my\公众、\公众friend\"大众四个单词，在搜索的时候对文档进行扫描，符合条件的查出来。这种办法事理非常大略，但是由于其检索效率太低，基本没什么实用代价。
倒排索引则完备相反，它是关键字-->文档的映射，我用张表格展示一下就比较清楚了：
意思是我现在这里有\公众Tom is Tom\"大众、\"大众Tom is my friend\"大众、\"大众Thank you, Betty\"大众、\"大众Tom is Betty's husband\公众四句话，搜索引擎会根据一定的切分规则将这句话切成N个关键字，并以关键字的维度掩护关键字在每个文本中的涌现次数。这样下次搜索\"大众Tom\"大众的时候，由于Tom这个词语在\公众Tom is Tom\公众、\"大众Tom is my friend\"大众、\"大众Tom is Betty's husband\"大众三句话中都有涌现，因此这三条记录都会被检索出来，且由于\"大众Tom is Tom\公众这句话中\"大众Tom\公众涌现了2次，因此这条记录对\"大众Tom\公众这个单词的匹配度最高，最先展示。这便是搜索引擎倒排索引的基本事理，假设某个关键字在某个文档中涌现，那么倒排索引中有两部分内容：
文档ID在该文档中涌现的位置情形可以举一反三，我们搜索\"大众Betty Tom\"大众这两个词语也是一样，搜索引擎将\"大众Betty Tom\公众切分为\"大众Tom\"大众、\"大众Betty\"大众两个单词，根据开拓者指定的知足率，比如知足率=50%，那么只要记录中涌现了两个单词之一的记录都会被检索出来，再按照匹配度进行展示。
搜索型NoSql以ElasticSearch为例，它的优点为：
支持分词场景、全文搜索，这是差异于关系型数据库最大特点支持条件查询，支持聚合操作，类似关系型数据库的Group By，但是功能更加强大，适宜做数据剖析数据写文件无丢失风险，在集议论况下可以方便横向扩展，可承载PB级别的数据高可用，自动创造新的或者失落败的节点，重组和重新平衡数据，确保数据是安全和可访问的同样，ElasticSearch也有比较明显的缺陷：
性能全靠内存来顶，也是利用的时候最须要把稳的点，非常吃硬件资源、吃内存，大数据量下64G + SSD基本是标配，算得上是数据库中的爱马仕了。为什么要专门提一下内存呢，由于内存这个东西是很值钱的，相同的配置多一倍内存，一个月差不多就要多花几百块钱，至于ElasticSearch内存用在什么地方，大概有如下这些：Indexing Buffer----ElasticSearch基于Luence，Lucene的倒排索引是先在内存里天生，然后定期以Segment File的办法刷磁盘的，每个Segment File实际便是一个完全的倒排索引Segment Memory----倒排索引前面说过是基于关键字的，Lucene在4.0后会将所有关键字以FST这种数据构造的办法将所有关键字在启动的时候全量加载到内存，加快查询速率，官方建议至少留系统一半内存给Lucene各种缓存----Filter Cache、Field Cache、Indexing Cache等，用于提升查询剖析性能，例如Filter Cache用于缓存利用过的Filter的结果集Cluter State Buffer----ElasticSearch被设计为每个Node都可以响运用户要求，因此每个Node的内存中都包含有一份集群状态的拷贝，一个规模很大的集群这个状态信息可能会非常大读写之间有延迟，写入的数据差不多1s样子会被读取到，这也正常，写入的时候自动加入这么多索引肯定影响性能数据构造灵巧性不高，ElasticSearch这个东西，字段一旦建立就没法修正类型了，如果建立的数据表某个字段没有加全文索引，想加上，那么只能把全体表删了再重修因此，搜索型NoSql最适用的场景便是有条件搜索尤其是全文搜索的场景，作为关系型数据库的一种替代方案。
其余，搜索型数据库还有一种特殊主要的运用处景。我们可以想，一旦对数据库做了分库分表后，原来可以在单表中做的聚合操作、统计操作是否统统失落效？例如我把订单表分16个库，1024张表，那么订单数据就散落在1024张表中，我想要统计昨天浙江省单笔成交金额最高的订单是哪笔如何做？我想要把昨天的所有订单按照韶光排序分页展示如何做？这便是文档型NoSql的另一大浸染了，我们可以把分表之后的数据统一打在文档型NoSql中，利用文档型NoSql的搜索与聚合能力完成对全量数据的查询。
至于为什么把它放在KV型NoSql后面作为第二个写呢，由于常日搜索型NoSql也会作为一层前置缓存，来对关系型数据库进行保护。
列式NoSql（代表----HBase）
列式NoSql，大数据时期最具代表性的技能之一了，以HBase为代表。
列式NoSql是基于列式存储的，那么什么是列式存储呢，列式Sql和关系型数据库一样都有主键的观点，差异在于关系型数据库是按照行组织的数据：
看到每行有name、phone、address三个字段，这是行式存储的办法，且可以不雅观察id = 2的这条数据，纵然phone字段没有，它也是占空间的。
列式存储完备是另一种办法，它是按每一列进行组织的数据：
这么做有什么好处呢？大致有以下几点：
查询时只有指定的列会被读取，不会读取所有列存储上节约空间，Null值不会被存储，一列中有时候会有很多重复数据（尤其是列举数据，性别、状态等），这类数据可压缩，行式数据库压缩率常日在3:1~5:1之间，列式数据库的压缩率一样平常在8:1~30:1旁边列数据被组织到一起，一次磁盘IO可以将一列数据一次性读取到内存中第二点说到了数据压缩，什么意思呢，以比较常见的字典表压缩办法举例：
仔细看图理解一下，该当就懂了。
接着连续讲讲优缺陷，列式NoSql，以HBase为代表的，优点为：
海量数据无限存储，PB级别数据随便存，底层基于HDFS（Hadoop文件系统），数据持久化读写性能好，只要没有滥用造成数据热点，读写基本随便玩横向扩展在关系型数据库及非关系型数据库中都是最方便的之一，只须要添加新机器就可以实现数据容量的线性增长，且可用在廉价做事器上，节省本钱本身没有单点故障，可用性高可存储构造化或者半构造化的数据列数理论上无限，HBase本身只对列族数量有哀求，建议1~3个说了这么多HBase的优点，又到了说HBase缺陷的时候了：HBase是Hadoop生态的一部分，因此它本身是一款比较重的产品，依赖很多Hadoop组件，数据规模不大没必要用，运维还是有点繁芜的KV式，不支持条件查询，或者说条件查询非常非常弱吧，HBase在Scan扫描一批数据的情形下还是供应了前缀匹配这种API的，条件查询除非定义多个RowKey做数据冗余不支持分页查询，由于统计不了数据总数因此HBase比较适用于那种KV型的且未来无法预估数据增长量的场景，其余HBase利用还是须要一定的履历，紧张表示在RowKey的设计上。
文档型NoSql（代表----MongoDB）
坦白讲，根据我的事情经历，文档型NoSql我只有比较浅的利用履历，因此这部分只能结合之前的利用与网上的文章大致给大家先容一下。
什么是文档型NoSql呢，文档型NoSql指的是将半构造化数据存储为文档的一种NoSql，文档型NoSql常日以JSON或者XML格式存储数据，因此文档型NoSql是没有Schema的，由于没有Schema的特性，我们可以随意地存储与读取数据，因此文档型NoSql的涌现是办理关系型数据库表构造扩展未便利的问题的。
MongoDB是文档型NoSql的代表产品，同时也是所有NoSql产品中的明星产品之一，因此这里以MongoDB为例。按我的理解，作为文档型NoSql，MongoDB是一款完备和关系型数据库对标的产品，就我们从存储上来看：
看到，关系型数据库是按部就班地每个字段一列存，在MongDB里面便是一个JSON字符串存储。关系型数据可以为name、phone建立索引，MongoDB利用createIndex命令一样可以为列建立索引，建立索引之后可以大大提升查询效率。其他方面而言，就大的基本观点，二者之间基本也是类似的：
因此，对付MongDB，我们只要理解成一个Free-Schema的关系型数据库就完事了，它的优缺陷比较一览无余，优点：
没有预定义的字段，扩展字段随意马虎相较于关系型数据库，读写性能优胜，命中二级索引的查询不会比关系型数据库慢，对付非索引字段的查询则是全面胜出缺陷在于：
不支持事务操作，虽然Mongodb4.0之后流传宣传支持事务，但是效果待不雅观测多表之间的关联查询不支持（虽然有嵌入文档的办法），join查询还是须要多次操作空间占用较大，这个是MongDB的设计问题，空间预分配机制 + 删除数据后空间不开释，只有用db.repairDatabase()去修复才能开释目前没创造MongoDB有关系型数据库例如MySql的Navicat这种成熟的运维工具总而言之，MongDB的利用场景很大程度上可以对标关系型数据库，但是比较适宜处理那些没有join、没有强同等性哀求且表Schema会常变革的数据。
总结：数据库与NoSql及各种NoSql间的比拟
末了一部分，做一个总结，本文归根到底是两个话题：
何时选用关系型数据库，何时选用非关系型数据库选用非关系型数据库，利用哪种非关系型数据库首先是第一个话题，关系型数据库与非关系型数据库的选择，在我理解里面无非便是两点考虑：
第一点，不多阐明该当都理解，非关系型数据库都是通过捐躯了ACID特性来获取更高的性能的，假设两张表之间有比较强的同等性需求，那么这类数据是不适宜放在非关系型数据库中的。
第二点，核心数据不走非关系型数据库，例如用户表、订单表，但是这有一个条件，便是这一类核心数据会有多种查询模式，例如用户表有ABCD四个字段，可能根据AB查，可能根据AC查，可能根据D查，假设核心数据，但是便是个KV形式，比如用户的谈天记录，那么HBase一存就完事了。
这几年的事情履历来看，非核心数据尤其这天记、流水一类中间数据千万不要写在关系型数据库中，这一类数据常日有两个特点：
写远高于读写入量巨大一旦利用关系型数据库作为存储引擎，将大大降落关系型数据库的能力，正常读写QPS不高的核心做事会受这一类数据读写的拖累。
接着是第二个问题，如果我们利用非关系型数据库作为存储引擎，那么如何选型？实在上面的文章基本都写了，这里只是做一个总结（所有的缺陷都不会表示事务这个点，由于这是所有NoSql比较关系型数据库共有的一个问题）：
但是这里特殊解释，选型一定要结合实际情形而不是照本宣科，比如：
企业发展之初，明明一个关系型数据库就能搞定且支撑一年的架构，搞一套大而全的技能方案出来有一些数据条件查询多，更适宜利用ElasticSearch做存储降落关系型数据库压力，但是公司本钱有限，这种情形下这类数据可以考试测验连续利用关系型数据库做存储有一类数据格式大略，便是个KV类型且增长量大，但是公司没有HBase这方面的人才，运维上可能会有一定难度，出于实际情形考虑，可先用关系型数据库顶一阵子以是，如果不考虑实际情形，虽然得当有些存储引擎更加得当，但是强行利用反而揠苗助长，总而言之，适宜自己的才是最好的。
