分布式存储与TDDL

分布式存储与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节点解决

–      写瓶颈，用规则进行切分