Uber、創業期に使っていたPostgreSQLからMySQLベースの独自レイヤーへ移行

Uberは創業当初PostgreSQLを主要データベースとして採用していたが、事業拡大とともに複数の技術的課題に直面した。Postgresでは行を更新するたびにすべてのインデックスを更新する必要があり、「1つのインデックスにしかかかっていないフィールドの更新が12個すべてのインデックスに伝播する」といった書き込み増幅が発生した。またPostgresのレプリケーションプロトコルは冗長で、特にデータセンター間レプリケーションで大量のデータ転送を招いた。加えてPostgres 9.2のバグにより本来非アクティブとしてマークされるべきレコードがマークされず重複レコードが返される障害も発生し、ストリーミングレプリカでオープントランザクションがあると更新がブロックされてタイムアウトするリスク、さらに異なるメジャーバージョン間でのレプリケーションができずアップグレードに数時間の停止が必要になるという運用上の制約もあった。

エンジニアリングチームはMySQLの特性がUberの用途により適していると判断し、複数の点を評価した。

• MySQLのInnoDBストレージエンジンではセカンダリインデックスがプライマリキー値へのポインタを保持し、行の更新はその場で行われるため、変更されたインデックスのみを更新すればよい
• レプリケーションもロジカルな行の更新情報のみを含むためバイナリログがPostgresのWALストリームより大幅にコンパクトになる
• InnoDB自身がLRUを実装しコンテキストスイッチが少ない
• MySQLは接続ごとにスレッドを生成する方式のためPostgresのプロセス単位の接続方式より効率的だった

これらの特性を踏まえ、MySQLを基盤とした独自のデータストアレイヤー「Schemaless」を構築して移行を進めた。

移行の結果、現在Uberのデータベースの大部分はMySQLベースのSchemalessレイヤー上に構築されるか、一部の特殊なケースではCassandraなどのNoSQLデータベースに置き換わっている。一部レガシーなPostgreSQLインスタンスも残存している。