Facebook Velox 是一个针对 SQL 运行时的 C++ 库，旨在统一 Facebook 各种计算流，包括 Spark 和 Presto，使用推的模式、支持向量计算。
Velox 接受一棵优化过的 PlanNode Tree，然后将其切成一个个的线性的 Pipeline，Task 负责这个转变过程，每个 Task 针对一个 PlanTree Segment。大多数算子是一对一翻译的，但是有一些特殊的算子，通常出现在多个 Pipeline 的切口处，通常来说，这些切口对应计划树的分叉处，如 HashJoinNode，CrossJoinNode， MergeJoinNode ，通常会翻译成 XXProbe 和 XXBuild。但也有一些例外，比如 LocalPartitionNode 和 LocalMergeNode 。
不知道为何，今年朋友圈分享年终总结的朋友格外多。我挺喜欢这个形式，一来，我很爱看别人的年终总结，看故事之余还能看到一些不同路径；二来，每年定期回顾下，也确实能帮着梳理下思路，简单做下展望。
古代知识垄断的时代，只有帝王将相才能有纪传；而今信息爆炸的世代，人人皆可记之，为自己代言。于短期来说，年岁渐长，思虑日增，很多事不记下来，旬月便忘，通过年终回顾，日后回头追踪下自己思想变迁轨迹，也算三省吾身，冀有新得；于长期来说，我们终将作古，若借助互联网能留下个一鳞半爪，博后世一笑，也算雁过留声。
DDIA 读书分享会，会逐章进行分享，结合我在工业界分布式存储和数据库的一些经验，补充一些细节。每两周左右分享一次，欢迎加入，Schedule 和所有文字稿在这里。我们有个对应的分布式&数据库讨论群，每次分享前会在群里通知。如想加入，可以加我的微信号：qtmuniao，简单自我介绍下，并注明：分布式系统群。另外，我的公众号：“木鸟杂记”，有更多的分布式系统、存储和数据库相关的文章，欢迎关注
本书第一部分讲单机数据系统，第二部分讲多机数据系统。
冗余（Replication） 是指将同一份数据复制多份，放到通过网络互联的多个机器上去。其好处有：
本章假设我们的数据系统中所有数据能够存放到一台机器中，则本章只需考虑多机冗余的问题。如果数据超过单机尺度该怎么办？那是下一章要解决的事情。
上云的好处在于池化资源，让多租户共享，然后按需分配，从而降低成本。但进行：
是一对相对矛盾的事情，我认为，也是云原生数据库最要解决的问题。不把这个问题解决好，则数据库：
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 语句，转化为读写请求，发送给存储层。对于存储层，又可以细分为三层：
来源：https://engineering.fb.com/2022/05/04/data-infrastructure/delta/
导读：偶然看到群里同学分享的 Meta 博客新公开的高可用、强一致、链式复制的对象存储。由于我也做过一段时间的对象存储，也分享过 Facebook 家的小文件存储：Haystack（做 batch） 和 F4（冷热分开、EC）， 顿时来了兴致，好奇这次 Meta 又带来了什么干货。
看完之后觉得的确有点意思，下面简单梳理下文章要点，感兴趣的同学可以去看看博客原文，还有华人小姐姐解说的相关视频哦。
Delta 是简单、可靠、可扩展、低依赖的对象存储，只提供四个基本操作：put、get、delete 和 list。在架构设计上，Delta 牺牲了读写延迟和存储效率，来换取架构的简单性和可靠性。
Delta 不是：
做数据库有一段时间了。最近有一些在校的同学问到，在实际中，分布式数据库中存储层工作内容是什么样的？简单回答了下，想到其他人可能也有类似问题，于是来这里总结下、抛个砖头。经验所限，难免有误，欢迎交流。
注：限定下讨论范围，分布式数据库，存储计算分离，share-noting 架构，仅讨论存储层。
存储层涉及的东西很庞杂，想说清楚，需要有一个合适的切入角度。数据库最本质的功能，是存储数据，以对外提供数据的查询和写入接口。不妨，就首先以这两条线串一下各个模块，然后再补充下不能归到这两条线中的一些组件。