PostgreSQLアンチパターン

PostgreSQLアンチパターン

What is it?

RDBの限界を感じた事ありませんか？

What is it?

PostgreSQLは銀の弾丸ではありません

What is it?

アンチパターン

What is it?

アンチパターン ↓

良かれと思ってした事が後々に苦しみを生む

What is it?

アンチパターンを知る

What is it?

アンチパターンを知る ↓

同じ過ちを繰り返さない

What is it?

愚者は経験に学び、賢者は歴史に学ぶ

　　　　　　オットー・フォン・ビスマルク

What is it?

What is it?

SQLアンチパターンは厳選された失敗集

What is it?

SQLアンチパターンは厳選された失敗集

↓ DBのノウハウが詰まった名著

What is it?

しかしMySQLがベース

What is it?

今日はPostgreSQLの失敗例をご紹介します

What is it?

SQLアンチパターン本の内容

とは全く関係ありません

What is it?

俺の屍を越えて行け

あじぇんだ

１　自己紹介２　とりあえず削除フラグ３　困ったときの配列型とJSON型４　マテビューの功罪５　まとめ

あじぇんだ


自己紹介名前：曽根　壮大（そね　たけとも）年齢：３１歳（三人の子供がいます）職業：Webエンジニア

所属：日本PostgreSQLユーザ会

　　　中国支部支部長

　　技術的にはLL系言語とかRDBが好きです

中国地方DB勉強会

https://dbstudychugoku.github.io/

https://dbstudychugoku.github.io/

あじぇんだ


とりあえず削除フラグ

http://www.slideshare.net/t_wada/ronsakucasual

http://www.slideshare.net/t_wada/ronsakucasual


こんなカラム名を

作ったことありませんか？


hoge_delete_flag


会員削除フラグ… 顧客削除フラグ…

hogeデータ削除フラグ…


論理削除と言う名の闇



論理削除はなぜダメなのか？


論理削除の理由


• エンドユーザから見えなくしたいがデータは消したくない • 削除したデータを検索したい • データを消さずにログに残したい • 誤った操作をなかったことにしたい、直ぐに元に戻したい


そして生まれるDELETE_FLAG


論理削除のデメリット


• 積み重なるWHERE delete_flag = 0 • Unique制約が使えなくなる • 複雑な表示条件（Query）の原因



積み重なるWHERE句

-- ブログを取ってきたい場合 SELECT * FROM blog WHERE blog.delete_flag = 0



ブログの削除フラグを見る



ブログの削除フラグを見る

更新者アカウントが削除されてたら？


-- 有効なアカウントのブログを取ってきたい場合 SELECT * FROM blog INNER JOIN users ON users.id = blog.user_id AND users.delete_flag = 0 WHERE blog.delete_flag = 0



ユーザの削除フラグを見る



ユーザの削除フラグを見る

所属が削除されてたら？


-- 有効な所属の有効なアカウントのブログを取ってきたい場合 SELECT * FROM blog INNER JOIN users ON users.id = blog.user_id AND users.delete_flag = 0 INNER JOIN customers ON customers.id = users.customer_id AND customers.delete_flag = 0 WHERE blog.delete_flag = 0



JOINがどんどん積み重なる



JOINがどんどん積み重なる

Queryがボトルネックに


Queryの複雑度に対する対策


Queryの複雑度に対する対策 ↓

有効なデータのViewを作る


Queryの複雑度に対する対策 ↓

有効なデータのViewを作るQueryの高速化にはならない


全てのINDEXのセカンダリに

DELETE_FLAGを入れる必要がある


全てのINDEXのセカンダリに

DELETE_FLAGを入れる必要がある

INDEXの肥大化よりもそもそもINDEXを効かせる複数のQueryを書くのが大変


PostgreSQLには

マテリアライズド・ビューがある


マテビューで有効データViewを作る


マテビューで有効データViewを作る ↓

高速でQueryもシンプル


マテビューで有効データViewを作る ↓

高速でQueryもシンプルSELECT * FROM active_blog


それ、シンプルになるの参照だけ


それ、シンプルになるの参照だけ ↓

更新系で生まれる悪夢


更新したらマテビューを更新


更新したらマテビューを更新 ↓

customersでもusersでもblogでも更新があればマテビューも更新


更新したらマテビューを更新 ↓

customersでもusersでもblogでも更新があればマテビューも更新

頻発する REFRESH MATERIALIZED VIEW


実際にはdeleteされないのでデータは増え続ける



↓ マテビューの更新コストが肥大



↓ マテビューの更新コストが肥大

そして第三章の問題へ…





つまり外部Key制約も死ぬ


id name age deleted

1 soudai 30 1

2 soudai 30 0

3 sone 20 0

4 taketomo 31 0


id name age deleted

1 soudai 30 1

2 soudai 30 0

3 sone 20 0

4 taketomo 31 0


id name age deleted

1 soudai 30 1

2 soudai 30 0

3 sone 20 0

4 taketomo 31 0

同じユーザが2名いるのでUnique制約できない


id name age deleted

1 soudai 30 1

2 soudai 30 0

3 sone 20 0

4 taketomo 31 0

同じユーザが2名いるのでUnique制約できない

もちろん外部キー制約もできない


id name age deleted

1 soudai 30 1

2 soudai 30 0

3 sone 20 0

4 taketomo 31 0

サロゲートキーで外部キー制約した場合は関連したデータは別人扱いになる


id name age deleted

1 soudai 30 1

2 soudai 30 0

3 sone 20 0

4 taketomo 31 0

サロゲートキーで外部キー制約した場合は関連したデータは別人扱いになる

ナチュラルキーの場合は死ぬ


PostgreSQLには

Unique制約にWHERE句がある

Unique制約が使えなくなる

-- deletedが0の時にUnique制約をかける CREATE UNIQUE INDEX user_idx ON users (name) WHERE deleted = 0;


id name age deleted

1 soudai 30 1

2 soudai 30 0

3 sone 20 0

4 taketomo 31 0


id name age deleted

1 soudai 30 1

2 soudai 30 0

3 sone 20 0

4 taketomo 31 0


id name age deleted

1 soudai 30 1

2 soudai 30 0

3 sone 20 0

4 taketomo 31 0


id name age deleted

1 soudai 30 1

2 soudai 30 0

3 sone 20 0

4 taketomo 31 0

deletedが1なのでUnique制約対象外


id name age deleted

1 soudai 30 1

2 soudai 30 0

3 sone 20 0

4 taketomo 31 0

nameでUnique制約をかけれる


id name age deleted

1 soudai 30 1

2 soudai 30 0

3 sone 20 0

4 taketomo 31 0

nameでUnique制約をかけれる

しかし外部キー制約は死ぬ


Unique制約にWHERE句 ↓

結局は外部キー制約は死ぬ


外部キー制約が死ぬ


外部キー制約が死ぬ ↓

テーブルの関連性の担保が死ぬ


データの不整合を防げない


データの不整合を防げない ↓

バグの温床になる




正しいデータを

表示させる条件が多い



表示させるために 3つのテーブルが関係している


1つのデータを取るために

関係するTABLEが多すぎる


「あのデータ取るには○○と☓☓と△△をJOINしてWHEREしてSELECT

句にASで別名を付けて…」みたいな事が頻発する


仕様変更の時の影響範囲が広い


仕様変更の時の影響範囲が広い ↓

つまりバグの温床になる


論理削除は使わないほうが良い


論理削除は使わないほうが良い ↓

TABLEに状態を持たせない


論理削除は使わないほうが良い ↓

TABLEに状態を持たせない

リレーショナルモデルで表現する


処方箋


有効なデータのみを残す


有効なデータのみを残す ↓

例えば削除済みTABLEを作る


deleted_usersusers


deleted_usersusers

soudai

sone

taketomo


deleted_usersusers

soudai

sone

taketomo

削除(DELETE文)


deleted_usersusers

soudai

sone

taketomo

soudai

トリガーで移す


deleted_usersusers

sone

taketomo

soudai

テーブルには実際のデータのみが残る


注意点


注意点 ↓

トリガーは仕様変更に弱い


注意点 ↓


例えばALTER文でカラムを増やすとトリガーが死ぬ


ケースバイケースで手法は選ぶこと


ケースバイケースで手法は選ぶこと ↓

論理削除は使わない


関連したテーブルは？


関連したテーブルは？ ↓

必要なら削除済みTABLEを作る不要ならDELETEする




外部キー制約が使えればCASCADEも出来る




外部キー制約が使えればCASCADEも出来る

事実のみを保存する


•ユーザの状態(statusカラム） •課金状態（与信、請求済み） •カート情報（カゴの中、購入済み）

類似例


DBに状態を持たせるのは危ない


DBに状態を持たせるのは危ない ↓

DBには事実のみを保存する

あじぇんだ


困ったときの配列型とJSON型

PostgreSQLは型が豊富


配列型やJSON型を使うと


配列型やJSON型を使うと ↓

1:Nを1つのカラムで表現出来る


id title body

1 初めてのポスグレ …

2pg9.5 beta リリース …

3篠崎愛

「おしのブログ」 …

blog_id tag

1 postgres1 beginner3 魂

blog tag


id title body

1 初めてのポスグレ …

2pg9.5 beta リリース …

3篠崎愛

「おしのブログ」 …

blog_id tag

1 postgres1 beginner3 魂

blog tag

1:N


id title body tag

1 初めてのポスグレ … [“postgres”, ”beginner”]

2pg9.5 beta リリース … null

3篠崎愛

「おしのブログ」 … [“魂”]

blog(配列型の使用例)


テーブルを減らす事が出来る


テーブルを減らす事が出来る ↓

しかもINDEXも効く


JSON型の場合


JSON型の場合 ↓

KeyValueを表現できる


id title body properties

1 初めてのポスグレ … {tag:[“postgres”, “beginner”]}

2 pg9.5 beta リリース

… null

3 篠崎愛「おしのブログ」

… {tag:[“魂”]}

blog(JSON型の使用例)





… null


… {tag:[“魂”], event:[“握手会”]}






… null


… {tag:[“魂”], event:[“握手会”]}


JSON型はドキュメント指向なスキーマレスを表現できる→つまりDB構造を変更すること無く項目を追加できる


注意点 ↓




注意点 ↓



JSON型ならDB構造を変えない →仕様変更時にトリガーが死なない


JSON型はデータに柔軟性を与える


JSON型はデータに柔軟性を与える ↓

それは整合性を犠牲にする


配列型もJSON型も

データを守る機能が弱い


外部キー制約→使えない CHECK制約→使えない



該当のカラムが紐づくテーブルを関連付けなれない



該当のカラムに入るデータを制限出来ない


UPDATE文に弱い


UPDATE文に弱い ↓

特定の要素のみの更新が難しい


仕様が曖昧な時にJSON型


仕様が曖昧な時にJSON型 ↓

仕様変更には強いので有効だが運用時にデータが守れない


処方箋


ちゃんと正規化する


ちゃんと正規化する ↓

面倒でも正規化すれば運用フェーズで必ず救われる


ちゃんと正規化する ↓

面倒でも正規化すれば運用フェーズで必ず救われる

逆説的にリソースが許されるなら困ってから正規化の選択肢もアリ


使っていい場合


• UPDATEが無い(INSERTのみ) • データを守る必要が無い(制約を使わない) • データを関連付けない(JOINしない) • UPDETE時は対象カラムをまるっと更新 • 集約関数等の対象にならない


•ブログのTags •可変なプロパティ •外部のWebAPIの結果

具体例



具体例例えばServerのOS情報などはディストリビューションの違いを気にしなくても良くなる



具体例

いつ仕様変更が来るかわからない →その変更に柔軟に対応できる


ご利用は計画的に


ご利用は計画的に ↓

基本的に正規化しましょう

あじぇんだ


マテビューの功罪

マテビューはPostgreSQL 9.3から


•複雑なテーブルをシンプルに •遅いクエリを高速に •INDEXチューニングも可能

メリット


•表領域を使う •リフレッシュが必要 •リフレッシュのコストが高い

デメリット



デメリット



デメリット実体を持つのでデータファイルが作成される作った分だけディスクスペースを圧迫する



デメリット実体を持つのでデータファイルが作成される作った分だけディスクスペースを圧迫する

参照元のテーブルの増加と合わせてマテビューが増えれば指数的にディスクスペースの使用量が増える



デメリット


集計済み表課金log

計算結果をマテビューにする



課金1


課金2



課金1


課金2

リフレッシュ



課金1 集計結果


課金2

リフレッシュ





課金2

集計結果を参照するので高速でシンプル！！





課金2

課金3





課金2

課金3

☓更新失敗





課金2

課金3

☓更新失敗

前回の更新結果のままなので不整合


更新が失敗した際の処理が必要


更新が失敗した際の処理が必要 ↓

自動更新の場合にアプリケーションで制御出来ない


更新が失敗した際の処理が必要 ↓

自動更新の場合にアプリケーションで制御出来ない

DBはテストの自動化も大変未然にバグを検知しにくい



デメリット



デメリット

PostgreSQLには差分更新は無い →データがクエリの実行速度が遅ければ更新も遅い



デメリット


データが大きくなるにつれ、負荷も上がる →特に集約関数を使ったようなクエリは

メモリに乗らなくなった瞬間に急激に遅くなる



デメリット


データが大きくなるにつれ、負荷も上がる →特に集約関数を使ったようなクエリは

メモリに乗らなくなった瞬間に急激に遅くなる

更新が遅くなった事に気づきにくい


処方箋


DB状態を監視する


DB状態を監視する ↓

死活監視だけでは無くレコードの増加量やCPU使用率など


DB状態を監視する ↓

死活監視だけでは無くレコードの増加量やCPU使用率など

Zabbixを使っているならpg_monzなどを使う


兎にも角にもマテビューはしない


兎にも角にもマテビューはしない ↓

マテビューを集計してマテビューのような闇を作らない


マテビューは便利だが銀の弾丸ではない ↓

必要になった時、それは多くの場合設計に問題を抱えている







根本的な解決策が必要なのでマテビューが必要になった時は設計を見直す


使わないに越した事は無い


使わないに越した事は無い ↓

積極的に使うものではない


使わないに越した事は無い ↓

積極的に使うものではない

新機能は使いたくなるけども

あじぇんだ


まとめ

PostgreSQLは高機能

まとめ

PostgreSQLは高機能 ↓

設計の不備を機能でカバー出来てしまう

まとめ

機能に依存し過ぎない

まとめ

機能に依存し過ぎない ↓

シンプルな設計は全てに勝る

まとめ

愚者は経験に学び、賢者は歴史に学ぶ

まとめ

周囲の経験談から学ぶ

まとめ

周囲の経験談から学ぶ ↓

積極的にコミュニティを利用する

参考資料

・公式ドキュメント(日本語) https://www.postgresql.jp/document/9.4/html/postgres-fdw.html

・postgresql-jp Slack(チャットルーム) https://postgresql-hackers-jp.herokuapp.com/

https://www.postgresql.jp/document/9.4/html/postgres-fdw.html

https://postgresql-hackers-jp.herokuapp.com/

まとめ

データの寿命はコードよりも長い

まとめ

一度作ったDBは消せない

まとめ

一度作ったDBは消せない ↓

設計が大事

まとめ

より良い設計を

一緒に考えて行きましょう

ご静聴ありがとうございました。

Data & Analytics

PostgreSQLアンチパターン