单实例支撑每天上亿个请求的SSDB

2013-08-26

单实例支撑每天上亿个请求的SSDB

Views: 46583 | 22 Comments

SSDB 是一个 C++ 开发的 NoSQL 存储服务器, 支持 zset, map 数据结构, 可替代 Redis, 特别适合存储集合数据. SSDB 被开发和开源出来后, 已经在生产环境经受了3个季度的考验, 一直稳定运行.

在一个支撑数千万用户的列表数据(例如用户的订单历史, 用户的好友列表, 用户的消息列表等)的实例上, SSDB 每天处理上亿个读写请求, 仍然能保持 CPU 占用在3%左右, 内存占用为 1G. 这种数据规模是我们原来使用的 Redis 所无法满足的, 因为 Redis 无法保存如此大量的数据, 物理内存的容量限制了 Redis 的能力. 根据我们的经验, Redis在10G数据规模时比较适用, 数据规模再扩大时, Redis 就非常吃力, 而且几乎无法扩展. 这时, 必须改用 SSDB.

SSDB 具有和 Redis 高度重合的 API, 而且对于 hash(map) 还是可分段遍历的, 相比较, Redis 只能通过 hgetall 一次遍历 hash 中的所有元素, 在大的 hash 中, 这个操作非常低效.

如果要列出几条必须放弃 Redis, 改为使用 SSDB 的观点, 我相信这几条非常有吸引力:

单个实例的存储容量相当于 100 个 Redis 实例!
内存占用只有 Redis 的一千分之一(最大设计容量时).
所有的数据集合(包括 KV)都是可分段(分页)遍历的.
特别适合存储列表等集合数据.

SSDB 是一个开源的项目(https://github.com/ideawu/ssdb), 你可以免费获取它的源码, 并且不需要编程和修改配置文件就可以启动服务器.

Posted by ideawu at 2013-08-26 23:18:10 Tags: NoSQL, Redis

22 Responses to "单实例支撑每天上亿个请求的SSDB"

lucky 2015-12-10 at 09:55:57

楼主你看,为什么我测试ssdb 和redis 仅仅是简单的set 和 get的效率 ssdb是7000/s redis是15W/s 同一台机器，请问下是我ssdb配置的有问题吗，我用的是github上最新的代码和配置 set的是很简单的数据比如key1.. value1…这样子的数据 Reply
xiezhaohui 2015-10-20 at 13:23:09

在测试一亿条数据的批量插入，读取，删除，都是以 1000的个数进行操作，发现后面删除的时候，基本上跑不动了，是什么原因呢？ Reply
xiezhaohui 2015-10-20 at 13:21:26

could not open data db: ./var_slave/data ,强制退出后，报错？该如何解决啊？ Reply
Tomw 2015-03-23 at 10:21:29

博主你好：
我在实际应用中有大量的读操作，几乎没有什么写的需求。请问我用KV还是hashmap来存储数据效率更好一些。 Reply

ideawu 2015-03-23 at 10:34:48

@Tomw: 用 map 存储更方便管理. Reply
raul 2014-10-20 at 00:03:50

大师，你好，
如果缓存命中率极低的情况下,也就是说所有的请求都走ssd，而在缓存中没有，这个怎么测试QPS呢，我把levaldb 的 cache size 设置为0, 这样我得出来的QPS是1W7左右，不知道这样测试是否正确。 Reply
竿子 2014-05-06 at 12:01:55

大师，你好。我还有个疑问就是 ssdb配置的缓存最好为1GB吗？你好像说如果缓存配置的过大会影响写性能？那么意思是最好不要把可用的物理内存都分配来用作ssdb的缓存（比如32g物理内存）？那应该配置为多少合适呢？ Reply

ideawu 2014-05-06 at 13:48:28

@竿子: 根据你的配置(32G内存), 可以配成4G cache. Reply
万老湿 2014-02-19 at 22:22:32

当我使用一个进程写的时候性能我比较满意，key=32字节，value约15k，set一万次约1.2秒，偶尔有一万次set耗时11秒的情况，这个效率用在生产环境完全可行。
在这种情况下再开一个进程随机读取，每一百随机get操作耗时约3秒，同时set进程停止输出，我是一万次set或get打印下执行时间，所以不清楚set一万次需要多少时间，反正时间很长

而在我的业务环境里面会在一个进程里面随机读取和写入，同时也有很多并发的进程

就在写入和随机读取的效率来看似乎不适合使用在生产环境中

请问博主，我是哪里配置错了么？或者是有32位机和64位的区别？
我需要提供我的测试脚本和配置文件么？ Reply

ideawu 2014-02-20 at 00:22:47

@万老湿: 一般的生产环境只有突发的每少1万次请求, 而且持续时间很短. 正常情况是非常少的, 大概在一千以内. 所以, 你所测试的压力相比实际生产环境还是相差比较大的.

不知道你是在压测了多少时间才出现阻塞的情况, 是在一个空的实例里很快就出现吗? 还是在一个实例里总共写了很多数据时才突然出现?

另外, 麻烦你用 ssdb-cli 连接服务器, 然后执行 info 命令, 把输出结果反馈给我. 多谢. 可以的话, 把测试脚本和配置文件发到我的邮箱(在页面头部菜单的"关于"链接里有). Reply

万老湿 2014-02-20 at 01:00:06

@ideawu: 在没有get的情况下set的效率我很满意，估计没有set的get效率我也很满意

在我的业务里面每次页面的request可能需要set操作500次，get操作1000次

在我的测试中，我先运行set的测试脚本后开始写get的测试脚本，运行get测试脚本时大约已经set 350万数据，当开启get测试后，set测试立即停止输出，效率明显下降，关闭get测试脚本后set测试需要经过50秒插入3万次后恢复正常

另外，在64位机器上启用压缩后插入数据程序会崩溃 Reply

ideawu 2014-02-20 at 10:36:02

@万老湿: 崩溃的问题, 应该是你编译过程新老代码交叉导致的. 你重新建一个新目录, 获取 SSDB 代码, 编译一个新的 ssdb-server.

根据你的描述, 当你*连续*写了3.5M条数据, 每条15K时, 其实已经连续写了近50GB的数据. 如果非常快速且持续地往 SSDB 写入数据(例如导大量数量), 会触发 SSDB 的写保护机制, 阻塞写一段时间. 但线上环境极少需要经常导大量数据.

你可以重新弄一个新的库, 然后同时启动set测试和get测试. Reply
Afred 2014-02-09 at 16:44:02

楼主，我在windows下用JMeter压ssdb，200线程ssdb-server就挂掉了，需要提供dump文件给你吗？ Reply

ideawu 2014-02-09 at 23:26:06

@Afred: 不用了. ssdb 设计在 Linux 操作系统上使用, 在 windows 只作为开发目的. Reply

Afred 2014-02-10 at 21:29:07

@ideawu:

好的，谢谢 Reply
zzz 2013-09-30 at 09:23:04

redis可能的缺点在于单机和容灾方面相对比较弱吧。内存我们生产系统有超过24G的也没什么问题，
但是从资料看，目前redis在容灾方面不是特别完善. Reply

ideawu 2013-09-30 at 09:47:43

@zzz: 24G 的空间也许看起来多, 但只是对于小型个人站来说. 其实, 24G真的不值一提, 对于我们根本不到一个月的数据就超过这个容量. Reply
lb 2013-09-15 at 22:13:30

楼主你好：
我想请教，你所说的“. 根据我们的经验, Redis在10G数据规模时比较适用, 数据规模再扩大时, Redis 就非常吃力, 而且几乎无法扩展. ”，这个是你们真实生产环境遇到的么？我们现在的架构就是redis和ssdb组合的，但redis中的数据可能会超过10g。 Reply

ideawu 2013-09-15 at 23:30:07

@lb: Redis的存储能力确实是个很大的问题, 我们在实际使用中就遇到, 所以我们目前在慢慢把Redis从通用存储改为cache服务, 或者是可预见的小服务(如小于1G数据)来使用. 大存储(T级)我们会使用SSDB, 而更大规则的数据, 如离线log统计得, 我们会使用hbase.

Redis在超过10G数据时的问题, 主要表现为读取和写入速度变慢, 有时一个zadd()操作会达到几秒. 之所以说Redis不可扩展, 是因为它的key是无法分段遍历的, keys 操作会将服务器锁死数十秒, 所以只能停机维护, 和迁移数据. 所以, 我们根据经验, 认为Redis的存储能力为10G. Reply