1

データベースに大量の一時的なBLOBを格納する、大幅な書き換えを間もなく行うアプリケーションがあります。アプリケーションは、毎日の間に多数のブロブ（それぞれ最大5MBのサイズ）を挿入および削除します。現在、アプリケーションは非常に古いバージョンのPostgreSQL（7.3.x）を使用しています。このバージョンのPostgreSQLでは、データベースのサイズを制御するために外部バキュームプロセスを定期的に実行する必要がありました。さらに、このプロセスでは、正しく機能するためにアプリケーションをシャットダウンする必要がありました。

最新のPostgreSQLにアップグレードするか、別のデータベースに移行することを検討していました。具体的には、MySQLへの移行に関心がありました。ここにいる誰かがこれらのサーバーの最新バージョンのblob処理サポートに精通していて、blobを絶えず挿入および削除するアプリケーションに最適なパフォーマンスを提供する提案があるかどうか疑問に思いました。2つのサーバー間のその他の機能の違いは、私たちにとって問題ではありません。

私はいくつかの調査を行い、MySQLとPostgreSQLの機能の比較をたくさん見つけましたが、この問題に実際に対処したものは何もありませんでした。ここにいる誰かが、一方または両方のデータベースシステムのこの側面についてある程度の経験を積んでくれることを願っています。

ありがとう

4

1 に答える 1

1

Postgres 7.xは、バキュームに関しては確かに主要なPITAでした。9.0はこの分野ではるかに優れています。autovacuumデーモンは、8.3と思うので、テーブルごとのレベルで構成できます。説明されているシナリオでは、おそらくそのテーブル（または複数のテーブルが関係している場合はテーブル）に対して非常に積極的になります。

byteaBLOB（つまり）列のある行を削除するかどうかは重要ではないと思います。特に、blobはオフラインで格納されているためです（いわゆるTOASTテーブルに対しても自動真空デーモンを構成する必要があるかもしれませんが、よくわかりません）。

問題は、各BLOBの大きさではなく、テーブル内で削除/更新する行数（合計行のパーセント）です。

私はPostgreSQLが好きですが、バキュームのトピック全体（リリースごとにどんどん簡単になっているにもかかわらず）が依然としてその弱点の1つであることを認めなければなりません（そして多くの問題の原因です）。

実稼働環境で使用したことがないため、MySQLについては何も言えません。あなたとは対照的に、他の機能（blob以外）は、MySQLから離れるのに十分重要です-そしてそれがライセンスのためだけである場合。

于 2011-03-07T18:25:42.683 に答える