分布式存储与TDDL

hendley

贡献于2011-11-19

字数:0 关键词: 分布式/云计算/大数据

分布式存储与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 db2 db0 db1 db2 db3 当id = 2时 Id % 3 =2 Id % 4 = 2 不需要迁移到新节 点。 当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是一切数据存取的最基本组成部分 – 但以前很难解决扩展性问题,现在已经很容易 就可以解决了。 • 存储节点少做一点,业务代码就要多做一 点。 • 没有银弹,想提升查询速度,只有冗余数 据这一条路可走。 • 类结构化查询语言,对查询来说非常方便

下载文档,方便阅读与编辑

文档的实际排版效果,会与网站的显示效果略有不同!!

需要 15 金币 [ 分享文档获得金币 ] 13 人已下载

下载文档

相关文档