KeyDB on FLASH：容量规划和硬件配置
** 重要提示 - KeyDB FLASH 仍被视为 Beta（实验性）功能，应按此对待。在使用时请牢记这一点，并通过这里报告问题来帮助我们！ **
何时使用 KeyDB on FLASH#
KeyDB on FLASH 能大幅节省成本，并且可以保持非常高的性能。然而，在 RAM 和 FLASH 之间找到合适的平衡点，并理解 KeyDB on FLASH 的应用及其与您用例的关系，这一点非常重要。
NVMe SSD 速度非常快，但仍比 RAM 慢几个数量级，并且有其局限性。通过将 FLASH 与 RAM 结合，我们能够两全其美，从 RAM 中提供热数据，并将冷数据存储在 FLASH 上。
对于大多数用例，LRU 或 LFU 驱逐策略使您能够从 RAM 中提供大部分读取请求。这使得速度能够保持非常高，同时支持大容量存储。
性能预期#
RAM 与闪存的比例越高，您以更高速度和更大吞吐量提供服务的能力就越强。SSD 受限于写入操作，并且有不同的性能层级。持续的大量写入操作将导致性能下降。同样重要的是，不要超过磁盘能处理的写入量。如果能根据您的用例正确规划机器容量，并配合良好的 RAM 与 FLASH 比例，您将能够充分利用其优势，最大化吞吐量，同时显著降低内存消耗。
您可以在下面找到有关 AWS NVMe SSD 性能的更多信息。AWS 文档很好地解释了 IOPS 和硬件性能。请记住，针对您特定用例的实际 IOPS 可以通过测试确定。
R5: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/memory-optimized-instances.html
M5 及通用型: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/general-purpose-instances.html
如果您有大量数据和较低的 IOPS，FLASH 是一个轻松的选择，FLASH 与 RAM 的比例通常可以高得多。然而，如果您有非常高的流量和 IOPS，要求极快的速度，那么您的设置的容量规划和水平扩展需要仔细选择。
选择 RAM、FLASH 和机器大小#
在为您的机器选择 RAM 容量时，请考虑以下因素：
- 在任何给定时间，有多少数据被视为“热”数据。您绝对需要确保有足够的可用内存来最小化所需的磁盘读取比例。
- 我们建议将 50% 的内存（maxmemory 设置）分配给数据，如果您分配了类似大小的交换空间，则最多可分配 70%。这为系统操作以及在大量写入负载下 BGSAVE 期间可能分配的高达 30% 的空间留出了余地。
- 我们建议不要将 maxmemory 策略设置得太低。理想情况下，这至少应为几 GB。在启用集群模式时，这应至少设置为 2G。在运行较小实例大小的情况下，不建议低于 1G。RocksDB、后台保存以及副本输出缓冲区都需要开销，这使得拥有合理数量的闪存变得必要。
选择 FLASH 时请考虑以下因素：
- IOPS。这可能是与性能相关的最重要因素。查看磁盘制造商的设置，可以给您一个相对的性能预期，这可以通过负载测试来验证。通常这些数字着眼于初始和磁盘缓存性能。随着磁盘填充和在持续高负荷使用下，这些值通常会远低于发布的值。
- 了解您的写入负载并确保不会超过每台机器可用的 SSD IOPS 是很重要的。如果磁盘写入过载，这将大大增加延迟。因此，水平扩展集群的时机将更多地取决于写入，而不是其他任何因素。
- 不同的机器提供不同的 IOPS，不同的磁盘也是如此。查看预期情况非常重要。
- 您期望存储的总容量。如果您选择的机器的写入负载是可接受的，那么总的 SSD 容量将是您期望的总容量需求（可达 TB 级别）。
考虑您的备份卷
- 对于 AWS NVMe SSD，如果机器停止，它们可能会被分离，因此不被视为可靠的持久存储介质，即使在 KeyDB 故障时数据持久化在那里。因此，如果您使用 RDB 保存，应确保根 SSD 卷或 S3 存储桶的大小至少是您 FLASH 卷的 2.5 倍。这是因为旧的 RDB 会一直保留到新的 RDB 完成为止，这最多可能使用 RDB 大小的 2 倍空间。
选择机器大小/类型时请考虑以下因素：
- 对于 KeyDB FLASH，拥有更多核心有助于处理并发的读/写操作。
- 不同的机器有不同的配置 IOPS。请检查详细信息并进行测试以验证。
确定集群节点数量#
如果您有大量数据和较低的 IOPS，且不超过 SSD 限制，那么一个主从复制（active-replica）或大型单实例可能效果很好。
然而，如果您有更重的流量或需要相当大的 IOPS，您可能需要运行一个集群以实现 IOPS 的水平扩展。
您选择的节点数量很可能反映了您预期的写入操作。根据机器类型和 SSD 类型，您可以确定一个理想的设置，并在此基础上进行水平扩展。
最好先预测您想使用的机器大小/类型，然后进行测试以确保它能满足您的需求。之后再进行扩展/分片就很容易了。
FLASH 配置#
KeyDB 设置#
- maxmemory: 这个设置决定了分配给 KeyDB 的 RAM 数量。一旦设置，您 KeyDB 的 RAM 使用量将不会超过这个值。然而，在 BGSAVE 期间如果有传入流量，这个量会增加高达 30%。RAM 也可用于副本输出缓冲区，并配合此处使用的驱逐策略。我们建议将 maxmemory 设置为可用 RAM 的 50%（默认值）。但是，如果您将交换空间增加到与 RAM 相当的大小，您可以将 maxmemory 增加到 70%。如果增加得更高，则进入交换空间时会增加系统变慢的风险。同时请注意系统内存的使用情况以及可能被其他应用程序消耗的内存，尤其是在共享服务器上运行时。
- maxmemory-policy: 通常设置为
allkeys-lru（最近最少使用）或allkeys-lfu（最不经常使用）策略。这能很好地确保一个可工作的“热”数据集保留在内存中。也可以使用其他策略。 - maxmemory-samples: 这是驱逐时要选择的样本数量。默认值为 16，对于大多数使用 FLASH 的场景来说是一个很好的数值。如果需要，可以增加这个值（注意日志警告）。
SSD 设置#
我们推荐使用 ext4 文件系统，并采用以下挂载设置：
如果使用多个 SSD，请考虑将它们设置为 RAID 阵列。
如果您使用 AWS，您将需要在启动时通过 fstab（通常使用 UUID）重新挂载到您的 NVME 卷。
监控#
您可以使用常见的 Linux 工具，如 top、htop、iotop、df 等，来监控整个系统的 RAM 和 SSD 使用情况。
您还可以通过 KeyDB 的 INFO 命令获得具体的洞察。在这里您可以看到已使用的内存以及已使用的 FLASH 卷大小。
基准测试#
对于大多数依赖于在 FLASH 存储之外存储和提供热数据的用例，建议使用 memtier 的高斯分布模式，或者如果使用 YCSB 基准测试工具，则使用工作负载 "d"。
关于测试的说明： 请记住，memtier 有可能将 SSD 写入推到其极限之外。这可能导致测试期间延迟过高。您可能会注意到磁盘写入随着数据压缩和移动（在接近极限时）而出现波动。因此，如果您遇到这种情况，您可能需要降低写入比例，或减少使用的客户端/线程数。一旦您了解了写入极限，就可以用较小的负载进行测试，以获得实际的延迟情况。像 YCSB 这样的工具非常适合执行指定的负载然后测量延迟。
如果您预期大部分请求都会命中，请考虑在测试前预加载数据库。同时也要确保并非所有数据都保存在内存中。您可以通过请求数乘以数据大小来预测您正在存储的数据量。当您放入的数据超过 maxmemory 设置所允许的量时，额外的数据将完全存放在 FLASH 存储中。您可以通过 info 命令查询以查看有多少数据存储在 FLASH 中。
此测试中值得注意的 Memtier 参数：（所有参数请参阅 memtier_benchmark --help）
- -n, --requests=NUMBER : 每个客户端的请求数
- --ratio=RATIO : 设置与获取的比率。如果正在加载数据，您可以执行所有写入操作，例如 1:0。在测试期间，您需要一个有代表性的比率，例如 1:10 或 1:20。
- -d --data-size=SIZE : 指定数据大小。这有助于理解特定的基准测试和预测数据库大小。
- --data-size-range=RANGE : 您可以使用此参数来设定一个变化的数据大小范围，以帮助更准确地模拟工作负载。
- --key-pattern=PATTERN : 对于加载数据，您会希望使用 P:P 模式；对于测试，您可能希望使用 G:G 模式。P=parallel（并行），每个客户端有一个固定的键范围，因此它们不会重复写入。G=Gaussian（高斯）分布模式，代表了大多数工作负载。如果您使用 R=random（随机）模式，这最终将主要从磁盘读取，速度会变慢，但可能适用于那些不太可能从热数据集中读取太多数据的用例。
- --cluster-mode : 如果您在集群模式下运行 keydb，则需要此设置。
如果您的写入 IOPS 容量规划正确，并且没有超过 KeyDB 的处理能力，当主要从热数据层读取时，性能应保持相当快，同时允许一个很大的数据库大小，如这篇博客文章所示。
目前，KeyDB 将客户端连接在第一个线程上合并到 50 个，依此类推，以帮助减少大多数用例的延迟。如果您希望在工作负载中使用 50 个或更少客户端连接时确保 keydb 使用更多线程，您可以指定 KeyDB 配置文件选项 --min-clients-per-thread 0。
一个用 Memtier 填充数据库 2000 万个大小为 1024 字节的键的示例命令可能是：
测试一个使用高斯模式的常见工作负载：
在测试时，您可以调整参数以反映您预期的负载。
测试特定命令#
您可以使用 --command 标志通过 memtier 测试特定命令。然而，memtier 在集群模式下不支持此功能，因此必须在单个实例上完成。您可以运行多个命令并指定比率、模式以及自动生成的键和值。更多信息请参阅 memtier_benchmark --help。
示例：创建并读取一个哈希。设置一个有限的键 ID 范围和更大的请求数量，以确保哈希中的键值对数量增长。
key 和 data 的值由 memtier 生成。如果需要测试您的工作负载，可以尝试不同的组合。请记住，这可能需要使用特定的键前缀来执行，以确保您不会在现有数据类型上使用不正确的命令。