Redis(Remote Dictionary Server,远程字典服务器)和 MongoDB 是两类知名的 NoSQL数据库,其以非结构化的方式存储数据。与传统关系数据库使用表格、行和列来组织数据不同,NoSQL数据库采用了不同的数据存储模型。Redis是一种开源的内存数据库,以键值对的形式存储数据,其将数据存储在 RAM 中,以实现高效的读写性能,同时也提供磁盘持久存储作为补充功能。MongoDB是另一种开源的文档数据库,通过序列化的 JSON 格式来存储数据,MongoDB会将数据存储在外部存储中。
尽管 Redis和 MongoDB 都是广受欢迎的 NoSQL数据库,并且在现代软件开发中得到了广泛的应用和验证,但二者在设计理念、应用场景等方面存在显著差异。对于刚接触 NoSQL 数据库的读者来说,这些差异可能会带来困惑。本文旨在为读者提供关于这两种数据库的详细信息,帮助大家更好地理解二者的区别,进一步根据自身开发团队的需求和业务应用场景,更有效地选择最合适的数据库解决方案。
数据模型
首先,我认为我们可以从数据模型开始聊起。所谓数据模型,指的就是我们向数据库中存储数据时,这些数据究竟以何种形式进行组织、存储。了解了数据模型,进而能窥探出数据库的设计思想,从而指导我们如何正确地去使用。例如 SQL 数据库在存储时,会将数据组织为表格的形式,同时表格还会附带若干属性约束,这就是典型的关系数据模型,如下图所示。
而 NoSQL 数据库本身是一个大的分类,其囊括了包含键值数据库、文档数据库、图数据库甚至时序数据库在内多种服务于不同需求的细分子类。本文中我们的目光将聚焦于 Redis 和 MongoDB 采用的不同数据模型,以及二者在架构上不同存储数据的方式。
Redis
Redis 将数据存储在 RAM 中,RAM 带来的优势就在于数据可以被快速访问,并能提供极低的延迟。不过由于 RAM 的特性,这种存储方式也限制了可以存储的数据量,无论是 HDD 还是 SSD,硬盘的单位存储价格始终远低于 RAM。而为了实现数据持久性,Redis 提供了两种机制:快照(Snapshot)和仅追加文件(AOF)日志记录,这两种方法可以将数据集保存在磁盘上,规避 RAM 易失性的缺陷。
Redis 使用键值对的形式存储数据,每个数据条目都有一个唯一的键(Key)。它支持多种数据类型,常用的包括有序集合(Sorted Set)、哈希(Hash)、无序集合(Set)、列表(List)与字符串(String)。键值对的大小被限制为不超过 512MB,不过通常我们在使用中会尽可能地避免使用较大的键值对。
Redis 还支持 Pub-Sub 或者流模式,这使其不仅仅是一个键值缓存系统。该功能允许在系统中实现消息队列等功能,额外的 Redis Model 支持也提供了缓存之外的拓展选项,不过这就是另一个独立的话题。
下图展示了 Redis 的数据模型。
MongoDB
MongoDB 是一种文档存储数据库,与传统的 SQL 驱动的关系数据库有显著不同。在关系数据库中,如上文所言,数据通常被简化为具有索引的 CSV 文件形式,每个文件代表一个表;而在文档存储中,数据则被简化为具有索引的 JSON 文件,每个文件对应一个文档,多个文档组合成一个集合。
JSON 文件的结构与 XML 和 YAML 文件类似,也类似于 Python 中的字典。因此,可以按照这种层次结构来组织和涉及数据。在 MongoDB 中,文档由已命名的键组成,而这些键可以包含其他文档、数组或标量值。举例而言,一个文档中可能包含一个键 Address.Street,其值为 123 Main St。你可以通过在索引中查找 Address.Street 等于某个值的文档集合来进行搜索。
{
_id: "5f4e3ab0b5d6",
Name: "Alice Johnson",
Address:
Street: "123 Main St",
City: "Springfield",
State: "IL"
Orders:
- "A1001"
- "B2002"
- "C3003"
}
MongoDB 还允许文档包含数组,例如 Orders 数组,其中可以包含多个订单信息。可以针对 Orders 数组的内容进行复杂的查询操作,比如查找包含某个特定值子集的文档。举例来说,如果 Orders 包含 ["A1001", "B2002"],查询 Orders includes "A1001" 会返回这个文档;而查询 Orders includes any of ["B2002", "C3003"] 则会返回包含这些订单中任一项的文档。
文档的嵌套层次越深,其灵活性和数据组织的能力越强。例如,Address 可以包含一个子文档 Geo,其中有 Latitude 和 Longitude 信息。如果业务的数据高度结构化,文档存储模型往往比关系数据库更具优势。
下图展示了 MongoDB 的数据模型。
什么情况下使用 Redis 或 MongoDB
以开发团队以及应用需求为导向
如果您的应用需要频繁的查询操作,Redis 中的数据通常存储在各种专门的数据结构中,为了优化性能,开发人员需要为每种类型的对象选择特定的数据结构。因此,选择 Redis 可能会带来一些额外的开发与适配工作。而在 MongoDB 中,由于其数据结构更加一致(JSON),类似的查询可能在实现层面上更加简单。不过事有两面,尽管在 Redis 中的查询或许需要处理多种数据结构,但这种些微复杂性带来的好处是响应速度的提升。Redis 的高性能可以弥补在查询处理上的额外工作量。
对于开发人员而言,尤其是那些拥有传统数据库和 SQL 背景的开发人员对 MongoDB 的接受程度或许会更好。虽然二者都是 NoSQL 数据库,但MongoDB 提供了一种更直观、更符合 SQL 习惯的方式来管理和查询数据。相较之下,Redis 虽然使用上完全称不上复杂,但以键值对为设计思想的存储模式,可能需要花费更多时间和精力去学习,但同样地,作为回报,Redis 也提供了更高的灵活性。
艾体宝高级工程师Eero认为,“就个人而言,我倾向于选择 Redis 来满足大多数需求。其高性能和灵活性使其在许多应用场景中相当有效。不过最终的选择,应该基于具体的应用需求和开发团队的技能组合。”
Redis
对于需要快速查询的临时数据存储,非常建议使用 Redis。Redis 能够提供对频繁访问的数据的快速响应,因此非常适合用作缓存或会话存储等场景。此外,Redis 内置了对发布-订阅(Pub/Sub)消息传递模式的支持(新发布的 Redis Stream 还在此基础上进一步做了改),其在实时应用程序或事件驱动架构中表现出众。Redis 还提供其它高级数据结构例如有序集合和列表,用于实现速率限制、任务队列与作业调度系统。最后,Redis 还能高效地对数据进行计数和汇总,也非常适用于跟踪排行榜数据或其他统计数据。
MongoDB
相比之下,MongoDB 适用于存储复杂的应用程序数据,尤其是大规模的数据集。其提供了更传统的数据库结构,同时支持无模式的存储,赋予了开发者相较于关系数据库更大的灵活性。MongoDB 能够有效地处理大量的写入和读取操作,常见的用例如内容管理系统或大规模的用户资料管理。
两者非此即彼吗?
恰恰相反。许多应用程序中,同时使用 Redis 和 MongoDB 是一种行之有效的策略。Redis 的高性能与 MongoDB 的长期存储能力相得益彰,得以显著优化数据库的整体性能,提高系统的可扩展性,并为应用程序提供更多的灵活性。
例如,Redis 的高速内存存储使其能够迅速捕获和处理实时数据流,非常适用于需要实时响应的场景。处理后的数据或结果,可以存储在 MongoDB 中,进行存档或用于更复杂的分析。该策略一方面能提高系统的响应速度,另一方面还能为数据的持久性和可扩展性提供额外的保障。
另一个常见的应用场景是跨 Redis 和 MongoDB 的混合数据模型。您可以利用 Redis 的键值存储来快速访问频繁使用的元数据,同时使用 MongoDB 处理更复杂的数据结构。如此,职责分明,Redis 提供低延迟的读取和写入操作,而 MongoDB 则处理复杂的查询和数据持久化。通过结合两种数据库的优点,进而构建一个既高效又灵活的系统,满足多种应用需求。
差异总结
Redis | MongoDB | |
数据模型 | 基于键值的内存数据存储 | 永久性的文档数据库 |
扩展性 | 通过水平扩展、分片和分区数据,提供可扩展性 | 通过水平扩展、分片和分区数据,具有高度可扩展性 |
可用性 | Redis Sentinel、Redis Cluster 或 Redis Enterprise 提供各层级高可用 | 默认情况下,自动进行失效转移 |
完整性 | 提供用于创建单个原子操作的命令,但对 ACID事务仅做到部分支持 | 内置对多文档ACID事务和回滚的支持 |
查询语言 | 使用自有的命令进行查询,主流语言客户端库支持 | 使用 MongoDB 查询语言(MQL)来查询和操作数据 |