• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
分布式存储与TDDL
 

分布式存储与TDDL

on

  • 7,239 views

淘宝的分布式存储与中间件TDDL

淘宝的分布式存储与中间件TDDL

Statistics

Views

Total Views
7,239
Views on SlideShare
4,990
Embed Views
2,249

Actions

Likes
18
Downloads
0
Comments
0

9 Embeds 2,249

http://www.mysqlops.com 2191
http://www.joybig.com 29
http://m.oschina.net 10
http://cache.baidu.com 5
http://www.tuicool.com 5
http://vm-192-168-12-28.shengyun.grandcloud.cn 3
http://www.oschina.net 3
http://webcache.googleusercontent.com 2
http://cache.baiducontent.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    分布式存储与TDDL 分布式存储与TDDL Presentation Transcript

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