参考：
在公司学习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. 无主机模式Ｒ>Ｎ-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
写入瓶颈：用规则切分
版权声明：本文为博主原创文章，未经博主允许不得转载。