本文来自 Amazon S3 VP Andy Warfield 在 FAST 23 上的主旨演讲的文字稿,总结了他们在构架和维护如此量级的对象存储 —— S3 的一些经验。我们知道,Amazon S3 是云时代最重要的存储基础设施之一,现在各家云厂商的对象存储基本都兼容 S3 接口,所有云原生的基础设施,比如云原生数据库,其最终存储都要落到对象存储上。
Firebolt:如何在十八个月内组装一个商业数据库
假如你是一个初创公司的 CTO,想迅速推出一款面向 AP 市场可用的数据库产品,还得有差异化的功能(不然谁会用一个新产品),你会怎么做呢?
Firebolt 在 2022 年专门发了一篇论文:Assembling a Query Engine From Spare Parts 来讲这个事情。核心思想就是,利用开源组件,像攒台式机一样攒出一个数据库。
【图解面试基础】三种基本排序算法
知新的关键——类比
这一年来,由于各种原因,需要不断地学新东西。于是如何高效地学习,就成了一个随之而来的问题。最近看了一些书和公开课,包括 Scott H Young 的 Learn More, Study Less(以下简称 LMSL),和 Coursera 上的公开课学会如何学习(Learning How to Learn,以下简称 LHL),发现了一些有意思的观点,趁着热乎(虽然都还没看完),记下来梳理一下,也希望能对大家有所启发。
这两个资源在进行讲解时,都使用了类比(analogy)。
LMSL 中提出了整体学习法(Holistic learning),其基本思想是:你不可能孤立地学会一个概念,而只能将其融入已有的概念体系中,从不同角度对其进行刻画来弄懂其内涵和外延。
数据库面试的几个常见误区
生活工程学(一):多轮次拆解
我们在工程实践中,有些构建代码的小技巧,其背后所体现的思想,生活中也常常可见。本系列便是这样一组跨越生活和工程的奇怪联想。这是第一篇:多轮次拆解,也即,很多我们习惯一遍完成的事情,有时候拆成多个轮次完成,会简单、高效很多。
我在进行 code review 时,常看到一些新手同学在一个 for 循环中干太多事情。常会引起多层嵌套,或者 for 循环内容巨大无比。此时,如果不损失太多性能,我通常建议同学将要干的事情拆成多少个步骤,每个步骤一个 for 循环。甚至,可以每个步骤一个函数。
当然,这些全是从维护角度着眼的。因为人一下总是记不了太多事情,一步步来,而不是揉在一块来,会让每个步骤逻辑清晰很多。后者,我通常称之为”摊大饼“式代码,这种代码的特点是写时很自然,但是维护起来很费劲——细节揉在一起总会让复杂度爆炸。软件工程中的最小可用原型,也是类似的理念。
数据处理的大一统——从 Shell 脚本到 SQL 引擎
NUMA-Aware 执行引擎论文解读
最近翻 DuckDB 的执行引擎相关的 PPT(Push-Based-Execution) 时,发现了这篇论文:Morsel-Driven Parallelism: A NUMA-Aware Query Evaluation Framework for the Many-Core Age。印象中在执行引擎相关的文章中看到他好几次;且 NUMA 架构对于现代数据库架构设计非常重要,但我对此了解尚浅,因此便找来读一读。
从题目中也可以看到,论文最主要关键词有两个:
- NUMA-Aware
- Morsel-Driven
据此,大致总结下论文的中心思想:
- 多核时代,由于部分 CPU 和部分内存的绑定关系,CPU 访问内存是不均匀(NUMA)的。也即,对于某一个 CPU 核来说,本机上一部分内存访问延迟较低,另一部分内存延迟要高。
- 传统火山模型,使用 Exchange 算子来进行并发。其他算子并不感知多线程,因此也就没办法就近内存调度计算(硬件亲和性)。也即,非 NUMA-local。
- 为了解决此问题,论文在数据维度:对数据集进行水平分片,一个 NUMA-node 处理一个数据分片;对每个分片进行垂直分段(Morsel),在 Morsel 粒度上进行并发调度和抢占执行。
- 在计算维度:为每个 CPU 预分配一个线程,在调度时,每个线程只接受数据块(Morsel)分配到本 NUMA-node 上的任务;当线程间子任务的执行进度不均衡时,快线程会”窃取“本应调度到其他线程的任务,从而保证一个 Query 的多个子任务大约同时完成,而不会出现”长尾“分片。
20230819 B 站求职面试直播
这是我第一次在 b 站直播分享,录屏地址 https://www.bilibili.com/video/BV1Fz4y1u79v ,主要是从我的求职经历以及面试经历角度聊了一些关于 infra 找工作的注意点,并回答了同学一些现场问题。
🐎 求职准备
软素质
💁♂️ 沟通。面试时无论是经历描述,系统设计甚至写代码,沟通都是第一位的,这是面试各个环节顺利展开的前提。
把一件事说清楚:
- 上下文:先和面试官对齐上下文,不要默认他比你知道的多。
- 条理性:背景 → 需求 → 方案 → 挑战点 → 结果
- 简洁性:就跟写文章一样,多过几遍就好了。
🧠 思维。主要是抽象和联想。
- 抽象。也可以说是归纳,或者叫知识聚簇。以树来做类比,就是遍历几个子节点,抽象出其共通的父节点的特质,然后进而推演出新的子节点。比如调度问题(CPU 调度、分布式任务调度)。
- 联想。也可以说是关联,或者叫跨域跳联。以图来做类比,就是对于几个连通子图,在新的维度上给其建立通路。比如文字是思想的一种序列化。
RocksDB 运行原理
RocksDB 是很多分布式数据库的底层存储,如 TiKV、CRDB、NebulaGraph 等等。在 DataDog 工作的 Artem Krylysov 写了一篇文章来对 RocksDB 做了一个科普,通俗易懂,在这里翻译下分享给大家。
导语
近几年,RocksDB 的采用率急速上升,俨然成为内嵌型键值存储(以下简称 kv 存储)的不二之选。
目前,RocksDB 在 Meta、Microsoft、Netflix 和 Uber 等公司的生产环境上运行。在 Meta,RocksDB 作为 MySQL 部署的存储引擎,为分布式图数据库(TAO)提供支持存储服务。
大型科技公司并非 RocksDB 的仅有用户,像是 CockroachDB、Yugabyte、PingCAP 和 Rockset 等多个初创企业都构建在 RocksDB 基础之上。
我在 Datadog 工作了 4 年时间,在生产环境中构建和运行了一系列基于 RocksDB 的服务。本文将就 RocksDB 的工作原理进行概要式讲解。
影响我写代码的三个 “Code”
国内很多大学的计算机专业,比较偏重基础和理论的“灌输”(就我当年上学的体验,现在可能会好一些),对于代码能力,虽然也有一些课程实验,但往往不太够用。于是,在进入正式工作前,很多同学就会对自己代码水平不太自信。下面我就根据我自身的写代码经历提供一些建议。
Facebook Velox 运行机制全面解析
概述
Facebook Velox 是一个针对 SQL 运行时的 C++ 库,旨在统一 Facebook 各种计算流,包括 Spark 和 Presto,使用推的模式、支持向量计算。
Velox 接受一棵优化过的 PlanNode
Tree,然后将其切成一个个的线性的 Pipeline
,Task
负责这个转变过程,每个 Task 针对一个 PlanTree Segment。大多数算子是一对一翻译的,但是有一些特殊的算子,通常出现在多个 Pipeline 的切口处,通常来说,这些切口对应计划树的分叉处,如 HashJoinNode
,CrossJoinNode
, MergeJoinNode
,通常会翻译成 XXProbe 和 XXBuild。但也有一些例外,比如 LocalPartitionNode
和 LocalMergeNode
。