10|稀疏索引:为什么高并发写不推荐关系数据库?
该思维导图由 AI 生成,仅供参考
B+Tree 索引与数据量
- 深入了解
- 翻译
- 解释
- 总结
本文介绍了关系数据库在高并发写入场景下的局限性,以及新型分布式数据库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归属地:北京55 - Mr.Tree有点好奇,OLAP既然是列式存储,那么当查询返回是其中几列数据中少量满足条件的数据查询时,它是怎么快速将满足条件的那一行的数据一一对应起来的?
作者回复: 你好,Mr.Tree,你问到了关键点,这个问题在后面的写多读少相关章节课程有详细介绍
2022-11-22归属地:北京3