内部構造から学ぶPostgreSQL 設計・運用計画の鉄則 Software Design plus
- 作者: 勝俣智成,佐伯昌樹,原田登志
- 出版社/メーカー: 技術評論社
- 発売日: 2014/09/17
- メディア: Kindle版
- この商品を含むブログを見る
引き続き、この本を読み進めている。Part2では、設計/計画編だった。このセクションも長いので、ボチボチ読んでいく。
知らなかったこと
型
文字列型
char型は余ったらその分を半角スペースで埋める。 varcharとtextの場合、textのほうがパフォーマンスがいいという話を聞いたことがあったのだが、その理由を知ることができた。varcharは長さを指定する必要があるため、サイズ上限チェックの処理が行われるため、textよりもわずかにパフォーマンスがよくないらしい(微々たるものだが)。
面白い話で、char型は文字列連結のときの動作が異なるというのがコラムに書いてあった。concatで連結すると、半角スペースで埋められた分を反映するが、||で連結すると半角スペース埋めがなくなるらしい。
数値データ型
numeric型は精度がいいが、演算が遅い。ただ、double型などは精度が低いので、正確な数値を出したい場合はnumeric型を使うべし。
smallint, int, bigintや、連番型のsmallserial, serial, bigserialなどがある。
日付型
timestamp with timezoneなどタイムゾーンを扱える型がある。タイムゾーンを含める場合は、timestamp with timezoneを使うとよい。time with timezoneはサマータイムとかのことが考慮できないのでよくないとか。interval型はOSS-DB本でも出てきたが、まだ使いどころがよくわかってない。タイマーとかだろうか?
制約
外部キー制約
外部キーには暗黙的なインデックスが設定されないということなので、必要に応じて外部キーにもインデックスをつけたほうがよいらしい。
PostgreSQL固有のテーブル設計
TOASTを意識しろとのこと。日本語だと過大属性格納技法というちょっと難しい感じがする言い方だが、要は列のデータサイズが大きい場合の実装技法のことらしい。行にたくさんの列があって、行のデータサイズが2KBを超えるとTOAST領域にデータが作られるらしいので、なるべくこれに収まるようにするとよいようだ。
とはいえ、そんなにシビアに意識しなくてもよいとか。
ファイル
WALファイルとアーカイブファイル
WALファイルとアーカイブファイルはバックアップ・リストアのときに重要。更新ログが多くなって再利用されるときに古いWALファイルは削除されるので、アーカイブ設定をちゃんと行うこと。また、アーカイブファイルはストレージを圧迫していくのでストレージ容量をちゃんと監視しておかなければならない。
HOTとFILLFACTOR
HOTはVACUUMを待つことなくすぐに不要領域を再利用する仕組みで、インデックスの更新が発生しないため、更新時のパフォーマンスがよくなったとか。
FILLFACTORは、ページ内の空き領域を多めに取っておくことで、更新処理が行われたときに新しいページの生成を抑止することができる。メリットは、新しいページが作られないのでパフォーマンスが向上することだが、デメリットは多めに空き領域を取るため、ストレージを多めに使うことになる。デフォルトは100%で、空き領域を作らない設定のようなので、更新が頻繁に発生するテーブルには下限を70%として設定するといいとか。これ以上下げても、HOTがあるから不要領域がすぐ回収されるため、そんなに多くの空き領域を作っておかなくてもいいらしい。
気づき
FILLFACTORのことは全く知らなかった。うちのサービスはデータを定期的に更新するため、これを設定したら更新パフォーマンスが上がりそうに思った。 使えそうなところで使っていきたい。