Michael Stonebraker：数据库的多形态革新者，从Ingres到Postgres，再到"一个引擎不能统治一切"

图灵奖第四十九届（2014）| Michael Stonebraker：数据库的多形态革新者，从Ingres到Postgres，再到”一个引擎不能统治一切”

一句话概括：当别人试图打造”万能数据库”时，他坚信”没有一种数据库适合所有场景”——从关系型Ingres到对象关系型Postgres，再到列存储C-Store、流处理StreamBase，他用40年证明：不同的数据问题需要不同的引擎。

🏆 获奖简介

Michael Ralph Stonebraker（迈克尔·拉尔夫·斯通布雷克，1943-）是现代数据库系统的连续革新者，多形态数据库架构的先驱。

出生时间：1943年10月11日
出生地点：美国马萨诸セッツ州纽伯里波特
主要成就：创建Ingres、Postgres、C-Store、H-Store、SciDB等多个影响深远的数据库系统
获奖年份：2014年
获奖原因：在现代数据库系统底层概念与实践方面的根本性贡献

为什么他是第四十九位？ 1970年代，Edgar Codd提出关系模型理论，但理论到实践的鸿沟巨大。Stonebraker用Ingres证明关系数据库可以高效实现，成为商业数据库（如Oracle、SQL Server）的蓝本。1980年代，当所有人都在优化关系模型时，他看到了对象、复杂数据类型的需求，创造了Postgres（PostgreSQL的前身），开创对象关系数据库时代。进入21世纪，他又提出”一刀切的数据库已死”理念，针对不同负载（分析、流处理、科学数据）设计专用引擎。从学术界到产业界，他创建了至少9家数据库公司，其中VoltDB、Vertica等成为各自领域的标准。他不仅是技术天才，更是将学术创新转化为产业价值的大师。

🚀 重大贡献

1. Ingres：关系数据库的工程实现先驱（1973-1985）

背景（1970年代初）：

理论突破：Edgar Codd 1970年发表《A Relational Model of Data for Large Shared Data Banks》
业界怀疑：关系模型被认为”太慢、不实用”
主流技术：层次数据库（IMS）、网状数据库（CODASYL）
挑战：如何将数学化的关系代数转化为高效系统？

Ingres的革命性设计：

查询优化器的诞生

问题： SQL查询是声明式的（告诉”要什么”，不告诉”怎么做”），但执行效率差异巨大：

SELECT * FROM employees, departments
WHERE employees.dept_id = departments.id AND departments.location = 'Beijing'

两种执行计划：

笨办法：先笛卡尔积（employees × departments），再过滤 → 百万级操作
聪明办法：先过滤location=‘Beijing’的部门，再join → 千级操作

Ingres的查询优化器：

分解-优化(Decomposition)：将复杂查询分解为单变量查询
启发式重写：自动调整查询顺序
成本估算：基于统计信息选择索引或全表扫描

意义：这是世界上第一个真正的关系查询优化器，奠定了现代数据库的核心技术。今天所有SQL数据库（Oracle、MySQL、PostgreSQL）的优化器都继承了这一思想。

QUEL语言的创新

为什么不用SQL？ 当时SQL还是IBM的专利，且语法笨拙。Stonebraker设计了QUEL：

SQL vs QUEL对比：

-- SQL (当时)
SELECT E.name, D.name
FROM employees E, departments D
WHERE E.dept_id = D.id AND D.location = 'Beijing'

-- QUEL (更自然)
RANGE OF E IS employees
RANGE OF D IS departments
RETRIEVE (E.name, D.name)
WHERE E.dept_id = D.id AND D.location = 'Beijing'

QUEL更接近关系代数，表达力更强（支持传递闭包等），但最终SQL因为标准化胜出。

商业化的波折与成功

学术 → 产业的艰难转型：

1980：Stonebraker与学生创立Relational Technology Inc. (RTI)
产品：Ingres商业版
竞争对手：Oracle（Larry Ellison盗用了Ingres的部分思想！）
1994：被Computer Associates收购
遗产：PostgreSQL、Actian Ingres继续发展

影响： Ingres证明关系数据库可以商业化，激发了Oracle、Sybase、Informix等数据库产业的爆发。

2. Postgres：对象关系数据库的开创（1986-1994）

背景（1980年代）：

关系模型的局限：
- 只支持简单数据类型（整数、字符串、日期）
- 无法存储复杂对象（图像、地理信息、时序数据）
面向对象编程兴起：C++、Smalltalk流行
需求：数据库能否支持”对象”？

Postgres（Post-Ingres）的革命性特性：

可扩展类型系统

传统数据库：类型固定（INT, VARCHAR, DATE） Postgres：用户可以定义新类型！

例子：地理信息系统

-- 定义新类型：点、线、多边形
CREATE TYPE point AS (x float, y float);
CREATE TYPE polygon AS (points point[]);

-- 定义新操作符：包含、相交
CREATE FUNCTION contains(polygon, point) RETURNS bool AS ...
CREATE OPERATOR @ (leftarg=polygon, rightarg=point, procedure=contains);

-- 查询：哪些城市包含某个坐标？
SELECT city FROM cities WHERE boundary @ point(116.4, 39.9);

意义：这使得Postgres能支持任何领域的数据，无需修改内核。今天PostgreSQL的JSON、地理空间（PostGIS）、时序数据扩展，都源于此。

复杂查询：嵌套与继承

支持嵌套关系：

-- 一个员工可以有多个技能
CREATE TABLE employees (
    name text,
    skills text[]  -- 数组类型！
);

SELECT name FROM employees WHERE 'Python' = ANY(skills);

支持表继承：

CREATE TABLE persons (name text, age int);
CREATE TABLE students (grade int) INHERITS (persons);
CREATE TABLE employees (salary int) INHERITS (persons);

-- 查询所有persons（包括students和employees）
SELECT * FROM persons*;

规则系统与触发器

需求：数据库能否”主动”响应事件？

例子：物化视图

-- 创建摘要表
CREATE TABLE dept_summary (dept_id int, total_salary int);

-- 定义规则：当employees更新时，自动更新摘要
CREATE RULE update_summary AS
ON UPDATE TO employees
DO UPDATE dept_summary SET total_salary = ...

这是世界上第一个商业级触发器系统。

时间旅行（Time Travel）

创新理念：数据库能否记住”历史”？

Postgres中，每行数据有时间戳，可以查询”过去的状态”：

-- 查询1990年1月1日的员工工资
SELECT * FROM employees AS OF '1990-01-01';

虽然因性能问题后来移除，但启发了时态数据库和版本控制数据库的研究。

Postgres的遗产：

1996：开源为PostgreSQL，成为最先进的开源数据库
今天：全球数百万安装，云数据库服务（AWS RDS、Google Cloud SQL）的首选
技术领先：JSON支持、全文搜索、外部数据包装器（FDW）

3. “一个尺寸不适合所有”：专用数据库引擎（2000s-2010s）

Stonebraker的洞察（2005）：在论文《“One Size Fits All”: An Idea Whose Time Has Come and Gone》中，他宣告：

传统数据库试图满足所有需求（OLTP、分析、流处理），结果是什么都做不好。未来属于专用引擎。

C-Store / Vertica：列存储分析数据库

问题：OLTP数据库按行存储，分析查询需要扫描大量行但只用少数列，浪费巨大。

例子：

-- 传统行存（浪费）
Row 1: [id=1, name='Alice', age=30, salary=50000, dept='IT', ...]
Row 2: [id=2, name='Bob', age=35, salary=60000, dept='HR', ...]
...
-- 查询：SELECT AVG(salary) FROM employees WHERE dept='IT'
-- 需要读取所有列，虽然只用salary和dept

-- 列存（高效）
Column salary: [50000, 60000, ...]
Column dept: ['IT', 'HR', ...]
-- 只读取需要的列，压缩效率高（相同列数据相似）

C-Store的创新：

列式存储：每列独立存储、压缩
投影优化：预计算常用列组合
混合存储：热数据按行（快速写入），冷数据按列（高效查询）

商业化：

2005：创立Vertica公司
2011：被HP以3.4亿美元收购
影响：亚马逊Redshift、Google BigQuery等云数仓都采用列存

H-Store / VoltDB：内存OLTP

问题：传统数据库为磁盘优化（缓冲池、B树索引），但现代服务器内存已达TB级，为何不全放内存？

H-Store的激进设计：

全内存：无磁盘I/O
无锁：单线程执行事务（避免锁开销）
分区：数据按分区键分布到多核心
存储过程：预编译事务代码，极致性能

性能：传统数据库（MySQL）：~1000 TPS VoltDB：~100,000 TPS （100倍提升！）

商业化：

2009：创立VoltDB公司
应用：金融交易、电信计费、广告竞价（低延迟场景）

SciDB：科学数据管理

问题：科学数据（天文、基因组、气候）是多维数组，关系模型不合适。

传统做法（笨拙）：

-- 存储3D气象数据：温度[时间][经度][纬度]
CREATE TABLE climate (
    time int,
    lon float,
    lat float,
    temp float
);
-- 查询某时间片→需要复杂JOIN和聚合

SciDB（优雅）：

-- 直接定义数组
CREATE ARRAY climate<temp:float>[time=0:*, lon=0:360, lat=0:180]

-- 切片查询
SELECT * FROM climate WHERE time=100

-- 数组运算
SELECT AVG(temp) FROM climate GROUP BY lon, lat

特点：

原生多维数组
分布式并行计算
支持科学计算算子（FFT、矩阵运算）

影响： NASA、NIH等机构使用，启发了TileDB、Rasdaman等系统。

StreamBase / Aurora：流数据处理

问题：传统数据库假设数据”静态存储”，但物联网、金融交易数据是”流”。

流数据库的范式转换：

传统：查询固定，数据变化 → SELECT * FROM logs WHERE timestamp > ?
流处理：数据流动，查询固定 → “每分钟统计错误数”

Aurora的连续查询：

-- 注册持续查询
CREATE CONTINUOUS QUERY error_monitor AS
SELECT COUNT(*)
FROM error_logs[RANGE 1 MINUTE]
GROUP BY server_id;

-- 数据流入时自动更新结果

商业化：

2003：创立StreamBase
2013：被TIBCO收购
影响：Apache Flink、Kafka Streams继承了思想

4. Stonebraker的企业家精神：从学术到产业

9家数据库公司的创业传奇：

年份	公司	产品	结果
1980	RTI	Ingres	1994被CA收购
1994	Illustra	对象关系数据库	1996被Informix收购
2001	StreamBase	流处理	2013被TIBCO收购
2003	Vertica	列存分析	2011被HP收购（3.4亿）
2005	VoltDB	内存OLTP	现存，开源+商业
2008	Paradigm4	SciDB	继续运营
2012	Tamr	数据整合	被Databricks收购
2016	Goby	基因组数据	早期阶段

每个公司都源于学术项目，都解决特定领域问题。

Stonebraker的创业哲学：

学术严谨：先写论文验证思想
原型系统：在大学开发开源原型
商业验证：找到刚需场景
产业化：组建团队，融资，市场拓展
退出或持续：被收购或独立发展

争议与批评：有人批评他”学术资源商业化”，但他反驳：

“技术不产业化就是浪费。我的论文和代码都开源，任何人都能用。创建公司只是确保技术真正服务社会。”

🌍 对世界的深远影响

对数据库技术

关系数据库的实用化： Ingres证明关系模型不是”玩具”，直接促成了：

Oracle的商业成功（Larry Ellison承认从Ingres论文学习）
IBM DB2的推出（追赶Ingres的压力）
Microsoft SQL Server的诞生

PostgreSQL的生态：今天PostgreSQL是：

云数据库的基础：AWS Aurora、Google AlloyDB都基于Postgres
创业公司首选：Stripe、Instagram、Reddit都用Postgres
扩展生态：PostGIS（地理）、TimescaleDB（时序）、Citus（分布式）

专用引擎的繁荣： Stonebraker的”一个尺寸不适合”理念引发了数据库碎片化（但这是好事！）：

列存：Vertica、Redshift、ClickHouse、Apache Druid
时序：InfluxDB、TimescaleDB、Prometheus
图数据库：Neo4j、TigerGraph
流处理：Apache Flink、Kafka Streams
搜索：Elasticsearch、Solr

对数据科学

SciDB的理念影响了：

Xarray（Python）：多维数组库
Dask：分布式数组计算
TensorFlow/PyTorch：深度学习框架的张量计算

对云计算

Vertica启发了云数仓：

Amazon Redshift（2012）：采用列存
Google BigQuery（2010）：Dremel列存引擎
Snowflake（2014）：分离存储与计算

VoltDB启发了分布式数据库：

Google Spanner：全球分布式一致性
CockroachDB：Postgres协议的分布式版本

🏆 获奖理由（通俗版）

ACM官方：“在现代数据库系统的概念与实践方面做出了根本性贡献，尤其是Ingres、Postgres、C-Store等系统。”

更通俗的理解：

如果把数据库比作工具，传统思维是造一把”瑞士军刀”（啥都能干，啥都不精）。Stonebraker说：

“别妄想一把刀切所有东西。切肉用切肉刀，削水果用水果刀，修螺丝用螺丝刀。”

他花40年证明：

OLTP用行存（快速读写单条记录）
分析用列存（扫描大量数据）
流处理用特殊引擎（持续查询）
科学数据用数组（多维计算）

今天数据库的繁荣（从MySQL到Snowflake到ClickHouse），都源于他的多元化理念。

👤 个人生平与传奇

早年与学术生涯

背景：

1943年10月11日：出生于马萨诸セッツ州纽伯里波特
1965年：普林斯顿大学电气工程学士
1971年：密歇根大学计算机科学博士

博士论文：关于操作系统的资源管理，但很快转向数据库（受Codd论文启发）。

加州大学伯克利分校（1971-1999）：

Ingres项目（1973-1985）：与Eugene Wong教授共同领导
Postgres项目（1986-1994）：独立领导
培养学生：数十位博士，多人成为数据库领域教授或创业者

MIT（1999-至今）：

CSAIL（计算机科学与人工智能实验室）兼职教授
继续研究与创业

性格与风格

争议性人物： Stonebraker以”直言不讳”著称，经常公开批评竞争对手：

批评Oracle”技术落后，靠营销赚钱”
批评Hadoop”架构笨拙，性能差”
批评NoSQL”放弃一致性是倒退”

学术界评价：

支持者：“他敢于挑战正统，推动技术进步。”
批评者：“他太商业化，论文质量下降。”

个人哲学：

“我不相信’平衡’。如果你不是极端主义者，就不会创造真正新的东西。”

工作狂： 70岁仍在创业，学生回忆他经常凌晨2点发邮件讨论技术。

荣誉

图灵奖（2014）
ACM软件系统奖（1988，Ingres；1992，Postgres）
SIGMOD Edgar F. Codd创新奖（1992）
IEEE John von Neumann奖章（2005）
美国国家工程院院士（1997）

💭 为什么他值得纪念？

1. 他证明了学术与产业不矛盾

学术严谨 + 商业落地：每个产品都源于顶级论文（SIGMOD、VLDB发表），但不止于论文：

Ingres → 50+篇论文 + 商业数据库
Postgres → 40+篇论文 + PostgreSQL开源生态
C-Store → VLDB 2005最佳论文 + Vertica公司

启示：技术人不必在”象牙塔”与”商业化”间二选一。

2. 他改变了数据库的范式

之前（1970-1990s）：数据库 = 关系模型 = SQL = 通用解决方案

之后（2000s-）：数据库 = 多元化 = 不同负载用不同引擎

今天的证据：一个典型互联网公司的数据栈：

OLTP：MySQL / PostgreSQL
缓存：Redis / Memcached
分析：Snowflake / BigQuery
搜索：Elasticsearch
时序：InfluxDB
流处理：Kafka + Flink
图：Neo4j

全是专用引擎！Stonebraker的预言成真。

3. 他影响了几代工程师

PostgreSQL社区：全球数千开发者在他奠定的架构上持续创新。

创业生态：许多数据库创业公司（Snowflake、Databricks、Confluent）的创始人都受其影响。

学术传承：他的学生和博士后成为MIT、UC Berkeley、卡内基梅隆等名校的教授。

4. 他永不停止创新

70岁仍在创业（Tamr、Goby），关注：

数据整合：如何整合企业的碎片化数据？
基因组数据：如何管理人类基因组的PB级数据？

他的信念：

“数据库领域永远有新问题。只要人类产生数据，就需要更好的管理工具。”

🔍 技术深度：列存储的原理

为什么列存更快？

行存（传统）：

Row 1: [id=1|name=Alice|age=30|salary=50000]  <- 一行连续存储
Row 2: [id=2|name=Bob  |age=35|salary=60000]
Row 3: [id=3|name=Carol|age=28|salary=55000]

列存（C-Store）：

Column id:     [1, 2, 3]                      <- 每列独立存储
Column name:   [Alice, Bob, Carol]
Column age:    [30, 35, 28]
Column salary: [50000, 60000, 55000]

优势1：只读需要的列

SELECT AVG(salary) FROM employees WHERE age > 25

行存：读取全部4列，浪费75%的I/O
列存：只读age和salary两列

优势2：更好的压缩 列中数据相似度高（例如性别列只有”M”/“F”），压缩率可达10:1甚至更高。

优势3：向量化执行 现代CPU有SIMD指令，可以一次处理多个数据：

// 传统代码：逐行处理
for (int i = 0; i < N; i++) {
    if (age[i] > 25) sum += salary[i];
}

// 向量化：一次处理4个
for (int i = 0; i < N; i += 4) {
    __m128 ages = _mm_load_ps(&age[i]);       // 加载4个age
    __m128 mask = _mm_cmpgt_ps(ages, 25);     // 比较
    __m128 sals = _mm_load_ps(&salary[i]);    // 加载4个salary
    sum += _mm_sum_ps(_mm_and_ps(mask, sals));// 条件求和
}

权衡：写入慢 列存的写入需要更新多个列文件，比行存慢。因此：

行存适合OLTP（频繁小事务）
列存适合OLAP（批量分析）

Vertica的混合架构

WOS（Write-Optimized Store）：

新数据先写入行存（内存中）
快速写入，支持实时查询

ROS（Read-Optimized Store）：

定期将WOS数据批量转换为列存（磁盘上）
高压缩、高查询性能

查询时：合并WOS和ROS的结果，用户无感知。

这种设计被广泛采用：ClickHouse、StarRocks、Doris等都有类似机制。

🧪 实践意义：选择合适的数据库

Stonebraker的决策树

步骤1：确定负载类型

OLTP（在线事务）：订单、用户管理 → 行存关系数据库（PostgreSQL、MySQL）
OLAP（在线分析）：报表、BI → 列存数仓（Snowflake、ClickHouse）
流处理：实时监控、IoT → 流引擎（Flink、Kafka Streams）
搜索：全文检索 → 搜索引擎（Elasticsearch）
图关系：社交网络、知识图谱 → 图数据库（Neo4j）

步骤2：评估数据量

< 1TB：单机数据库足够
1TB - 10TB：考虑分布式（Citus、TiDB）
> 10TB：云数仓（BigQuery、Redshift）

步骤3：考虑一致性需求

强一致性：金融、库存 → ACID数据库（PostgreSQL）
最终一致性：社交媒体、日志 → NoSQL（Cassandra）

步骤4：成本与运维

自建：有专业DBA团队
云托管：快速启动，按需付费

现实案例

Uber的数据架构：

用户/订单OLTP：PostgreSQL（后迁移到Schemaless，自研）
实时流处理：Kafka + Flink
数据仓库：Hadoop（后迁移到Hive/Presto）
搜索：Elasticsearch
缓存：Redis
监控时序：M3DB（自研）

正是Stonebraker”专用引擎”理念的体现！

📚 延伸阅读

经典论文

Stonebraker et al. (1976): “The Design and Implementation of INGRES”
- 关系数据库工程实现的里程碑
Stonebraker & Rowe (1986): “The Design of POSTGRES”
- 对象关系数据库的开创性工作
Stonebraker et al. (2005): “C-Store: A Column-oriented DBMS”
- VLDB最佳论文，列存数据库的理论基础
Stonebraker (2007): “The End of an Architectural Era (It’s Time for a Complete Rewrite)”
- 宣告传统数据库架构已过时
Stonebraker & Cetintemel (2005): “One Size Fits All: An Idea Whose Time Has Come and Gone”
- 专用引擎理念的宣言

书籍

Stonebraker & Hellerstein (Eds.): “Readings in Database Systems” (The Red Book)
- 数据库领域的经典论文集，Stonebraker主编
- 免费在线：http://www.redbook.io/

系统

PostgreSQL：https://www.postgresql.org/
- 继承Postgres遗产，生产环境就绪
C-Store原型（学术）：http://db.csail.mit.edu/projects/cstore/
- 研究列存原理

访谈与演讲

2015年图灵奖演讲（YouTube）
- “One Size Does Not Fit All”
- 回顾40年数据库演进
ACM访谈系列
- Stonebraker讲述创业故事与技术决策

🌟 精神遗产

”做系统，不只是写论文”

Stonebraker的座右铭：

“一个没有实现的想法只是一个幻想。”

他坚持每个研究项目都要：

理论论文：严格证明
原型系统：代码开源
实验评估：真实数据验证
产业化：创建公司或被业界采用

启示：对计算机科学研究者，“端到端”的系统思维比算法优化更重要。

“不要妥协于’平庸的平衡’”

在数据库领域，很多人试图设计”通用”系统（啥都能干）。Stonebraker反其道而行：

“如果你的系统在所有场景都’还行’，那它在任何场景都不出色。宁可在一个场景做到极致。”

现实验证：今天没有一个”统治一切”的数据库：

Oracle市场份额从50%降到20%
专用数据库（Snowflake、MongoDB、Elasticsearch）市值数百亿

”技术应该服务现实需求”

Stonebraker的每个项目都源于真实问题：

Ingres：解决商业数据管理
Postgres：解决复杂数据类型
C-Store：解决分析查询慢
SciDB：解决科学家的数据管理难题

他从不为了”学术新颖”而研究，而是为了”世界需要”。

总结语：Michael Stonebraker是数据库领域的”连续革命者”。从1970年代的Ingres到2010年代的VoltDB，他跨越40年持续创新，改变了我们存储、查询、分析数据的方式。他用实践证明：没有完美的数据库，只有最适合场景的数据库。他不仅是技术天才，更是将学术思想转化为产业价值的大师，创建了9家公司，影响了数十亿美元的市场。

从Oracle的SQL优化器到PostgreSQL的类型扩展，从Snowflake的列存到Kafka的流处理，现代数据基础设施的每一层都有他的印记。他教会我们：伟大的系统不是妥协的产物，而是对特定问题的极致追求。在AI和大数据时代，他的”专用引擎”哲学比以往任何时候都更加重要——因为世界不需要一个数据库统治一切，而需要生态繁荣，让每个问题都有最优解。

最后更新: 2024年12月 本文为图灵奖系列文章,旨在以通俗方式介绍计算机科学先驱的贡献

本文回答什么问题

图灵奖第四十九届（2014）| Michael Stonebraker：数据库的多形态革新者，从Ingres到Postgres，再到”一个引擎不能统治一切”

🏆 获奖简介

🚀 重大贡献

1. Ingres：关系数据库的工程实现先驱（1973-1985）

查询优化器的诞生

QUEL语言的创新

商业化的波折与成功

2. Postgres：对象关系数据库的开创（1986-1994）

可扩展类型系统

复杂查询：嵌套与继承

规则系统与触发器

时间旅行（Time Travel）

3. “一个尺寸不适合所有”：专用数据库引擎（2000s-2010s）

C-Store / Vertica：列存储分析数据库

H-Store / VoltDB：内存OLTP

SciDB：科学数据管理

StreamBase / Aurora：流数据处理

4. Stonebraker的企业家精神：从学术到产业

🌍 对世界的深远影响

对数据库技术

对数据科学

对云计算

🏆 获奖理由（通俗版）

👤 个人生平与传奇

早年与学术生涯

性格与风格

荣誉

💭 为什么他值得纪念？

1. 他证明了学术与产业不矛盾

2. 他改变了数据库的范式

3. 他影响了几代工程师

4. 他永不停止创新

🔍 技术深度：列存储的原理

为什么列存更快？

Vertica的混合架构

🧪 实践意义：选择合适的数据库

Stonebraker的决策树

现实案例

📚 延伸阅读

经典论文

书籍

系统

访谈与演讲

🌟 精神遗产

”做系统，不只是写论文”

“不要妥协于’平庸的平衡’”

”技术应该服务现实需求”

评论与补充

继续阅读

Alfred V. Aho & Jeffrey D. Ullman：他们写下的"龙书"训练了几代程序员，让编译器从黑魔法变成系统科学

Peter Naur：从ALGOL 60到"编程即理论建构"，他定义了程序设计的认识论

Jim Gray