众所周知的 Redis 性能

最近，一家已知的 NoSQL 供应商宣布在其数据库产品中添加内存功能。决定在其数据库产品中采用混合方法引起了若干严重的担忧。Redis（内存中、开源、键值存储）已经为现代应用程序的世界提供了许多见解。特别引人注目的一个观察结果是，具有内存功能的数据库具有内在的需求。因此，NoSQL 供应商一直在勤勉地努力，以利用磁盘和内存数据库的好处。

在 Redis 中，我们认为这种混合方法是错误的。我们的担忧源自使用这种方法的供应商无法成功地提供 Redis 等仅具有内存功能的数据库已经引入到现代应用程序的好处。Salvatore Sanfilippo 在其最近的 文章 中列出了数据库性能的三个重要因素，包括延迟、操作速度和操作质量。以下真实生活场景根据我们从支持成千上万个现代应用程序中获得的经验对这三个因素进行了举例说明。

在深入研究这些性能组件中的每一个之前，我想分享我们所做的内部研究结果，以比较许多流行的 SQL 和 NoSQL 数据库的性能。如下所示，毫无疑问，内存数据库的性能显着提高了。

NoSQL 和 SQL 响应性能比较

三个主要标准

所有内存系统都可以根据三个主要标准进行测量：延迟、吞吐量和效率。与 Sanfilippo 的三个重要的数据库性能因素类似，在这些标准上表现出色可以使内存数据库（如 Redis）的性能明显优于其磁盘竞争对手。正因为如此，内存数据库已经成为现代可伸缩应用程序和实时处理的关键。

1 - 延迟：现代应用程序要求从请求到达应用程序到应用程序处理并生成响应并将其返回给用户时的延迟约为 100 毫秒。为了实现这一目标，数据库级别必须以稳定的亚毫秒延迟执行，而这只能由从 RAM 中直接检索所有数据的内存数据库来完成。

2 - 吞吐量：如今，应用程序性能需要立即进行扩展。以一个拥有 100 万粉丝的 Twitter 帐户为例。准备让 100 万人看到的单条推文可以立即生成 100 万次同时写入，并且需要立即扩展。这些类型的事件会持续不断地发生，并且没有任何事先警告，从而给系统带来了严峻挑战。

这些场景需要基础架构能够立即扩展。自动扩展无法完成工作，因为为现有集群设置其他节点可能需要数分钟。而建立整个 NoSQL 基础设施仅仅为了满足高峰时期的请求则非常昂贵。因此，越来越多的开发人员完全从头开始使用 Redis 来设计实时应用。

3 - 效率：虽然内存内数据库可能是非常快的，但如果它一直在数据库和应用程序之间传输大量原始数据，它的性能仍会持续较差。原始数据的冗余处理不仅浪费了资源，还增加了延迟。此外，这种原始数据传输可能会阻塞整个网络基础架构，需要添加节点以维持网络速度。

使用 Redis 特有的数据类型和命令，可以按照这种方式构建架构：根据应用程序请求，无需任何额外处理，即可调整数据库。这种智能设计大幅减少了传输的数据量。

右侧的图表说明了来自我们一个客户的实际场景。如果没有 Redis，他们可能需要建立一个 150 个以上的节点集群来支持 120 Gbps 的网络速度。此外，他们的应用层需要更多时间。Redis 使用六个内存在内存节点集群、1.5 Gbps 以及无应用层额外工作的方式运行。

选择适当的数据库

试图添加不兼容数据库中内存功能来修复 Redis 已解决的问题注定会失败。

在 Redis，我们相信最佳实践方法。没有理由只满足于一种类型的数据库，无论是基于内存还是基于磁盘。现代可扩展应用程序应该按照一种特定的方式设计，以确保每个组件都利用适当的数据库。

（作者注：非常感谢 Salvatore Sanfilippo 提供卓有成效的对话，指引了这篇文章中的观念。）