OracleからPostgresへのDB移行に関するEDB日本支社公式ブログサイト
Amit Kapila, Senior Database Architect ここ数年、PostgreSQLは、多くのコアシステムの機能、性能、スケーラビリティの点でかなり進歩してきました。 しかし、多くの企業が依然として不満を持っている問題の1つは、時間が経過するにつれてサイズが大きくなることです。これは一般に肥大化と呼ばれます。 私の同僚のRobert Haasは彼のブログの中でそのようなケースをいくつか議論しました。つまり、PostgreSQLのヒープが肥大化する傾向にあること、肥大化を回避するための解決策として「zHeap」と呼ばれるPostgreSQLの新しいストレージフォーマットにEnterpriseDB社が取り組んでいることに言及しました。 このブログ記事では、「zHeap」についてより詳細に説明し、いくつかの実証結果を開示いたします。
Robert Haas, Vice President, Chief Architect, Databese Server もしPostgreSQLでVACUUMの必要がまったくなくなったらどうでしょうか？これはなかなか想像し難いことのようです。結局のところ、PostgreSQLはマルチバージョン コンカレンシー コントロール（MVCC）を使用しています。従って複数の行バージョンを作成する場合、最終的に何らかの形で不要行バージョンを削除する必要があります。 PostgreSQLでは、VACUUMがそれを確実に実行しており、オートバキュームプロセスのおかげで、それが遅滞なく行われているわけです。とは言え、全てのリレーショナル・データベースが、同じ方法でMVCCを実現しているわけではないという事実からも明らかなように、他の方法を取ることも可能です。PostgreSQLが新しいアプローチを採用することで、大いに恩恵を得ることができる可能性もあるのです。実際、EnterpriseDBの私の同僚の多くは、新しいアプローチの実装に忙殺されております。今日は私たちが何をやっており、なぜそれをやっているのかについてお話ししたいと思います。
Robert Haas, Vice President, Chief Architect, Databese Server この記事では、近年のVACUUMの改善の歴史、PostgreSQLにおけるVACUUMの現状、そして今後どのように改善されるのかを話したいと思います。 私が最初にPostgreSQLを使い始めた頃、オートバキュームは存在せず、手動のVACUUMを行う必要性も感じませんでした。しかし、数ヶ月過ぎた頃、なぜか私のデータベースがとても遅くなりました。 そこで、cronで6時間ごとにvacuumdbコマンドが実行されるようにスケジュールすることで対応しました。当時の私のニーズでは、そのレベル十分でした。データベースが小さく、限られた量のトラフィックしか処理しなかったからでしょう。