• 2013-05-02

    SSDB 双主(多主)同步模式现在 beta

    Views: 37661 | No Comments

    经过半个用的开发和测试, SSDB 发布了新版本 1.4.0. 这个版本最大的改进是重新设计了主从同步机制, 数据同步更安全, 另外还支持双主(多主)同步模式. 目前, 单主模式的主从同步功能是稳定的, 而双主(多主)模式从 experiment 升级到 beta 阶段.

    此次的更新包括:

    • 主从同步机制重新设计, 双主(多主)模式进入 beta 阶段
    • info 命令返回更多的统计信息, 包括每个命令的请求次数和消耗时间和等待时间
    • 升级为 LevelDB 1.9.0

    此次升级还探索了多线程处理模型, 将写操作或者读操作分配到独立的线程池中进行处理. 但经过测试, 性能下降了20%左右, 所以多线程处理模型没有被采用. 多线程处理模型的主要延时发生在 IO 线程将请求分配给工作线程的过程, 为了对处理线程的结果进行 select, 所以采用 pipe 进行消息传递. 但 pipe 延时在 10 us(微秒)左右, 这个成本非常大.

    SSDB 双主(多主)模式的使用文档: https://github.com/ideawu/ssdb/wiki/Replication#master-masterbeta

    Posted by ideawu at 2013-05-02 11:09:32 Tags: ,
  • 2013-03-22

    SSDB数据库的大规模应用

    Views: 33451 | 13 Comments

    SSDB是一个开源的高性能数据库服务器, 使用Google LevelDB作为存储引擎, 支持T级别的数据, 同时支持类似Redis中的zset和hash等数据结构, 在同时需求高性能和大数据的条件下, 作为Redis的替代方案.

    分布式

    因为SSDB的最初目的是替代Redis, 所以SSDB会经常和Redis进行比较. 我们知道, Redis是经常的"主-从"架构, 虽然可以得到负载均衡以及数据跨地域备份的功能, 但无法实现高可用性. 考虑这种情况, Redis的主和从分别在两个IDC机房, 当主所在的机房出现故障时, 整个服务其实就相当于停止了. 因为所有写操作都失败, 而应用一般不会实现自动降级服务.

    而SSDB支持"双主"架构(SSDB分布式架构: https://github.com/ideawu/ssdb/wiki/Replication), 两个或者更多的主服务器. 当其中一部分出现故障时, 剩余的主服务器仍然能正常接受写请求, 从而保证服务正常可用, 再将DNS解析修改之后, 就能在机房故障后立即恢复100%可用.

    实际应用

    SSDB最先在"IT牛人博客聚合网站"进行尝试应用, 接着在360游戏部门得到大规模应用, 目前支撑的数据量已经达到数百G. 这些应用最初使用Redis, 迁移到SSDB的成本非常低, 涉及的代码改动极小.

    你可以拿SSDB的PHP API文档Redis的PHP API文档进行对比.

    SSDB开源数据库项目地址: https://github.com/ideawu/ssdb

    Posted by ideawu at 2013-03-22 11:26:09 Tags: ,
  • 2012-11-05

    HBase 在 Linux 下安装和配置

    Views: 37767 | No Comments

    1. 下载安装包

    Hbase 官网下载页面下载安装包, 然后

    tar xfz hbase-0.94.2.tar.gz
    cd hbase-0.94.2
    chmod ugo+x ./bin/*.sh
    

    注意, 要修改 bin/ 目录下的脚本的的权限, 不然启动出错.

    2. 配置 hbase-env.sh 和 hbase-default.xml

    两个配置文件中的一个 hbase-env.sh 已经存在于 conf/ 目录下, 但 hbase-default.xml 并不在 conf/ 目录, 需要从 ./src/main/resources/ 目录拷贝
    Continue reading »

    Posted by ideawu at 2012-11-05 12:10:54 Tags: , , ,
  • 2012-10-30

    基于Redis构建系统的经验和教训

    Views: 42640 | 1 Comment

    Redis 是一个非常快速和强大的 Key-Value 存储(持久化)系统, 相对于一般的 NoSQL 存储系统, 它最大的特点是支持丰富的数据结构. 特别是其 zset(sorted set)数据结构, 堪称表达能力最强的结构之一(其它强大的数据结构如 sorted hashmap), 可以直接地表达业务逻辑.

    拿一个 Messaging(消息传递)系统来举例, 收件箱发件箱这样的业务逻辑直接用 zset 存储即可, 因为 zset 的每一个元素都有一个用于排序的权重值, 可以非常方便快速地地进行插入和删除操作. 如果使用纯粹的 KV 系统, 存储列表等非字符串结构的数据将是无尽的痛苦.

    由于 Redis 本身的限制, 它所能处理的数据必须完全放在内存中, 而硬盘上的数据是内存数据的一个镜像, 所以, 限制了它的容量不能超过内存的容量(VM 模式无实际意义, 已在新版本中去除). 当前, 服务器的内存以 32G 为普遍情况, 96G 算较好, 如果一个系统要存储 1T 的数据, 那么必须用上 10 台服务器, 硬件成本非常高 -- 且先不谈由此面临的软件的架构改动. 当前, 1T 的数据只能算零头, 对于一个100万活跃用户的系统, 平均每人每天产生 1K 数据, 便需要 1G 的存储空间, 这仅相当于每个用户每天只发10条微博或者10条聊天信息, 真正流行的系统将远远超过这个数据规模.
    Continue reading »

    Posted by ideawu at 2012-10-30 00:59:04 Tags: , ,
|<<<1>>>| 1/1 Pages, 4 Results.