系统与数据库2017dl.acm.org编辑精选
Spanner：演进为一个 SQL 系统
Spanner: Becoming a SQL System
进阶 · 约 60 分钟读完前置知识：分布式系统基础、Spanner 2012 论文、SQL 与查询执行基础
导读
这篇论文介绍 Spanner 从分布式键值存储演进为完整 SQL 系统的过程：新增原生 SQL 接口（不再依赖上层的 F1）、改用列式存储引擎（基于深度改造的 Bigtable）、支持频繁并发地重新分片，并支持全文搜索等特性。论文还解释了为何 Spanner 暂不支持 SQL DML 写入——事务中写入必须是最后一步，且不支持读取未提交的写入。
HN 关注点：Spanner 是 Google 核心分布式数据库，从 2012 年论文到如今变成 SQL 系统的架构巨变引发 HN 读者对分布式数据库演进路线的浓厚兴趣。
后来怎么样
确立了 Spanner 作为 Google 内部统一 SQL 存储系统的方向，其原生 SQL 化与列式存储改造成为业界讨论分布式数据库演进的重要参照，影响了后续 NewSQL 系统的设计思路。
HN 评论精选
这几条评论里：质疑 1 补充 2 亲历 1
补充梳理了新版 Spanner 相对 2012 年论文的五大架构变化
这个“现代版” Spanner 与 2012 年的版本大不相同。几个有意思的要点：Spanner 有了原生 SQL 接口，不再像 F1 那样依赖独立的上层 SQL 层；Spanner 不再构建在 Bigtable 之上，存储引擎改成了深度改造的 Bigtable，采用列式文件格式；数据会频繁地与其他操作并发地重新分片，分片布局通过“分布式 union”算子对查询计划抽象隐藏；Spanner 不支持 SQL DML 写入的可能原因是：写入必须是事务的最后一步，目前不支持读取未提交的写入（F1 则支持 DML）；Spanner 还支持全文搜索。
elvinyung查看英文原文
This "modern" Spanner feels very different from the one we saw in 2012 [1]. Some interesting takeaways: * There is a native SQL interface in Spanner, rather than relying on a separate upper-layer SQL layer, a la F1 [2] * Spanner is no longer on top of Bigtable! Instead, the storage engine seems to be a heavily modified Bigtable with a column-oriented file format * Data is resharded frequently and concurrently with other operations -- the shard layout is abstracted away from the query plan using the "distributed union" operator * Possible explanation for why Spanner doesn't support SQL DML writes: writes are required to be the last step of a transaction, and there is currently no support for reading uncommitted writes (this is in contrast to F1, which does support DML) * Spanner supports full-text search (!) [1] https://research.google.com/archive/spanner.html [2] https://research.google.com/pubs/pub41344.html
补充指出 Spanner/Aurora 论文作者多来自微软人才流失潮
说点题外话：看作者名单时我认出了很多 2005-2012 年微软 SQL Server 团队的人，都是我认识的顶尖工程师。看 Aurora 论文时也是如此。我认为这是 Ballmer 著名的 HR 政策以及 2010 年前后微软大规模人才流失的结果。
rusanu查看英文原文
Tangential. For me the fascinating thing is looking at the list of authors to recognize so many from the 2005-2012 Microsoft SQL Server team. Folk I know personally as exceptional performers. Same when I look at Aurora papers. I see this as the result of Ballmer's famous HR initiatives and the massive brain drain that occurred at Microsoft around 2010-ish.
亲历Google 工程师称内部存储系统终将统一到 Spanner
几个月前我在 Google Cloud 大会上和几位工程师聊过 Spanner。当我问它会如何影响他们其他存储产品（如 datastore、cloud sql 等）时，他们说随着时间推移，所有内部存储系统都会迁移到 Spanner 上。原话是“不管你知不知道，你都会在用 Spanner”。这位工程师显然是产品的忠实拥护者，我怀疑是否真会如此，但他们对 Spanner 的信心显而易见。
speedplane查看英文原文
I was at the Google Cloud conference a few months ago and spoke to a few engineers there about Spanner. When I asked them about how it would affect their other storage options (e.g., datastore, cloud sql, etc.), they said that over time, all of their internal storage systems would be moved over to Spanner. His words were "you'll be using Spanner whether you know it or not." This engineer was clearly a cheerleader for the product, so I'm dubious as to whether that will actually happen, but it's clear that they have quite a bit of confidence in it.
质疑质疑专有云数据库在 Google/微软之外的实际使用情况
Google 或微软之外，有人在用这些专有的 k/v/SQL/JSON 数据库吗？作为开发者，我无法接受对不能装在自己笔记本上的系统写代码；而企业也不会用无法支撑财务/HR/LDAP/SharePoint 等业务的数据存储。那么到底是谁在用、用来做什么？
sheeshkebab查看英文原文
Is anyone outside of Google or msft using these proprietary k/v/sql/Json databases? As a developer I can't bring myself to code against something I can't install on my laptop. And as enterprises would go, they won't use any data store that can't run their financials/hr/ldap/sharepoint thing. So, who uses them and for what?
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2017Hacker News 讨论帖162 分 · 38 评
同领域还值得读
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 分钟编辑精选