阿里LSMTree存储引擎X-Engine

阿里LSMTree存储引擎X-Engine
  X-Engine是阿里云研发的LSM-Tree结构的存储引擎,主打低存储成本带来的性价比。   问题 the tsunami problem 海啸问题:122倍突发流量 the flood discharge problem 泄洪问题:将内存数据快速转到持久化存储组件 the fast-moving current problem 快变洋流问题:热点行变化快 架构 优化总结 读路径优化 Extent Cache 多版本SuperVersion 增量cache替换 写路径优化 memtable热点行优化 ...

Grammar-like Functional Rules - for Representing Query Optimization Alternatives

Grammar-like Functional Rules - for Representing Query Optimization Alternatives
  《Grammar-like Functional Rules - for Representing Query Optimization Alternatives》 SIGMOD 1988 概述 优化器如果要做到可扩展,则要求执行计划的变换策略需要作为数据而不是代码存在。本质上优化器就是一个专家系统,使用strategy rules将一个查询计划变成另一个等价的更好的计划。这种灵活可扩展带来一个问题是 不够高效:在任意一步,都需要检查很多转换规则的使用条件,而且可能有多个规...

MyRocks in Facebook UDB

MyRocks in Facebook UDB
MyRocks Paper《MyRocks: LSM-Tree Database Storage Engine Serving Facebook's Social Graph》 这篇文章介绍了Facebook为了解决UDB数据库成本迁移MyRocks的挑战和解决方案。   Introduction 迁至MyRocks所遇到的挑战 在Facebook UDB场景下,MyRocks将存储空间压缩了一半,因此实例数目减半,也意味着UDB集群的CPU和IO硬件资源减半。 Range Scan的Forward和Backward性能不一样,这个主要是底层数据...

构建分析LSM Compaction Design Space

构建分析LSM Compaction Design Space
《Constructing and Analyzing the LSM Compaction Design Space》 VLDB'21 四个原语 Compaction是LSM-Tree引擎中最重要的环节之一,一方面它主导了LSM-Tree的形状进而影响了LSM-Tree的包括性能、空间占用等对外表现,另一方面它本身要消耗相当的计算和IO资源,容易造成抖动等问题。 但目前业界针对compaction较少有系统的探索,很多系统的compaction策略依赖工程师的个人经验,大量可能的策略未被分析测试...

LSMTree综述

LSMTree综述
  LSM-based storage techniques: a survey (VLDBJ 2020)   This paper aims to serve as a guide to the state of the art in LSM-based storage techniques for researchers, practitioners, and users.   LSMTree引擎在业界已经有了很多的落地。很多NoSQL系统如Bigtable、Dynamo、HBase、Cassandra、LevelDB、RocksDB、AsterixDB底层都是LSMTree引擎。RocksDB在Facebook的实时数据处理...

InnoDB源码解析-日志系统

InnoDB源码解析-日志系统
MySQL 5.7中 Log Sys锁冲突比较大,MySQL 8.0对InnoDB Log Sys进行了重构。 我们先描述下5.7的 Log Sys看看锁冲突,然后再介绍8.0的方案以及部分代码实现细节。 mtr mtr 表示 mini-transaction,表示操作的一个最小原子单元,比数据库事务概念要更小。比如一个事务可能插入两行数据,但每插入一行都可能触发B-Tree的叶子分裂,页面的分裂操作涉及多个页面,这些页面的修改必须保持原子(不能发生分裂的第...

PolarDB-SCC:RO节点强一致性读优化

PolarDB-SCC:RO节点强一致性读优化
《PolarDB-SCC: A Cloud-Native Database Ensuring Low Latency for Strongly Consistent Reads》 很多数据库系统通过类似于binlog复制或者redo复制的方式提供RO节点来提升整个系统的读吞吐,RW节点上产生更新,同步到RO节点apply变更。但只读请求发到RO节点上可能会读到陈旧的数据。如果想读到最新的数据(例如read-after-write一致性)呢? 首先读到最新数据或者强一致性读,指的是RO上启动的只读请求,...