13

我们正在开发具有以下属性的 SSD 支持的键值解决方案：

  • 吞吐量：10000 TPS；50/50 看跌/获得；
  • 延迟：平均 1 毫秒，第 99.9 个百分位数 10 毫秒
  • 数据量：约 10 亿个值，每个约 150 字节；64位密钥；随机访问，20% 的数据适合 RAM

我们在商品 SSD 上尝试了 KyotoCabinet、LevelDB 和 RethinkDB，使用不同的 Linux IO 调度程序、ext3/xfs 文件系统；使用Rebench进行了许多测试；并发现在所有情况下：

  • 只读吞吐量/延迟非常好
  • 仅写入/仅更新始终处于中等水平，但有许多高延迟异常值
  • 即使在直接访问块设备（绕过文件系统）的情况下，混合的读/写工作负载也会导致吞吐量/延迟的灾难性波动

下图说明了 KyotoCabinet 的这种行为（横轴是时间，三个周期清晰可见 - 只读、混合、仅更新）。

问题是：是否有可能使用 SSD 实现描述的 SLA 的低延迟以及推荐哪些键值存储？

在此处输入图像描述

4

4 回答 4

3

高度变化的写入延迟是 SSD（尤其是消费模型）的一个常见属性。在这个AnandTech 评论中有一个很好的解释。

总结是随着磨损均衡开销的增加，SSD 写入性能会随着时间的推移而恶化。随着驱动器上的可用页面数量减少，NAND 控制器必须开始对页面进行碎片整理，这会导致延迟。NAND 还必须构建 LBA 到块映射，以跟踪数据在各种 NAND 块中的随机分布。随着地图的增长，地图上的操作（插入、删除）会变慢。

您将无法使用软件方法解决低级硬件问题，您将需要升级到企业级 SSD 或放宽延迟要求。

于 2013-02-06T16:23:38.987 回答
1

Aerospike是一种较新的键/值（行）存储，可以完全在 SSD 上运行，读/写延迟小于 1 毫秒，TPS 非常高（达到数百万）。

SSD 具有出色的随机读取访问权限，但减少写入差异的关键是使用顺序 IO（这类似于常规硬盘）。它还大大减少了在 SSD 上进行大量写入时可能发生的磨损均衡和褪色。

如果您正在构建自己的键值系统，请使用日志结构的方法（如 Aerospike），以便批量写入并以大块的形式附加/写入。内存索引可以维护值的正确数据位置，而后台进程从磁盘清理过时/删除的数据并整理文件碎片。

于 2015-12-25T19:14:52.603 回答
0

这是一种轻率的想法，但它可能会奏效。假设您的 SSD 为 128GB。

  1. 在 SSD 上创建一个 128GB 的​​交换分区
  2. 配置您的机器以将其用作交换
  3. 在机器上设置 memcached 并设置 128GB 内存限制
  4. 基准

内核是否能够足够快地将内容分页进出？没办法知道。这更多地取决于您的硬件而不是内核。

Poul-Henning Kamp 在 Varnish 中做了与此非常相似的事情，它让内核跟踪 Varnish 的事物（虚拟与物理内存），而不是让 Varnish 去做。 https://www.varnish-cache.org/trac/wiki/ArchitectNotes

于 2012-12-06T20:46:04.903 回答
0

NuDB 专为您的用例而设计。无论数据库有多大，它都具有 O(1) 的插入和查找功能。目前，它使用 9TB（9 TB）的数据文件来满足 Rippled 的需求。该库是开源的，只有标头，并且只需要 C++11 https://github.com/CPPAlliance/NuDB

于 2019-04-05T23:13:54.907 回答