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
190
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
150
PyCon2014China-Zhuhai-meta programming
zoomquiet
1
120
PyCon2014China-Zhuhai-bpm.py
zoomquiet
0
92
PyCon2014China-Zhuhai-luna kv db
zoomquiet
0
88
PyCon2014China-Zhuhai-seed studio
zoomquiet
0
78
PyCon2014China-Zhuhai-Docker Registry Build By Python
zoomquiet
0
91
PyCon2014China-Zhuhai-jeff
zoomquiet
0
71
PyCon2014China-Zhuhai-pythonic front-end
zoomquiet
0
99
DevFest2014-Zhuhai-Polymer
zoomquiet
0
390
Other Decks in Technology
See All in Technology
技術者はかっこいいものだ!!~キルラキルから学んだエンジニアの生き方~
masakiokuda
2
250
古き良き Laravel のシステムは関数型スタイルでリファクタできるのか
leveragestech
1
670
IVRyにおけるNLP活用と NLP2025の関連論文紹介
keisukeosone
0
190
Classmethod AI Talks(CATs) #21 司会進行スライド(2025.04.17) / classmethod-ai-talks-aka-cats_moderator-slides_vol21_2025-04-17
shinyaa31
0
570
AWS全冠芸人が見た世界 ~資格取得より大切なこと~
masakiokuda
5
5.8k
システムとの会話から生まれる先手のDevOps
kakehashi
PRO
0
270
食べログが挑む!飲食店ネット予約システムで自動テスト無双して手動テストゼロを実現する戦略
hagevvashi
3
410
Spice up your notifications/try!Swift25
noppefoxwolf
2
350
Devinで模索する AIファースト開発〜ゼロベースから始めるDevOpsの進化〜
potix2
PRO
7
3.3k
Micro Frontends: Necessity, Implementation, and Challenges
rainerhahnekamp
2
480
低レイヤを知りたいPHPerのためのCコンパイラ作成入門 / Building a C Compiler for PHPers Who Want to Dive into Low-Level Programming
tomzoh
0
220
LangChainとLangGiraphによるRAG・AIエージェント実践入門「10章 要件定義書生成Alエージェントの開発」輪読会スライド
takaakiinada
0
140
Featured
See All Featured
The Art of Programming - Codeland 2020
erikaheidi
53
13k
4 Signs Your Business is Dying
shpigford
183
22k
Documentation Writing (for coders)
carmenintech
69
4.7k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.4k
Unsuck your backbone
ammeep
670
57k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
135
33k
Into the Great Unknown - MozCon
thekraken
37
1.7k
GraphQLとの向き合い方2022年版
quramy
46
14k
A Modern Web Designer's Workflow
chriscoyier
693
190k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Building Adaptive Systems
keathley
41
2.5k
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