Redis数据库跟MongoDB数据库有什么区别呢？

Copyright © 1999-2020, CSDNNET, All Rights Reserved
Redis
登录
骑行天下_徐鑫
关注
redis和MongoDB比较 转载
2019-07-02 22:00:52
1点赞

骑行天下_徐鑫
码龄3年
关注
Redis技术陷阱
Redis 基于内存，也可以基于磁盘持久化NoSql数据库，使用 c语言编写，常用端口6379
Redis对内存依赖性很强的NoSql数据库，在内存足够的情况下性能出色，但是一般情况下，服务器内存并没有那么多。
一般情况下，Redis会索取大量服务器内存进行存储数据，以达到快速读取查询的效果。当对Redis插入数据后，redis会异步将数据dump到硬盘中，
比如服务器内存是20G，Redi会fork一个进程，并且会占用同样的大小内存，他需要的内存空间瞬间变为20+20=40G，这是内存超过了物理内存的限制，马上会启动虚拟内存，虽然服务器会有虚拟内存，但是那是服务器的虚拟内存，并不是redis自己的虚拟内存。
Linux虚拟内存page很大，IO剧增，dump速度非常慢，整个服务器的性能降到冰点，服务请求会堵塞，严重到服务器崩溃。
对于单台机子，最好是降低redis虚拟内存设置，page可以根据配置进行修改，这个虚拟内存比Linux虚拟内存好多，因为page小很多。
如果Redis既要读又要写，那么最好不要用redis占用大半的内存。
可以设置它的虚拟内存到8G,但是要根据key值大小去衡量，因为key必须在内存中，这样一来就算是启用了虚拟内存，redis占用的实际内存也会超出设想。
官方建议对key小，value很大的数据设置虚拟内存。
另外master/slave不是很成熟，目前只支持主从，Redis在master是非阻塞模式，也就是说在slave执行数据同步的时候，master是可以接受客户端的请求的，并不影响同步数据的一致性，然而在slave端是阻塞模式的，slave在同步master数据时，并不能响应客户端的查询。
可以根据master/slave 的特点，master不dump,只负责写数据，让slaver去dump
Redis如何持久化：持久化就是将内存中的数据写入到硬盘中。
（1）：RDB：是将数据写入到临时文件（dumprdb）,持久化之后用这个临时文件替换上次持久化文件，达到数据恢复的目的。RDB是间隔异地短时间进行持久化，如果持久化之间redis发生故障，会发生数据丢失，所以这种方式更适合数据要求不严谨的时候，默认开启。
（2）：Redis内存淘汰策略：指的是用户存储的一些键可以被redis主动从实例中删除，从而产生miss的情况，内存淘汰是为了更好地使用内存，用一定的缓存miss来换取内存的使用率。① noeviction:默认策略，不删除任意数据，但是内存不够时，会直接返回错误
② Allkeys-lru:从数据集中(包括设置过期时间和未设置过期时间的数据集)，优先移除最近未使用的key
③ Volatile-lru:在设置了过期时间的数据集中，优先移除最近未使用的key
④ Allkeys-random:从数据集中(包括设置过期时间和未设置过期时间的数据集)，随机移除某个key
⑤ Volatile-random:在设置了过期时间的数据集中，随机移除某个key
Volatile-ttl:在设置了过期时间的数据集中，具有更早过期时间的key优先移除。
Redis有些数据类型：String Hash List Sets ZSets(存放多个值，不可有重复，有顺序，不同的是每个元素都会关联Double类型的分数，redis正是通过分数来为集合中的成员进行从小到大排序)，
Redis使用场景：
缓存热数据使用，热数据就是在项目中经常会被查询，但不经常会被修改和删除的数据。
计数器，诸如统计点击数等应用。
队列
位 *** 作（大数据处理），比如统计QQ用户在线。
最新列表
排行榜，使用zadd添加有序集合
Linux虚拟内存：
为了运行比实际物理内存容量还要大的程序，包括Linux在内的所有现代 *** 作系统几乎毫无里外都采用了虚拟内存技术。虚拟内存技术，可让系统看上去具有比实际意义内存大得多的内存空间，并为实现多道程序的执行创造条件。
虚拟内存概念：总所周知，为了对内存中的存储单元进行识别，内存中的每一个存储单元都必须有一个确切的地址。而一台计算机的处理器能访问多大的内存空间就取决于处理器的程序计数器，该计数器字长越长，能访问的空间越大。
例如对于程序计数器位数为32位的处理器来说，他的地址发生器所能发出的地址数目2^32=4G个，于是这个处理器所能访问的最大内存空间就是4G。载计算机技术中，这个值就是处理器的寻址空间或寻址能力。
MongoDB
文档结构的存储方式。能够快捷获取数据
支持GridFS 支持大容量存储，海量数据存储
海量数据下，性能优越
动态查询
全索引支持，拓展到内部对象和内嵌数组
查询记录分析
快速，就地更新
高效存储二进制大对象
复制和支持自动恢复故障
内置Auto-Sharding 自动分片支持云级别拓展性。分片简单
MapReduce 支持复杂聚合
缺点：不支持事务 *** 作，占用硬盘空间大，没有Mysql成熟的维护工具，无法进行关联表查询，不适用于关系多的数据，复杂句和 *** 作通过mapreduce创建，速度慢，模式自由，自由灵活的文件存储格式带来的数据错误，MongoDB在你删除记录后不会在文件系统回收空间，除非删掉数据库，但是空间没有浪费。
分布式文件存储数据库，介于NoSql和关系型数据库之间的一款产品，基于C++编写，具有查询语言、索引、key-value存储结构，MongoDB存储数据是以BSON类型（二进制json）。
Redis(读写快) ---àMongoDB （数据量大、查询统计、缺乏事务支持）àOracle（数据量大、查询统计方便、事务强）
MongoDB适用于表单数据 *** 作、完整性要求不高的系统使用，高性能、易部署、易使用，存储数据非常方便。MongoDB ：库->集合 JSON对象记录
区别联系：
（1）：性能方面：Redis大于MongoDB、MongoDB支持丰富的数据表达，索引，最类似于关系型数据库，支持查询的语言非常丰富，redis数据结构方面更加丰富，可以存储List/set/Hash/sort Set等集合。
（2）：内存空间和数据量大小： MongoDB适合大量数据存储
（3）：数据一致性 Redis事务支持比较弱，MongoDB不支持事务
(4):Redis用在数据量较小的 *** 作和运算上，Mongodb主要解决海量数据访问效率问题。
（5）MemCachd 不支持数据持久化，断电或者重启后数据消失，但其稳定性是有保证的，redis支持数据持久化和数据恢复，允许单点故障
1Memcached单个key-value大小有限，一个value最大只支持1MB，而Redis最大支持512MB
2Memcached只是个内存缓存，对可靠性无要求；而Redis更倾向于内存数据库，因此对对可靠性方面要求比较高
3从本质上讲，Memcached只是一个单一key-value内存Cache；而Redis则是一个数据结构内存数据库，支持五种数据类型，因此Redis除单纯缓存作用外，还可以处理一些简单的逻辑运算，Redis不仅可以缓存，而且还可以作为数据库用
4新版本（30）的Redis是指集群分布式，也就是说集群本身均衡客户端请求，各个节点可以交流，可拓展行、可维护性更强大。
关于其原因，在官方的FAQ中，提到有如下几个方面：
1、空间的预分配：为避免形成过多的硬盘碎片，mongodb每次空间不足时都会申请生成一大块的硬盘空间，而且申请的量从64M、128M、256M那 样的指数递增，直到2G为单个文件的最大体积。随着数据量的增加，你可以在其数据目录里看到这些整块生成容量不断递增的文件。
2、字段名所占用的空间：为了保持每个记录内的结构信息用于查询，mongodb需要把每个字段的key-value都以BSON的形式存储，如果 value域相对于key域并不大，比如存放数值型的数据，则数据的overhead是最大的。一种减少空间占用的方法是把字段名尽量取短一些，这样占用 空间就小了，但这就要求在易读性与空间占用上作为权衡了。
3、删除记录不释放空间：这很容易理解，为避免记录删除后的数据的大规模挪动，原记录空间不删除，只标记“已删除”即可，以后还可以重复利用。
4、可以定期运行dbrepairDatabase()来整理记录，但这个过程会比较缓慢
MongoDB没有如MySQL那样成熟的维护工具，这对于开发和IT运营都是个值得注意的地方。

MongoDB是一款广泛使用的文档型数据库，而Elasticsearch则是一款基于Lucene的搜索引擎，它们在设计和应用上有很大的差异，因此不能说MongoDB可以完全替代Elasticsearch。以下是一些具体的原因：

数据结构：MongoDB主要针对的是数据的存储和查询，而Elasticsearch则是专注于全文搜索和分析，因此它们的数据结构和查询方式不同。MongoDB的查询速度可能会受到文本索引的限制，而Elasticsearch具有更强大的全文搜索和分析功能，可以快速检索和分析海量数据。

扩展性：Elasticsearch是一个分布式搜索引擎，可以水平扩展以处理大规模数据，而MongoDB则需要通过复制集或分片技术来扩展。因此在处理大规模数据时，Elasticsearch能够更好地处理。

实时性：Elasticsearch具有较高的实时性，能够快速响应用户的搜索请求，而MongoDB可能需要更长时间来执行复杂的查询，因此在实时性方面会有所劣势。

综上所述，MongoDB和Elasticsearch各有优缺点，它们的应用场景也不同。如果需要高效地处理海量文本数据，进行全文搜索和分析，那么Elasticsearch是一个更好的选择；而如果需要处理大量结构化数据或进行多种查询 *** 作，则MongoDB是更适合的选择。

Apache三剑客：HBase, Cassandra, CouchDB。HBase的前景最为看好，因为它的开发者众多并且都是顶尖高手。Cassandra目前有很多否定的声音。CouchDB的小而精悍，赞誉很多，将要正式发布的CouchBase融合了MemBase和CouchDB，很令人期待。
HBase和Cassandra都是效仿Google的BigTable的基于列的数据库，它们都是用Java写的。另外一类似的数据库是HyperTable，百度用在一些后台分析，因为它是C++写的，速度比较快。不过HyperTable有点边缘，不太流行。这些基于列的开源数据库目前都比Goolge的BigTable差之少一个数量级
CouchDB是一个文档数据库。其最大的竞争者是MongoDB。MongoDB和HBase都采用主从服务器设计。CouchDB的服务器分布设计和Cassandra类似，Peer to Peer类型的。主从服务器设计一般能更好的strong consistent，属于CAP理论中的CP类型。 CouchDB和Cassandra一般认为都是eventual consistent，属于CAP理论中的AP类型。但其实MongoDB和Cassandra都可以设置成strong consistent或者eventual consistent。
以上所提到的数据库都支持MapReduce。好像出了HyperTable都支持非主键索引。HBase和strong consistent配置的MongoDB都支持最基本的锁定（HBase单行锁定，MongoDB单文档锁定），因此可以实现transaction，但是实现有点复杂和低效。单就transaction这一点，目前开源NoSQL数据库没有做的比较好的。
MongoDB的最大卖点是不需构建非主键索引也能执行很多查询。但是MongoDB的服务器分布设计实在不能让人恭维，可以说是NoSQL数据库中最Ugly的实现。
K-V数据库比较多，而且上面提到的基于列的数据库和文档数据库其实也都是K-V数据库。比较流行的纯种K-V数据库有:
Memcached: 非常流行，不支持持久化
VMWare's Redis: 很流行，新浪和知乎都在用，CP类型。
MemBase: 由很多Memcached的开发者开发，使用sqlite作底层存储。在社交游戏中用的比较多, zynga在用，CP类型。
Riak, 分布式实现和CouchDB/Cassandra比较像，AP类型。支持MapReduce。
Linkin's Voldemort， 在K-V中少见的eventual consistent ，AP类型。
TT, TC
纯基于二维座标索引的是Neo4j。但是现在MongoDB和CouchDB都集成这一特性。
目前CouchDB的开发者成立的公司CouchOne收购了MemBase，将其底层sqlite换成CouchDB推出了CouchBase，从而引入MapReduce以支持非主键索引。CouchBase暂时还没有正式发布官方正式版，不过快了。虽然CouchDB是eventual consistent的，但是CouchBase的开发者宣称CouchBase保持了MemBase的strong consistent特性，具体实现有待以后研究。
如果从成熟的角度来看，比较成熟并且十分流行的的有CouchDB，Memcached，Redis。

1、可能会问nosql和关系型数据库的区别：
优点：
1）成本：nosql数据库简单易部署，基本都是开源软件，不需要像使用Oracle那样花费大量成本购买使用，相比关系型数据库价格便宜
2）查询速度：nosql数据库将数据存储于缓存之中，关系型数据库将数据存储在硬盘中，自然查询速度远不及nosql数据库
3）存储数据的格式：nosql的存储格式是key,value形式、文档形式、形式等等，所以可以存储基础类型以及对象或者是集合等各种格式，而数据库则只支持基础类型
4）扩展性：关系型数据库有类似join这样的多表查询机制的限制导致扩展很艰难
缺点：
1）维护的工具和资料有限，因为nosql是属于新的技术，不能和关系型数据库10几年的技术同日而语。
2）不提供对sql的支持，如果不支持sql这样的工业标准，将产生一定用户的学习和使用成本
3）不提供关系型数据库对事物的处理
2、介绍下redis和mongodb：
自行google。
3、应用场景：
redis：
a主要是做热点数据缓存。
b数据过期处理。
c消息队列等功能。
d计数，例如投票等。
mongodb：
mongodb的主要目标是在键/值存储方式（提供了高性能和高度伸缩性）以及传统的RDBMS系统（丰富的功能）架起一座桥梁，集两者的优势于一身。mongo适用于以下场景：
a网站数据：mongo非常适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。
b缓存：由于性能很高，mongo也适合作为信息基础设施的缓存层。在系统重启之后，由mongo搭建的持久化缓存可以避免下层的数据源过载。
c大尺寸、低价值的数据：使用传统的关系数据库存储一些数据时可能会比较贵，在此之前，很多程序员往往会选择传统的文件进行存储。
d高伸缩性的场景：mongo非常适合由数十或者数百台服务器组成的数据库。
e用于对象及JSON数据的存储：mongo的BSON数据格式非常适合文档格式化的存储及查询。
4、支持的数据类型:
内容比较多，自行将网上的信息整理一下。

MongoDB 50标志着一个新的发布周期的到来，以更快地交付新特性给到用户。版本化API与在线重新分片相结合，使用户不必担心未来的数据库升级以及业务变化问题；本地原生时间序列数据平台也使MongoDB能支持更广泛的工作负载和业务场景；新的MongoDB Shell能够提升用户体验等均为MongoDB 50的功能。本文主要介绍MongoDB 50的新特性。

MongoDB 50通过原生支持整个时间序列数据的生命周期（从采集、存储、查询、实时分析和可视化，到在线归档或随着数据老化自动失效），使构建和运行时间序列应用程序的速度更快、成本更低。随着MongoDB 50的发布，MongoDB扩展了通用的应用数据平台，使开发能够更容易地处理时间序列数据，进一步扩展其在物联网、金融分析、物流等方面的应用场景。

MongoDB的时间序列集合以高度优化和压缩的格式自动存储时间序列数据，减少了存储大小和I/O，以实现更好的性能和更大的规模。同时也缩短了开发周期，使您能够快速建立一个针对时间序列应用的性能和分析需求而调优的模型。

创建时间序列数据集合的命令示例：

MongoDB可以无缝地调整采集频率，并根据动态生成的时间分区自动处理无序的测量值。最新发布的MongoDB Connector for Apache Kafka实现了在本地支持时间序列，您可以直接从Kafka主题消息中自动创建时间序列集合，使您在收集数据的同时根据需要对数据进行处理和聚合，然后写入到MongoDB的时间序列集合。

时间序列集合自动创建一个按时间排序的数据聚集索引，降低查询数据的延迟。MongoDB查询API还扩展了窗口函数，您可以运行分析性查询（例如移动平均数和累积总和）。在关系型数据库系统中，这些通常被称为SQL分析函数，并支持以行为单位定义的窗口（即三行移动平均线）。MongoDB更进一步，还增加了指数移动平均线、导数和积分等强大的时间序列函数，支持您以时间为单位定义窗口（例如15分钟的移动平均线）。窗口函数可用于查询MongoDB的时间序列和常规集合，为多种应用类型提供了新的分析方式。另外，MongoDB 50也提供了新的时间运算符，包括$dateAdd、$dateSubstract、$dateDiff和$dateTrunc，使您可以通过自定义的时间窗口对数据进行汇总和查询。

您可以将MongoDB的时间序列数据与企业的其他数据相结合。时间序列集合可以与同一个数据库中的常规MongoDB集合放在一起，您不必选择一个专门的时间序列数据库（它不能为任何其他类型的应用提供服务），也不需要复杂的集成来混合时间序列和其他数据。MongoDB通过提供一个统一的平台，让您建立高性能和高效的时间序列应用的同时，也为其他用例或工作负载提供支持，从而消除了整合和运行多个不同数据库的成本和复杂性。

从MongoDB 50开始， Write Concern 默认级别为majority，仅当写入 *** 作被应用到Primary节点（主节点）且被持久化到大多数副本节点的日志中的时候，才会提交并返回成功，“开箱即用”地提供了更强的数据可靠性保障。

说明 Write Concern 是完全可调的，您可以自定义配置 Write Concern ，以平衡应用程序对数据库性能和数据持久性的要求。

默认情况下，一个客户端连接对应后端MongoDB服务器上的一个线程（ netserviceExecutor 配置为synchronous）。创建、切换和销毁线程都是消耗较大的 *** 作，当连接数过多时，线程会占用MongoDB服务器较多的资源。

连接数较多或创建连接失控的情况称为“连接风暴”，产生该情况的原因可能是多方面的，且经常是在服务已经受到影响的情况下发生。

针对这些情况，MongoDB 50采取了以下措施：

以上措施，加上之前版本在mongos查询路由层的改进，进一步提升了MongoDB承受高并发负载的能力。

长时间运行的快照查询（Long-Running Snapshot Queries）增加了应用程序的通用性和d性。您可以通过该功能运行默认时间为5分钟的查询（或将其调整为自定义持续时间），同时保持与实时事务性数据库一致的快照隔离，也可以在Secondary节点（从节点）上进行快照查询，从而在单个集群中运行不同的工作负载，并将其扩展到不同的分片上。

MongoDB通过底层存储引擎中一个名为Durable history的项目实现了长期运行的快照查询，该项目早在MongoDB 44中就已实现。Durable history将存储自查询开始以来所有变化的字段值的快照。通过使用Durable history，查询可以保持快照隔离，即使在数据发生变化的情况下，Durable history也有助于降低存储引擎的缓存压力，使得业务可以在高写入负载的场景下实现更高的查询吞吐量。

为了提供更好的用户体验，MongoDB 50从头开始重新设计了MongoDB Shell（mongosh），以提供一个更现代化的命令行体验，以及增强可用性的功能和强大的脚本环境。新版MongoDB Shell已经成为MongoDB平台的默认shell。新版MongoDB Shell引入了语法高亮、智能自动完成、上下文帮助和有用的错误信息，为您创造一个直观、互动的体验。

随着新的PyMongoArrow API的发布，您可以在MongoDB上使用Python运行复杂的分析和机器学习。PyMongoArrow可以快速将简单的MongoDB查询结果转换为流行的数据格式（例如Pandas数据框架和NumPy数组），帮助您简化数据科学工作流程。

Schema验证（模式验证）是对MongoDB进行数据应用管理控制的一种方式。MongoDB 50中，模式验证变得更加简单和友好，当 *** 作验证失败时都会产生描述性的错误信息，帮助您了解不符合集合验证器的验证规则的文档及原因，以快速识别和纠正影响验证规则的错误代码。

MongoDB 50支持将正在进行中的索引创建任务在节点重新启动后自动会恢复至原来的位置，减少计划中维护动作对业务的影响。例如：重新启动或升级数据库节点时，您不需要担心当前正在进行的大集合索引创建任务失效。

由于MongoDB支持很多版本和平台，每个发布版本都需在20多个MongoDB支持的平台上进行验证，验证工作量大，降低了MongoDB新功能的交付速度，所以从MongoDB 50开始，MongoDB发布的版本将分为Marjor Release（大版本）和Rapid Releases（快速发布版本），其中Rapid Releases作为开发版本提供下载和测试体验，但不建议用在生产环境。

mongodb众所周知不支持事务，所以需要强事务的业务根本不能考虑mongodb。
mongodb的优势就是文档存储:
1 业务经常变动，需要不时的添加字段，那么mongodb比较适合，关系型数据库添加字段的复杂度也还好
2 嵌套文档，业务数据比较复杂，适合嵌套文档式存储，那么mongodb非常合适，这个关系型数据库比较难搞，虽然MySQL和pg也有文档存储，但MySQL的不成熟，pg毕竟现在生产中使用还是偏少，个人也不了解，这里不谈。但这不仅仅这一点优势，具体下面会细说。
3 upsert支持，查询速度也不慢
4 高可用的副本集支持
5 查询语法非常丰富，嵌套文档查询功能非常强大，不是重度用户可能不能理解
下面说说一个具体的使用事例:
项目的一条数据在10kb左右，如果使用关系型数据库那么需要将这条数据拆分成大概几百条左右，建造多个表，设计较复杂，这种数据大概在一百万条左右，想想拆分后在十几亿的数据量就可怕。打平后的数据什么DB也都可以拿下，只是一百万变十几亿比较恐怖而已。
如果采用MySQL存储，每次查询需要使用外键查询多个表，从这些表中拉取数据，性能肯定要下降很多，比不上只在一个表查询，而且只拉取少两个数量级的数据。查询也还好，业务允许可以对结果做缓存，放到redis里去。
但是重点来了，需求要增量更新部分数据，这时候需要更新多个表，根本没法做到原子性（注意事务不是原子 *** 作），当然也可以使用cas等技术补偿，达到最终一致性。但使用mongodb存储只需要update一条数据，对相应的嵌套文档中内容更新，可以做到原子性，是不是很方便？
推荐学习《python教程》
具体说说该项目的难点，查询无法使用缓存，可能会很吃惊，但是业务决定了确实做不了，而且增量更新的量达到上万的QPS，如果不能保证原子性想想多么可怕！
所以mongodb在这里帮了大忙，关系型数据库解决不了这个难题。
有人可能要问，mongodb没有事务，上游数据写入也会有问题，你不可能所有数据都存一个表吧？
当然不是的，我们mongodb里的数据是从MySQL中清洗出来存到mongodb中的，mongodb只做单点的业务需求，综合的数据还是在MySQL中。
此项目我们用了上百个副本集，保证系统的高可用，这些副本集配置只要一条shell就搞定，如果用MySQL的主从不知道怎么配（我自己不懂），估计DBA得忙死，而该项目完全不需要也没用到DBA。
说了这么多mongo的优点，也说说他的缺点:
1 查询优化器和MySQL没法比
2 不支持reload，只能冷重启，初始化配置的时候比较麻烦
3 没有事务，不敢存储第一手数据，多用来做备份数据的存储
mongodb可以做很多事情，取决于你脑洞，性能不差，存一些相对不重要的数据，mongodb嵌套文档功能强大，多看看官方文档挖掘挖掘有用信息，每次都能发现惊喜。

---