• 2013-11-20

    Facebook rocksdb 的网络服务器支持

    Views: 32888 | No Comments

    前几天, 我初探了 Facebook 开源的 rocksdb, 一个据称比 Google leveldb 性能强劲数倍的 KV 存储引擎. 虽然 rocksdb 提供了压测数据, 不过对于 rocksdb 是否名副其实, 以及它在不同的应用场景下有什么特点, 有没有坑, 我还是保留疑问的.

    为此, 需要对我们常见的使用的场景也做压测. 首先, 必须给 rocksdb 封装网络支持, 也即 client-server(C/S) 支持. 我直接使用了 ssdb 的源码, 几乎很少的代码改动就运行起来了. 因为 rocksdb 本来就是基于 leveldb 的, 函数名都几乎一样.

    我直接使用 ssdb 的源码对 rocksdb 进行封装, 也是考虑和原来的 ssdb 做对比. 稍微透露一下, 在空库的条件下测试, rocksdb 作为存储引擎时的性能比使用 leveldb 时有所下降. 不过, rocksdb 的官方测试数据都是在超过 RAM 的大数据场景下测的, 所以接下来, 我还要对各种场景进行测试.

    ssdb-rocks 项目地址: https://github.com/ideawu/ssdb-rocks

    Posted by ideawu at 2013-11-20 00:38:24 Tags: ,
  • 2013-11-17

    性能超越 Redis 的 NoSQL 数据库 SSDB

    Views: 52722 | 34 Comments

    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 »

    Posted by ideawu at 2013-11-17 22:44:56 Tags:
  • 2013-11-17

    Facebook 开源的 rocksdb 初探

    Views: 31454 | 3 Comments

    Facebook 最近开源了一个 NoSQL 存储引擎 rocksdb. 这个开源引擎是基于 Google 的 leveldb 1.5 版本, 但据称做了许多优化, 性能相对 leveldb 有了很大的提升, 而且解决了 leveldb 主动限制写的问题.

    为了试验 rocksdb 是否能应用于 ssdb, 以及换了 rocksdb 之后 ssdb 是否有明显的性能提高, 所以我下载了 rocksdb 的源码来试着编译一下.

    有几点需要注意的. 首先 rocksdb 用了 C++11 的特性, 所以需要升级你的 gcc/g++ 为 至少 4.8 版本. 编译过程还发现, rocksdb 在 Mac OS X 操作系统下无法正常编译, 尝试解决了一个问题, 又出现另一个问题. 因为官方没有考虑过这些问题, 所以暂还无法在 Mac 下使用. 所以, 我还在等待 Facebook 官方升级 rocksdb.

    所以, rocksdb 初探意外终止.

    2013-11-17 17:16 更新:

    官方已经解决了编译问题, 我将进行下一步试验.

    Posted by ideawu at 14:59:15 Tags: ,
  • 2013-10-23

    SSDB 增加 zrank, zrange 命令

    Views: 35833 | 6 Comments

    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 时, 可以在线上生产环境使用, 否则最好是离线环境中使用.

    Posted by ideawu at 2013-10-23 13:05:07 Tags: , , ,
  • 2013-10-22

    C++ hash_map(unordered_map)和map性能对比

    Views: 13746 | 2 Comments

    C++ STL 的 hash_map(unordered_map) 理论上能达到 O(1) 的查找速度, 而 map 是 O(log(N)). 一般会认为, map 比 hash_map 慢, 但是, 具体慢多少呢? 和元素个数有关系吗? 有没有直观的数据?

    为此, 我写了一个简单的测试程序, 分别在 100, 1000, 10000, 10000 个元素时, 对两种 map 进行查找, 对比下耗时. 结果如下:

    items  type     timespan  timestamp
    100    map      +0.432037 1382373147.689263
    100    hash_map +0.140390 1382373147.829653
    1000   map      +0.672411 1382373197.151690
    1000   hash_map +0.152739 1382373197.304429
    10000  map      +0.928384 1382373219.558242
    10000  hash_map +0.185142 1382373219.743384
    100000 map      +1.512256 1382373371.041342
    100000 hash_map +0.373361 1382373371.414702
    

    可以看到, 在元素数量较少时(1000 以内), hash_map 的速度是 map 的 3 到 4 倍. 而元素数量达到 10000 或者更多时, hash_map 的速度是 map 的 5 倍. 这就是直观的感受.

    补充了插入速度:

    100    build_map      +0.001180 1382443114.467226
    100    build_hash_map +0.000371 1382443114.467597
    1000   build_map      +0.002165 1382443150.065571
    1000   build_hash_map +0.001629 1382443150.067200
    10000  build_map      +0.012238 1382443170.254071
    10000  build_hash_map +0.019952 1382443170.274023
    100000 build_map      +0.121713 1382443188.696912
    100000 build_hash_map +0.204433 1382443188.901345
    

    可以看到, map 的插入速度比 hash_map 快速, 可以认为是 2 倍.

    Posted by ideawu at 2013-10-22 00:38:17
  • 2013-10-17

    SSDB 的 C++ 客户端接口

    Views: 31947 | 11 Comments

    SSDB 本身是用 C++ 语言编写的, 所以天生就支持 C++ 客户端 API. SSDB 源码中自带的 leveldb-import.cpp, ssdb-dump.cpp 等程序, 也是 C++ 客户端的例子. 不过, 这些 API 依赖整个项目, 编译和链接的参数非常繁琐. 因此, 有必要开发对用户友好的 C++ API, 减少依赖, 方便开发 SSDB 的 C++ 客户端应用.

    我很高兴的通知, 接口简单, 对用户友好的 SSDB 的 C++ 客户端 API 已经有了! 并且, 有了相应的 API 文档(我相信文档对于一个软件的作用是非常重要的). 我可以用一行代码了显示这个 API 的使用是如何的简单:

    g++ -o hello-ssdb hello-ssdb.cpp libssdb.a
    

    hello-ssdb.cpp 就是一个使用了 SSDB C++ API 的客户端程序, 上面的一行命令用于编译这个程序, 生成可执行文件.

    SSDB C++ API 包括了两类方法, 一类是简单方法, 另一类是语义化的方法. 简单方法就是在一个统一的函数中传递任意命令和参数. 而语义化的方法即类型 get(), set() 这样顾名思义的方法. 因为时间的缘故, 后一种方法还没有实现.(更新: 两类方法都已实现.)

    欢迎大家使用, 如果有什么意义, 欢迎反馈!

    SSDB C++ 客户端接口文档: http://www.ideawu.com/ssdb/docs/cpp/

    Posted by ideawu at 2013-10-17 23:27:05 Tags: , ,
|<<<123456789>>>| 5/12 Pages, 71 Results.