我到底应该怎么选？

2. Postgres 的设计所带来的后果

Postgres 的设计导致 Uber 的数据效率低下，还让我们遇到了很多麻烦。

写入放大

Postgres 的第一个问题是写入放大。通常，写入放大是指将数据写入 SSD 磁盘时遇到的问题：小的逻辑更新（例如，写入几个字节）在转换到物理层时会放大，成本会变高。在之前的示例中，如果我们对 al-Khwārizmī的出生年份进行小的逻辑更新，必须进行至少四个物理更新：

1. 将新的行元组写入表空间；
2. 更新主键索引；
3. 更新 (first,last) 索引；
4. 更新 birth_year 索引。

实际上，这四个更新也只反映了对主表空间的写操作。除此之外，这些写操作也需要反映在 WAL 中，因此磁盘上的写操作总数会变得更多。

这里值得注意的是更新 2 和更新 3。在更新 al-Khwārizmī的出生年份时，实际上并没有修改它的主键，也没有修改名字和姓氏。但尽管如此，仍然必须在数据库中创建新的行元组，以便更新这些索引。对于具有大量二级索引的表，这些多余的步骤可能会导致效率低下。例如，如果我们在一张表中定义了十二个索引，即使只更新了单个索引对应的字段，也必须将该更新传播给所有 12 个索引，以便反映新行的 ctid。

复制

这个写入放大问题自然也转化到了复制层，因为复制发生在磁盘级别。数据库并不会复制小的逻辑记录，例如“将 ctid D 的出生年份更改为 770”，而是将之前的 4 个 WAL 条目传播到网络上。因此，写入放大问题也转化为复制放大问题，Postgres 复制数据流很快变得非常冗长，可能占用大量带宽。

如果 Postgres 复制仅发生在单个数据中心内，那么复制带宽可能就不是问题。现代网络设备和交换机可以处理大量带宽，很多托管服务提供商还提供了免费或便宜的数据中心内部带宽。但是，如果要在数据中心之间进行复制，问题就会迅速升级。例如，Uber 最初使用了西海岸托管中心里的物理服务器。为了进行灾备，我们在东海岸托管中心添加了服务器。于是，我们在西部数据中心里有一个主 Postgres 实例（加上副本），在东部也有一个副本集。

级联复制将数据中心间的带宽限制为只能满足主数据库和单个副本之间的带宽需求，虽然第二个数据中心里还有很多副本。因为 Postgres 复制协议的冗繁，使用了大量索引的数据库会有很大的数据量。购买跨地域大带宽成本非常高昂，即使钱不成问题，也不可能获得与本地带宽类似的效果。这个带宽问题也给 WAL 归档带来了麻烦。除了将所有 WAL 更新从西海岸发送到东海岸之外，我们还要将所有 WAL 都存档到文件存储服务中，这是为了确保在发生灾难时我们可以还原数据。在早期的流量高峰期间，我们写入存储服务的带宽不够快，无法跟上 WAL 的写入速度。

数据损坏

在例行升级主数据库以便增加数据库容量的过程中，我们遭遇了 Postgres 9.2 个一个 bug。因为副本在切换时间方面出现了错误，导致其中一些副本错误地应用了一小部分 WAL 记录。由于这个问题，一些本应由版本控制机制标记为无效的记录实际上并未被标记为无效。

下面的查询说明了这个错误将如何影响我们的用户表：

（编辑：广元站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!