由于数据库存储的是结构化数据&＃xff0c;因此表结构schema是固定的&＃xff0c;扩展不方便&＃xff0c;如果需要修改表结构&＃xff0c;需要执行DDL&＃xff08;data definition language&＃xff09;语句修改&＃xff0c;修改期间会导致锁表&＃xff0c;部分服务不可用
例如like “%中国真伟大%”&＃xff0c;只能搜索到"2019年中国真伟大&＃xff0c;爱祖国"&＃xff0c;无法搜索到"中国真是太伟大了"这样的文本&＃xff0c;即不具备分词能力&＃xff0c;且like查询在"%中国真伟大"这样的搜索条件下&＃xff0c;无法命中索引&＃xff0c;将会导致查询效率大大降低
写了这么多&＃xff0c;我的理解核心还是前三点&＃xff0c;它反映出的一个问题是关系型数据库在高并发下的能力是有瓶颈的&＃xff0c;尤其是写入/更新频繁的情况下&＃xff0c;出现瓶颈的结果就是数据库CPU高、Sql执行慢、客户端报数据库连接池不够等错误&＃xff0c;因此例如万人秒杀这种场景&＃xff0c;我们绝对不可能通过数据库直接去扣减库存。
可能有朋友说&＃xff0c;数据库在高并发下的能力有瓶颈&＃xff0c;我公司有钱&＃xff0c;加CPU、换固态硬盘、继续买服务器加数据库做分库不就好了&＃xff0c;问题是这是一种性价比非常低的方式&＃xff0c;花1000万达到的效果&＃xff0c;换其他方式可能100万就达到了&＃xff0c;不考虑人员、服务器投入产出比的Leader就是个不合格的Leader&＃xff0c;且关系型数据库的方式&＃xff0c;受限于它本身的特点&＃xff0c;可能花了钱都未必能达到想要的效果。至于什么是花100万就能达到花1000万效果的方式呢&＃xff1f;可以继续往下看&＃xff0c;这就是我们要说的NoSql。
结合NoSql的方式做存储的架构演进
像上文分析的&＃xff0c;数据库作为一种关系型数据的存储引擎&＃xff0c;存储的是关系型数据&＃xff0c;它有优点&＃xff0c;同时也有明显的缺点&＃xff0c;因此通常在企业规模不断扩大的情况下&＃xff0c;不会一味指望通过增强数据库的能力来解决数据存储问题&＃xff0c;而是会引入其他存储&＃xff0c;也就是我们说的NoSql。
NoSql的全称为Not Only SQL&＃xff0c;泛指非关系型数据库&＃xff0c;是对关系型数据库的一种补充&＃xff0c;特别注意补充这两个字&＃xff0c;这意味着NoSql与关系型数据库并不是对立关系&＃xff0c;二者各有优劣&＃xff0c;取长补短&＃xff0c;在合适的场景下选择合适的存储引擎才是正确的做法。
比较简单的NoSql就是缓存&＃xff1a;
针对那些读远多于写的数据&＃xff0c;引入一层缓存&＃xff0c;每次读从缓存中读取&＃xff0c;缓存中读取不到&＃xff0c;再去数据库中取&＃xff0c;取完之后再写入到缓存&＃xff0c;对数据做好失效机制通常就没有大问题了。通常来说&＃xff0c;缓存是性能优化的第一选择也是见效最明显的方案。
但是&＃xff0c;缓存通常都是KV型存储且容量有限&＃xff08;基于内存&＃xff09;&＃xff0c;无法解决所有问题&＃xff0c;于是再进一步的优化&＃xff0c;我们继续引入其他NoSql&＃xff1a;
数据库、缓存与其他NoSql并行工作&＃xff0c;充分发挥每种NoSql的特点。当然NoSql在性能方面大大优于关系挺数据库的同时&＃xff0c;往往也伴随着一些特性的缺失&＃xff0c;比较常见的就是事务功能的缺失。
下面看一下常用的NoSql及他们的代表产品&＃xff0c;并对每种NoSql的优缺点和适用场景做一下分析&＃xff0c;便于熟悉每种NoSql的特点&＃xff0c;方便技术选型。
KV型NoSql&＃xff08;代表----Redis&＃xff09;
KV型NoSql顾名思义就是以键值对形式存储的非关系型数据库&＃xff0c;是最简单、最容易理解也是大家最熟悉的一种NoSql&＃xff0c;因此比较快地带过。Redis、MemCache是其中的代表&＃xff0c;Redis又是KV型NoSql中应用最广泛的NoSql&＃xff0c;KV型数据库以Redis为例&＃xff0c;最大的优点我总结下来就两点&＃xff1a;
- 数据基于内存&＃xff0c;读写效率高
- KV型数据&＃xff0c;时间复杂度为O(1)&＃xff0c;查询速度快
因此&＃xff0c;KV型NoSql最大的优点就是高性能&＃xff0c;利用Redis自带的BenchMark做基准测试&＃xff0c;TPS可达到10万的级别&＃xff0c;性能非常强劲。同样的Redis也有所有KV型NoSql都有的比较明显的缺点&＃xff1a;
- 只能根据K查V&＃xff0c;无法根据V查K
- 查询方式单一&＃xff0c;只有KV的方式&＃xff0c;不支持条件查询&＃xff0c;多条件查询唯一的做法就是数据冗余&＃xff0c;但这会极大的浪费存储空间
- 内存是有限的&＃xff0c;无法支持海量数据存储
- 同样的&＃xff0c;由于KV型NoSql的存储是基于内存的&＃xff0c;会有丢失数据的风险
综上所述&＃xff0c;KV型NoSql最合适的场景就是缓存的场景&＃xff1a;
- 读远多于写
- 读取能力强
- 没有持久化的需求&＃xff0c;可以容忍数据丢失&＃xff0c;反正丢了再查询一把写入就是了
例如根据用户id查询用户信息&＃xff0c;每次根据用户id去缓存中查询一把&＃xff0c;查到数据直接返回&＃xff0c;查不到去关系型数据库里面根据id查询一把数据写到缓存中去。
搜索型NoSql&＃xff08;代表----ElasticSearch&＃xff09;
传统关系型数据库主要通过索引来达到快速查询的目的&＃xff0c;但是在全文搜索的场景下&＃xff0c;索引是无能为力的&＃xff0c;like查询一来无法满足所有模糊匹配需求&＃xff0c;二来使用限制太大且使用不当容易造成慢查询&＃xff0c;搜索型NoSql的诞生正是为了解决关系型数据库全文搜索能力较弱的问题&＃xff0c;ElasticSearch是搜索型NoSql的代表产品。
全文搜索的原理是倒排索引&＃xff0c;我们看一下什么是倒排索引。要说倒排索引我们先看下什么是正排索引&＃xff0c;传统的正排索引是文档–>关键字的映射&＃xff0c;例如"Tom is my friend"这句话&＃xff0c;会将其切分为"Tom"、“is”、“my”、"friend"四个单词&＃xff0c;在搜索的时候对文档进行扫描&＃xff0c;符合条件的查出来。这种方式原理非常简单&＃xff0c;但是由于其检索效率太低&＃xff0c;基本没什么实用价值。
倒排索引则完全相反&＃xff0c;它是关键字–>文档的映射&＃xff0c;我用张表格展示一下就比较清楚了&＃xff1a;
意思是我现在这里有"Tom is Tom"、“Tom is my friend”、“Thank you, Betty”、“Tom is Betty’s husband"四句话&＃xff0c;搜索引擎会根据一定的切分规则将这句话切成N个关键字&＃xff0c;并以关键字的维度维护关键字在每个文本中的出现次数。这样下次搜索"Tom"的时候&＃xff0c;由于Tom这个词语在"Tom is Tom”、“Tom is my friend”、"Tom is Betty’s husband"三句话中都有出现&＃xff0c;因此这三条记录都会被检索出来&＃xff0c;且由于"Tom is Tom"这句话中"Tom"出现了2次&＃xff0c;因此这条记录对"Tom"这个单词的匹配度最高&＃xff0c;最先展示。这就是搜索引擎倒排索引的基本原理&＃xff0c;假设某个关键字在某个文档中出现&＃xff0c;那么倒排索引中有两部分内容&＃xff1a;
可以举一反三&＃xff0c;我们搜索"Betty Tom"这两个词语也是一样&＃xff0c;搜索引擎将"Betty Tom"切分为"Tom"、"Betty"两个单词&＃xff0c;根据开发者指定的满足率&＃xff0c;比如满足率&＃61;50%&＃xff0c;那么只要记录中出现了两个单词之一的记录都会被检索出来&＃xff0c;再按照匹配度进行展示。
搜索型NoSql以ElasticSearch为例&＃xff0c;它的优点为&＃xff1a;
- 支持分词场景、全文搜索&＃xff0c;这是区别于关系型数据库最大特点
- 支持条件查询&＃xff0c;支持聚合操作&＃xff0c;类似关系型数据库的Group By&＃xff0c;但是功能更加强大&＃xff0c;适合做数据分析
- 数据写文件无丢失风险&＃xff0c;在集群环境下可以方便横向扩展&＃xff0c;可承载PB级别的数据
- 高可用&＃xff0c;自动发现新的或者失败的节点&＃xff0c;重组和重新平衡数据&＃xff0c;确保数据是安全和可访问的
同样&＃xff0c;ElasticSearch也有比较明显的缺点&＃xff1a;
-
性能全靠内存来顶&＃xff0c;也是使用的时候最需要注意的点&＃xff0c;非常吃硬件资源、吃内存&＃xff0c;大数据量下64G &＃43; SSD基本是标配&＃xff0c;算得上是数据库中的爱马仕了。为什么要专门提一下内存呢&＃xff0c;因为内存这个东西是很值钱的&＃xff0c;相同的配置多一倍内存&＃xff0c;一个月差不多就要多花几百块钱&＃xff0c;至于ElasticSearch内存用在什么地方&＃xff0c;大概有如下这些&＃xff1a;
-
Indexing Buffer----ElasticSearch基于Luence&＃xff0c;Lucene的倒排索引是先在内存里生成&＃xff0c;然后定期以Segment File的方式刷磁盘的&＃xff0c;每个Segment File实际就是一个完整的倒排索引
-
Segment Memory----倒排索引前面说过是基于关键字的&＃xff0c;Lucene在4.0后会将所有关键字以FST这种数据结构的方式将所有关键字在启动的时候全量加载到内存&＃xff0c;加快查询速度&＃xff0c;官方建议至少留系统一半内存给Lucene
-
各类缓存----Filter Cache、Field Cache、Indexing Cache等&＃xff0c;用于提升查询分析性能&＃xff0c;例如Filter Cache用于缓存使用过的Filter的结果集
-
Cluter State Buffer----ElasticSearch被设计为每个Node都可以响应用户请求&＃xff0c;因此每个Node的内存中都包含有一份集群状态的拷贝&＃xff0c;一个规模很大的集群这个状态信息可能会非常大
-
读写之间有延迟&＃xff0c;写入的数据差不多1s样子会被读取到&＃xff0c;这也正常&＃xff0c;写入的时候自动加入这么多索引肯定影响性能
-
数据结构灵活性不高&＃xff0c;ElasticSearch这个东西&＃xff0c;字段一旦建立就没法修改类型了&＃xff0c;假如建立的数据表某个字段没有加全文索引&＃xff0c;想加上&＃xff0c;那么只能把整个表删了再重建
因此&＃xff0c;搜索型NoSql最适用的场景就是有条件搜索尤其是全文搜索的场景&＃xff0c;作为关系型数据库的一种替代方案。
另外&＃xff0c;搜索型数据库还有一种特别重要的应用场景。我们可以想&＃xff0c;一旦对数据库做了分库分表后&＃xff0c;原来可以在单表中做的聚合操作、统计操作是否统统失效&＃xff1f;例如我把订单表分16个库&＃xff0c;1024张表&＃xff0c;那么订单数据就散落在1024张表中&＃xff0c;我想要统计昨天浙江省单笔成交金额最高的订单是哪笔如何做&＃xff1f;我想要把昨天的所有订单按照时间排序分页展示如何做&＃xff1f;这就是文档型NoSql的另一大作用了&＃xff0c;我们可以把分表之后的数据统一打在文档型NoSql中&＃xff0c;利用文档型NoSql的搜索与聚合能力完成对全量数据的查询。
至于为什么把它放在KV型NoSql后面作为第二个写呢&＃xff0c;因为通常搜索型NoSql也会作为一层前置缓存&＃xff0c;来对关系型数据库进行保护。
列式NoSql&＃xff08;代表----HBase&＃xff09;
列式NoSql&＃xff0c;大数据时代最具代表性的技术之一了&＃xff0c;以HBase为代表。
列式NoSql是基于列式存储的&＃xff0c;那么什么是列式存储呢&＃xff0c;列式NoSql和关系型数据库一样都有主键的概念&＃xff0c;区别在于关系型数据库是按照行组织的数据&＃xff1a;
看到每行有name、phone、address三个字段&＃xff0c;这是行式存储的方式&＃xff0c;且可以观察id &＃61; 2的这条数据&＃xff0c;即使phone字段没有&＃xff0c;它也是占空间的。
列式存储完全是另一种方式&＃xff0c;它是按每一列进行组织的数据&＃xff1a;
这么做有什么好处呢&＃xff1f;大致有以下几点&＃xff1a;
- 查询时只有指定的列会被读取&＃xff0c;不会读取所有列
- 存储上节约空间&＃xff0c;Null值不会被存储&＃xff0c;一列中有时候会有很多重复数据&＃xff08;尤其是枚举数据&＃xff0c;性别、状态等&＃xff09;&＃xff0c;这类数据可压缩&＃xff0c;行式数据库压缩率通常在3:15:1之间&＃xff0c;列式数据库的压缩率一般在8:130:1左右
- 列数据被组织到一起&＃xff0c;一次磁盘IO可以将一列数据一次性读取到内存中
第二点说到了数据压缩&＃xff0c;什么意思呢&＃xff0c;以比较常见的字典表压缩方式举例&＃xff1a;
自己看图理解一下&＃xff0c;应该就懂了。
接着继续讲讲优缺点&＃xff0c;列式NoSql&＃xff0c;以HBase为代表的&＃xff0c;优点为&＃xff1a;
- 海量数据无限存储&＃xff0c;PB级别数据随便存&＃xff0c;底层基于HDFS&＃xff08;Hadoop文件系统&＃xff09;&＃xff0c;数据持久化
- 读写性能好&＃xff0c;只要没有滥用造成数据热点&＃xff0c;读写基本随便玩
- 横向扩展在关系型数据库及非关系型数据库中都是最方便的之一&＃xff0c;只需要添加新机器就可以实现数据容量的线性增长&＃xff0c;且可用在廉价服务器上&＃xff0c;节省成本
- 本身没有单点故障&＃xff0c;可用性高
- 可存储结构化或者半结构化的数据
- 列数理论上无限&＃xff0c;HBase本身只对列族数量有要求&＃xff0c;建议1~3个
说了这么多HBase的优点&＃xff0c;又到了说HBase缺点的时候了&＃xff1a;
- HBase是Hadoop生态的一部分&＃xff0c;因此它本身是一款比较重的产品&＃xff0c;依赖很多Hadoop组件&＃xff0c;数据规模不大没必要用&＃xff0c;运维还是有点复杂的
- KV式&＃xff0c;不支持条件查询&＃xff0c;或者说条件查询非常非常弱吧&＃xff0c;HBase在Scan扫描一批数据的情况下还是提供了前缀匹配这种API的&＃xff0c;条件查询除非定义多个RowKey做数据冗余
- 不支持分页查询&＃xff0c;因为统计不了数据总数
因此HBase比较适用于那种KV型的且未来无法预估数据增长量的场景&＃xff0c;另外HBase使用还是需要一定的经验&＃xff0c;主要体现在RowKey的设计上。
文档型NoSql&＃xff08;代表----MongoDB&＃xff09;
坦白讲&＃xff0c;根据我的工作经历&＃xff0c;文档型NoSql我只有比较浅的使用经验&＃xff0c;因此这部分只能结合之前的使用与网上的文章大致给大家介绍一下。
什么是文档型NoSql呢&＃xff0c;文档型NoSql指的是将半结构化数据存储为文档的一种NoSql&＃xff0c;文档型NoSql通常以JSON或者XML格式存储数据&＃xff0c;因此文档型NoSql是没有Schema的&＃xff0c;由于没有Schema的特性&＃xff0c;我们可以随意地存储与读取数据&＃xff0c;因此文档型NoSql的出现是解决关系型数据库表结构扩展不方便的问题的。
MongoDB是文档型NoSql的代表产品&＃xff0c;同时也是所有NoSql产品中的明星产品之一&＃xff0c;因此这里以MongoDB为例。按我的理解&＃xff0c;作为文档型NoSql&＃xff0c;MongoDB是一款完全和关系型数据库对标的产品&＃xff0c;就我们从存储上来看&＃xff1a;
看到&＃xff0c;关系型数据库是按部就班地每个字段一列存&＃xff0c;在MongDB里面就是一个JSON字符串存储。关系型数据可以为name、phone建立索引&＃xff0c;MongoDB使用createIndex命令一样可以为列建立索引&＃xff0c;建立索引之后可以大大提升查询效率。其他方面而言&＃xff0c;就大的基本概念&＃xff0c;二者之间基本也是类似的&＃xff1a;
因此&＃xff0c;对于MongDB&＃xff0c;我们只要理解成一个Free-Schema的关系型数据库就完事了&＃xff0c;它的优缺点比较一目了然&＃xff0c;优点&＃xff1a;
- 没有预定义的字段&＃xff0c;扩展字段容易
- 相较于关系型数据库&＃xff0c;读写性能优越&＃xff0c;命中二级索引的查询不会比关系型数据库慢&＃xff0c;对于非索引字段的查询则是全面胜出
缺点在于&＃xff1a;
- 不支持事务操作&＃xff0c;虽然Mongodb4.0之后宣称支持事务&＃xff0c;但是效果待观测
- 多表之间的关联查询不支持&＃xff08;虽然有嵌入文档的方式&＃xff09;&＃xff0c;join查询还是需要多次操作
- 空间占用较大&＃xff0c;这个是MongDB的设计问题&＃xff0c;空间预分配机制 &＃43; 删除数据后空间不释放&＃xff0c;只有用db.repairDatabase()去修复才能释放
- 目前没发现MongoDB有关系型数据库例如MySql的Navicat这种成熟的运维工具
总而言之&＃xff0c;MongDB的使用场景很大程度上可以对标关系型数据库&＃xff0c;但是比较适合处理那些没有join、没有强一致性要求且表Schema会常变化的数据。
总结&＃xff1a;数据库与NoSql及各种NoSql间的对比
最后一部分&＃xff0c;做一个总结&＃xff0c;本文归根到底是两个话题&＃xff1a;
- 何时选用关系型数据库&＃xff0c;何时选用非关系型数据库
- 选用非关系型数据库&＃xff0c;使用哪种非关系型数据库
最后
各位读者&＃xff0c;由于本篇幅度过长&＃xff0c;为了避免影响阅读体验&＃xff0c;下面我就大概概括了整理了&＃xff0c;需要的话请**点赞后点击这里免费下载文章资料&＃xff01;**
后点击这里免费下载文章资料&＃xff01;](https://gitee.com/vip204888/java-p7)**
[外链图片转存中…(img-BGKjmNNu-1628232325649)]
[外链图片转存中…(img-YIMCV7fL-1628232325649)]
[外链图片转存中…(img-Krk0vBvH-1628232325650)]
京公网安备 11010802041100号