プログラミングは素晴らしい

2006-08-15 [PostgreSQL] テーブルスペース+テープルパーティショニング+メモ

[] テーブルスペース+テープルパーティショニング+メモリ内ファイルシステム 20:25

最近 大量のログの処理についていろいろと考えています。

おそらくすでによく知られていると思いますが、最近の PostgreSQL では、テーブルスペースという機能と、テーブルパーティショニングという機能があります。

テーブルスペースという機能は、テーブルごとに実際に配置される位置を変更可能にするようなテクニックです。

そして、テーブルパーティショニングは PostgreSQL にあるテーブルを継承する機能と「Constraint Exclusion」という機能を用いることで、テーブルを特定の条件に従って分割し、本当に必要なテーブルに対してのみディスクアクセスが発生するようにする機能です。

現在取り組んでいるのは、この2つの機能を組み合わせることで、大量の処理に対してより高速に対応可能であるようにしようとしています。

そして、現在これにさらに高速化するために、tmpfs (メモリ内ファイルシステム)を使うことを検討しています。メモリ内ファイルシステムの配下のディレクトリにテーブルスペースを構築し、そのテーブルスペース内に更新頻度が高いレコードを含むテーブルを置くという方式です。

更新頻度が高いレコード(以下 open なレコード)があらかじめ予測可能であるためそのようなレコードを集めたテーブルをあらかじめ tmpfs 上で構築しておき、それらが更新頻度が低いレコード(以下 closed なレコード)になれば、それらのレコードを定期的に、そのテーブルから本来のテーブルに COPY 文で反映させるような方式を検討しています。

レコードは一般的に open な状態から closed な状態へと遷移するという前提が適用可能で open な状態の間は参照・更新が多発するが closed になるとそれほどでもないという状況を想定しています。この場合、open な状態ではメモリ上で処理し、closed な状態になると、ディスク上に保管するようにするならば、ディスクアクセスを大幅に減らすことが出来ます。より大量のログを処理することが可能になるでしょう。

この方式の難点は誰でも気がつく点ですが、メモリ内の状態が突然の再起動等によって失われた場合の対応をどうするかです。

定期的にチェックポイントを設けて、自動的にロールバックするような仕組みが必要になります。簡単に言ってしまうと、本来データベースシステムが行うよう処理を自分で実装する必要に迫られるということです。

この方式が実際に効果的かどうかまではまだ試していないのですが、試す価値があるように思えます。特殊な状況でないと厳しそうですが。

Connection: close