分类： 服务器与存储
2014-01-20 10:31:26
原文地址：分布式存储与TDDL 作者：yaofang123
分布式存储与TDDL
• Nosql 与sql的核心区别就在于
– 数据库层是否应该全部的放弃关系代数，将所有关系代数都交托给上层进行处理？
– 事务是否是必须应该被放弃的东西？
– 上层api，是否应该放弃sql引擎
• 永远正确定律:
– 计算机其实是个分形系统，将一系列的想法不断地重复
– 越接近硬件和微元件，速度越快。
– 所以nosql一定会快于sql。但代价是方便性
– 处理查找，什么查找方式能达到比较好的效果？
• 二分查找
• 树
• hash
• 如何按照其他key找到对应的数据
– Second index
– 倒排索引
• 如何能够找到符合一组查询条件的查询语句
– 组合索引 col1,col2
– Select * from tab where col1 = ? And col2 = ?
分布式存储里面的路由
• 本质来说还是个查找的过程
• 于是逻辑结构也就决定了。
– Hash
• O(1)效率
• 不支持范围查询（时间这样的查询条件不要考虑了）
• 不需要频繁调整数据分布
– Tree
• 主要是B-Tree
• O(logN)效率
• 支持范围查询
• 需要频繁调整节点指针以适应数据分布
• Hash
– Id % n
• 最普通的hash
• 如果id % 3 -> id % 4 总共会有80%的数据发生移动，最好情况下是倍分 id % 3 -> id % 6 会有50%的数据发生移动
• 但数据移动本身就是个要了亲命了。
• Hash
– 一致性hash
Def idmod = id % 1000 ;
If(id >= 0 and id < 250)
return db1;
Else if (id >= 250 and id < 500)
return db2;
Else if (id >= 500 and id < 750)
return db3;
Else
return db4;
一致性hash
• Hash
– 一致性hash
• 可以解决热点问题
• 但如果热点均匀，加机器基本等于n->2n方案
因为要在每个环上都加一台机器，才能保证所有节 点的数据的一部分迁移到新加入的机器上
• Hash
– 虚拟节点
• 解决一致性hash的问题
– 解决热点问题，只需要调整对应关系即可
– 解决n->n+1问题，规则可以规定只移动需要移动的数据
• 但方案相对的复杂一些
• 一般推荐使用简单方案开始，使用n->2n方案扩容
• 只有需要的情况下，再考虑平滑的扩展到虚拟节点方案即可
• B-Tree
– Hbase使用的切分方法
• 支持范围查询
• 但方案过于复杂，对于大部分场景来说，引导列都是pk.userid一类的单值查询，用树相对复杂。
• 需要频繁的进行切分和合并操作---region server的噩梦。
• 固定节点情况下，跨度相对较大，查找效率进一步降低
如何保持一致性？
• HA 是个永恒的难题
– 对这个问题的概要性描述CAP：在数据存了多份的前提下，一致性和响应时间，读写可用性不可兼得，理论的其他部分笑笑就好。
一份数据存了多份如何保持一致性？
– 常见处理模型
• Dynamo :gossip 读写高可用 最终一致
• Mongodb ob : 两段提交 ，保证数据不丢，切换时间可接受，但可能存在极短时间内写不可用
• Mysql :与mongodb ob类似，但采用的是半同步方案，切换时间短，写存在极短时间不可用
• 在实际的线上系统，还需要考虑以下问题
– 有些机器负担写任务，因此读压力可能不均衡，因此必须有权重设置
– 单个节点挂掉的时候，TCP超时会导致业务APP的线程花费更多的时间来处理单个请求，这样会降低APP的处理能力，导致雪崩。
– 因为突发情况，导致数据库请求数增加，数据库响应变慢，导致雪崩
TDDL最佳实践
• 尽一切可能利用单机资源
– 单机事务
– 单机join
• 好的存储模型，就是尽可能多的做到以下几点:
– 尽可能走内存
– 尽可能将一次要查询到的数据物理的放在一起
– 通过合理的数据冗余，减少走网络的次数
– 合理并行提升响应时间
– 读取数据瓶颈，加slave节点解决
– 写瓶颈，用规则进行切分
