为什么Uber从PostgreSQL换成了MySQL

说明：本文翻译自Why Uber Engineering Switched from Postgres to MySQL

引言

Uber的早期架构包括一个用Python编写的单一后端应用程序，它使用Postgres进行数据持久化。从那时起，Uber的架构发生了重大变化，转向了微服务和新数据平台的模式。具体来说，在以前使用Postgres的许多情况下，我们现在使用Schemaless，这是一种构建在MySQL之上的新型数据库分片层。在本文中，我们将探讨使用Postgres时发现的一些缺点，并解释为什么要在MySQL之上构建Schemaless和其他后端服务。

Postgres的架构

我们遇到了许多Postgres的限制:

• 低效的写入体系结构
• 数据复制效率低下
• 表损坏的问题
• 糟糕的副本MVCC支持
• 难以升级到新版本

我们将通过分析Postgres在磁盘上表示表和索引数据的方式来了解所有这些限制，特别是将其与MySQL用InnoDB存储引擎表示相同数据的方式进行比较。请注意，我们在这里提出的分析主要是基于我们使用有点旧的Postgres 9.2发行版系列的经验。据我们所知，我们在本文中讨论的内部架构在较新的Postgres发行版中并没有发生重大变化，而且9.2中磁盘上表示的基本设计至少从Postgres 8.3发行版(现在已经有将近10年的历史了)开始就没有发生重大变化。

磁盘格式

关系数据库必须执行以下几个关键任务:

• 提供插入/更新/删除功能
• 提供进行模式更改的功能
• 实现多版本并发控制(MVCC)机制，以便不同的连接拥有它们所处理的数据的事务性视图

考虑所有这些特性如何协同工作是设计数据库如何表示磁盘上的数据的重要部分。
Postgres的核心设计方面之一是不可变的行数据。这些不可变的行在Postgres中被称为“元组”。这些元组由Postgres所称的ctid唯一标识。ctid在概念上表示元组的磁盘位置(即物理磁盘偏移量)。多个ctid可以潜在地描述单行(例如，当出于MVCC目的存在多个版本的行，或者当autovacuum进程尚未回收行的旧版本时)。有组织的元组的集合形成一个表。表本身具有索引，这些索引被组织为数据结构(通常是b树)，将索引字段映射到ctid有效负载。
通常，这些ctid对用户是透明的，但是了解它们的工作方式有助于理解Postgres表的磁盘结构。要查看一行的当前ctid，可以在WHERE子句中将" ctid "添加到列列表中:

uber@[local] uber=> SELECT ctid, * FROM my_table LIMIT 1;

-[ RECORD 1 ]--------+------------------------------

ctid                 | (0,1)

为了解释布局的细节，让我们考虑一个简单的用户表示例。对于每个用户，我们都有一个自动递增的用户ID主键、用户的姓和名，以及用户的出生年份。我们还在用户的全名(姓和名)上定义了一个复合二级索引，并在用户的出生年份上定义了另一个二级索引。创建这样一个表的DDL可能是这样的:

CREATE TABLE users (

    id SERIAL,

    first TEXT,

    last TEXT,

    birth_year INTEGER,

    PRIMARY KEY (id)

);
 CREATE INDEX ix_users_first_last ON users (first, last)