高并发系统实战课
徐长龙
前微博架构师、极客时间架构师
11663 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 30 讲
结束语&结课测试 (2讲)
高并发系统实战课
15
15
1.0x
00:00/00:00
登录|注册

10|稀疏索引:为什么高并发写不推荐关系数据库?

数据量超过三层时需要更多的IO操作
树的深度和数据量影响查询效率
列方式更好进行数据压缩
列筛选式查询性能高
顺序读写提高查询性能
高写并发处理能力
查询时遍历子树查找
合并不同Level的数据
顺序写形成数据块
内存中暂存新数据
数据持续高并发插入导致MySQL集群异常
查询遵循左前缀原则,不能利用多个CPU并行查询
多个索引限制表插入性能
B+Tree索引与数据量
ClickHouse
ElasticSearch
列存储数据库提高OLAP查找性能的原因
HTAP提供更多选择
数据底层根据场景选择更高效的方式
OLAP和OLTP数据库的不同
根据SQL和数据情况自动选择查询引擎
同一套数据支持多种存储方式
行式存储与列式存储的区别
列式存储的优势
LSM索引的优势
LSM索引的实现
MySQL关系数据库的限制
实时数据统计分析的服务
思考题
总结
HTAP实现OLAP和OLTP的互补
列存储数据库
稀疏索引LSM Tree与存储
HTAP实现OLAP和OLTP融合
稀疏索引:为什么高并发写不推荐关系数据库?

该思维导图由 AI 生成,仅供参考

你好,我是徐长龙。
从这一章起,我们来学习如何优化写多读少的系统。说到高并发写,就不得不提及新分布式数据库 HTAP,它实现了 OLAP 和 OLTP 的融合,可以同时提供数据分析挖掘和关系查询。
事实上,HTAP 的 OLAP 并不是大数据,或者说它并不是我们印象中每天拿几 T 的日志过来用于离线分析计算的那个大数据。这里更多的是指数据挖掘的最后一环,也就是数据挖掘结果对外查询使用的场景。
对于这个范围的服务,在行业中比较出名的实时数据统计分析的服务有 ElasticSearch、ClickHouse,虽然它们的 QPS 不高,但是能够充分利用系统资源,对大量数据做统计、过滤、查询。但是,相对地,为什么 MySQL 这种关系数据库不适合做类似的事情呢?这节课我们一起分析分析。

B+Tree 索引与数据量

MySQL 我们已经很熟悉了,我们常常用它做业务数据存储查询以及信息管理的工作。相信你也听过“一张表不要超过 2000 万行数据”这句话,为什么会有这样的说法呢?
核心在于 MySQL 数据库的索引,实现上和我们的需求上有些冲突。具体点说,我们对外的服务基本都要求实时处理,在保证高并发查询的同时,还需要在一秒内找出数据并返回给用户,这意味着对数据大小以及数据量的要求都非常高高。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文介绍了关系数据库在高并发写入场景下的局限性,以及新型分布式数据库HTAP的OLAP与OLTP融合特性。文章首先分析了MySQL的B+Tree索引与数据量的关系,指出索引树的深度和数据量对查询效率的影响。随着数据量增加,查询效率会下降,限制了关系数据库对大数据的处理能力。此外,文章还探讨了MySQL在高并发写入场景下的问题,包括主从同步延迟、主库响应缓慢等。接着,文章介绍了稀疏索引LSM Tree的特点,以及RocksDB如何利用LSM索引实现写多读少的KV数据存储查询服务。LSM Tree通过顺序写入提高了写入性能,同时在读取时通过遍历子树来查找,减少了写入时对树的合并代价。这种存储方式适用于OLAP数据库,尤其在写多读少的场景下表现出更高的效率。文章还讨论了列存储数据库的优势,指出其能够提高OLAP查找性能的原因在于能够充分利用磁盘顺序读写的性能,并且更好进行数据压缩,从而在实时计算领域做数据统计分析时表现更好。最后,文章介绍了HTAP的发展趋势,即将OLAP和OLTP结合成一套数据库集群服务,共同对外提供数据服务,从而实现行数据库与列数据库的互补。文章通过对关系数据库和稀疏索引的对比分析,展现了稀疏索引在高并发写入场景下的优势,为读者提供了对关系数据库局限性的深入了解。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《高并发系统实战课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(2)

  • 最新
  • 精选
  • 千锤百炼领悟之极限
    如果我们每行数据的索引是 1KB,那么除去 Page 页的一些固定结构占用外,一页只能放 16 条数据。 我们从这个 Page 就可以推导出:索引第一层放 16 条,树第二层大概能放 2 万条,树第三层大概能放 2400 万条。 请问老师,上面数的第二层能放2万条,第三层能放2400万条是如何计算出来的?

    作者回复: 你好,这个问题比较复杂,简单描述下,假设我们的b+tree是三层深度那么:第一层:(15k(page去掉头尾数据存储可用大小) / 12byte(bigint主键+页号FIL_PAGE_OFFSET)) = 1280 条数据 每个page,那么第二层: 1280条数据 * 15个页 = 19200 条数据,最后第三层: (1280条数据 ^ 2) * 15个页 = 24576000 条数据,大致是这样,只有末节点放置的是数据,前几个放置的都是主键以及page号

    2022-12-06归属地:北京
    5
    5
  • Mr.Tree
    有点好奇,OLAP既然是列式存储,那么当查询返回是其中几列数据中少量满足条件的数据查询时,它是怎么快速将满足条件的那一行的数据一一对应起来的?

    作者回复: 你好,Mr.Tree,你问到了关键点,这个问题在后面的写多读少相关章节课程有详细介绍

    2022-11-22归属地:北京
    3
收起评论
显示
设置
留言
2
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部