存储类的应用,在扩容更多的节点后,数据是否应该被重新分配以保持平衡?

查看 44|回复 4
作者:RedisMasterNode   
比如有 5 个节点,哪一天因为容量不太够了(例如已经达到 70%了)想再加 5 个节点,那么加完之后:
  • 原本 5 个节点仍然是 70%,但是增速可以变慢 50%;
  • 新的 5 个节点是 0%,增速与上面一样;

    如果要重新分配:
  • 有一半数据要通过网络 IO 磁盘 IO 写来写去,可能很重,影响在线业务,也慢

    如果不重新分配:
  • 除非数据有过期淘汰机制,不然会一直不平衡

    咋整?
  • povsister   
    存储层单独抽象出来,不要和业务耦合。
    rebalance 过程要可观测可预测,做好限速。
    正经的存储中间件都是必须考虑 rebalance 的,你这个大概率手搓的吧。
    edenzhang   
    无他,做限流,做好跟业务 IO 的并发控制,优先保证业务
    这是分布式存储中的典型场景了,设计初期就应该要考虑到
    RedisMasterNode
    OP
      
    Attach 不了,在评论里补个上下文:
    是时序数据,例如监控指标,通常这些都会在一定时间后被删除(例如 3 个月,6 个月)
    有这个前提下考虑:
    - 做重平衡很重,而且如果没有重平衡其实数据过段时间自然就会平衡
    但是很多人又想要这样的功能(思考 ing
    实际上可以遇见的是,做出来算是一个复杂的特性,容易做错不说,错了肯定会被投诉,而且在上下文里总是觉得其实用户并不是真的需要这个功能,只是重平衡之后可以缓解容量焦虑(当然,也接受别人的不同观点,能理解)
    snipking   
    参考 mongodb sharding ,支持重新平衡,可以设置什么时间到什么时间允许进行重新平衡
    您需要登录后才可以回帖 登录 | 立即注册

    返回顶部