系统与数据库2015malteschwarzkopf.de
Google 技术栈
The Google Stack
入门 · 约 25 分钟读完前置知识：分布式系统基础概念、Google 基础设施系统（GFS、MapReduce、Borg 等）的初步了解
导读
这篇论文（图示）梳理了 Google 内部的基础设施技术栈，涵盖从 GFS/Colossus、BigTable 等存储系统，到 Borg、MapReduce、Dremel 等计算与数据处理平台的整体架构层次。它展示了 Google 各系统之间的依赖关系，其中不少组件后来以 Google Cloud 服务的形式对外提供。
HN 关注点：HN 读者对 Google 内部系统的全景图很感兴趣，讨论焦点在于它与 Facebook 技术栈的对比、与 Google Cloud 产品的对应关系，以及这种以数据为中心的架构视角。
后来怎么样
图中多个内部系统后来以 Google Cloud 服务形式对外提供（Borg→Kubernetes、Dremel→BigQuery 等），Kubernetes 更成为容器编排的事实标准。
HN 评论精选
这几条评论里：支持 1 质疑 1 补充 2
补充建议与同作者的 Facebook 技术栈图对比，甚至可视化各公司系统之间的相互影响
有趣的是可以把这张图和同一位作者画的 Facebook 技术栈对比：……如果能把不同公司基础设施平台之间的“相关工作”箭头也画出来就更有意思了，不过那需要 3D 可视化才行。
mrry查看英文原文
It's interesting to compare this with the Facebook stack, drawn by the same author: http://malteschwarzkopf.de/research/assets/facebook-stack.pdf …and it would be doubly interesting to see the "related work" arrows between the different companies' infrastructure platforms. We'd need a 3D visualization for that though.
支持这张图体现了以数据为中心而非以语言/框架为中心的架构观
看这张图时我注意到它与我们通常描述技术栈的方式差别很大：几乎没有涉及语言、框架或软件惯用意义上的“模式”，而是由各种各样的数据存储和访问层组成。差程序员担心代码，好程序员担心数据结构？
wwweston查看英文原文
When I'm looking at this diagram I'm struck by how much it diverges from the typical entities invoked when we generally describe a tech stack. There's almost no discussion of language or framework or "patterns" in the software idiom sense. Instead it's largely a wide variety of data stores and access layers. Bad programmers worry about code, good programmers worry about data structures?
补充Google 内部栈的许多组件已对应外部化为 Google Cloud 服务
有意思的是，其中很多都通过 Google Cloud 以某种形式对外提供了：GFS/Colossus = GCS，Borg = Kubernetes，Dremel = BigQuery，BigTable = BigTable（自然），FlumeJava/MapReduce/MillWheel = Dataflow。
vgt查看英文原文
Interesting is that much of this is externalized through Google Cloud in one way or another: - GFS/Colossus = GCS - Borg = Kubernetes - Dremel = BigQuery - BigTable = BigTable (naturally) - FlumeJava,MapReduce,MillWheel = Dataflow
质疑质疑该图缺乏具体服务与栈组件的对应关系，信息量有限
Google 有很多服务。这张图如果不说明哪些服务使用了技术栈的哪些部分，意义就不大。
amelius查看英文原文
Google has many services. This diagram means little if it does not specify what services use what parts of the stack.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2015Hacker News 讨论帖158 分 · 40 评
同领域还值得读
I/O 比 CPU 更快——让我们划分资源并消除操作系统抽象
I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions
指出在现代服务器硬件上 I/O 速度已接近甚至超过 CPU，传统操作系统抽象反而成为瓶颈。
系统与数据库2019 · 817 分 · 277 评进阶 · 约 30 分钟编辑精选使用 io_uring 的高效 I/O
Efficient IO with io_uring
由 Linux 内核开发者 Jens Axboe 撰写，介绍 Linux 新的异步 I/O 接口 io_uring。
系统与数据库2019 · 426 分 · 96 评进阶 · 约 45 分钟编辑精选线程对大多数用途而言是个坏主意（1995）
Threads Are a Bad Idea for Most Purposes (1995)
这篇 1995 年的文章由 John Ousterhout 撰写，讨论为什么线程对大多数用途而言是坏主意，并主张事件驱动编程通常更简单、更高效。
系统与数据库2017 · 423 分 · 382 评进阶 · 约 25 分钟编辑精选学习型索引结构之论证
The Case for Learned Index Structures
提出把索引看作一种"模型"：既然 B-tree 等结构本质上是在学习数据的分布，就可以用机器学习模型（如回归模型、神经网络）来近似键到位置的映射，从而替代 B-tree、哈希索引…
系统与数据库2017 · 398 分 · 66 评 · 引用 25进阶 · 约 60 分钟编辑精选FoundationDB：一个分布式、解耦的事务型键值存储
FoundationDB: A distributed, unbundled, transactional key value store
介绍 FoundationDB：一个分布式、解耦设计的事务性键值存储。
系统与数据库2021 · 283 分 · 99 评进阶 · 约 90 分钟编辑精选