网站大量收购独家精品文档,联系QQ:2885784924

infinidb在大数据的实战应用-赖亿_it168文库.pdf

infinidb在大数据的实战应用-赖亿_it168文库.pdf

  1. 1、本文档共34页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
infinidb在大数据的实战应用-赖亿_it168文库

Infinidb在大数据的实战应用 赖亿2015/4/16 目录 • 背景 • InfiniDB的特点 • Infinidb的实战 问题 一个真实的血案: • 需求:我们在数据库mysql要做基于pv的分析。日均裸数据增量10g • 初始方案:使用innodb 问题:数据量增加太快,磁盘空间增加太快(40g) 数据加载太慢了 最最重要统计类查询太慢了,需要建太多的索引/汇总表 • 改进方案:换成tokudb 解决问题:数据压缩4倍,空间增加勉强可以接受(10g) 数据加载快些了4倍左右,勉强可以接受 未解决: 最最重要查询太慢了,一个查询5分钟甚至更长, 优化太痛苦,需要建太多的索引/汇总表 问题 一个真实的血案: • 需求:我们在数据库mysql要做基于pv的分析。日均裸数据增量10g • 初始方案:使用innodb 问题:数据量增加太快,磁盘空间增加太快(40g) 数据加载太慢了 最最重要统计类查询太慢了,需要建太多的索引/汇总表 • 改进方案:换成tokudb 解决问题:数据压缩4倍,空间增加勉强可以接受(10g) 数据加载快些了4倍左右,勉强可以接受 未解决: 最最重要查询太慢了,一个查询5分钟甚至更长, 优化太痛苦,需要建太多的索引/汇总表 解决:--换成infinidb • 最终方案:使用infinidb(和最初方案innodb 比较) – 空间增量2g ( 原来增量40g) – 加载数据20万/每秒 (原来1万/每秒) – 查询一般小于1分钟(原来5分钟,甚至20分钟) – 免优化(再也不要建index了哦) • 业务线的反馈 目录 • 背景 • InfiniDB的特点 • Infinidb的实战 Infinidb的定位 infinidb Hbase 等 infinidb infinidb产品介绍 产品特点: • Mysql协议兼容 • 全功能,支持dml • 统计类查询10倍 • Load数据快(每秒10万) • 压缩率5倍(和裸数据比) • 免优化 Infinidb的单机构架 InfiniDB 分布式框架 集群文件系统(hdfs/gfs ) 2013.10.15 支持hdfs –不太建议生产环境用 真实业务性能测试—查询性能 分析类存储引擎InfiniDB – 查询性能对比测试 TPCH测试(以下以1G数据量,150000行用户数据测试) InfiniDB存储– 为啥查询这样快 数据存储方面, “拆拆拆”: • 按列拆 • 按行(范围)拆: 核心算法:hash join InfiniDB存储– 按列拆 InfiniDB存储– 按行(范围)拆 每个范围(术语:Extent Map)都有最大/最小值,方便过滤 Extent Map 的向上扩展更大的范围(术语:Partition)也有最大值/最小值 每个Extent Map 可以并行计算 InfiniDB存储– hash join 核心算法:hash join • 每行都有一个rowid • 查询2列以上:通过行rowid关联,使用hash join • 不太怕表的关联 • 很怕Select * InfiniDB存储– 为啥查询这样快(总结) 数据存储

文档评论(0)

maxmin + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档