UberのPostgresからMySQLへの移行

最近のブログ記事により、Uberは、なぜPostgreSQLからMySQLに置き換えをしたのか、詳細を明らかにした。

Userが抱える主要な課題は、Postgresにおけるライトアンプリフィケーションの問題に由来している。 ライトアンプリフィケーションは、複数のインデックスが貼られているテーブル内の1レコードを更新することにより、結果的に全てのインデックスが更新され、ディスクへの書き込みが大量発生する現象である。SSDを使用している場合には厄介な問題となる。 HOT(Heap-Only-Tuples)機能は、この問題を軽減でき、いくつかの使用例においては解決策となる。 いずれにせよ、ライトアンプリフィケーションの問題により、レプリケーションの際、1回の更新に対して複数回の更新がネットワーク上に発信されることになる。 これは障害復旧シナリオにおいては大きな問題である。 データセンタはお互いに離れた地点に設置すべきだが、同時に十分な帯域を確保し、常に利用可能でなければならない。

さらに、定期アップグレードの最中、Postgres9.2のバグにより、いくつかのテーブルが破壊された。 非活性にしたはずの項目に対するマークに失敗することが原因である。 影響を受ける項目数の計算が行えなくなり、さらに物理レイヤにてレプリケーションが発生することにより、データベースインデックスが破壊される恐れがある。

また、Postgresは真のレプリカMVCCをサポートしていない。 レプリカは、マスタと同一のWAL(Write Ahead Log)を適用せねばならない。 Postgresの設計では、トランザクションによりオープンされた行による影響を受ける場合、WALによるデータベース更新がブロックされる。 これは、ロングトランザクション(long running transaction)に対しては特に深刻である。 ロングトランザクションは、WALスレッドをブロックしてしまうため、Postgresによって中断される。 これは、この現象を知らないアプリケーション開発者にとって気づきにくい問題となる。 特にトランザクション境界を明確にしないORMを使用しているときには顕著な問題である。

レプリケーションが物理レベルでの処理であるため、データベースの更新は全ノードで同期している必要がある。そうでなければレプリケーションは機能しない。 これがUberにとって、新規リリースにアップグレードする際の大きな問題となった。 この問題は、Postgres 9.4から利用可能なpglogicalにより解消できる。

Uberの抱える柔軟なレプリケーションの課題に対して、MySQLであればいくつかの優位性がある。 MySQLは、接続ごとにプロセスを生成するのではなく、軽量スレッドを生成する。 さらに低コストのキャッシュ機構が、設計判断をする際に有利に働く。 ディスク表現に関する主たる課題は、InnoDBストレージの使用により、効率良くコンパクトになった。Postgresで発生した複数インデックスのライトアンプリフィケーションの影響も防げる。

Uberのユースケースに対する的確な反論はMarkus Winand氏、Simon Riggs氏、およびRobert Haas氏が行っている。 彼らは、これらの問題がいくつかのユースケースでは解決可能であることを示している。 また、全ての状況においてPostgresよりMySQLが適切ともいえないこと、その逆もまた言えることを示している。