(๓) - Chula · n.ñ. fl.q. bddd d/bddd 0b bddd n.n. bddd" tihunuân YN.ØI. bddb " OG
Bddb beihang
48
百度网页库存储引擎 BDDB设计简介 @林仕鼎 2012/4/24, 北航
description
Transcript of Bddb beihang
百度网页库存储引擎 BDDB设计简介
@林仕鼎
2012/4/24, 北航
个人介绍
95~02，北航6系
操作系统
02~07，MSRA系统研究组
P2P、分布式系统、存储
07~12，百度
搜索
基础架构
移动•云
Mola BDDB HDFS
低延时高并发 在线K/V存储
海量高吞吐 网页存储
离线数据备份
百度存储技术的发展 – 各种存储
块存储
分布式 数据结构
Object File Table
数据访问层
内存、Flash、硬盘
百度存储技术的发展 – 新存储
存储 集群
华北
存储 集群
华东
华南
存储 集群
写
写
写
百度存储技术的发展 – 云存储
百灵网页库
Data Mining
网页
倒排表
检索系统
Ranking
Crawling Index Building
Query Serving
搜索引擎架构示意
大容量
万亿级网页存储 (~100PB)
高吞吐
每天处理一遍
结构化存储 (DB-like)
网页+属性
百灵简介
自动运维、易于管理
分布式系统
支持处理任务调度执行
计算平台
百灵系统架构
存储
调度系统
机群管理
Build Garbage Anti-spam 各种挖掘…
BDDB BDDB BDDB
BDDB BDDB BDDB
BDDB BDDB BDDB
BDDB BDDB BDDB
机器
自动运维
直接读取
FIFO
写
入
Spider
属性
回灌
读
取
BDDB BDDB BDDB
BDDB BDDB BDDB
Bailing-Live
Outline
背景
分析
思路
方案
理念
其他
存储引擎 数据组织与访问
分布式架构 可靠性与自管理能力
系统 折中
组合
实现 (性能、优雅与否)
做一个存储系统要考虑什么？
存储系统 = 存储引擎 + 分布式架构 + 系统
结构 File
Object
Table
访问模式 实时读写
批量写、实时读
流式读
Scan / Range query
数据特点 Mutable or not
Size
Data layout
“实时性” Realtimeness
Freshness
Consistency
存储引擎
硬盘的特点 容量大
随机读写性能差，磁头寻道时间 15ms左右
顺序访问性能极好，>50MBps
S长度 (MB) 数据每次I/O的耗时
t = 0.015 + (S / 50)
约束1 – 来自硬件
容量 GB / TB / PB
结构化 按key进行增、删、改、查
按attribute进行查找
按某种order进行scan
Range query
实时性要求 更新操作在时间 t 后可见
一致性：data : metadata, data : data
约束2 – 来自应用
设计 简单
可扩展 (extensible)
实现 复用 (reusable)
高性能
约束3 – 来自“美”
回顾一下百灵架构
存储
调度系统
机群管理
Build Garbage Anti-spam 各种挖掘…
BDDB BDDB BDDB
BDDB BDDB BDDB
BDDB BDDB BDDB
BDDB BDDB BDDB
机器
自动运维
直接读取
FIFO
写
入
Spider
属性
回灌
读
取
BDDB BDDB BDDB
BDDB BDDB BDDB
Bailing-Live
单机大容量 单机容量10TB，数据20亿条以上
表结构 Key
Schema
Sort
优先支持scan 吞吐率与记录大小无关 (除了query)
单机吞吐>100MBps
BDDB的选择 - 1
以table为单位 单机多table，table间独立
合理的粒度: 管理、复制、恢复
可支持State-Replication
框架化 可定制: schema、key等
BDDB的选择 - 2
放松实时性保证 批处理
更新延迟反映
放松可靠性保证（单机存储单元） 数据可丢（随时可停机）
但保持一致
快速恢复（至历史上某个正确的状态）
BDDB的选择 - 3
背景
分析
思路
方案
理念
其他
Outline
Disk的接口 sector / block
FS的接口 <offset, data#length>
Table的接口 <key, {attr}>
Associative Addressing key -> offset
可变长
为什么Table难做？
• block_no = Hash(key)
简单模型: Hash-based
Blocks
Block metadata
模型2: B+ tree
空间管理 变长数据
定长块
优化：Multi-level
内存消耗 Record size较小，数量巨大
性能 随机I/O (多次)
按序scan只能转化为多次query
问题
三个紧箍咒 - Associative Addressing - 变长数据 - 硬盘随机访问性能
Multi-level Block Management
4K
8K
16K
32K
模型3: Log-based Structure
Table
Block0
Block 1
…
Block X
In-Memory Records
{<key, data>}
Log Block-N
Log Block-1 New table
Block 0
Block 1
…
Block Y
Memory
Disk
Update Query
Dump
Commit
…
背景
分析
思路
方案
理念
其他
Outline
BDDB层次结构
Block 定长
Stream Key-Value存储
可排序
基于key的查询、增加和删除
Table 为value增加schema
支持对属性的改动和查询
Table Layer
Stream Layer
Block Layer
Metad
ata
数据块管理
Block
Block
@disk0
Block
@disk1
Block
@diskN
<key, data>
Memory
Disk
dump
…
Block
…
A Big Virtual File by Blocks
记录组织方式
RecordN
Key0
…
KeyN
Record0
…
Off0
Head
Pointer-offset
sorted
Key0
Record0
…
RecordN
Record1
Key1
…
KeyN
Head
sorted
Key1
Record1
…
Record0
RecordN
KeyN
…
Key0
Head
unso
rted
C B A
OffN
Data1 Data2 … DataN
Log
Record
…
LogX
Log1
Data1’ Data2’ … DataM’
Data blocks
New data blocks
Merge-sort
Dump
通过Merge-Sort生成Sorted Stream
Memory
Disk
通过Metadata将Block串成Stream so
rted
Group 1
Group 2
Group X
…
…
Block
sort
ed
Block
Block
Block
Block
…
…
…
…
Block
Block
Block’
sort
ed
Block’
Block
Block’
Block’
…
…
…
…
Block’
Block
K1l
K1h
K2l
K2h
KXl
KXh
支持随机查询: 假如索引都在内存中
Block-1 Block-2 Block-3 … Block-N
Memory
Disk
<key, id,off>
<key, id,off>
<key, id,off>
… <key,
id,off> <key,
id,off> <key,
id,off>
#Rec: 20亿 #Index: 20亿*16B = 32GB
如果索引不放在内存中
Block-1 Block-2 Block-3 … Block-N
Id KeyL KeyH
Id KeyL KeyH
2nd-level Index
Memory
Disk
Base Stream
<key, id,off>
<key, id,off>
<key, id,off>
… <key,
id,off> <key,
id,off> <key,
id,off>
Index Group Index Group Index Group
Id KeyL KeyH
Id KeyL KeyH
Id KeyL KeyH
Id KeyL KeyH
Index Stream
Table的生成 - 1
Sorted table 基于sorted stream
写入速度受排序性能限制
Unsorted table 写入速度高，但
需要随机I/O以支持修改/删除
在索引无法常驻内存时，需要多次随机I/O
We can do better!
Table的生成 - 2
Base stream 无序 = 以地址(addr)为序
新记录append
批量处理修改操作
Patch stream <addr, mod>
Index stream key -> addr
Mod stream <key, mod>
Table的生成 - 3
Block-N … Block-2 Block-1
Index stream key->addr
Mod stream <key, mod>
Patch stream <addr, mod>
append
merge
merge
generate
Base stream
Table的生成 - 4
Merge-sort
Merge
Merge-sort
Base
Strea
m
Reco
rd-Y
Reco
rd-X
…
Reco
rd-2
Reco
rd-1
Reco
rd-0
<k2, A
, e>
<k1, D
, d>
…
<k2
, A, b
>
<kX
, M, a>
Sorted by addr A <key2,data2’>
Up
dates
Patch Stream
M <keyX,dataX’>
A <key2,data2’’>
D <key1>
<M
, kX
, dX
> M <key2,data3>
Reco
rd-2’
…
Reco
rd-2’’
<M
, k2, d
3>
<D
, k1
>
e d . c b a y x . 2 1 0
<k2
, M, c
>
<kY
, y>
<kX
, x>
…
<k1
, 1>
<k0, 0
>
<k2
, 2>
Ind
ex S
tream
<k2
, d3 >
<kX
, dX
>
Ind
ex lo
gs
(1)
(2)
<kX
, x>
Mod
Strea
m
Mod
logs
+ +
(3)
<x, M
, dX
>
(2.1) (2.2)
(3.1)
<1, D
>
<2, D
>
(3.2)
(4)
Patch
logs
(5)
…
<b, D
>
Merg
e-sort
(6)
总结
Block作为基本数据存储单元 通过metadata串成“大文件”
Stream <key, value>
可排序
可自定义merge函数
Table 通过schema将stream中的value解释为属性
通过多stream的组合实现删除/改动
（重用Sort-Merge实现内部数据结构）
属性修改由merge函数实现
背景
分析
思路
方案
理念
其他
Outline
设计理念 - 1
层次化 Block
Stream
Table
数据组织 紧凑存储
由schema解释内容
存储以block为单位 简化buffer管理
Multi-buffer、全异步
增大吞吐
Block只读 无需上锁
简化数据修复过程
设计理念 - 2
Stream Log-based ，避免随机I/O
重用sorted stream以建立索引
Table 将修改/删除操作转化为multi-stream的merge
基于sorted stream可建立属性索引
复杂功能通过基本功能组合实现 大量重用Merge-Sort机制（重载merge函数）
减少代码量，降低复杂度
设计理念 - 3
Metadata异步维护 内存数据随时可丢，不保证高可靠
通过更新协议保证硬盘数据一致
I/O效率高
可快速恢复 (fast-recovery)
通过上层的分布式协议保证可靠性
背景
分析
思路
方案
理念
其他
Outline
Block
Table Insert
Delete
Modify
Query
Scan
Schema
Snapshot (merge操作)
View, Concrete View
BDDB概念
Snapshot
Block Block Block Block Block
Snapshot
View
C.V.
Block
Merge
Select
Select
可扩展记录格式
可扩展 Schema (最小粒度：bit)
自定义key比较函数
自定义merge函数
长度 key 定长属性 变长属性长度 变长属性
key 定长属性
两种记录格式：
Schema示例 struct Record {
DEF_TIME(create_time);
DEF_TIME(in_time);
DEF_TIME(last_mod_time);
int16 garbage;
int16 laser;
unsigned int pt_number;
unsigned del : 1;
unsigned page_weight : 6;
unsigned is_dynamic : 1;
unsigned zip : 4;
…
VAR_STRING_65536(url);
VAR_STRING_65536(anchor_text);
VAR_STRING_65536(title);
VAR_DATA(content);
VAR_DATA(page);
VAR_DATA(link);
VAR_STRING(inv_link);
};
BDDB发展历程
开发 始于2007/10
快照库 2008/6上线
Bailing 2008/12试运行
2009/9正式上线
新存储 2010/6 ~ now
Thanks!
