idea's blog

SSDB 是一个 C++ 开发的 NoSQL 数据库, 使用 Google 公司开源的 LevelDB 引擎作为底层的存储引擎. Redis 是一个 C 语言开发的内存 NoSQL 数据库.

Redis 非常流行, 不仅仅是因为其高性能和可持久化的特点, 还因为它支持丰富的数据结构, 能很好的表达业务模型. Redis 的国内属新浪应用比较广泛.

但是, Redis 的缺点也很明显, 那就是它的内存数据库模型. 所有数据都存在内存中, 即使最有钱的互联网公司, 也没法承受 $5000 (一台服务器, 100G 内存)固定成本, 以及持续不断的 IDC 租金成本来存储区区的 50GB 的数据, 这个成本太高了!

SSDB 拥有 Redis 的主要优点 - 高性能, 丰富数据结构, 并且拥有 Redis 所不具备的能力 - 大数据存储能力. SSDB 服务器的单机存储能力是 Redis 的 100 倍! 因为 SSDB 能将数据存储在硬盘中.

在使用 SSDB 自带的 ssdb-bench 工具, 以及 Redis 自带的 redis-benchmark 工具在相同机器上的测试中, SSDB 的读性能完全超过了 Redis, 这非常出乎意料. 不过, SSDB 的写性能还是比 Redis 慢了 10% 左右. 要知道, SSDB 是一个硬盘数据库, 而 Redis 是内存数据库, 后者写性能高一些是可以理解的.

欢迎各位在自己的机器上做性能测试, 并反馈. 下面我做的测试的结果图.

机器信息: MacBook Pro, Retina, 13-inch, Late 2012

Continue reading »

从 1.6.4 版本开始, SSDB 采用里程碑式的版本发布机制, 每一个稳定的版本都会作为 git 库中的一个 branch, 而 master 的代码是最新的待发布的代码. 在 github 项目主页, 默认显示的是最新的稳定版本的分支. 目前, 最新的 SSDB 稳定版本是 stable-1.6.4.

目前, master 上的代码相对 stable-1.6.4 版本, 有了比较大的改动, 加入了多线程支持. 例如, scan 等命令都会在单独的线程中执行, 所以, 即使 scan 非常大的数据, 也不会阻塞别的操作.

SSDB 是一个 NoSQL 数据库, 兼容 Redis 接口, 存储容量是 Redis 的 100 倍以上, 采用 LevelDB 作为存储引擎. 项目地址: https://github.com/ideawu/ssdb

今天在 Redis 的 maillist 里看到一个帖子, 说的是某数据库(HyperDex)和 Redis 的性能对比. 说实话, 这个数据库的网站我看过, 没有深究, 后来就不再关注了. Redis 的作者 Salvatore Sanfilippo 有一条说的我比较认可:

2) In all the other tests, probably they are comparing single-core
Redis with multi-core HyperDex, or multi-node HyperDex. To give you an
example Redis LPUSH can easily insert 1 million items per second into
lists, but if you push against four instances at the same time, one
per core, you can reach 3/4 million inserts per second. This does not
mean we should write "four millions operations per second11!1!!!one"
in our home page.

简单翻译一下:

单个 Redis 实例每秒能处理 1 百万次 LPUSH 操作, 但是, 如果你启了 4 个 Redis 实例, 那当然能每秒处理 3 到 4 百万次插入. 但我们绝不会在网站首页写"每秒 4 百万次操作!!!".

Zrank/zrrank 命令是 zset 数据结构的一个特有命令, 用于求某个元素在集合中的排序名次. 对于 Redis 来说, 数据都在内存里, 而且是排序的, 所以求元素的排名(indexOf)可以很快, 但因为 SSDB 的数据主要在硬盘中, 所以, 求排序名次可不是那么简单.

基于这个考虑, SSDB 原来并不支持 zrank 命令. 但 zrank 命令的需求还是有的, 经过考虑, 所以在 1.6.3 版本中增加了 zrank 命令.

不过, 使用这个命令应该是在离线环境中, 而不能是在线上生产环境中, 因为 zrank 的实现是通过遍历数据(相当于全表扫描).

另外, SSDB 还增加了 zrange/zrrange 命令, 相当于数组的 slice 操作或者 MySQL 的 limit 操作. 和 zrank 类似, zrange 也是通过表扫描来实现的, 只要 offset 越大, 速度就越慢. 所以, 在 offset 小于 200 时, 可以在线上生产环境使用, 否则最好是离线环境中使用.

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

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

Continue reading »

在一个网站广告系统中, 需要针对每一个用户所接受的弹窗次数和点击次数这两个重要指标进行统计, 从而进行效果分析和精准投放的改进. 这两个指标的统计算法其实非常简单, 主要的难点在于大数据量. 广告系统的涉及的用户量达到数千万人, 每天的日志数据量是几亿条.

最开始的想法是使用 MySQL 数据库, 不过这个方案马上就被否, 因为如此大量数据已经远远超过 MySQL 的存储能力, 必定带来许多无谓的问题.

第二个方案是使用 Redis. Redis 是内存存储方案, 速度快, 而且 zset 数据结果存储列表数据非常方便, 能直接地统计用户的弹窗次数和点击次数. 不过, Redis 本身的局限就是它最多能存储不超过内存容量的数据, 对于一台 100G 内存的服务器, Redis 最好是存储不超过 30G 的数据量. 因此, Redis 的方案在运行了短时间之后也被否定了.

第三个方案是使用 SSDB. SSDB 可以存储 TB(1000GB) 级别的数据, 并且支持列表等集合数据结构, 有着和 Redis 高度兼容的 API, 所以, 当从 Redis 迁移到 SSDB 时, 改动非常小.

每一个用户的弹窗历史用一个 zset 来存储, key 是时间戳, 对应的 score 也是时间戳, 因为我们只关心用户的弹窗历史, 具体的弹窗信息会用 map 来存储(时间戳作为 key, 对应弹窗信息 value). SSDB 的 zset 支持根据 score 范围来查询, 所以只需要一条命令就能算出用户在任意时间段内的弹窗次数.

用户的点击统计也是类似.