TikTok 或许不用卖，也能在美国运营了
|
要基于 (first, last) 索引 执行查询，需要进行两次查找。第一次先搜索表，找到记录的主键。在找到主键之后，搜索主键索引，找到数据行对应的磁盘位置。 所以，在执行二级查找时，InnoDB 相比 Postgres 略有不利，因为 InnoDB 必须搜索两个索引，而 Postgres 只需要搜索一个。但是，由于数据已经规范化，在更新行数据时只需要更新实际发生变化的索引记录。此外，InnoDB 通常会在原地进行行数据更新。为了支持 MVCC，如果旧事务需要引用一行数据，MySQL 会将旧行复制到一个叫作回滚段的特殊区域中。 我们来看看更新 al-Khwārizmī的出生年份会发生什么。如果空间足够，id 为 4 的那一行数据中的出生年份字段会进行原地更新（实际上，这个更新总是发生在原地，因为出生年份是一个占用固定空间量的整数）。出生年份索引也进行原地更新。旧数据行将被复制到回滚段。主键索引不需要更新，(first, last) 索引也不需要更新。即使这张表有大量索引，也只需要更新包含 birth_year 字段的索引。假设我们基于 signup_date、last_login_time 等字段建立了索引，我们不需要更新这些索引，但在 Postgres 中需要更新。
这种设计还让数据清理和压缩变得更加高效。回滚段中的数据可以直接清除，相比之下，Postgres 的 autovacuum 进程必须进行全表扫描来识别哪些行可以清除。 这种设计意味着副本通常会比主数据库落后几秒钟，很容易出现事务被终止的情况。例如，假设开发人员写了一些代码，需要通过电子邮件将收据发送给用户。根据编写方式的不同，代码可能会隐式地让数据库事务处于打开状态，直到电子邮件完成发送为止。尽管在执行不相关的阻塞 IO 时一直打开数据库事务是很糟糕的做法，但大多数工程师并不是数据库专家，他们可能也不知道有这个问题，特别是在使用隐藏了底层细节的 ORM 框架时。 升级 Postgres 由于复制发生在物理层面，所以我们无法在 Postgres 的不同版本之间复制数据。Postgres 9.3 的主数据库不能被复制到 Postgres 9.2 的副本，而 Postgres 9.2 的主数据库也不能被复制到 Postgres 9.3 的副本。 我们按照以下这些步骤从一个 Postgres GA 版本升级到另一个版本：
我们从 Postgres 9.1 开始，并成功完成了升级过程，迁移到了 Postgres 9.2。但是，这个过程花费了数小时，我们无力承担再次执行这种升级过程的费用。到 Postgres 9.3 发布时，Uber 的规模增长极大增加了我们的数据集，因此升级时间就变得更长了。因此，即使 Postgres 9.5 已经发布了，我们的 Postgres 实例仍然是 9.2 版本。 如果你的 Postgres 是 9.4 或更高版本，可以使用 pgologic 之类的东西，它为 Postgres 实现了一个逻辑复制层。你可以用它在不同的 Postgres 版本之间复制数据，这意味着可以从 9.4 升级到 9.5，而不会造成大面积停机。不过，这个功能仍然是有问题的，因为它尚未被集成到 Postgres 主线中。而对于那些使用较旧版本的 Postgres 的人来说，pgologic 并不适用。 3. MySQL 架构上文解释了 Postgres 的一些局限性，接下来，我们将解释为什么 MySQL 会成为 Uber 工程团队存储项目（例如 Schemaless）的新工具。在很多情况下，我们发现 MySQL 更适合我们的使用场景。为了理解这些差异，我们研究了 MySQL 的架构，并将其与 Postgres 进行了对比。我们专门分析了 MySQL 的 InnoDB 存储引擎。 InnoDB 的磁盘表示 与 Postgres 一样，InnoDB 支持 MVCC 和可变数据等高级功能。关于 InnoDB 磁盘表示的详尽细节不在本文的讨论范围之内，我们将把重点放在它与 Postgres 的主要区别上。
最主要的架构差异是：Postgres 直接将索引记录映射到磁盘上的位置，而 InnoDB 使用了二级结构。InnoDB 的二级索引有一个指向主键值的指针，而不是指向磁盘位置的指针（如 Postgres 中的 ctid）。因此，MySQL 会将二级索引将索引键与主键相关联： （编辑：广元站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
