如果你有非常重要的信息需要保护，以防数据损坏，该怎么办？如果你无法承受失去对这些信息的访问权限，又该怎么办？你应该如何存储数据，才能在需要时随时可用，同时保持其完整性？为了回答这些问题，我们 KeyDB 决定使用 Raft 算法，并计划在未来的 KeyDB 版本中实现它。

一个被长期要求但Redis 未实现的功能是为带有子成员的数据类型（如 SET 和 HASH）的单个成员设置过期时间。Redis 不添加此功能的理由对 Redis 来说是合理的，但 KeyDB 专注于提供一款高性能且易于使用的产品，而若无内置命令，尝试实现此功能会很困难，因此添加此功能是理所当然的。

KeyDB 最初尝试添加子键过期功能时，采用了一种直接的方法，即为每个过期项添加一个用于存储潜在子键过期的向量，但这导致了一些性能问题。在这篇博客文章中，我们探讨了这些问题的根本原因，以及我们如何使用更复杂的数据结构（如哈希表）来解决它们。

您是否曾担心在流量激增时数据库会如何反应？或者，随着日活跃用户数量的增长，您能否保持高性能？当您的软件能够达到惊人的速度时，您设置的每个部分都需要协同工作来支持这些速度。

KeyDB 速度很快，这意味着我们经常遇到这些问题。由于各种硬件瓶颈，可能难以达到最佳性能，这令用户感到沮丧。然而，硬件问题很难调试，我们需要一种方法来持续诊断这些问题。在寻求解决此问题的通用方案时，我们发现了以下内容。

为您的数据库引入 Cron 的强大功能#

当您设置数据库时，Cron 通常就在不远处……那么对于低延迟调用，为什么不让数据库来处理呢？

我们最近通过 KEYDB.CRON 命令引入了这个工具，它允许用户通过调度器在特定时间或按固定间隔执行 Lua 脚本。此功能是持久化的，并存储在本地，将调用从第三方工具带入数据库内部。

我们对 Redis 和 KeyDB 的 '6.0' 版本中新增的 TLS（传输层安全）支持感到非常兴奋。TLS 数据库连接是纵深防御持续趋势的一部分，这一趋势由来已久，最早始于2013年谷歌加密其数据中心之间的链接。

不幸的是，在 Redis 中，TLS 带来了 36-61% 的大幅性能下降。虽然安全很重要，但在性能上做出妥协可能并非总是可行的选择。我们仔细考虑了 KeyDB 中的 TLS 实现，以防止我们的用户遇到这种情况。通过利用 KeyDB 的多线程架构，我们能够保持性能，实现了近 100 万次操作/秒的速度，比 Redis TLS 实现快 7 倍以上。

SCAN 是一个用于查询数据的强大工具，但其阻塞性质在大量使用时会破坏性能。KeyDB 改变了此命令的性质，使其性能提升了几个数量级！

本文探讨了使用 SCAN 命令的局限性及其对性能的影响。它展示了 Redis 出现的严重性能下降，并介绍了 KeyDB 如何通过实现 MVCC 架构来解决这个问题，使 SCAN 变为非阻塞式，从而避免了对性能的任何负面影响。

人们经常问，Elasticache、Redis 和 KeyDB 哪个更快。随着支持多线程 I/O 的 Redis 6 即将发布，我们觉得是时候进行一次全面比较了！本博客比较了 Elasticache、开源 KeyDB 和开源 Redis v5.9.103（6.0 分支）的单节点性能。我们将使用不同的工具，在不同负载下考察吞吐量和延迟。

我仍然记得开车两个小时去取“附近”唯一有货的 Ryzen 3900X。AMD 终于打破英特尔在高端 CPU 上的垄断，那种兴奋感是会传染的。从那时起，它几乎处理了我交给它的所有任务，但我总觉得我运行的大多数软件仍然只为英特尔优化。这些 CPU 的性能非常出色，但如果软件专门为它们优化，性能能好多少呢？

我们一直对 Arm 充满热情，所以当亚马逊为我们提供他们新的基于 Arm 的实例的早期访问权限时，我们抓住机会想看看它们能做什么。我们当然指的是由 AWS Graviton2 处理器驱动的 Amazon EC2 M6g 实例。其宣称的性能和围绕 Graviton2 的热议让我们迫不及待地想看看我们的高性能数据库会有怎样的表现。

本文比较了KeyDB 在几种不同的 M5 和 M6g EC2 实例上的运行情况，以深入了解成本、性能和用例优势。数据非常令人兴奋，AWS Graviton2 名副其实，希望您会喜欢！

开源数据库存在一个商业化问题，即使是这些公司自己也承认这一点。在宣布其新的专有许可证时，MongoDB 声称这是必要的，否则云服务商可能会“攫取所有价值”。Redis Labs 也非常担忧，他们觉得有必要更改许可证以维持“云时代的 可持续业务”。当这些公司放弃开源转向专有许可证并将责任归咎于他方时，我们不禁感觉到，问题不在于许可证和云服务商等外部力量，而在于他们采取的商业化方法。