木鸟杂记

分布式系统,数据库,存储

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

阅读全文 »

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

事务型还是分析型

术语 OL(Online)主要是指交互式的查询。

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

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

阅读全文 »

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

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

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

阅读全文 »

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

概要

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

如何分析一个数据模型

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

如何考量查询语言

  1. 如何与数据模型关联、匹配
  2. 声明式(declarative)和命令式(imperative)
阅读全文 »