The EDB Blog
November 16, 2016

L先週ユーバーエンジニアによるブログ投稿でPostgreSQLからMySQLに移行する事を選んだ理由を説明しました.この記事は広い意味で報告され又多くのユーザーやデベロッパーとPostgresSQLコミュニティー内で話し合われ ユーバーはPostgreSQLの持つ改善の余地を幾つかのエリアではっきりと克明に感情を実施にふれた感覚で表現しています。私はその感情をシェアします。PostgreSQL は非常に良いデータベースですが改善する事が出来る事が沢山あると信じていますユーザーが特に良く知られているユーバーの様な場合、彼らの環境では何が役に立ち何がダメかを説明する事でPostgreSQLコミュニティーの助けに成ります又、アクティブなディベロッパー企業が改善に最も必要な事が分ります。 私は思慮深く、深く考慮してこれに反応しています、PostgreSQLコミュニティのメンバーで見ていて満足しています。

ブログの記事を何回か読んで今、私は自分自身でもう少しだけ詳細を引き続き見つけています。私は本当に望んでいたユーバー論理レプリケーションではなく、物理的なレプリケーションを大きな問題の一つが、論理レプリケーションがまだPostgreSQLのコアで利用できない結論に来ています。ユーバーが言及した、prological、だがそれは幾分それより古いもので彼らが使用していたサーバーのバージョンで利用できませんでした。彼等は Slony,Bucardo,或いは Londiste;或いは, 独自のサイドのEnterpriseDB'sxDBレプリケーションサーバー.としてもアウトオフコアレプリケーションの幾つかとして試したかどうかは言及していません。彼らは彼らの経験を聞くことでそれらのいずれかをしようとした場合はそれは素晴らしい物です。いずれにしても、事実上PostgreSQLコミュニティ全体では、コア内の論理複製ソリューションが重要であるという合意に達していると思います。私は2011年にこれについてブログを始めました私たちは論理的なデコードを導入したPostgreSQL9.4で大きな進歩を遂げましたが、完全な解決策はまだありません。ロジカルレプリケーションは、ユーバーがワイドエリアネットワークを介して送信する必要がある変更ストリームのサイズ、クロスバージョンレプリケーション、物理的な破損の伝播、およびレプリカでのクエリのキャンセルに関するユーバーの懸念に対処する事を私は信じています。

これらの問題のいくつかは、他の方法で対処できます。たとえば、レプリカでクエリの取り消しは、hot_standby_feedbackを構成することによって防ぐことができると私はユーバーのエンジニアがこの機能を認識していたかどうかブログの記事から伝えることはできません。先行書き込みログファイルはSSLプロトコルの一部として圧縮を行うことができます。を使用するか、(任意圧縮コマンドを適用するようを使用してワイドエリアネットワーク上で送信する前に圧縮することができます。(たとえばgzip)各16MBは、それを送信する前に分割します。再び、これが試され効果がない或いは不十分だと しかしより深い詳細を聞くことが出来ると良いでしょう。メジャーバージョンのアップグレードのために彼らはそのpg_upgradeで起るはずがないそれらの環境で数時間を取った事について言及します。多数のオブジェクトを含むデータベースの処理に関連するpg_upgradeとの多くのパフォーマンス上の問題は、新しいリリースで修正されています。そのため、9.4や9.5ではもっと良くなったかもしれませんが、詳細は分かりません。 理解できる問題は修正できるので、知っておくと良いでしょう。

Perhaps the thorniest problem which Uber raises is that of write amplification caused by secondary index updates. As the Uber post explains, there are some basic differences between the way PostgreSQL organizes data and the way MySQL organizes data, which I've written about before. PostgreSQL performs some update as "HOT" updates and the rest as "non-HOT". HOT updates touch no indexes, while a non-HOT update must touch every index. Therefore, the percentage of updates which are HOT has a critical impact on update performance, and any update that touches an indexed column is always non-HOT. For this reason, many experienced PostgreSQL users are quite cautious about adding indexes, since it is quite easy to create a great deal of additional index maintenance - both index insertions and later VACUUM activity - if the percentage of non-HOT updates falls. For most users, being conservative in adding indexes is sufficient to avoid this problem, but Uber isn't the only company to have problems of this type. In InnoDB, or any other system where the primary key index is a clustered index and secondary indexes reference the primary key rather than the physical tuple position, secondary index updates are less frequent than they are in PostgreSQL. This approach is not without disadvantages - for example, it may be space-inefficient if the primary key is very wide and every secondary index access must also traverse the clustered index - but it's unquestionably got some benefits, especially for tables that are both heavily indexed and heavily updated.

What makes this problem thorny is that the PostgreSQL tuple format is pretty deeply embedded throughout the system, and it presupposes the current model for handling updates. We might be able to do better - HOT, itself, was an optimization as compared with our old strategy of ALWAYS updating every index - but I believe, and have believed for a while, that PostgreSQL also needs to be open to the idea of alternate on-disk formats, including but not limited to index-organized formats. In the past, there has been considerable skepticism within the PostgreSQL community about this kind of development direction, not only because developing a new on-disk format is hard, but also because of fears that the alternate formats would proliferate, dividing the community's development resources and perhaps even leading to multiple forks. While I'd like to hear more about Uber's experience - exactly how much secondary index traffic did they experience and were all of those secondary indexes truly necessary in the first place? - I view this overall as another piece of evidence suggesting that we need to look very hard at making our storage layer pluggable so that it's easier to experiment with new designs in this area. We may be able to get a bit more mileage out of extending the HOT optimization, but I think to really solve the problem is going to require something altogether new.

これほども長年にわたって私はPostgreSQLと取り組んできて既に8年経っていますが、いつも多くのなすべき仕事がある事が分るのは素晴らしい事です。私達はとても長い道を来ましたその間、無数のパフォーマンス機能でレプリケーション機能と他を追加します。しかし、本当に深刻な問題のすべてを克服したばかりだと思う度に、新しい世代の問題が現れ、必然的に開発者の注目が必要です。もう一度違反に対して!

[このブログ記事を書いた後しかし出版する前に、Markus Winandは既にこのトピック1について一つの優れた記事を書いていたことを知りました]。

Robert Haas is Vice President, Chief Database Architect at EnterpriseDB. 

This post originally appeared on Robert's personal blog

robert.haas_enterprisedb.comの写真

Robert is Chief Architect, Database Server, employed at EnterpriseDB as well as a PostgreSQL Committer. Robert is an expert in OLTP query tuning, schema design, triggers and stored procedures, and internals development, as well as an experienced UNIX/Linux system administrator. Additionally,...