BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Uber系统从Postgres迁移到MySQL

| 作者 Alex Giamas 关注 10 他的粉丝 ,译者 周元昊 关注 0 他的粉丝 发布于 2016年8月26日. 估计阅读时间: 3 分钟 | AICon 关注机器学习、计算机视觉、NLP、自动驾驶等20+AI热点技术和最新落地成功案例。

Uber最近在博客中详细阐述了他们为什么要使用MySQL来替代PostgreSQL。Uber遇到的主要困难源于Postgres的写入放大问题。写入放大是在对涉及索引的单行数据进行更新时,需要更新所有的索引,从而导致大量对磁盘的写操作,在使用固态硬盘时这个问题更加严重。HOT(Heap-Only-Tuples)特性可以缓解这个问题,这在一些用例中也许是一个解决方案。因此,写入放大问题泄漏到了复制过程中,造成为了一些简单的更新而在副本间传播多个更新操作。在灾难恢复的场景中,由于数据中心之间可能相距较远,并且无法获得廉价、便利的带宽,就会导致重大问题。

在Postgres 9.2的一次常规更新中,一个bug导致了一些表的数据损坏。这是由于没有标记一些应该被标记为不活跃的数据所导致的。无法计算这个bug这所影响到的数据总数,而且由于复制是发生在物理层,这也就存在着损坏数据库索引的风险。

Postgres的副本并没有真正支持多版本并发控制(MVCC)。副本必须和主节点使用一致的预写式日志(WAL:Write Ahead Log)。加上如果更新操作涉及其他事务中已打开的行,Postgres会将其阻塞,这在很大程度上会影响长事务(long running transaction)。一旦长事务阻塞了预写式日志线程,就会被Postgres终止,如果应用开发人员没有意识到这点,特别是在使用事务边界不透明的对象关系映射(ORM)时,就会带来问题。

再一次由于复制过程是工作在物理层,数据库更新不得不在所有副本间同时进行,不然复制无法正常工作。这意味着就Uber的规模来说,升级到当时的新版本真的会造成很多问题。这个问题已经自9.4版本之后使用pglogical修复了。

在决定Uber案例的设计方案时,设计者看重MySQL的优势有:拥有灵活的副本、每个连接使用轻量级的线程而不是进程、廉价的缓存。应对磁盘存储上的主要问题,则使用InnoDB存储,使压缩更高效而不会影响大量索引或引起Postgres中的写入放大问题。

Markus WinandSimon RiggsRobert Haas针对Uber用例提出了一些很好的反驳。他们详细阐述了在诸多用例中如何解决上述问题,以及为什么并不是对每个案例都应该抛弃Postgres而使用MySQL,反之亦然。

查看英文原文:Uber Engineering Moving from Postgres to MySQL


感谢百占辉对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT