Contenu connexe Similaire à 分布式存储与TDDL (20) 分布式存储与TDDL2. 你理解的存储有什么?
• MYSQL/ORACLE/PGSQL/SQLSERVER
• HDFS/TFS/BIGTABLE
• TAIR/REDIS/MEMCACHED
• HBASE
• Cassandra/mongodb/Couchdb/voldmort
• neo4j
• http://nosql-database.org/ currently 122+
3. 问题
• http://nosql-database.org/ [currently 122+]
• “I’m the fastest”
• “but we are web scale well”
• 我们最安全,从不会失败
• 我们最简单
7. K-v存储
• Nosql 与sql的核心区别就在于
– 数据库层是否应该全部的放弃关系代数,将所有关
系代数都交托给上层进行处理?
– 事务是否是必须应该被放弃的东西?
– 上层api,是否应该放弃sql引擎
• 永远正确定律:
– 计算机其实是个分形系统,将一系列的想法不断地
重复
– 越接近硬件和微元件,速度越快。
– 所以nosql一定会快于sql。但代价是方便性
9. K-v存储
• 如何按照其他key找到对应的数据
– Second index
– 倒排索引
• 如何能够找到符合一组查询条件的查询语
句
– 组合索引 col1,col2
– Select * from tab where col1 = ? And col2 = ?
COL1 COL2
00 001
00 002
00 003
01 001
10. K-V分布式存储
• 很多东西可以复用,本质来说,从硬件到
软件,就是一个不断分形的过程
• 额外需要考虑的因素
– 网络延迟
• TCP/IP –公用网络,ip跳转慢,tcp包头大
• FIBRE CHANNEL – 专用 点对点传播 包头小 无ip协议
– 丢包
• Tcp 协议规范决定,努力送达但不保证一定可达
13. 路由
• Hash
– Id % n
• 最普通的hash
• 如果id % 3 -> id % 4 总共会有80%的数据发生移动,
最好情况下是倍分 id % 3 -> id % 6 会有50%的数据发
生移动
• 但数据移动本身就是个要了亲命了。
14. 路由
• 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
16. 路由
• Hash
– 一致性hash
• 可以解决热点问题
• 但如果热点均匀,加机器基本等于n->2n方案
因为要在每个环上都加一台机器,才能保证所有节
点的数据的一部分迁移到新加入的机器上
17. 路由
• Hash
– 虚拟节点
Def hashid = Id % 65536
Hash id Target node id
0 0
1 1
2 2
3 3
4 0
…. …
65535 3
18. 路由
• Hash
– 虚拟节点
• 解决一致性hash的问题
– 解决热点问题,只需要调整对应关系即可
– 解决n->n+1问题,规则可以规定只移动需要移动的数据
• 但方案相对的复杂一些
• 一般推荐使用简单方案开始,使用n->2n方案扩容
• 只有需要的情况下,再考虑平滑的扩展到虚拟节点
方案即可
19. 路由
• B-Tree
– Hbase使用的切分方法
• 支持范围查询
• 但方案过于复杂,对于大部分场景来说,引导列都
是pk.userid一类的单值查询,用树相对复杂。
• 需要频繁的进行切分和合并操作---region server的噩
梦。
• 固定节点情况下,跨度相对较大,查找效率进一步
降低
20. 路由
• TDDL的选择
– 规则引擎
• Groovy脚本实现,本质是为了实现多版本的规则推送,
其他事情,可以完全委托给业务的具体需求。
• 内建对3种hash模式的支持,并且允许从简单hash平滑的
过度到一致性hash或虚拟节点hash
• 允许使用外部实现规则
• 允许引入静态方法
– 默认推荐使用id % n
– 实现了多版本,并且与迁移工具绑定
– 可以与其他产品无缝结合—MDDAL可以不用改动代
码
21. 路由
• 数据迁移
– 与规则系统绑定,需要规则系统提供多版本支
持
• 核心思路是:输入相同的参数,老规则和新规则如果
计算出了相同的结果,那么数据不用移动,如果算
出不同结果,那么数据需要移动
将增量数据 本机数据增
全量复制 数据检查 部分停写 数据检查 规则切换 删除数据
保持在本机 量复制
22. 将
增 本
路由
量 机
数 全 数 数 部 数 规 删
据 量 据 据 分 据 则 除
保 复 增 检 停 检 切 数
持 制 量 查 写 查 换 据
在 复
本 制
机
db0 db1
db0 db1
当id = 2时
Id % 3 =2
Id % 4 = 2
db2 不需要迁移到新节
点。 db2 db3
当id = 3时
Id % 3 = 0;
Id % 4 = 3;
需要做节点移动
23. 路由
• 规则和迁移
– 解决scale out问题
– 可以解决一切有状态节点的扩容问题
• Redis?
– 规则+动态创建数据源可以实现存储资源的管理
• 根据访问量和磁盘容量,决定你的数据节点应该如
何分配。
24. 一致性选择
• HA 是个永恒的难题
– 对这个问题的概要性描述CAP:在数据存了多份的前提
下,一致性和响应时间,读写可用性不可兼得,理论
的其他部分笑笑就好。
– 常见处理模型
• Dynamo :gossip 读写高可用 最终一致
• 淘宝老方案: oracle + emc 用fibre channel做p2p直连保证数据不
丢 ,但切换时间比较长
• ob : 两段提交 ,保证数据不丢,切换时间可接受,但可能存在
极短时间内写不可用
• Mysql :与mongodb ob类似,但采用的是半同步方案,切换时间
短,写存在极短时间不可用
• Mongodb cassandra : W+R>N 模型,简单来说,就是多数派
accept的时候数据才算写入成功。
25. 数据库HA还不够
• 在实际的线上系统,还需要考虑以下问题
– 有些机器负担写任务,因此读压力可能不均衡,
因此必须有权重设置
– 单个节点挂掉的时候,TCP超时会导致业务APP
的线程花费更多的时间来处理单个请求,这样
会降低APP的处理能力,导致雪崩。
– 因为突发情况,导致数据库请求数增加,数据
库响应变慢,导致雪崩
27. 数据库HA还不够
• Matrix 层
– 核心是规则引擎
• 可以单独抽取出来,放在其他实现里,比如MDDAL
• 通过规则引擎实现了动态扩容
– 主要路径
• Sql解析->规则引擎计算->数据执行->合并结果
– 如果有更好的封装,我们非常欢迎
28. 数据库HA还不够
• GROUP 层
– 读写分离
– 权重
– 写的HA切换
• 写HA切换,目前的实现比较复杂
• 想借鉴uic的成功经验,但改动较大,牵一发而动全
身了,有一点过度设计。
– 读的HA切换
– 动态加新的slave节点
29. 数据库HA还不够
• Atom层
– 单个数据库的抽象
– 动态化的jboss数据源,ip port 用户名密码都可
以动态修改。
– Thread count .try catch模式,保护业务的处理线
程
– 动态阻止某个sql执行
– 执行次数统计和限制
31. TDDL 最佳实践
• 尽可能使用一对多规则中的一进行数据切分
– 互联网行业,用户是个非常简单好用的维度。
• 卖家买家问题,使用数据增量复制的方式冗余
数据进行查询。这种冗余从本质来说,就是索
引。
• 合理利用表的冗余结构,减少走网络的次数
– 卖家买家,都存了全部的数据,这样,按照卖家去
查的时候,不需要再走一次网络回表到买家去查一
次。
32. TDDL 最佳实践
• 尽一切可能利用单机资源
– 单机事务
– 单机join
• 好的存储模型,就是尽可能多的做到以下几点:
– 尽可能走内存
– 尽可能将一次要查询到的数据物理的放在一起
– 通过合理的数据冗余,减少走网络的次数
– 合理并行提升响应时间
– 读取数据瓶颈,加slave节点解决
– 写瓶颈,用规则进行切分
34. 未来
• K-V是一切数据存取的最基本组成部分
– 但以前很难解决扩展性问题,现在已经很容易
就可以解决了。
• 存储节点少做一点,业务代码就要多做一
点。
• 没有银弹,想提升查询速度,只有冗余数
据这一条路可走。
• 类结构化查询语言,对查询来说非常方便