报价宝 › 科技 ›

主流NOSQL:Redis、Memcache、MongoDb分析及应用场景

报价宝来源：baojiabao.com 发布时间：2019-10-26 21:02:00 11月14日更新

报价宝综合消息主流NOSQL:Redis、Memcache、MongoDb分析及应用场景

Nosql的全称是Not Only Sql，这个概念早起就有人提出，在09年的时候比较火。Nosql指的是非关系型数据库，而我们常用的都是关系型数据库。就像我们常用的mysql，oralce、sqlserver等一样，这些数据库一般用来储存重要资讯，应对普通的业务是没有问题的。但是，随着互联网的高速发展，传统的关系型数据库在应付超大规模，超大流量以及高并发的时候力不从心。而就在这个时候，Nosql应运而生。

Nosql和关系型数据库的区别

1.储存方式

关系型数据库是表格式的，储存在表的行和列中。他们之间很容易关联协作储存，提取资料很方便。而Nosql数据库则与其相反，他是组合在一起。通常储存在资料集中，就像文件、键值对或者图结构。

2.储存结构

关系型数据库对应的是结构化资料，资料表都预先定义了结构(列的定义)，结构描述了资料的形式和内容。这一点对资料建模至关重要，虽然预定义结构带来了可靠性和稳定性，但是修改这些资料比较困难。而Nosql数据库基于动态结构，使用与非结构化资料。因为Nosql数据库是动态结构，可以很容易适应资料型别和结构的变化。

3.储存规范

关系型数据库的资料储存为了更高的规范性，把资料分割为最小的关系表以避免重复，获得精简的空间利用。虽然管理起来很清晰，但是单个操作设计到多张表的时候，资料管理就显得有点麻烦。而Nosql资料储存在平面资料集中，资料经常可能会重复。单个数据库很少被分隔开，而是储存成了一个整体，这样整块资料更加便于读写

4.储存扩充套件

这可能是两者之间最大的区别，关系型数据库是纵向扩充套件，也就是说想要提高处理能力，要使用速度更快的计算机。因为资料储存在关系表中，操作的效能瓶颈可能涉及到多个表，需要通过提升计算机效能来克服。虽然有很大的扩充套件空间，但是最终会达到纵向扩充套件的上限。而Nosql数据库是横向扩充套件的，它的储存天然就是分散式的，可以通过给资源池新增更多的普通数据库服务器来分担负载。

5.查询方式

关系型数据库通过结构化查询语言来操作数据库(就是我们通常说的SQL)。SQL支援数据库CURD操作的功能非常强大，是业界的标准用法。而Nosql查询以块为单元操作资料，使用的是非结构化查询语言(UnQl)，它是没有标准的。关系型数据库表中主键的概念对应Nosql中储存文件的ID。关系型数据库使用预定义优化方式(比如索引)来加快查询操作，而Nosql更简单更精确的资料访问模式。

6.事务

关系型数据库遵循ACID规则(原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、永续性(Durability))，而Nosql数据库遵循BASE原则(基本可用(Basically Availble)、软/柔性事务(Soft-state )、最终一致性(Eventual Consistency))。由于关系型数据库的资料强一致性，所以对事务的支援很好。关系型数据库支援对事务原子性细粒度控制，并且易于回滚事务。而Nosql数据库是在CAP(一致性、可用性、分割槽容忍度)中任选两项，因为基于节点的分散式系统中，很难全部满足，所以对事务的支援不是很好，虽然也可以使用事务，但是并不是Nosql的闪光点。

7.效能

关系型数据库为了维护资料的一致性付出了巨大的代价，读写效能比较差。在面对高并发读写效能非常差，面对海量资料的时候效率非常低。而Nosql储存的格式都是key-value型别的，并且储存在内存中，非常容易储存，而且对于资料的一致性是弱要求。Nosql无需sql的解析，提高了读写效能。

8.授权方式

关系型数据库通常有SQL Server，Mysql，Oracle等。主流的Nosql数据库有Redis，Memcache，MongoDb。大多数的关系型数据库都是付费的并且价格昂贵，成本较大，而Nosql数据库通常都是开源的。

Redis、Memcache、MongoDb的优缺点

Redis优点

支援多种资料结构，如 string(字串)、 list(双向连结串列)、dict(hash表)、set(集合)、zset(排序set)、hyperloglog(基数估算)

支援持久化操作，可以进行aof及rdb资料持久化到磁盘，从而进行资料备份或资料恢复等操作，较好的防止资料丢失的手段。

支援通过Replication进行资料复制，通过master-slave机制，可以实时进行资料的同步复制，支援多级复制和增量复制，master-slave机制是Redis进行HA的重要手段。

单执行绪请求，所有命令序列执行，并发情况下不需要考虑资料一致性问题。

支援pub/sub讯息订阅机制，可以用来进行讯息订阅与通知。

支援简单的事务需求，但业界使用场景很少，并不成熟。

Redis缺点

Redis只能使用单执行绪，效能受限于CPU效能，故单例项CPU最高才可能达到5-6wQPS每秒(取决于资料结构，资料大小以及服务器硬件效能，日常环境中QPS高峰大约在1-2w左右)。

支援简单的事务需求，但业界使用场景很少，并不成熟，既是优点也是缺点。

Redis在string型别上会消耗较多内存，可以使用dict(hash表)压缩储存以降低内存耗用。

Memcache优点

Memcached可以利用多核优势，单例项吞吐量极高，可以达到几十万QPS(取决于key、value的字节大小以及服务器硬件效能，日常环境中QPS高峰大约在4-6w左右)。适用于最大程度扛量。支援直接配置为session handle。

Memcache缺点

只支援简单的key/value资料结构，不像Redis可以支援丰富的资料型别。

无法进行持久化，资料不能备份，只能用于快取使用，且重启后资料全部丢失。

无法进行资料同步，不能将MC中的资料迁移到其他MC例项中。

Memcached内存分配采用Slab Allocation机制管理内存，value大小分布差异较大时会造成内存利用率降低，并引发低利用率时依然出现踢出等问题。需要使用者注重value设计。

MongoDB优点

更高的写负载，MongoDB拥有更高的插入速度。

处理很大的规模的单表，当资料表太大的时候可以很容易的分割表。

高可用性，设定M-S不仅方便而且很快，MongoDB还可以快速、安全及自动化的实现节点(资料中心)故障转移。

快速的查询，MongoDB支援二维空间索引，比如管道，因此可以快速及精确的从指定位置获取资料。MongoDB在启动后会将数据库中的资料以档案对映的方式载入到内存中。如果内存资源相当丰富的话，这将极大地提高数据库的查询速度。

非结构化资料的爆发增长，增加列在有些情况下可能锁定整个数据库，或者增加负载从而导致效能下降，由于MongoDB的弱资料结构模式，新增1个新字段不会对旧表格有任何影响，整个过程会非常快速。

MongoDB缺点

不支援事务。MongoDB占用空间过大。

MongoDB没有成熟的维护工具。

Redis、Memcache、MongoDB的区别

效能:三者的效能都比较高，总的来讲：Memcache和Redis差不多，要高于MongoDB。

便利性:memcache资料结构单一;redis丰富一些，资料操作方面，redis更好一些，较少的网络IO次数;mongodb支援丰富的资料表达，索引，最类似关系型数据库，支援的查询语言非常丰富。

储存空间:redis在2.0版本后增加了自己的VM特性，突破实体内存的限制;可以对key value设定过期时间(类似memcache);memcache可以修改最大可用内存,采用LRU算法;mongoDB适合大资料量的储存，依赖操作系统VM做内存管理，吃内存也比较厉害，服务不要和别的服务在一起。

可用性

redis，依赖客户端来实现分散式读写;主从复制时，每次从节点重新连线主节点都要依赖整个快照,无增量复制，因效能和效率问题，所以单点问题比较复杂;不支援自动sharding,需要依赖程式设定一致hash 机制。一种替代方案是，不用redis本身的复制机制，采用自己做主动复制(多份储存)，或者改成增量复制的方式(需要自己实现)，一致性问题和效能的权衡。

Memcache本身没有资料冗余机制，也没必要;对于故障预防，采用依赖成熟的hash或者环状的算法，解决单点故障引起的抖动问题。

mongoDB支援master-slave,replicaset(内部采用paxos选举算法，自动故障恢复),auto sharding机制，对客户端遮蔽了故障转移和切分机制。

可靠性

redis支援(快照、AOF)：依赖快照进行持久化，aof增强了可靠性的同时，对效能有所影响。

memcache不支援，通常用在做快取,提升效能。

MongoDB从1.8版本开始采用binlog方式支援持久化的可靠性。

一致性

Memcache 在并发场景下，用cas保证一致性。

redis事务支援比较弱，只能保证事务中的每个操作连续执行。

mongoDB不支援事务。

资料分析:mongoDB内建了资料分析的功能(mapreduce),其他两者不支援。

应用场景