デジタルディスラプションを象徴する企業として，いまこの瞬間も破竹の勢いで成長を続け，交通サービスの世界を大胆に塗り替えているUber。未上場ながらすでに企業価値は6兆円を超えているとも言われており，世界最大のユニコーン企業として，その動向はつねに注目されつづけています。

クラウドやビッグデータ分析，オープンソースなど，最先端のITをフル活用し，ごく短期間で劇的にビジネスを拡大させたUberに対しては，やはり技術者からの強い関心があつまります。現在，1200名を超えると言われるUberのエンジニアたちは何をどんな環境で使い，どう動かしているのか ―Uberのエンジニアリングチームが公開している技術ブログ「Uber Engineering Blog」は，Uberのエンジニアたちが現場でどんな課題に向き合い，どう解決しているのかを知るにはうってつけの情報ソースです。

7月27日，そのUber Engineering Blogにある"問題作"とも言えるエントリが投稿されました。「⁠Why Uber Engineering Switched From Postgres To MySQL（なぜUberエンジニアリングはPostgreSQLからMySQLに移行したのか）」というタイトルにある通り，UberがデータベースをPostgreSQLからMySQLに移行した理由について詳細に書かれているのですが，全体的に「PostgreSQLではアーキテクチャに制限がありすぎてUberのシステムを支えきれない，MySQL＋InnoDBに変えたら全部解決した」というトーンで貫かれています。

これに対し世界中の開発者，とくに（当然ながら）PostgreSQL開発者から強い疑問と反論の声が聞こえてくるようになりました。同時に少なくないPostgreSQL開発者が「PostgreSQLはそんなに大規模システムには向かないのか…」「⁠あのUberがPostgreSQLはダメだと言っている」と不安な思いを抱いたのではないでしょうか。

そこで本稿ではPostgreSQLコミッタのひとりであり， SRA OSS, Inc. 日本支社 取締役支社長 石井達夫氏にいただいたコメントを紹介しながら，件のブログエントリの問題点を探ってみたいと思います。

Uberの決断 ―PostgreSQLからMySQL＋InnoDBへ

Uberは2014年から「Project Mezzanine」という名のプロジェクトの下で，モノリシックなPostgreSQLからMySQL＋InnoDBへの移行を実施しています。この移行の最大の理由は「リアルタイムのシステムを支えるにはバックエンドとは別のスキーマレスなデータベースが必要」というものでした。2014年といえばUberの利用者が急激に増えていた時期でもあります。ドライバーがいつ，どこで，誰をピックアップし，どこまで乗せているのか，それらのトリップデータは頻繁な更新が要求され，しかもそのトラフィックは日に日に増えていきます。まさしくビジネスの拡大とともにデータが増大していく，という状況を地で行っていた真っ最中だったのでしょう。

当時，UberではシングルインスタンスのPostgreSQLがこれらのリアルタイムデータ処理に加え，バックエンド（ドライバーへの支払い，利用者への請求，詐欺対策，ユーザデータ分析など）のデータストアも兼ねていましたが，リアルタイムに処理すべきトリップデータがデータベース内に占める割合がその他のデータをはるかに上回るようになり，スケーラビリティやパフォーマンスで大きな支障が出るようになりました。

ここでUberはスケーラビリティ（シャーディング）をとくに重視した結果，MySQL＋InnoDBをトリップデータを扱うためのデータストアとして選択し，約6週間の構築期間を経て2014年10月末に本番環境として稼働を開始，現在に至っています。Project MezzanineについてはすでにUber Engineering Blogで記事が公開されているので，詳細はそちらをご参照ください。

Project Mezzanineの内容だけなら「膨大なトラフィック増加にともなうアーキテクチャの見直し」であり，「⁠シャーディング重視のNoSQLライクな実装が可能なMySQLのほうがピュアなRDBMSのPostgreSQLよりも，Uberの拡大路線にはあっていたのかも」であって，とくにとくにPostgreSQL関係者が目くじらを立てるようなこともありません。では7/27のエントリは何がPostgreSQL関係者の怒りを買ったのでしょうか。