《专场11.4-百度沧海.存储万亿级元数据底座TafDB设计和实践-曹彪(脱敏版).pdf》由会员分享,可在线阅读,更多相关《专场11.4-百度沧海.存储万亿级元数据底座TafDB设计和实践-曹彪(脱敏版).pdf(32页珍藏版)》请在三个皮匠报告上搜索。
1、百度沧海.存储万亿级元数据底座TafDB设计和实践曹彪 百度 云存储高级架构师目录云存储元数据面技术演进趋势01云存储元数据底座的技术选型02云存储元数据底座TafDB关键设计和实践03TafDB应用效果04后续规划05云存储元数据面技术演进趋势01数据持续爆发式增长,对云存储系统的扩展性提出了更高要求数据持续爆发式增长,对云存储系统的扩展性提出了更高要求 IDC预测,全球数据量从2018年的33ZB将增长至2025半年的175ZB云存储系统由元数据面和数据面构成,元数据面的扩展性影响到云存储系统由元数据面和数据面构成,元数据面的扩展性影响到整个存储系统整个存储系统的扩展性的扩展性云存储元数据
2、面的扩展性面临挑战百度沧海百度沧海.存储存储 整体架构整体架构元数据面技术演进趋势 层级Namespace/分布式文件系统分布式文件系统namespace架构演进路线架构演进路线 单机全内存目录树架构 静态子目录树划分 基于共享存储 10亿级别,无法横向扩展 单个静态子树存在上限,最大10亿级别 易产生热点,负载均衡代价高 不支持跨子树的rename 无限扩展cbnmaxyNS/cbnmaxyNS0NS1NS2/cbnmaxyNS元数据存储底座元数据面技术演进趋势 平坦Namespace对象存储对象存储平坦平坦namespace介绍介绍元数据面技术演进趋势 平坦Namespace平坦平坦nam
3、espace架构演进路线架构演进路线 基于数据库中间件 基于分布式事务数据库 扩容只能倍扩,对成本造成很大压力 对跨库的分布式事务支持不友好 从根本上解决了数据库中间件扩展性问题数据库中间件文件1属性Slice list文件2属性Slice list文件n属性Slice list分布式事务数据库文件1属性Slice list文件2属性Slice list文件n属性Slice list云存储元数据底座的技术选型02元数据底座设计目标规模支撑万亿级纪录存储性能百万QPS,毫秒级延迟运维数据均衡,扩缩容简单数据库特性事务、索引、备份、CDC元数据底座技术选型调研结论自主研发:打造一个类Spanner
4、架构的NoSQL with ACID的系统技术流派技术流派适应场景适应场景Spanner面向通用面向通用OLTP场景场景Calvin面向确定性事务面向确定性事务OLTP场景场景FoundationDB面向对延迟要求不高的面向对延迟要求不高的OLTP场景场景TafDB关键设计和实践03TafDB系统架构挑战挑战TafDB工程挑战挑战1:如何在保证元数据ACID 操作的同时,避免2PC事务的高额开销?挑战2:如何在大量删除场景保证LSM-Tree范围操作的性能?挑战3:如何消除数据流程的单点,提供极致的扩展性和可用性?-解决事务、索引功能和系统性能的矛盾-解决连续删除+范围查询和性能的矛盾-解决事
5、务功能和高可扩展性&可用性的矛盾TafDB工程挑战 整体解决思路挑战解决思路挑战1:如何在保证元数据ACID操作的同时避免2PC事务的高额开销?-解决事务、索引功能和系统性能的矛盾挑战2:如何保证LSM-Tree范围操作的性能?-解决lsm-tree连续删除+范围查询和性能的矛盾挑战3:如何消除数据流程的单点来提供极致的扩展性和可用性?-解决事务、索引功能和系统性能的矛盾消除系统中不必要的跨分片事务:异步索引自定义分裂策略 Scale out:打散删除到多台机器 Scale up:提升单机墓碑消除速度,在确定性时间内消除墓碑设计分布式时钟方案挑战1:如何在保证元数据操作ACID的同时,避免2P
6、C事务高额开销?背景:跨分片事务性能开销极大背景:跨分片事务性能开销极大2PC事务流程未经优化的2PC模型会带来N倍的写放大跨跨2个分片事务的写放大次数个分片事务的写放大次数写Raft log次数写rocksdb次数77涉及IO操作不涉及IO操作挑战1:如何在保证元数据操作ACID的同时,避免2PC事务高额开销?痛点:元数据场景可能触发大量跨分片事务痛点:元数据场景可能触发大量跨分片事务平坦Namespace场景层级Namespace场景全局二级索引:主键数据和索引数据在不同的分片上依赖分布式事务保证主键和索引写入的原子性目录树操作:要修改的节点通常在不同分片上依赖分布式事务保证跨分片操作的原
7、子性针对平坦针对平坦Namespace解决方案:支持异步二级索引解决方案:支持异步二级索引BOS写请求类型占比主键和索引不要求原子写入主键和索引不要求原子写入主键和索引要求原子写入Rename挑战1:如何在保证元数据操作ACID的同时,避免2PC事务高额开销?异步索引系统特性:毫秒级延迟不丢可重针对平坦针对平坦Namespace解决方案:支持异步二级索引解决方案:支持异步二级索引BOS写请求类型占比主键和索引不要求原子写入主键和索引不要求原子写入主键和索引要求原子写入Rename挑战1:如何在保证元数据操作ACID的同时,避免2PC事务高额开销?异步索引系统特性:毫秒级延迟不丢可重挑战1:如何
8、在保证元数据操作ACID的同时,避免2PC事务高额开销?针对层级针对层级Namespace解决方案:支持自定义分裂策略解决方案:支持自定义分裂策略 关键设计:?支持自定义分裂策略:同目录下的所有子节点控制在同一个数据分片?单分片事务优化:业务系统调整表结构,控制大部分操作要更改的节点都在同层目录挑战2:如何在大量删除场景保证LSM-Tree范围查询的性能?背景背景LSM-Tree对大量删除后的范围操作不友好 Rocksdb Tombstone存在时长无法控制 如范围扫描的区间存在大量墓碑会导致扫描性能低下TafDB两层墓碑机制进一步加剧了此问题 为实现MVCC,TafDB在删除时使用墓碑机制
9、全量MVCC GC的方式导致TafDB tombstone存在时长无法控制解决方案:在确定性时间内消除两层墓碑解决方案:在确定性时间内消除两层墓碑支持多层级的MVCC GC机制:FastGC:优先级感知的MVCC GC机制,对存在大量删除的range进行精确的GC FullGC:周期性全量MVCC GCCompaction精细化调度:精确感知删除Range,针对这一段Range触发compact_range挑战2:如何在大量删除场景保证LSM-Tree范围查询的性能?Tablet rangeTablet rangeDeleted data rangegc requiredNo gc requi
10、redOldOptimizedgc requiredTablet rangeTablet rangeTombstone rangecompaction requiredNo compaction requiredOldOptimizedcompaction required挑战3:如何消除数据流程的单点,提供极致的扩展性和可用性?痛点:全局时间戳服务器是痛点:全局时间戳服务器是TafDB扩展性和可用性的瓶颈扩展性和可用性的瓶颈挑战3:如何消除数据流程的单点,提供极致的扩展性和可用性?业界分布式数据库时钟方案业界分布式数据库时钟方案方案系统优点缺点全局时间戳服务器TafDB当前实现简洁时钟服务成
11、为性能和可用性瓶颈HLCCockroachDB无中心化的性能和可用性瓶颈时钟和DB逻辑耦合调试复杂度高挑战3:如何消除数据流程的单点,提供极致的扩展性和可用性?元数据写场景TafDB分布式时钟方案单分片事务跨分片事务写请求类型占比1PC2PCMax Timestamp:200Global CordinatorTimestamp:100Local TimeServerTable Acollectcollect max timestampTimestamp:200Local TimeServerTable BcollectMax Timestamp:201Global CordinatorTime
12、stamp:201Local TimeServerTable Asyncsync max timestampTimestamp:201Local TimeServerTable BsyncProxyTimestamp:100Local TimeServerTable A直接使用本地时钟服务通过广播协调保证因果序TafDB应用效果04TafDB应用效果系统定位:百度沧海系统定位:百度沧海.存储统一元数据底座存储统一元数据底座TafDB应用效果业务业务上线效果上线效果对象存储扩展性提升:单 Bucket 容量从 百亿级别提升到万亿级别性能提升:小文件延迟降低42%文件系统扩展性提升:单集群容量从十亿级别提升到万亿级性能提升:写延迟2ms,读延迟百us级后续规划05目标:打造业界领先的元数据存储底座后续规划更高性能更高性能面向元数据场景设计最优的读写路径面向元数据场景设计最优的读写路径更稳定更稳定打造零运维的存储系统打造零运维的存储系统更易用更易用提供更丰富的“提供更丰富的“LayerLayer”:”:NamespaceLayerNamespaceLayer、EtcdLayerEtcdLayer