Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ZHGDG_HOA.6_分布式元数据快速同步算法
Search
Zoom.Quiet
May 12, 2014
Technology
0
150
ZHGDG_HOA.6_分布式元数据快速同步算法
140511 #GDG #Zhuhai
分布式元数据快速同步算法
Zoom.Quiet
May 12, 2014
Tweet
Share
More Decks by Zoom.Quiet
See All by Zoom.Quiet
PyCon2014China-Zhuhai-high performance
zoomquiet
0
120
PyCon2014China-Zhuhai-meta programming
zoomquiet
1
91
PyCon2014China-Zhuhai-bpm.py
zoomquiet
0
66
PyCon2014China-Zhuhai-luna kv db
zoomquiet
0
69
PyCon2014China-Zhuhai-seed studio
zoomquiet
0
46
PyCon2014China-Zhuhai-Docker Registry Build By Python
zoomquiet
0
57
PyCon2014China-Zhuhai-jeff
zoomquiet
0
46
PyCon2014China-Zhuhai-pythonic front-end
zoomquiet
0
61
DevFest2014-Zhuhai-Polymer
zoomquiet
0
310
Other Decks in Technology
See All in Technology
VS CodeでAWSを操作しよう
smt7174
8
1.7k
Postman v10リリース後を振り返る / Looking back at Postman v10 after release
yokawasa
1
160
SIEMを用いて、セキュリティログ分析の可視化と分析を実現し、PDCAサイクルを回してみた
coconala_engineer
0
340
Compose Compiler Metricsを使った実践的なコードレビュー
tomorrowkey
1
220
推しは推せるときに推せ! プロダクトにフィードバックしていこう
nakasho
0
320
開発生産性大幅アップ!Postman VS Code拡張機能
nagix
2
390
AOAI をきっかけに 社内の Azure 管理を見直した話
recruitengineers
PRO
1
300
ChatworkのSRE部って実は 半分くらいPlatform Engineering部かもしれない
saramune
0
160
JSON攻略法.pdf
miyakemito
8
5.1k
エンジニアのキャリアをちょっと楽しくする3本の軸/Three Pillars to Make an Engineer's Career More Enjoyable
kwappa
0
2.7k
自己改善からチームを動かす! 「セルフエンジニアリングマネージャー」のすゝめ
shoota
6
800
Gitlab本から学んだこと - そーだいなるプレイバック / gitlab-book
soudai
4
440
Featured
See All Featured
Git: the NoSQL Database
bkeepers
PRO
422
63k
A Tale of Four Properties
chriscoyier
151
22k
The Brand Is Dead. Long Live the Brand.
mthomps
49
29k
Principles of Awesome APIs and How to Build Them.
keavy
121
16k
Fashionably flexible responsive web design (full day workshop)
malarkey
398
65k
Faster Mobile Websites
deanohume
299
30k
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
Creatively Recalculating Your Daily Design Routine
revolveconf
210
11k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
659
120k
The Cult of Friendly URLs
andyhume
74
5.7k
What's in a price? How to price your products and services
michaelherold
237
11k
Build your cross-platform service in a week with App Engine
jlugia
225
17k
Transcript
一种分布式系统元数据 快速同步算法 廖杰
[email protected]
https://github.com/richardliao
目录 背景 1 1 实现 2 2 效率分析 3 3
问答 4 4
GDG livin ZhuHai life ;-)
背景 1 1
背景 • 开源项目 swarmstorage • https://github.com/richardliao/swarmstorage • Content Addressable 分布式对象存储
• 用golang编写
背景: 系统特性 • 分布式 • 存储content addressable对象 • 对象内容不可修改 •
去POSIX文件系统
背景: 系统特性 • Storage POD
背景: 系统特性 • 超大规模 • 去中心化 • Shared nothing •
高读写性能 • 高扩展性 • 高可用 • 运维友好
背景: CAP理论 • 大多数系统 – 选择最终一致性,以确保可用性和读写性能 – 复杂 – 脆弱
背景: CAP理论 • swarmstorage – 做减法 – 专注存储的核心 – 确保可用性和读写性能
– 同时确保数据的高强度一致性 – Content Addressable数据本身
元数据 • 节点存储的文件对象的哈希值 • 存储在每个节点内存中 • 用于查询文件对象 • 用于副本节点间同步文件对象
元数据同步需求 • 元数据的数据量大 • 同步频率高 • 动态修改
征求算法 • 大家的想法?
rsync同步算法 • 内容变化后,需要重新计算 • 同步时不能改变内容
BloomFilter • 可以支持动态数据 • 同步需要传输完整的过滤器集合,数据量较大 • 进行数据匹配时,计算量巨大 • False Positive问题
ODS(Orthogonal Digest Sync)算法 • 支持动态变化的内容同步 • 内容变化后,同步计算量极小 • 可以实时计算同步数据 •
同步数据量小 • 同步数据量稳定 • 适用于高度同步的节点间, 定时同步少量变化状态
实现 2 2
正交摘要 • 元数据摘要: 对原始数据在某个维度的投影 • 对原始数据在正交的多个维度上进行投影 • BloomFilter
摘要算法 • 每条元数据(哈希值)为20字节字符串 • 全体元数据按固定bucket分割 • 摘要数据是离散的 • bucket数量: 分辨率
• 第1,2维度没有数据重叠: 正交 • 第1个维度: 取前2个字节,共分割为65536个 bucket • 第2个维度: 取后2个字节
摘要算法 • 对每个bucket内的元数据 • 计算CRC32值, 4字节 • 每个维度字节:65536*4 = 262144
• 全部维度字节: 262144*2 = 524288, 512KB
更新摘要 • 增加文件对象 • 删除文件对象 • 更新对应bucket的摘要值
更新摘要 • 假设每个分区大小为3T, 平均每个文件1M, 存储 的元数据 – 3T/1M = 3145728
– 3145728*40/(1024*1024) = 120MB • 对象均匀分布 • 需要更新48个对象个数 – 3145728/65536 = 48 • 需要计算的字节数 – 48*20*2 = 1920字节的CRC32
同步摘要 • 源节点将一个分区的完整摘要推送到目标节点 • 目标节点按相同维度对比,过滤出元数据 – 有差异的摘要 – 同时出现在2个维度 –
即可能在源节点缺失的元数据(False Negative) • 返回差异的元数据 • 源节点跟本地元数据匹配,发现真实缺失的文件 对象
效率分析 3 3
适用场景 • 适用于高度相似的节点同步 • 如果差异对象1024个, 多传输元数据(False Negative) – (1024/65536)^2 =
1/4096 – 3145728*1/4096 = 768 个 – 768*20 = 15360, 15KB
中度适用场景 • 如果差异对象8192个, 多传输元数据 – (8192/65536)^2 = 1/16 – 3145728*1/16
= 196608 个 – 196608*20 = 3932160, 3.9MB
劣化场景 • 如果节点间差异的文件对象超过一定数量,效率 急剧劣化 – 如果差异对象超过65536 – 每个bucket都有差异,则需要返回所有元数据
同步内容中速变化 • 同步时间为1秒 • 千兆网络, 全部写入一个分区 • 128新文件/秒 • 多传输元数据
– (128/65536)^2 = 1/512 – 3145728*1/512 = 6144 个 – 6144*20 = 122880, 120KB
同步内容高速变化 • 同步时间为1秒 • 10千兆网络, 全部写入一个分区 • 1280新文件/秒 • 多传输元数据
– (1280/65536)^2 = 1/51 – 3145728*1/51 = 61680 个 – 61680*20 = 1233600, 1.2MB
适应更快速变化 • 增加维度 – 取3个维度 – 摘要总量 256*256*4*3 = 786432,
786KB – 准确度提高256倍 – 劣化情况无明显改善
适应更快速变化 • 提高分辨率, 增加bucket数量 – 取2.5个字节, 1048576 – 适用变化场景提高 16*16
= 256倍(327680新文 件/秒) – 摘要总量 256*256*16*4*2 = 8388608, 8MB – 劣化情况明显改善
问答 4 4
祝: 码不停提 !-) Happy Hacking
blog.zhgdg.org