百度Tera数据库介绍——类似cassandra,levelDB

转自:https://my.oschina.net/u/2982571/blog/775452 

设计背景

百度的链接处理系统每天处理万亿级的超链数据,在过去,这是一系列Mapreduce的批量过程,对时效性收录很不友好。在新一代搜索引擎架构设计中,我们采用流式、增量处理替代了之前的批量、全量处理。链接从被发现到存入链接库再到被调度程序选出,变成一个全实时的过程。在这个实时处理过程中,无论链接的入库还是选取,都需要对链接库进行修改,存储系统需要支持千万甚至上亿QPS的随机读写。旧的存储系统无论在单机性能,还是在扩展性方面,都无法满足,所以我们设计了Tera。

链接存储的需求

1. 数据按序存储

        支持主域、站点和前缀等多维度统计、读取。

2. 自动负载均衡  

        分区可以动态调整,在一个分区数据量变大或者访问频率过高时,可以自动切分,小的分区也可以自动合并。

3. 记录包含时间戳和多个版本

        对于链接历史抓取状态等记录,需要保留多个版本,对于策略回灌等场景,需要根据时间戳判断,避免旧的数据覆盖新的。

4. 强一致性

        写入成功,立即可被所有的用户看到。

5. 支持列存储  

        在用户只访问固定的少数几列时,能使用更小的IO,提供更高的性能(相对于访问全记录),要求底层存储将这部分列在物理上单独存储。

设计目标

功能目标

1. 全局有序  

        key可以是任意字符串(二进制串),不限长度,比较逻辑可由用户定义,按Key的范围分区,分区内由单机维护有序,分区间由Master维护有序。

2. 多版本  

        每个字段(单元格)都可以保留指定多个版本,系统自动回收过期版本,用户可以按时间戳存取

3. 自动分片  

        用户不需要关心分片信息,系统自动处理热点区间的分裂,数据稀疏区间的合并。
        单个分区的数据量超过阈值,自动切分为多个,单个分区的读写频率增高时,自动切分

4. 自动负载均衡和扩容  

        单机上保存多个分区,分区的总大小和总访问量达到阈值时,可以触发将部分分区迁移到空闲的机器。

 

性能指标

Tera设计使用SSD+SATA磁盘混布机型。  

1. 单机吞吐  

        顺序读写: 100MB/S  
        随机读1KB: 30000QPS  
        随机写1KB: 30000QPS  

2. 延迟  

        延迟和吞吐需要折衷考虑,在延迟敏感性不高的场合,使用延迟换吞吐策略,延迟定位在10ms级,写操作延迟<50ms,读延迟<10ms。  
        对于对延迟要求高的场合,读写延迟定位在<1ms,但吞吐会有损失,初期不做优化重点。  

3. 扩展性  

        水平扩展至万台级别机器,单机管理百级别数据分片。

 数据量系统吞吐
站点信息服务 10TB 百亿次/天
用户行为分析 1PB 百亿次/天
超链存储 10PB 万亿次/天
页面存储 100PB 万亿次/天

设计思路

数据存储

1. 数据持久性

        为保证数据安全性,要使用三副本存储,但维护副本的一致性与副本丢失恢复需要处理大量细节,基于一个分布式的文件系统构建,可以显著降低开发代价,所以我们选择了使用DFS(如BFS)
        系统的所有数据(用户数据和系统元数据)都存储在DFS上,通过DFS+WriteAheadLog保证数据的持久性,每次写入,保证在DFS上三副本落地后,才返回成功。

2. 强一致性

        数据会按key分区存储在DFS上,分区信息由Master统一管理,Master保证每个分区同一时间只由一个数据节点提供读写服务,保证一致性

3. 延迟换吞吐

        每次写操作落地一次导致的性能问题可以通过批量落地实现,比如每10ms数据落地一次,在数据落地前写操作不返回,代价是增加了5ms的平均响应时间

4. 存储接口封装

        Tera不会以某一种DFS作为唯一选择,而是通过底层存储接口的封装,使其可搭建在其他分布式存储之上,方便用户根据个性化需求灵活地部署Tera。

 

希望了解更多?请点击 https://github.com/baidu/tera

posted @ 2016-12-22 16:24  bonelee  阅读(2942)  评论(0编辑  收藏  举报