参考:
在公司学习TDDL,无意间感觉这方面挺有意思的。
很多工程上的方案并不像论文上写的那样精准,要考虑的问你有很多,最后看到的方案比较粗暴、高效、精准性略低。
性能
易用
可运维、可监控
结果简单
组件化
内网上的课程笔记:
分布式存储原理与TDDL 地址
零、数据库提供功能
ACID中的事务(保证原子性),sql的查询、视图、存储过程。
数据库功能:K-V存储 关系代数和事务引擎 用户API
K-V存储关键
1. 范围查找
2. 处理更新
3. 读写性能
4. 面向磁盘
5. 并行指标
6. 内存占用
一、基本数据结构
数据库底层实现的角度来看问题。计算机中的大部分问题都是映射问题即K-V
查询分为两种:单值查询,范围查询。前者使用hash、后者使用树解决问题。
存储介质上,硬盘特性寻道和分块存储,内存是随机存储
跳表:解决链表不能二分查找的问题
B树 :解决二分查找且可插入。相对于二叉树,考虑到磁盘的特性读取块是性能瓶颈,因此树要矮,同时B树存在空间浪费情况,这在内存不可取。
LSM树:目前nosql中使用的数据结构,减少了随机性,但读取性能低于B-tree
二、关系代数即数据库如何使用映射
对于一条select * from table where id=? 处理
对于索引来说,主键建立索引支持范围
对于其他属性可以建立二级索引,对于项目少且常用的可以建立组合索引,或者单个索引,分步查找回表查找。
三、用户API即SQL引擎
将SQL语句转为AST,就可以做到有序分步执行。然后做执行计划(选取可以达到目标的最优方案,选取索引的顺序、步骤的顺序不唯一NP问题)
利用SQL将数据库与应用业务隔离、降低耦合
eg:查找汽车轮子是name的轮子,如果仅仅是K-V就要查看所有的汽车然后再在其中查看轮子,若是关系代数模型就可以直接查找(name=xx)
四、分布式
核心问题:partion、replication。性能方面是网络和均衡
partion 如何路由:传统的就是K-V,一致性hash、路由hash
1. 传统K-V的扩容要成2倍的进行,这样就能保证只有一半的数据需要迁移,否则迁移数据会很多(机器数由3到4迁移60%)
2. 一致性hash
hashid=id%100;
if(hashid<25) return 0;
else if(hashid<50) return 1;
else if(hashid<75) return 2;
else return 3;
扩容的时候将字段范围拆分改变即可eg:<40 <50
3. 虚拟hash就是对应一张映射表,迁移的时候先将原先的对应关系放上去,这样平滑过渡,然后再修改
对于TDDL它的规则引擎就是简单hash,热点处理就是简单脚本判断。扩容过程:先将增量数据存储到本地,全量复制到新机器,数据校验,数据同步(可以选用原库停写等待追上)然后切换
replication中的一致性
1. 无主机模式R>N-W 读机器 总机器 写机器 。读几次能取到最新数据,适应于写多读少情况
eg:N=3,W=1,那么R>2 就要读3份。
eg:N=3,W=2,那么R>1 就要读2份。
2. 有主机模式,只有一台可写,Master管理多个slave。很好控制一致性。
实用:若主机挂掉就随机选响应的。
问题:
1. 读写不均衡
2. 单个节点死掉,导致雪崩
3. 突发情况的雪崩
TDDL
第一层Matrix 可以自动扩容,路径:SQL解析-规则引擎-执行-合并。路由到哪一组。
第二层group里面有主备,数据统一。读写分离,权重设置,读写切换,允许动态增加slave机器。
第三册Atom保护业务线程等等
数据增量复制:异构增量(买家分库卖家查询,评价被评价双维度)
使用:
1. 预估性能:数据从读取位置的时间预估到传输等等
2. 尽可能对一对多规则中的一进行数据切分
3. 使用数据增量复制的方式冗余数据进行查询,合理利用冗余减少网络
4. 尽可能在单机、内存、同一块中。
读取瓶颈:增加slave
写入瓶颈:用规则切分
版权声明:本文为博主原创文章,未经博主允许不得转载。
原文地址:http://blog.csdn.net/gg_gogoing/article/details/47680047