MySQL」というエントリが公開されました。Bloghttps://eng.uber.com/mysql-migration/それに対して、PostgreSQLコミュニティ界隈でもいろいろなブログエントリが公開されました。Databases」が個人的に興味深かったので、同氏の翻訳許可をいただきまして、ここに対訳形式で公開します。(@snaga)などで連絡いただけますと幸いです。MySQL)」という記事を公開しました。私は、この記事をすぐには読んでいませんでした。いうのは、私の中のナード魂が、記事を読むのではなく自宅の改修を行うように私に促してきたからです。lousy?)」というような質問でいっぱいになりました。一般的に言って、PostgreSQLはひどくはありません。それらのメッセージは、そもそも元記事でどれだけ大げさなことが書かれているのだろうか、という疑問を私に植えつけました。この記事は、Uberの記事にどのような理屈・道理を見出すか、というひとつ試みになります。article.私の見解では、Uberの記事は彼らの環境においてPostgreSQLよりMySQLの方がよくフィットしていることに気付いた、ということを基本的には述べています。そのメッセージを伝えるに当たって、この記事はひどいものとなっています。「PostgreSQLは更新処理の多いユースケースではいくつかの制約がある」と書くのではなく、この記事は単に「更新には非効率なアーキテクチャ」と書いています。あなたが更新処理の多いユースケースでないのであれば、Uberの記事で説明されている問題を心配する必要はありません。store.本ポストでは、なぜUberの記事を一般的なデータベース選択のアドバイスとして受け取ってはならないのか、なぜMySQLがUberによって良い選択肢なのか、そして、成功することがなぜ単なるデータストアのスケーリング以上の問題を引き起こすのかを解説します。workload.Uberの記事が解説しているけれども厳密には不完全な最初の問題は、PostgreSQLはテーブル内の行を更新する時に常にすべてのインデックスを更新する必要がある、という部分です。一方で、InnoDBを使うMySQLは更新されたカラムを使っているインデックスだけを更新する必要がある。これがUberにとって大きな問題なのであれば、これらの更新が彼らのワークロードの多くを占めているはずです。ついて言及していないのです。PostgreSQLのソースコードには、HOTは特殊なケース、「インデックスが作成されているカラムを変更しない更新が繰り返される」時に有用である、とあります。この場合に、PostgreSQLは新しいバージョンの行が以前のバージョンの行と同じページに格納できる時には、インデックスに一切触らずに更新できるのです。設定を使うことで調整できます。記事がこれに気付いていると仮定すると、HOTが彼らの問題のソリューションにならない理由は、つまりは彼らが高頻度で実行している更新処理が、インデックスの貼られたカラムを少なくとも一つは対象としているからなのでしょう。反映させるために12個すべてのインデックスへと伝播されなければなりません」。case)になりますが、そうでなければ(※訳注:インデックスが無いカラムの場合には)PostgreSQLのHOTがこの問題を解決します。私は心底、彼らの作成しているインデックスの数をどれだけ減らせるかに興味があります、インデックス再設計の挑戦として。それらのインデックスがあまり使われていないという可能性は十分にあるものの、それでもそれらが使われた時には重要ではあります。sense.彼らは、多くの更新処理を、インデックスの貼られた少なくとも一つ以上のカラムを更新するものを実行しているようですが、それでも「1ダースの」インデックスと比べると、相対的に少ないです。これがユースケースの大部分なのであれば、記事の主張であるPostgreSQLの代わりにMySQLを使うという主張は納得がいくものです。記事では、MySQL/InnoDBはクラスター化インデックスを使っており、「この設計は、InnoDBがセカンダリインデックスを参照する時に、PostgreSQLに対してわずかな不利益があることを意味している。Postgresがただ一つのインデックスを使うのに対して、InnoDBでは2つのインデックスを検索しなければならないからだ」ということを認めています。Serverにおけるこの問題(クラスタ化インデックスのペナルティ)について以前書いたことがあります。key.私の注意を引いたのは、彼らがクラスター化インデックスのペナルティを「わずかな不利益」としていたことです。私の見解では、もしあなたがセカンダリインデックスを使う多くのクエリを実行しているのであれば、これは非常に大きな不利益なのです。これが彼らにとってわずかな不利益なのであれば、それらのインデックスがめったに使われていないことを示唆しています。ほとんどの場合には主キーによる検索(searching)である(よってクラスター化インデックスのペナルティは発生しない)ことを意味しています。私が選択(selecting)ではなく検索(searching)と書いたことに注意してください。その理由は、クラスター化インデックスのペナルティは、SELECTのみならず、すべてのWHERE句を持つクエリに影響するからです。このことにより、高頻度の更新処理の大部分は主キーを使っていると想定できます。彼らはPostgreSQLのIndex-Onlyスキャンの実行における制約については触れていません。更新の多いデータベースにおいては、PostgreSQLのIndex-Onlyスキャンはまったくと言っていいほど役に立ちません。これは、私の顧客の多くに影響を与える唯一の問題です。このことについて、2011年にはブログを書きました。9.2がIndex-Onlyスキャンの限定されたサポート(大部分が静的なデータに対してのみ機能する)を実現しました。Uberはそれについて問題視していません。SELECTの速さは彼らにとって問題ではないのです。想像するに、クエリの速さは一般的に、レプリカでSELECTすることによって解決され、かつ、主キーを使って操作するということによって(※訳注:実行時間は)限定されるのです。Key/Valueストアの方がよりフィットするように見えます。InnoDBは非常に堅牢で人気のあるKey/Valueストアなのです。私が思うに、MySQLとMariaDBは非常に人気のあるものです。皮肉を許してください。あなたが求めているものがKey/Valueストアであり、シンプルなクエリを時々実行するものであれば、MySQL(またはMariaDB)は合理的な選択肢です。Key/Valueストアよりは良い選択肢だと思います。Uberは、逆に彼ら自身のもの(Schemaless)をInnoDBとMySQLの上に構築しました。記事中でB-Treeインデックスの文脈で「再バランス(rebalancing)」という言葉を使っています。Wikipediaの「削除後の再バランス」の記事へのリンクも貼っています。残念なことに、Wikipediaの記事の内容はデータベースのインデックスに対して適用させることはできません。Wikipediaで説明されているアルゴリズムでは、各ノードが少なくとも半分埋まっている状態であることを要求しているからです。PostgreSQLでは、並行性を向上させるためにこの前提を除去して疎(sparse)なインデックスを可能にするLhemanとYaoのB-treeの派生版を使っています。Internals"のスライド15枚目を見てください)、これは枝葉の問題です。「B-treeの本質的な側面は、それらが定期的に再バランスを必要とすることです」。ここで明確にしておきたいのは、これは毎日実行されるような定期的なプロセスではない、ということです。