资源描述:
《Inside BeansDB》由会员上传分享,免费在线阅读,更多相关内容在学术论文-天天文库。
1、BeansDB设计与实现davies.liu@gmail.comDoubanInc.2010-12-28BeansDB是什么?Key-Value数据库分布式的,伸缩性比较好(P)性能和容量最终一致的(C)可能出现短时间内的数据不一致高可用的(A)部分节点出现故障不影响服务BeansDB不是什么?事务型关系数据库有严格数据一致性需求的多个对象POSIX文件系统不要放过大的对象不能访问对象的部分内容缓存系统性能不是那么高,与内存是否充足有关CDN等等典型用法图片文件,小媒体文件(mp3)大文本字段(通常>1kb)profile,properties数
2、据体系中的叶子部分不是其它数据依赖的关键非典型使用大量过于零碎的小内容(<100byte)收藏数据广播数据通常需要批量查询非在线使用数据用户上传的原始图片日志文件中间结果矩阵计算的中间结果系统结构ABCDEFProxy1Proxy2Clients…数据分布方式手动指定按照bucket分配(bucket数容易调整)Proxy自动路由,根据存储节点的数据信息为什么不用ConsistantHash?数据迁移成本比较大数据所在位置不清晰,不方便迁移不方便扩容等节点数更多时再采用数据分布同步0/001/00HashTree16进制2/00@3/
3、00@04/3040710897413@005/98510904490@a6/1528810916003@a07/3005110911943@aa8/39841@f@f09/00@f1a/233761memcat--servers=localhost:7900@b/00c/5054610893019d/1595310899763e/3664110903396f/3483210886637冲突解决版本号优先用高版本覆盖低版本修改时间用新数据覆盖旧数据数据迁移及故障恢复直接拷贝数据及Hint文件不需要关闭正常数据节点协议memcach
4、ed兼容协议set过期时间作为版本号get@xxx返回HashTree状态get?xxxx返回对应key的meta信息flush_allMerge,压缩数据文件大小协议实现使用memcached的代码异步网络IO多worker线程,leader/follower模式数据存储实现Bitcasktestdb日志结构+全内存索引
5、--0简单,可靠,高性能
6、
7、--000.data
8、
9、--000.hint.qlz多目录
10、
11、--001.data便于迁移和恢复
12、`--001.hint.qlz提高并发性
13、--1支持数据压缩
14、
15、--000.data
16、
17、
18、--000.hint.qlz自动选择性压缩
19、
20、--001.data
21、`--001.hint.qlzHashTree实现需求读取,保护在数据文件中的偏移修改时的版本管理,版本号节点间的同步,内容的hash能快速建立,降低启动时间空间效率索引全部在内存,决定了单机容量平均20byte/record(包括key在内)时间效率每秒插入近百万条HashTree实现类似于Heap实现Item[verion,hash,pos,length,name[…]]Node基于数组,16进制D=0D=1D=2LeafItem连续存储,最多128个[size,co
22、unt,used,Item[0],Item[1],…]线程模型N个worker线程Leader/follower模型得到事件后立即处理,无线程切换释放leader锁,IO操作时不阻塞其它事件写缓存,后台定时/定量写入到磁盘读的时候才打开数据文件减少fd占用,读并发好案例1:图片和音频文件数据量:每个1k到20M460Gx16x3=22T16Mx16x3=768M17个节点,约50块SATA硬盘访问量:150qps左右有CDN作为缓存性能Med/Avg/90%/99%:18/35/86/266ms案例2:文本数据数据量:每个10b到100k70G
23、x16x3=3.3T28Mx16x3=1.3B8个节点,9块SATA硬盘访问量:180qps左右有memcached作为缓存性能Med/Avg/90%/99%:3/10/21/65ms为什么做BeansDB?其它Key-Value选择memcachedb,tokyotrant,主从复制不便于Fail-Over其它类Dynamo选择Dynomite:erlang完整实现,内存效率可能有问题Voldemort:Java部分实现最初的