Tera的系统设计

本文重点介绍百度的万亿量级数据库Tera的诞生背景、业务场景及需求、设计目标和设计思路。若是您还不了解Tera，可参考Tera主页。

 

设计背景

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

连接存储的需求

1. 数据按序存储

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

2. 自动负载均衡  

        分区能够动态调整，在一个分区数据量变大或者访问频率太高时，能够自动切分，小的分区也能够自动合并。

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

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

4. 强一致性

        写入成功，当即可被全部的用户看到。

5. 支持列存储  

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

 

设计目标

功能目标

1. 全局有序  

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

2. 多版本  

        每一个字段（单元格）均可以保留指定多个版本，系统自动回收过时版本，用户能够按时间戳存取。

3. 自动分片  

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

4. 自动负载均衡和扩容  

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

5. 局部性群组(LocalityGroup)  

        每一个局部性群组内部包含多个列族，列族内列个数不限制，不一样局部性群组在物理上单独存储，以提升访问效率。

6. 行级原子性  

        对一行的多列进行一次写入，要么所有成功，要么所有失败。

性能指标

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

1. 单机吞吐  

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

2. 延迟  

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

3. 扩展性  

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

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

稳定性指标

能自动处理因为网络抖动带来的各类问题，不会由于少许节点的网络联通性问题致使集群不可用。能处理机器假死带来的异常，保证及时清除问题机器，不影响整个集群可用性与吞吐。  

1. 数据节点单点故障恢复时间  

        数据节点故障，分区迁移到其余数据节点自己代价不大，50ms能够完成，但频繁迁移会致使数据本地化丧失，因此设计数据节点30s不可用，才进行切换。  

2. Master单点故障恢复时间  

        为避免网络抖动带来的频繁切换，设定master的lease过时时间为10s，10s没法服务才会被备份节点取代。  

3. 集群均衡度  

        设计单机数据量超过集群平均数据量1.2倍触发负载均衡操做，单点访问频率超过集群平均负载2倍，且负载超过设计负载，触发负载均衡操做。

 

设计思路

数据存储

1. 数据持久性

        为保证数据安全性，要使用三副本存储，但维护副本的一致性与副本丢失恢复须要处理大量细节，基于一个分布式的文件系统构建，能够显著下降开发代价，因此咱们选择了使用DFS（如BFS）。
        系统的全部数据（用户数据和系统元数据）都存储在DFS上，经过DFS+WriteAheadLog保证数据的持久性，每次写入，保证在DFS上三副本落地后，才返回成功。

2. 强一致性

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

3. 延迟换吞吐

        每次写操做落地一次致使的性能问题能够经过批量落地实现，好比每10ms数据落地一次，在数据落地前写操做不返回，代价是增长了5ms的平均响应时间。

4. 存储接口封装

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

 

但愿了解更多？请点击 https://github.com/baidu/tera