这是我第一次在 b 站直播分享，录屏地址 https://www.bilibili.com/video/BV1Fz4y1u79v ，主要是从我的求职经历以及面试经历角度聊了一些关于 infra 找工作的注意点，并回答了同学一些现场问题。

🐎 求职准备

软素质

💁‍♂️ 沟通。面试时无论是经历描述，系统设计甚至写代码，沟通都是第一位的，这是面试各个环节顺利展开的前提。

把一件事说清楚：

1. 上下文：先和面试官对齐上下文，不要默认他比你知道的多。
2. 条理性：背景 → 需求 → 方案 → 挑战点 → 结果
3. 简洁性：就跟写文章一样，多过几遍就好了。

🧠 思维。主要是抽象和联想。

1. 抽象。也可以说是归纳，或者叫知识聚簇。以树来做类比，就是遍历几个子节点，抽象出其共通的父节点的特质，然后进而推演出新的子节点。比如调度问题（CPU 调度、分布式任务调度）。
2. 联想。也可以说是关联，或者叫跨域跳联。以图来做类比，就是对于几个连通子图，在新的维度上给其建立通路。比如文字是思想的一种序列化。

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 的工作原理进行概要式讲解。

国内很多大学的计算机专业，比较偏重基础和理论的“灌输”（就我当年上学的体验，现在可能会好一些），对于代码能力，虽然也有一些课程实验，但往往不太够用。于是，在进入正式工作前，很多同学就会对自己代码水平不太自信。下面我就根据我自身的写代码经历提供一些建议。

概述

Facebook Velox 是一个针对 SQL 运行时的 C++ 库，旨在统一 Facebook 各种计算流，包括 Spark 和 Presto，使用推的模式、支持向量计算。

Velox 接受一棵优化过的 PlanNode Tree，然后将其切成一个个的线性的 Pipeline，Task 负责这个转变过程，每个 Task 针对一个 PlanTree Segment。大多数算子是一对一翻译的，但是有一些特殊的算子，通常出现在多个 Pipeline 的切口处，通常来说，这些切口对应计划树的分叉处，如 HashJoinNode，CrossJoinNode， MergeJoinNode ，通常会翻译成 XXProbe 和 XXBuild。但也有一些例外，比如 LocalPartitionNode 和 LocalMergeNode 。

不知道为何，今年朋友圈分享年终总结的朋友格外多。我挺喜欢这个形式，一来，我很爱看别人的年终总结，看故事之余还能看到一些不同路径；二来，每年定期回顾下，也确实能帮着梳理下思路，简单做下展望。

古代知识垄断的时代，只有帝王将相才能有纪传；而今信息爆炸的世代，人人皆可记之，为自己代言。于短期来说，年岁渐长，思虑日增，很多事不记下来，旬月便忘，通过年终回顾，日后回头追踪下自己思想变迁轨迹，也算三省吾身，冀有新得；于长期来说，我们终将作古，若借助互联网能留下个一鳞半爪，博后世一笑，也算雁过留声。

知乎上有个问题：如何实现一个数据库？手痒忍不住又水了一篇。以计算机中最常用的分析、理解问题的思想，我们可以从两个维度：逻辑和物理，来思考如何实现一个数据库。

逻辑维度

数据模型（对外，面向用户）

想要实现一个数据库，首先你得定义给给用户什么样的数据模型？在前些年，这些可能不是个问题，彼时，数据库约等于关系型数据，约等于 Oracle/SQLServer/MySQL/PostgreSQL 。但随着数据量的不断增大、用户需求的不断细化，关系模型已经不能一招鲜、吃遍天。

DDIA 读书分享会，会逐章进行分享，结合我在工业界分布式存储和数据库的一些经验，补充一些细节。每两周左右分享一次，欢迎加入，Schedule 和所有文字稿在这里。我们有个对应的分布式&数据库讨论群，每次分享前会在群里通知。如想加入，可以加我的微信号：qtmuniao，简单自我介绍下，并注明：分布式系统群。另外，我的公众号：“木鸟杂记”，有更多的分布式系统、存储和数据库相关的文章，欢迎关注
本书第一部分讲单机数据系统，第二部分讲多机数据系统。

冗余（Replication） 是指将同一份数据复制多份，放到通过网络互联的多个机器上去。其好处有：

1. 降低延迟：可以在地理上同时接近不同地区的用户。
2. 提高可用性：当系统部分故障时仍然能够正常提供服务。
3. 提高读吞吐：平滑扩展可用于查询的机器。

本章假设我们的数据系统中所有数据能够存放到一台机器中，则本章只需考虑多机冗余的问题。如果数据超过单机尺度该怎么办？那是下一章要解决的事情。

知乎上有个问题，如何辨别一个程序员水平的高低？就这几年 Review 代码的体感，忍不住就工程素养这个话题吐两句槽，正好作为好好写代码系列的第二篇。

思维体系

水平差的程序员往往在“抽象”上做的不好。

什么是抽象能力呢？简言之，就是分门别类、触类旁通的能力。通过大量实践和书籍输入，将所解决过的问题进行正交分解，分解过的元知识多具有很好地复用性；再利用这些元知识，进行组合推演，创造性的解决新遇到的问题。即归纳和演绎。

概述：流控为啥重要

上云的好处在于池化资源，让多租户共享，然后按需分配，从而降低成本。但进行：

1. 多租户隔离：用户要求可以使用其买到的流量，并且不会被其他租户影响。
2. 资源共享：资源只能逻辑隔开，不能物理隔开，否则无法充分动态分配（超发）。

是一对相对矛盾的事情，我认为，也是云原生数据库最要解决的问题。不把这个问题解决好，则数据库：

1. 要么平台不赚钱：比如资源静态预留，虽然可以让用户满意，总能随时用到卖给他的资源配额，但会存在巨大资源浪费，要么价格贵，要么用户不买单。
2. 要么用户不满意：多用户共享物理资源，但非常容易进行互相影响，造成用户不能用到平台声称的配额。

DynamoDB 从静态分配开始，逐步演化出一套全局和局部组合的准入控制机制，从而实现了物理上资源共享，但又在逻辑上给用户以配额隔离，从而实现了数据库真正的云原生。下面，我依据 Amazon DynamoDB: A Scalable, Predictably Performant, and Fully Managed NoSQL Database Service 这篇论文披露的细节，对其流控机制的演进过程做一个梳理，以飨诸君。

水平所限，谬误之处，欢迎随时指出。

Google LevelDB 是一个 LSM-Tree 的实现典范。但在开源出来后，为了保持轻量、简洁的风格，除了修修 Bug 之外，一直没有做太大的更新迭代。为了让其能够满足工业环境中多样性的负载， Facebook（Meta） 在 Fork 了 LevelDB 之后，做了多方面的优化。硬件方面，可以更有效地利用现代硬件，如闪存和快速磁盘、多核 CPU等；软件方面，针对读写路径、Compaction 也做了大量优化，如 SST 索引、索引分片、前缀 Bloom Filter、列族等。

本系列文章，依据 RocksDB 系列博客，结合源码和一些使用经验，分享一些有趣的优化点，希望能对大家有所启发。水平所限，不当之处，欢迎留言讨论。

本篇是 RocksDB 优化系列第一篇，为了优化深层查询性能，将不同层级的 SST 通过一定方式索引起来。

很久没有发文了，搞了一个月事务相关的资料和分享，今天用这篇文章做个小节。希望能给大家一些启发。

说起数据库的事务，大家第一反应多是 ACID，但这几个属性的重要性和复杂度并不等同。其中，最难理解的当属隔离性（I，Isolation）。造成这种理解困局的一个重要原因是，历史上对几种隔离级别的定义和实现耦合在了一块、不同厂商的的叫法和实现又常常挂羊头卖狗肉。本文试着从锁的角度来梳理下几种常见的隔离级别，用相对不精确的叙述给大家建立一个直观感性的认识。

在Google I/O 2022 大会上，Google Cloud 发布了兼容 PostgreSQL 标准的云原生数据库 AlloyDB（注：Alloy 意为合金），号称比 Amazon 的同类产品（Aurora？）快两倍，这个口号，对老用户来说，应该不足以让其迁移，但对于新用户来说，确有一些吸引力。

由于笔者主要做存储，下面基于谷歌这篇介绍 AlloyDB 存储层博文，剖析下 AlloyDB 存储层架构，看看其设计有何亮色。

整体架构

在整体上，AlloyDB 分为 Database 层和存储层。其中，DB 层用以兼容 PostgreSQL 协议，解析 SQL 语句，转化为读写请求，发送给存储层。对于存储层，又可以细分为三层：

1. log storage 层：DB 层会将写入转换为操作日志，或者说 WAL 写入存储层。log storage 负责这些日志记录的高效写入和存储。
2. LPS 层：Log Processing Service，LPS，日志处理服务层，消费 log storage 层的 WAL ，生成 Block，本质是一个物化（Materialized）的过程。
3. block storage 层：对应单机 PostgreSQL 的 block 层，用于服务查询，通过分片（shard）提供并行度、通过冗余（replication）保证跨区容错性。