低延迟的SSD键值存储

Question

14

我们正在开发一个基于SSD的键值存储方案，具有以下特性：

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

下面的图片说明了KyotoCabinet的这种行为（横轴是时间，可以清楚地看到三个时期-只读，混合，仅更新）。

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

enter image description here

- user1128016

2

这是一个很好的问题，但它不适合在SO上讨论，因为它实际上是一个讨论串（超出了SO的范围）。它与编程没有直接关系，我也不确定它适合在哪里讨论。 - Jim Garrison

2

正如我所说，这是一个好问题，但与编程没有直接关系。你可能会在[sf]或[dba.se]上获得更好的反响。 - Jim Garrison

你尝试过多少不同的SSD供应商？ - Brian Cain

你的预算门槛是多少？（我认为FusionIO产品不属于你的“商品”类别） - Benedetto

你需要随机访问非当前（即旧的，因此它们已从RAM刷新到SSD）记录吗？还是只需从RAM读/写并异步地以较大批量写入SSD就可以了？ - pi.

显示剩余2条评论

4个回答

2

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

SSD具有很好的随机读取访问能力，但减少写入方差的关键是使用顺序IO（这类似于普通硬盘）。它还大大降低了在SSD上进行大量写入时可能发生的磨损平衡和褪色。

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

- Mani Gandham

0

这是一个有点冒失的想法，但它可能会起作用。假设您的SSD为128GB。

内核能否足够快地将东西分页进出？无从得知。这更取决于您的硬件而不是内核。

Poul-Henning Kamp在Varnish中执行非常类似的操作，通过使内核跟踪Varnish的事物（虚拟内存与物理内存）来代替让Varnish执行此操作。 https://www.varnish-cache.org/trac/wiki/ArchitectNotes

- Mike Sandford

0

NuDB是专门为您的用例而设计的。它具有O(1)的插入和查找功能，无论数据库变得多么大。目前，它正在为rippled提供服务，使用9TB（9太字节）的数据文件。该库是开源的，仅包含头文件，并且只需要C++11 https://github.com/CPPAlliance/NuDB。

- Vinnie Falco

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Dan B · Accepted Answer

高度变异的写入延迟是SSD（尤其是消费者型号）的常见属性。这篇AnandTech评论有一个相当好的解释。

简而言之，随着磨损均衡开销的增加，SSD的写入性能会随时间恶化。随着驱动器上可用页面的数量减少，NAND控制器必须开始碎片整理页面，这会导致延迟。 NAND还必须构建一个LBA到块映射以跟踪数据在各个NAND块之间的随机分布。随着这个映射的增长，映射上的操作（插入、删除）将变得更慢。

你无法通过软件方法解决低级硬件问题，你需要升级到企业级SSD或放宽延迟要求。