SSDB VS redis

现在有不少团队开始使用了一个新型高效的 NoSQL数据库 - SSDB,如 京东、唱吧 ……

SSDB 官网的定义

一个高性能的支持丰富数据结构的 NoSQL 数据库,用于替代 Redis

官网 http://ssdb.io/zh_cn

特点

兼容 Redis,支持 Redis 客户端

有与 Redis 一样丰富的数据结构,如 list,hash,zset...

使用Google LevelDB作为存储引擎, 支持T级别的数据

客户端支持的语言丰富,如 C++,PHP,Python,Java,Go

主从复制,负载均衡

性能

官网给出的SSDB与Redis的性能对比

get操作

set操作

从官方数据看,SSDB的性能很突出,与Redis基本相当了,Redis是内存型,容量问题是弱项,并且内存成本太高,SSDB针对这个弱点,使用硬盘存储,使用Google高性能的存储引擎LevelDB,适合大数据量处理并把性能优化到Redis级别,具有Redis的数据结构、兼容Redis客户端,还给出了从Redis迁移到SSDB的方案。

那么接下来我在一台测试服务器上分别对Redis与SSDB做性能测试,但是结果是SSDB比Redis差了很多,与SSDB官网上显示的对比数据相差较大

预料到SSDB会弱于Redis,但没想到差这么多,可能是测试数量不同,或者是我的服务器硬件配置不利于SSDB等原因导致的

测试条件

测试命令

SET GET HSET HGET

请求数

1000000 一百万

并发数

1000 一千

QPS 结果数据

SET

Redis    38017.03

SSDB    10386

GET

Redis    37855.84

SSDB    11097

HSET

Redis    40673.55

SSDB    8830

HGET

Redis    39021.34

SSDB    10429

时间: 2024-08-03 07:33:59

SSDB VS redis的相关文章

转:SSDB:快速取代redis的nosql

原文来自于:http://hao.jobbole.com/ssdb%EF%BC%9A%E5%BF%AB%E9%80%9F%E5%8F%96%E4%BB%A3redis%E7%9A%84nosql/ SSDB是一个开源的高性能数据库服务器, 使用Google 的 LevelDB作为存储引擎, 大家有可能没听过leveldb的名字,但是淘宝的开源nosql tair大家应该有所耳闻吧,他也是基于leveldb做的开发.ssdb支持T级别的数据, 同时支持类似Redis中的zset和hash等数据结构

Redis/SSDB+Twemproxy的配置与使用(Mac/Linux平台)

对于redis而已,相信不少的后台开发人员一直都在使用,相比memcache而已,redis不仅可以作为key-value缓存使用,而且提供了丰富的数据结构如set.list.map等,能够实现很多复杂的功能,但是Redis本身主要作用是内存缓存,不适合做持久化存储到磁盘,所以目前出现了很多基于磁盘存储的组件,如:SSDB.ARDB. LevelDB.LMDB.beansDB等 Twemproxy是一个Redis/Memcached代理中间件,可以实现诸如分片逻辑.HashTag.减少连接数等功

电商初级技术方案探讨

一. 电商技术栈 主流:  nginx + lua  ???   待验证 from   http://www.infoq.com/cn/articles/e-commerce-web-tech-stack 二 .  java方案 前端分移动端(Android.IOS).PC端,业务层开放restful接口给前端调用,http协议json传输数据,前后端分离,分开部署,接口文档工具采用了阿里的rap,减少前端后端人员的沟通成本.其中前端主要nginx分流,当然,还没用现在主流电商采用的nginx+

测试人机问答系统智能性的3760个问题

本文给出了3760个问题,这些问题来自于广大网友对QuestionAnsweringSystem的测试. 在面对这些问题的时候,我们人类是怎么思考回答的呢? 对我们来说,回答这些问题是一个很自然甚至很简单的思考过程,可是我们却很难把我们的思考过程严格地描述清楚.我们从小到大,积累了很多的经验和知识,这些经验和知识来自我们的社会实践和学校学习. 我们所处的世界不是完美的,我们本身也不是完美的,人与人的相互交流也不是完美的,我们经常需要反复地沟通,尽管这样,有时候我们还是不能完全理解对方的意思,有可

使用VS2010编译MongoDB C++驱动详解

最近为了解决IM消息记录的高速度写入.多文档类型支持的需求,决定使用MongoDB来解决. 考虑到MongoDB对VS版本要求较高,与我现有的VS版本不兼容,在leveldb.ssdb.redis.hbase等NoSQL中转了一圈,最后还是选择了MongoDB,应了那句话:没有最好的,只有最合适的. MongoDB由于使用了C++的新特性,官方建议使用VS2013来编译,最低要求VS2010. MongoDB C++驱动编译过程较为复杂,官方也没有提供编译好的驱动包,网上的资料编译版本都比较老了

爬虫IP代理池

下载安装 下载源码: git clone [email protected]:jhao104/proxy_pool.git 或者直接到https://github.com/jhao104/proxy_pool/releases 下载zip文件 安装依赖: pip install -r requirements.txt 配置Config/setting.py: # Config/setting.py 为项目配置文件 # 配置DB DATABASES = { "default": { &q

发布一个参考ssdb,用go实现的类似redis的高性能nosql:ledisdb

起因 ledisdb是一个参考ssdb,采用go实现,底层基于leveldb,类似redis的高性能nosql数据库,提供了kv,list,hash以及zset数据结构的支持. 我们现在的应用极大的依赖redis,但随着我们用户量越来越大,redis的内存越来越不够用,并且replication可能还会导致超时问题.虽然后续我们可以通过添加多台机器来解决,但是在现有机器配置下面,我们仍希望单台机器承载更多的用户.另外,因为业务的特性,我们其实并不需要将所有的数据放到内存,只需要存放当前活跃用户.

跨平台轻量级redis、ssdb代理服务器(C++ 11编写)

dbproxy 是我业余采用C++11编写的跨平台代理服务器(并使用lua和自己的网络库),以扩展系统负载,同时使用多个后端数据库,后端数据库支持redis和ssdb. 需要由用户自己编写lua脚本控制sharding.测试效率比codis略高,且占用更少的CPU和内存. 下面是github上的readme,我直接拷贝下来: 介绍 dbproxy是一个采用C++11编写的代理服务器,支持redis和 ssdb数据库. 其主要用于扩容和提高系统负载.使用lua控制sharding,把不同的key-

redis和ssdb读取性能对比

最近关注了一下ssdb,他的特点是基于文件存储系统所以它支撑量大的数据而不因为内存的限制受取约束.从官网的测试报告来看其性能也非常出色和redis相当,因此可以使用他代表redis来进行k-v数据业务的处理.想法总是美好的,不过现实中就可能非常骨感. 以于针对Redis和ssdb的几个读操进行一个简单的性能测试对比,这个测试不是直接在本机调用Redis和ssdb. 而是通过一个程序在别的服务器上调用.测试指令(get,hget,lregion)以下是测试结果截图 测试代码 private voi