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

说起数据库的事务，大家第一反应多是 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）。因为持久化存储和网络传输都是面向字节流的。序列化本质上是一种“降维”操作，将内存中高维的数据结构降维成单维的字节流，于是底层硬件和相关协议，只需要处理一维信息即可。

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

事务型还是分析型

术语 OL（Online）主要是指交互式的查询。

术语事务（ transaction ）由来有一些历史原因。早期的数据库使用方多为商业交易（commercial ），比如买卖、发工资等等。但是随着数据库应用不断扩大，交易\事务作为名词保留了下来。

事务不一定具有 ACID 特性，事务型处理多是随机的以较低的延迟进行读写，与之相反，分析型处理多为定期的批处理，延迟较高。

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

第二章讲了上层抽象：数据模型和查询语言。
本章下沉一些，聚焦数据库底层如何处理查询和存储。这其中，有个逻辑链条：

使用场景→ 查询类型 → 存储格式。

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

概要

本节围绕两个主要概念来展开。

如何分析一个数据模型：

1. 基本考察点：数据基本元素，和元素之间的对应关系（一对多，多对多）
2. 利用几种常用模型来比较：（最为流行的）关系模型，（树状的）文档模型，（极大自由度的）图模型。
3. schema 模式：强 Schema（写时约束）；弱 Schema（读时解析）

如何考量查询语言：

1. 如何与数据模型关联、匹配
2. 声明式（declarative）和命令式（imperative）

计算下推其实是常见的思想：将计算推到数据旁。由于在数据库中，逻辑上，计算常在存储层之上，因此将一部分算子推到存储层去做，称为计算下推。其在分布式数据库中尤为重要。

下面是 CockroachDB 和 TiDB 的解决方案，内容来自于文档和博客，因此可能和最新代码的逻辑并不一致。

CockroachDB

基本概念

CockroachDB 中相应的模块叫 DistSQL，其思想来源于Sawzall，有点类似 MapReduce。支持的算子叫做 aggregator，本质上是对 SQL 聚合算子的一种泛化。

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

第一章是很容易被跳过的一章，因为概念较多，容易泛泛而谈。但其给出的三个概念，确实是构建系统避不开的三个重点方向。

ps. 开源中文版本有些地方翻译的不是很地道，读起来可能会有些难受，不过这是所有翻译难免的。

（贾）岛初赴举京师，一日驴上得句云：“鸟宿池边树，僧敲月下门”。始欲着“推”字，又欲着“敲”字，练之未定，遂于驴上吟哦，时时引手作推敲之势。

—— 宋·胡仔《苕溪渔隐丛话》卷十九引《刘公嘉话》

命名，是编码中最为紧要的事情，其之于程序，便如脸面之于少女。好的命名，能清晰的传达代码的意图，甚而，有一种韵律的美感。而懒散随意的起名，则令人如堕云雾，不忍卒读，会一遍遍地消耗维护者的精气神儿。此外，混乱的命名体系，能轻巧的掩藏 BUG，贻祸千里。

因此，我们在写代码时，有必要花一点时间，对关键命名进行推敲，与人方便，与己方便。对于生命周期越长的项目，其益处便越明显。那么该如何推敲呢？结合自己写代码、看代码、Review 代码的一些经验，聊聊我的一些体会。

最近写 golang 多一点，因此例子用的都是 golang ，但都是伪代码，有些例子并不不严格遵从语法。此外，例子大多出于现造，因此可能并不是特别贴合。

引子

哈希的本质是从一个较大空间映射到一个较小的空间，因此在插入数据足够多之后，根据鸽巢原理，一定会存在位置冲突。常见的哈希表（Hash Table 或者字典，dictionary）会通过链表、开放地址探测等方式来处理冲突。单桶多函数的布谷鸟哈希，便是开放地址法处理冲突的一种哈希表，只不过有冲突后，不是通过线性寻找新的位置，而是通过额外哈希函数来寻找。