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性能不一样,这个主要是底层数据...

RocksDB演进

RocksDB演进
《Evolution of Development Priorities in Key-value Stores ServingLarge-scale Applications: The RocksDB Experience》FAST'20 这篇文章是讲述Facebook大规模部署RocksDB的经验,主要是RocksDB优化目标的演变。 RocksDB应用比较广,除了作为KV产品服务业务,也在很多其他系统中作为存储组件。 Streaming Processing: Flink, Kafaka Stream, Samba, Facebook's Stylus. Logging/Queuing Service: Fa...

LSMTree自适应内存管理

LSMTree自适应内存管理
LSMTree自适应内存管理 Breaking Down Memory Walls: Adaptive Memory Managementin LSM-based Storage Systems(VLDB'21) 内存管理整体架构比较清晰,如图,无需赘言。 Write Memory内存管理 Write Memory的管理方式见下图。 像RocksDB的Write Memory就是一整个memtable,论文给出了另外一个思路,即使是write memory也用leveled方式,如图。Memory也分成M0,M1,M2三层,M0满则merge到M1,同理M1 merg...

构建分析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策略依赖工程师的个人经验,大量可能的策略未被分析测试...

论文阅读 - OLTP Through the Looking Glass

论文阅读 - OLTP Through the Looking Glass
这篇文章是08年SIGMOD的文章。 OLTP系统各组件开销 很多OLTP数据库的架构扔延续了70年代面向当时的硬件的设计,但30年来,现代CPU、内存、网络等等已经有了很大的变化。这篇论文分析了一个OLTP数据库的各个组件的开销。   OLTP系统设计趋势 Cluster Computing 从单机多线程的架构,在80年代有了shared disk的架构,最近20年又有shared nothing的架构。再以后的数据库必须要考虑面向集群。   Mem...

Databricks Lakehouse

Databricks Lakehouse
《Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics》 CIDR21'   整片文章讲的比较宽泛。   Introduction 第一代数仓:结构化数据,用于决策支持和BI。 第二代数仓:解决存储和计算资源耦合、无弹性、非结构化数据激增等问题,采用了data lakes方案,采用开放格式,数据存储到分布式文件系统,主要代表是Hadoop运动。 第三代数仓,2015年...

Snowflake Elastic Data Warehouse

Snowflake Elastic Data Warehouse
《The Snowflake Elastic Data Warehouse》 SIGMOD 16' Snowflake具备如下的特点: 纯粹的SaaS体验:用户将数据放到云上,然后可以通过snowflake对他们的数据进行查询。 关系型:支持SQL和ACID 办结构化:内置函数和SQL扩展来支持对半结构化数据的访问,自动schema discovery和列式存储 弹性:存储和计算资源可以独立无缝弹性,不影响数据可用性和当前查询性能 高可用:容忍node、cluster和data cent宕机...

How to Architect a Query Compiler Revisited

How to Architect a Query Compiler Revisited
How to Architect a Query Compiler, Revisited》 SIGMOD'168 数据库执行一个查询的流程包括前端语法解析、优化器以及后端解释执行。语言编译器的流程与之类似,除了最后一步会编译成机器码执行,DBMS一般还是解析执行的。 在相当长一段时间内,硬盘IO是主要的性能瓶颈,计划的解释执行有利于移植,因此将解释执行替换成编译执行没有太大必要。但NVM硬件发展和业务对AP型查询需求增多,使得很多时候查询是...

Orca优化器

Orca优化器
《Orca: A Modular Query Optimizer Architecture for Big Data》 SIGMOD 2014   Orac是Pivotal数据管理系列产品(包括 Pivotal Greenplum Database和Pivotal HAWQ)共用的优化器模块,面向AP负载,整合了当时最新的技术。 Orac的主要特点: Modularity 对元数据和系统描述进行抽象,因此可移植 Extensibility 将所有的查询元素和优化操作当做first class citizen,避免多阶段优化 Multi-core Ready...

关系数据库优化器概述

关系数据库优化器概述
《An Overview of Query Optimization in Relational Systems》PODS 1998, Microsoft Research 优化器的输入是用户查询,负责生成一个高效的执行计划,优化过程是一个比较复杂的过程。 优化器主要包含三个部分: Search Space:搜索空间包含足够好的计划 代价估计:代价估计足够精确 枚举算法:枚举算法要足够高效 System R优化器案例 以System R为例来初步看下优化器的这三部分,通过这一节,对优化器...