ZHGDG_HOA.6_分布式元数据快速同步算法

 ZHGDG_HOA.6_分布式元数据快速同步算法

140511 #GDG #Zhuhai
分布式元数据快速同步算法

6002ee051e03f0b762642ee7fafd111f?s=128

Zoom.Quiet

May 12, 2014
Tweet

Transcript

  1. 一种分布式系统元数据 快速同步算法 廖杰 richard.liao.i@gmail.com https://github.com/richardliao

  2. 目录 背景 1 1 实现 2 2 效率分析 3 3

    问答 4 4
  3. GDG livin ZhuHai life ;-)

  4. 背景 1 1

  5. 背景 • 开源项目 swarmstorage • https://github.com/richardliao/swarmstorage • Content Addressable 分布式对象存储

    • 用golang编写
  6. 背景: 系统特性 • 分布式 • 存储content addressable对象 • 对象内容不可修改 •

    去POSIX文件系统
  7. 背景: 系统特性 • Storage POD

  8. 背景: 系统特性 • 超大规模 • 去中心化 • Shared nothing •

    高读写性能 • 高扩展性 • 高可用 • 运维友好
  9. 背景: CAP理论 • 大多数系统 – 选择最终一致性,以确保可用性和读写性能 – 复杂 – 脆弱

  10. 背景: CAP理论 • swarmstorage – 做减法 – 专注存储的核心 – 确保可用性和读写性能

    – 同时确保数据的高强度一致性 – Content Addressable数据本身
  11. 元数据 • 节点存储的文件对象的哈希值 • 存储在每个节点内存中 • 用于查询文件对象 • 用于副本节点间同步文件对象

  12. 元数据同步需求 • 元数据的数据量大 • 同步频率高 • 动态修改

  13. 征求算法 • 大家的想法?

  14. rsync同步算法 • 内容变化后,需要重新计算 • 同步时不能改变内容

  15. BloomFilter • 可以支持动态数据 • 同步需要传输完整的过滤器集合,数据量较大 • 进行数据匹配时,计算量巨大 • False Positive问题

  16. ODS(Orthogonal Digest Sync)算法 • 支持动态变化的内容同步 • 内容变化后,同步计算量极小 • 可以实时计算同步数据 •

    同步数据量小 • 同步数据量稳定 • 适用于高度同步的节点间, 定时同步少量变化状态
  17. 实现 2 2

  18. 正交摘要 • 元数据摘要: 对原始数据在某个维度的投影 • 对原始数据在正交的多个维度上进行投影 • BloomFilter

  19. 摘要算法 • 每条元数据(哈希值)为20字节字符串 • 全体元数据按固定bucket分割 • 摘要数据是离散的 • bucket数量: 分辨率

    • 第1,2维度没有数据重叠: 正交 • 第1个维度: 取前2个字节,共分割为65536个 bucket • 第2个维度: 取后2个字节
  20. 摘要算法 • 对每个bucket内的元数据 • 计算CRC32值, 4字节 • 每个维度字节:65536*4 = 262144

    • 全部维度字节: 262144*2 = 524288, 512KB
  21. 更新摘要 • 增加文件对象 • 删除文件对象 • 更新对应bucket的摘要值

  22. 更新摘要 • 假设每个分区大小为3T, 平均每个文件1M, 存储 的元数据 – 3T/1M = 3145728

    – 3145728*40/(1024*1024) = 120MB • 对象均匀分布 • 需要更新48个对象个数 – 3145728/65536 = 48 • 需要计算的字节数 – 48*20*2 = 1920字节的CRC32
  23. 同步摘要 • 源节点将一个分区的完整摘要推送到目标节点 • 目标节点按相同维度对比,过滤出元数据 – 有差异的摘要 – 同时出现在2个维度 –

    即可能在源节点缺失的元数据(False Negative) • 返回差异的元数据 • 源节点跟本地元数据匹配,发现真实缺失的文件 对象
  24. 效率分析 3 3

  25. 适用场景 • 适用于高度相似的节点同步 • 如果差异对象1024个, 多传输元数据(False Negative) – (1024/65536)^2 =

    1/4096 – 3145728*1/4096 = 768 个 – 768*20 = 15360, 15KB
  26. 中度适用场景 • 如果差异对象8192个, 多传输元数据 – (8192/65536)^2 = 1/16 – 3145728*1/16

    = 196608 个 – 196608*20 = 3932160, 3.9MB
  27. 劣化场景 • 如果节点间差异的文件对象超过一定数量,效率 急剧劣化 – 如果差异对象超过65536 – 每个bucket都有差异,则需要返回所有元数据

  28. 同步内容中速变化 • 同步时间为1秒 • 千兆网络, 全部写入一个分区 • 128新文件/秒 • 多传输元数据

    – (128/65536)^2 = 1/512 – 3145728*1/512 = 6144 个 – 6144*20 = 122880, 120KB
  29. 同步内容高速变化 • 同步时间为1秒 • 10千兆网络, 全部写入一个分区 • 1280新文件/秒 • 多传输元数据

    – (1280/65536)^2 = 1/51 – 3145728*1/51 = 61680 个 – 61680*20 = 1233600, 1.2MB
  30. 适应更快速变化 • 增加维度 – 取3个维度 – 摘要总量 256*256*4*3 = 786432,

    786KB – 准确度提高256倍 – 劣化情况无明显改善
  31. 适应更快速变化 • 提高分辨率, 增加bucket数量 – 取2.5个字节, 1048576 – 适用变化场景提高 16*16

    = 256倍(327680新文 件/秒) – 摘要总量 256*256*16*4*2 = 8388608, 8MB – 劣化情况明显改善
  32. 问答 4 4

  33. 祝: 码不停提 !-) Happy Hacking

  34. blog.zhgdg.org