百度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
