2014-10-26

SSDB 分布式的一些想法

Views: 23388 | 15 Comments

到目前为止, SSDB 还是一个单机存储方案, 存储容量受到单机硬盘的限制, 虽然 SSDB 可以自动压缩数据, 将存储容量提高 10 倍以上, 但还是在 TB 级别. 不少 SSDB 的用户一直在呼唤 SSDB 分布式, SSDB 集群, 但是千呼万唤不出来. 为什么?

分布式数据存储是一个真正的技术难道, 不说各种理论, 最简单的是数据怎么迁移. 想想, 原来你只有一个存储节点, 但数据多了之后, 硬盘存不下, 这时怎么把一部分数据迁移到另一个新的存储节点? 这就是数据迁移问题. 这其实是2个问题:

1. 一份数据应该存储在哪个节点? 原有的节点, 还是新加入的节点?
2. 在什么时机, 用什么手段来迁移? 如何保证迁移的过程不影响服务?

有些同学一听到分布式数据存储, 就言必称"一致性哈希", 遇到这种人我只有一个字 - 滚!

所谓的"一致性哈希"只解决了上面的问题1, 而且仅仅是解决问题1的众多方案中的一种, 也不是最好的一种. 而对于分布式数据存储来说, 解决了问题1, 只不过是解决了万分之一, 只是皮毛. 你言必称"一致性哈希", 不让你滚蛋还能怎么样?

怎么解决数据迁移?

方案一: 引入唯一的 proxy

引入了唯一的 proxy 之后, 所以有请求必须通过 proxy, 那么就可以在 proxy 上做数据迁移, 迁移中的数据如果被请求到, 就先挂起请求, 快的话, 只需要挂起几百毫秒.

这种方案就是 twemproxy 采用的. 缺点也很明显, proxy 很容易成为瓶颈.

方案二: 停机维护

这种方案看起来比较土. 当我的存储空间不够的时候, 我就把网站停了, 然后人工操作, 写脚本导数据. 数据导完后, 再采用著名的"使用者自己分布式(客户端分布式)".

--------

还有更多的方案, 欢迎大家讨论. SSDB 不会采用 proxy 方式, 因为这种方式大概只能支撑两三台这个量级的"集群". 如果采用方案二, 那么 SSDB 集群将可以支持无限庞大.

说实话, 集群不集群这两个概念有时很模糊. 例如, 某个公司部署了数千个 Redis 实例, 这些实例可能分为几个一组, 支持不同的业务, 但对外宣传, 却可以把"千个实例的集群"作为噱头. 如果这种也算集群, 那么全世界的所有 MySQL 实例就是一个"十万个实例的集群", 全世界的 PC 机和笔记本也是一个"数十亿实例的集群", 等等, 虽然不是每一个实例都同意被归在集群里.

我的意思是说, 你不能在想象中把多个没有联系的实例划到一起, 就叫做"集群".

但是, SSDB 会做分布式数据存储集群, 因为在设计中, 这个群集的所有节点之间是有直接联系的, 数据可以在集群节点间迁移.

对于一个集群, 能动态的添加新节点, 或者某一个节点从集群中移除, 这是最基本的特性, 没有这个特性就不能称为"集群"! SSDB 分布式将从最基本的特性开始, 第一步先提供方便地增删存储节点的功能.

Related posts:

  1. 性能超越 Redis 的 NoSQL 数据库 SSDB
  2. SSDB 支持 Redis 协议!
  3. 使用 Twemproxy 来做 SSDB 负载均衡
  4. 从 Redis 迁移到 SSDB
Posted by ideawu at 2014-10-26 12:03:25 Tags: ,

15 Responses to "SSDB 分布式的一些想法"

  • 同意博主的看法,数据分布各种方法可以解决,如何迁移数据才是重中之重。自己想了下,毫无头绪。。 Reply
  • 我们的初步想法是用容量和热度自动分布,ZK做confif server Reply
    @ruochen: 还是普遍认为数据是一致性均匀分布在各节点的比较OK,那么迁移比较容易完成 Reply
    @ruochen: 基于容量和热度的分布式, 难度更大了. Reply
    @ideawu: couchbase的vbucket机制可以很好的实现容量平均分布,,如果能做到自动迁移的话那就很厉害了,手动迁移也是可以接受 Reply
  • 集群的动态迁移是最难实现的事情,之前代理层的问题,是不是可以参考lvs dr模式?这样性能可以得以保证。目前来说,ssdb的用户对数据范围扫描和聚合的需求还是很少吧? Reply
    @saver: 用户对KV的范围扫描需求其实很少. 如果有这个需求, 都会换成 HASH 了. Reply
    动态迁移的问题是不是可以参考mongodb的设计,但是这样的话,数据分布就需要有config节点来完成,提供多重分布方式,而不是仅仅靠算法来做了。 Reply
    @saver: config server 几乎是跑不掉的. Reply
    将热数据均匀分布在多个节点上,是我们目前集群要解决的问题,数据的冷热统计就成了重中之重,没有这些,就没法去谈数据迁移了,提供手动数据迁移的方式也是我们的选择之一,目前我们用的是最傻的tw双节点,轮流重启的模式去解决数据迁移的问题 Reply
  • 博主可以参考redis 3.0的分布式方案,集群数据被分成若干bucket,每个节点保存若干bucket的数据,节点内部保存了bucket和key的映射关系,存储节点负责数据迁移.
    另外也可参考淘宝tair,也是使用leveldb的分布式存储.有专门的中心节点负责集群路由表,通知存储节点进行迁移工作 Reply
    @lili: 谢谢你提供的信息. 其实如何分布数据, 无论是bucket, 或者所谓的"一致性哈希", 都只解决了问题1. 最重要的还是问题2, 也即在什么时机, 用什么手段迁移数据? Reply
    @ideawu: 你说的是,数据如何分布只是第一步.
    迁移数据的时机和手段确实需要仔细考虑.在线上环境部署过tair,说一些可能会有坑的地方:1.在迁移数据的过程中如果再次发生节点故障 2.迁移数据操作的对磁盘的压力可能会影响实时的读写 这些细节供你实现时参考
    至于迁移数据的具体方法,我觉得可以像目前的zset结构一样,在leveldb存储时key前面加上分布式信息的前缀(类似于其他系统中的bucket号等),迁移数据时用这个前缀在leveldb中扫描需要迁移的数据. Reply
    @lili: 非常感谢你的经验分享, 非常有帮助! Reply
    @ideawu: 另外,迁移数据会带来大量的写操作,如果leveldb compaction不够快,造成leveldb level 0文件数达到限制,导致实时写操作被阻塞.这部分我们也踩过坑,供您参考. Reply

Leave a Comment