木鸟杂记

概述

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）保证跨区容错性。

来源：https://engineering.fb.com/2022/05/04/data-infrastructure/delta/

导读：偶然看到群里同学分享的 Meta 博客新公开的高可用、强一致、链式复制的对象存储。由于我也做过一段时间的对象存储，也分享过 Facebook 家的小文件存储：Haystack（做 batch） 和 F4（冷热分开、EC）， 顿时来了兴致，好奇这次 Meta 又带来了什么干货。

看完之后觉得的确有点意思，下面简单梳理下文章要点，感兴趣的同学可以去看看博客原文，还有华人小姐姐解说的相关视频哦。

Delta 是什么？

Delta 是简单、可靠、可扩展、低依赖的对象存储，只提供四个基本操作：put、get、delete 和 list。在架构设计上，Delta 牺牲了读写延迟和存储效率，来换取架构的简单性和可靠性。

Delta 不是：

1. 通用存储系统。Delta 只追求弹性、可靠和最小依赖。
2. 文件系统。Delta 只是简单的对象存储，不提供 POSIX 语义。
3. 为存储效率而优化的系统。Delta 并没有针对存储效率、延迟和吞吐做优化，而是专注简单和弹性。

做数据库有一段时间了。最近有一些在校的同学问到，在实际中，分布式数据库中存储层工作内容是什么样的？简单回答了下，想到其他人可能也有类似问题，于是来这里总结下、抛个砖头。经验所限，难免有误，欢迎交流。

注：限定下讨论范围，分布式数据库，存储计算分离，share-noting 架构，仅讨论存储层。

存储层涉及的东西很庞杂，想说清楚，需要有一个合适的切入角度。数据库最本质的功能，是存储数据，以对外提供数据的查询和写入接口。不妨，就首先以这两条线串一下各个模块，然后再补充下不能归到这两条线中的一些组件。

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

第三章讲了存储引擎，本章继续下探，探讨编码相关问题。

所有涉及跨进程通信的地方，都需要对数据进行编码（Encoding），或者说序列化（Serialization）。因为持久化存储和网络传输都是面向字节流的。序列化本质上是一种“降维”操作，将内存中高维的数据结构降维成单维的字节流，于是底层硬件和相关协议，只需要处理一维信息即可。