相关疑难解决方法(0)

SSD的低延迟键值存储

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

  • 吞吐量:10000 TPS; 50/50看/得;
  • 延迟:平均1ms,99.9百分位10ms
  • 数据量:约10亿个值,每个约150个字节; 64位密钥; 随机访问,20%的数据适合RAM

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

  • 只读吞吐量/延迟非常好
  • 整个写入/更新是适度的,但有许多高延迟异常值
  • 即使在直接访问块设备(绕过文件系统)的情况下,混合读/写工作负载也会导致吞吐量/延迟出现灾难性的振荡

下图说明了KyotoCabinet的这种行为(横轴是时间,三个周期清晰可见 - 只读,混合,仅更新).

问题是:是否可以使用SSD实现所描述的SLA的低延迟以及建议使用哪些键值存储?

在此输入图像描述

database performance solid-state-drive key-value nosql

10
推荐指数
1
解决办法
2573
查看次数

在Berkeley DB中优化性能

几天前我刚开始玩Berkeley DB所以我试图看看在尽可能快地存储数据时是否有一些我一直缺失的东西.

以下是有关数据的一些信息: - 它有512个字节的块 - 块按顺序排列 - 块将按FIFO顺序删除 - 如果我因为电源故障而丢失一些数据,只要整个数据库不是'破了

在阅读了一堆文档之后,看起来像Queue db正是我想要的.

但是,在尝试了一些测试代码后,我的最快结果大约是每秒1MByte,只需循环通过DB-> put with DB_APPEND set.我也尝试过使用交易和批量看跌期权,但这些都放慢了速度,所以我没有追求它们很长时间.我插入了在我的飞思卡尔i.MX35开发板上的NANDFlash芯片上创建的新数据库.

由于我们希望每秒至少获得2MB的写入速度,我想知道是否有一些我错过的可以提高速度的东西,因为我知道我的硬件可以写得比这更快.

berkeley-db

6
推荐指数
1
解决办法
4664
查看次数