IT Cutting Edge ─世界を変えるテクノロジの最前線

第7回 UberエンジニアがブログでPostgreSQLにダメ出し,PostgreSQLコミッター石井達夫氏に反論を聞く

この記事を読むのに必要な時間:およそ 3 分

Uberの言い分は妥当なのか?

このエントリでは冒頭で,⁠PostgreSQLのアーキテクチャ」と題しつつ,PostgreSQLの技術的制限として以下の項目を挙げています。

  • 非効率な書き込みアーキテクチャ
  • 非効率なデータレプリケーション
  • テーブルコラプションの問題
  • レプリカにおける貧弱なMVCCサポート
  • 新しいリリースへのアップグレードが面倒

冒頭からすでに全PostgreSQL開発者をわざと怒らせるように煽っている雰囲気を強く感じるのですが,つづけて「今回の記事はPostgreSQL 9.2での経験をベースに書いているが,以降のバージョンでもPostgreSQLのアーキテクチャはそれほど変わっていない。そしてPostgreSQL 9.2のアーキテクチャは基本的に(10年以上前にリリースされた)8.3から大きく変わっていない」と書かれています。さすがに10年前のアーキテクチャと変わっていない,と言われて心穏やかなPostgreSQL開発者はいないのではないでしょうか。

以降,PostgreSQLのアーキテクチャ,とくに書き込みの非効率性についての批判と,それと比較してMySQL+InnoDBがいかに効率的でUberのニーズにあっているかが延々と続くのですが,PostgreSQL開発者にとっては明らかに看過できないポイントが散見されます。そのいくつかについて,石井氏からいただいたコメントを紹介します。

石井達夫氏

石井達夫氏

[その1]Write Amplification ―実際に書き込んだデータ量よりも,ディスクやフラッシュに書き込まれるデータ量が増える問題

このブログエントリでは,PostgreSQLのインデックス更新の効率が悪いことが書かれています。その理由について「行の一部の列を更新した場合でも,すべての列に関するインデックスを更新しなければならないから」とあります。

たしかに,エントリ冒頭の例(人物データベースで,ファーストネームとラストネームが同一だが,生年が違う場合のレコード更新)に挙げられているテーブルを更新する限りはそうなってしまいますが,これはそのテーブルにおいてはすべての列にインデックスが貼られているからなのです。エントリではまったく触れられていませんが,PostgreSQLでは,インデックスが貼られていない列を更新する際に,該当列以外のインデックスを更新しなくて済むHOT ⁠Heap Only Tuple)という機能がPostgreSQL 8.3から実装されており,すべての列にインデックスが貼られているわけではない現実的なケースでは,更新オーバヘッドを大幅に少なくすることができます。

このブログエントリの著者がHOTを知らなかったのか,それともUberではテーブルのすべての列にインデックスを貼る必要があるのかはわかりませんが,エントリ中でHOTにまったく触れなかったのは,正直片手落ちという印象があります。

なお,エントリで説明されているMySQLのインデックスの実装では,たしかにインデックス付きの列の更新は効率が良くなりますが,逆に検索時には,主キー付き以外の列でPostgreSQLの実装よりもオーバヘッドが増えます。主キー付き以外の列でも,必ず主キーを経由してアクセスしなければならないからです。

ちなみに,現在PostgreSQL開発者の間ではインデックスが付いている列を更新しても,それ以外の列のインデックスを更新しなくて済む改良が議論されています。これが実現すれば,⁠MySQLと違って)主キー経由のアクセスが必要ない検索高速性と,キー付き列でも高速更新ができるという,いいとこ取りのシステムができると期待されています。

[その2]レプリカにおける貧弱なMVCCサポート

このブログエントリで問題とされているケースの全部ではありませんが,多くのケースではPostgreSQL 9.1以降で実装された「hot_standby_feedback」という機能で解決できます。記事中でなぜ hot_standby_feedbackに触れていないのかは謎ですね。

[その3]アップグレードが面倒

"Run a command called pg_upgrade on the master, which updates the master data in place. This can easily take many hours for a large database, and no traffic can be served from the master while this process takes place."

バージョンアップの際にpg_upgradeを使うと何時間もかかるということのようですが,pg_upgradeには--linkというオプションがあり,これを使うとデータのコピーが回避できるので,pg_upgradeの実行は短時間(数十秒から1分程度)で完了します。なぜこのオプションを使わなかったのかは,これまた謎です。

石井達夫氏による考察

このブログエントリ全体を読んでどういった感想をお持ちになったのか,あらためて石井氏に伺ってみました。

ブログエントリを通して感じた第一印象は「UberではPostgreSQLの使いこなしの技術が不足していたのではないか」ということです。これはHOTやhot_standby_feedbackに触れられていないことからも推測できます。
PostgreSQLに対する勉強不足でうまくいかなかったので,あまり深く考えずにまたMySQLに戻してみたら,たまたま彼らのユースケース(NoSQLっぽい使い方)にはMySQLが合っていた,ということなのではないかと想像しています。
それをそのとおりに素直に書けばよいものを,PostgreSQL vs. MySQLの構図にしてブログにしてみた,というのがよく理解できないところです。

石井氏のコメントからもわかるように,このブログエントリの著者はHOTやpg_upgrade --linkなど,PostgreSQL開発者なら知っていて当然の内容をあえて避けているように思えます。冒頭でわざわざ「PostgreSQLは8.3から基本的なアーキテクチャが変わっていない」と明言しているところからも,8.3でHOTが実装されたことを知っていながら本文ではわざとHOTに触れていないようです。⁠ブログエントリ内で)例として挙げられているテーブルでは,全部の列にインデックスを貼ってあり,あえてHOTが効かないようにしているところに意図的なものを感じます」⁠石井氏)

そのほかにもこのエントリにはPostgreSQLへの誤解を招きかねない表現が数多くあり,さすがに我慢できなくなったのか,何人かのPostgreSQL開発者がこれについての反論記事を書いています。彼らも石井氏と同様,HOTについての記述がないことを強く批判しています。

星の数ほどあるスタートアップの中でも,Uberほど劇的なスピードで成長した企業はほとんどありません。そしてあまりの成長の速さに,既存の環境が追いつかなくなりリプレースを余儀なくされるという事情も十分に理解できます。また,プロジェクトを率いるリーダーやCTOの好みで,採用される技術が左右されることも多分にあるでしょう。今回のように,スキーマレスなNoSQLでスケーラビリティを担保し,膨大なトラフィックをリアルタイムにさばきたい,というニーズならたしかにPostgreSQLよりもMySQLが向いているのかもしれません。

しかし,そうした事情があるにせよ,PostgreSQLに対するミスリーディングを"意図的"に誘発していると受け取られても仕方ない筆致の技術エントリ,もっとはっきりいえば「アンフェア」なスタイルの記事をUberが公式サイトで世界に向けてアップしたことには,やはり強い失望を覚えます。最先端テクノロジをもって急成長したUberだからこそ,テクノロジに対してだけは誠実であってほしいと,米国出張のたびにUberにお世話になっている筆者はひそかに願っています。

著者プロフィール

五味明子(ごみあきこ)

IT系の出版社で編集者としてキャリアを積んだ後,2011年からフリーランスライターに。フィールドワークはオープンソースやクラウドコンピューティング,データアナリティクスなどエンタープライズITが中心。海外カンファレンス取材多め。Blog 「G3 Enterprise」やTwitter(@g3akk),Facebookで日々IT情報を発信中。

北海道札幌市出身/東京都立大学経済学部卒。

バックナンバー

IT Cutting Edge ─世界を変えるテクノロジの最前線

バックナンバー一覧