Redis 8 来了——而且它是开源的
了解更多
最近，一家知名的 NoSQL 供应商宣布为其数据库产品添加了内存功能。将内存功能引入其数据库产品，采用混合方法的决定引发了一些严重担忧。Redis，作为内存型、开源、键值存储，为现代应用世界提供了许多见解。一个特别引人注目的观察是，具有内存能力的数据库存在固有需求。因此，各领域的 NoSQL 供应商一直在努力利用磁盘数据库和内存数据库的优势。
在 Redis，我们认为这种混合方法是错误的。我们的担忧源于这样一个事实：采用这种方法的供应商无法成功提供像 Redis 这样纯内存型数据库为现代应用带来的优势。在 Salvatore Sanfilippo 的最近一篇文章中，他列出了数据库性能的三个重要因素，包括延迟、操作速度和操作质量。以下是基于我们支持数万个现代应用所获得的经验，用现实生活场景阐述这三个因素。
在深入探讨这些性能组件之前，我想分享我们进行的一项内部研究结果，该研究比较了多个流行的 SQL 和 NoSQL 数据库的性能。如下图所示，内存数据库性能显著更好，这一点毫无疑问。
NoSQL 和 SQL 响应性能比较
所有内存系统都可以通过三个主要标准来衡量：延迟、吞吐量和效率。与 Sanfilippo 提到的数据库性能三个重要因素类似，在这些标准上表现出色使得 Redis 等内存数据库比它们的基于磁盘的竞争对手性能显著更好。正因为如此，内存数据库对于现代、可伸缩的应用和实时处理至关重要。
1 – 延迟：现代应用要求从请求到达应用到处理完成、应用生成响应并返回给用户的时间延迟约为 100 毫秒。为了实现这一目标，数据库层面必须保持稳定在亚毫秒级延迟，这只能通过直接从内存中检索所有数据的内存数据库来实现。
2 – 吞吐量：如今，应用性能需要即时扩展。以一个拥有 100 万粉丝的 Twitter 账户为例。一条旨在瞬间触达 100 万人的推文会立即产生 100 万次并发写入，并需要立即扩展。这类事件随时可能发生，没有任何事先预警，给系统带来了巨大挑战。
像这样的场景需要能够即时横向扩展的基础设施。自动扩展无法满足要求，因为为现有集群配置额外的节点可能需要几分钟时间。而且，仅仅为了应对高峰时期的请求而构建一个完整的 NoSQL 基础设施成本非常高昂。因此，越来越多的开发者正在使用 Redis 从零开始设计实时应用。
3 – 效率：尽管内存数据库可能非常快，但如果它持续在数据库和应用之间传输大量原始数据，其性能仍然会很差。对原始数据进行冗余处理不仅浪费资源，还会增加延迟。此外，这种原始数据传输可能会阻塞整个网络基础设施，需要增加节点来维持网络速度。
利用 Redis 独特的数据类型和命令，可以构建一个 schema，使数据库经过调优后能够直接处理应用请求，无需在应用层面进行任何额外的处理。这种智能设计显著减少了传输的数据量。
右侧的图表展示了我们一位客户的实际场景。如果没有 Redis，他们需要构建一个由 150 多个节点组成的集群来支持 120 Gbps 的网络速度。此外，他们还需要在应用层面增加工作量。而 Redis 使用一个六节点内存集群，网络速度为 1.5 Gbps，且在应用层面无需额外工作。
试图通过向不兼容的数据库添加内存功能来解决 Redis 已经解决的问题，注定会失败。
在 Redis，我们信奉最佳实践（best-of-breed）方法。没有理由只满足于一种数据库类型，无论是内存型还是基于磁盘的。现代、可伸缩的应用应以确保每个组件都利用合适的数据库的方式进行设计。
（作者注：非常感谢 Salvatore Sanfilippo 富有成效的交流，这些交流促成了本文中的想法。）
