PostgreSQLアンチパターン

1. PostgreSQLアンチパターン

2. What is it? RDBの限界を感じた事ありませんか？

3. What is it? PostgreSQLは銀の弾丸ではありません

4. What is it? アンチパターン

5. What is it? アンチパターン ↓ 良かれと思ってした事が後々に苦しみを生む

6. What is it? アンチパターンを知る

7. What is it? アンチパターンを知る ↓ 同じ過ちを繰り返さない

8. What is it? 愚者は経験に学び、賢者は歴史に学ぶオットー・フォン・ビスマルク

9. What is it?

10. What is it? SQLアンチパターンは厳選された失敗集

11. What is it? SQLアンチパターンは厳選された失敗集 ↓ DBのノウハウが詰まった名著

12. What is it? しかしMySQLがベース

13. What is it? 今日はPostgreSQLの失敗例をご紹介します

14. What is it? SQLアンチパターン本の内容とは全く関係ありません

15. What is it? 俺の屍を越えて行け

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

18. 自己紹介名前：曽根壮大（そねたけとも）年齢：３１歳（三人の子供がいます）職業：Webエンジニア所属：日本PostgreSQLユーザ会中国支部支部長技術的にはLL系言語とかRDBが好きです

19. 中国地方DB勉強会 https://dbstudychugoku.github.io/

21. とりあえず削除フラグ http://www.slideshare.net/t_wada/ronsakucasual

22. とりあえず削除フラグこんなカラム名を作ったことありませんか？

23. とりあえず削除フラグ hoge_delete_ﬂag

24. とりあえず削除フラグ会員削除フラグ… 顧客削除フラグ… hogeデータ削除フラグ…

25. とりあえず削除フラグ論理削除と言う名の闇

26. とりあえず削除フラグ

27. とりあえず削除フラグ論理削除はなぜダメなのか？

28. とりあえず削除フラグ論理削除の理由

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

30. とりあえず削除フラグそして生まれるDELETE_FLAG

31. とりあえず削除フラグ論理削除のデメリット

32. とりあえず削除フラグ • 積み重なるWHERE delete_ﬂag = 0 • Unique制約が使えなくなる • 複雑な表示条件（Query）の原因

34. 積み重なるWHERE句 -- ブログを取ってきたい場合 SELECT * FROM blog WHERE blog.delete_ﬂag = 0

35. 積み重なるWHERE句 -- ブログを取ってきたい場合 SELECT * FROM blog WHERE blog.delete_ﬂag = 0 ブログの削除フラグを見る

36. 積み重なるWHERE句 -- ブログを取ってきたい場合 SELECT * FROM blog WHERE blog.delete_ﬂag = 0 ブログの削除フラグを見る更新者アカウントが削除されてたら？

37. 積み重なるWHERE句 -- 有効なアカウントのブログを取ってきたい場合 SELECT * FROM blog INNER JOIN users ON users.id = blog.user_id AND users.delete_ﬂag = 0 WHERE blog.delete_ﬂag = 0

38. 積み重なるWHERE句 -- 有効なアカウントのブログを取ってきたい場合 SELECT * FROM blog INNER JOIN users ON users.id = blog.user_id AND users.delete_ﬂag = 0 WHERE blog.delete_ﬂag = 0 ユーザの削除フラグを見る

39. 積み重なるWHERE句 -- 有効なアカウントのブログを取ってきたい場合 SELECT * FROM blog INNER JOIN users ON users.id = blog.user_id AND users.delete_ﬂag = 0 WHERE blog.delete_ﬂag = 0 ユーザの削除フラグを見る所属が削除されてたら？

40. 積み重なるWHERE句 -- 有効な所属の有効なアカウントのブログを取ってきたい場合 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

41. 積み重なるWHERE句 -- 有効な所属の有効なアカウントのブログを取ってきたい場合 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がどんどん積み重なる

42. 積み重なるWHERE句 -- 有効な所属の有効なアカウントのブログを取ってきたい場合 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がどんどん積み重なる Queryがボトルネックに

43. とりあえず削除フラグ Queryの複雑度に対する対策

44. とりあえず削除フラグ Queryの複雑度に対する対策 ↓ 有効なデータのViewを作る

45. とりあえず削除フラグ Queryの複雑度に対する対策 ↓ 有効なデータのViewを作る Queryの高速化にはならない

46. とりあえず削除フラグ全てのINDEXのセカンダリに DELETE_FLAGを入れる必要がある

47. とりあえず削除フラグ全てのINDEXのセカンダリに DELETE_FLAGを入れる必要がある INDEXの肥大化よりもそもそもINDEXを効かせる複数のQueryを書くのが大変

48. とりあえず削除フラグ PostgreSQLにはマテリアライズド・ビューがある

49. とりあえず削除フラグマテビューで有効データViewを作る

50. とりあえず削除フラグマテビューで有効データViewを作る ↓ 高速でQueryもシンプル

51. とりあえず削除フラグマテビューで有効データViewを作る ↓ 高速でQueryもシンプル SELECT * FROM active_blog

52. とりあえず削除フラグそれ、シンプルになるの参照だけ

53. とりあえず削除フラグそれ、シンプルになるの参照だけ ↓ 更新系で生まれる悪夢

54. とりあえず削除フラグ更新したらマテビューを更新

55. とりあえず削除フラグ更新したらマテビューを更新 ↓ customersでもusersでもblogでも更新があればマテビューも更新

56. とりあえず削除フラグ更新したらマテビューを更新 ↓ customersでもusersでもblogでも更新があればマテビューも更新頻発する REFRESH MATERIALIZED VIEW

57. とりあえず削除フラグ実際にはdeleteされないのでデータは増え続ける

58. とりあえず削除フラグ実際にはdeleteされないのでデータは増え続ける ↓ マテビューの更新コストが肥大

59. とりあえず削除フラグ実際にはdeleteされないのでデータは増え続ける ↓ マテビューの更新コストが肥大そして第三章の問題へ…

61. とりあえず削除フラグ • 積み重なるWHERE delete_ﬂag = 0 • Unique制約が使えなくなる • 複雑な表示条件（Query）の原因つまり外部Key制約も死ぬ

62. とりあえず削除フラグ id name age deleted 1 soudai 30 1 2 soudai 30 0 3 sone 20 0 4 taketomo 31 0

64. とりあえず削除フラグ id name age deleted 1 soudai 30 1 2 soudai 30 0 3 sone 20 0 4 taketomo 31 0 同じユーザが2名いるので Unique制約できない

65. とりあえず削除フラグ id name age deleted 1 soudai 30 1 2 soudai 30 0 3 sone 20 0 4 taketomo 31 0 同じユーザが2名いるので Unique制約できないもちろん外部キー制約もできない

66. とりあえず削除フラグ id name age deleted 1 soudai 30 1 2 soudai 30 0 3 sone 20 0 4 taketomo 31 0 サロゲートキーで外部キー制約した場合は関連したデータは別人扱いになる

67. とりあえず削除フラグ id name age deleted 1 soudai 30 1 2 soudai 30 0 3 sone 20 0 4 taketomo 31 0 サロゲートキーで外部キー制約した場合は関連したデータは別人扱いになるナチュラルキーの場合は死ぬ

68. とりあえず削除フラグ PostgreSQLには Unique制約にWHERE句がある

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

73. とりあえず削除フラグ id name age deleted 1 soudai 30 1 2 soudai 30 0 3 sone 20 0 4 taketomo 31 0 deletedが1なのでUnique制約対象外

74. とりあえず削除フラグ id name age deleted 1 soudai 30 1 2 soudai 30 0 3 sone 20 0 4 taketomo 31 0 nameでUnique制約をかけれる

75. とりあえず削除フラグ id name age deleted 1 soudai 30 1 2 soudai 30 0 3 sone 20 0 4 taketomo 31 0 nameでUnique制約をかけれるしかし外部キー制約は死ぬ

76. とりあえず削除フラグ Unique制約にWHERE句 ↓ 結局は外部キー制約は死ぬ

77. とりあえず削除フラグ外部キー制約が死ぬ

78. とりあえず削除フラグ外部キー制約が死ぬ ↓ テーブルの関連性の担保が死ぬ

79. とりあえず削除フラグデータの不整合を防げない

80. とりあえず削除フラグデータの不整合を防げない ↓ バグの温床になる

82. とりあえず削除フラグ正しいデータを表示させる条件が多い

83. 積み重なるWHERE句 -- 有効な所属の有効なアカウントのブログを取ってきたい場合 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 表示させるために 3つのテーブルが関係している

84. とりあえず削除フラグ 1つのデータを取るために関係するTABLEが多すぎる

85. とりあえず削除フラグ「あのデータ取るには○○と☓☓と △△をJOINしてWHEREしてSELECT 句にASで別名を付けて…」みたいな事が頻発する

86. とりあえず削除フラグ仕様変更の時の影響範囲が広い

87. とりあえず削除フラグ仕様変更の時の影響範囲が広い ↓ つまりバグの温床になる

88. とりあえず削除フラグ論理削除は使わないほうが良い

89. とりあえず削除フラグ論理削除は使わないほうが良い ↓ TABLEに状態を持たせない

90. とりあえず削除フラグ論理削除は使わないほうが良い ↓ TABLEに状態を持たせないリレーショナルモデルで表現する

91. とりあえず削除フラグ処方箋

92. とりあえず削除フラグ有効なデータのみを残す

93. とりあえず削除フラグ有効なデータのみを残す ↓ 例えば削除済みTABLEを作る

94. とりあえず削除フラグ deleted_usersusers

95. とりあえず削除フラグ deleted_usersusers soudai sone taketomo

96. とりあえず削除フラグ deleted_usersusers soudai sone taketomo 削除(DELETE文)

97. とりあえず削除フラグ deleted_usersusers soudai sone taketomo soudai トリガーで移す

98. とりあえず削除フラグ deleted_usersusers sone taketomo soudai テーブルには実際のデータのみが残る

99. とりあえず削除フラグ注意点

100. とりあえず削除フラグ注意点 ↓ トリガーは仕様変更に弱い

101. とりあえず削除フラグ注意点 ↓ トリガーは仕様変更に弱い例えばALTER文でカラムを増やすとトリガーが死ぬ

102. とりあえず削除フラグケースバイケースで手法は選ぶこと

103. とりあえず削除フラグケースバイケースで手法は選ぶこと ↓ 論理削除は使わない

104. とりあえず削除フラグ関連したテーブルは？

105. とりあえず削除フラグ関連したテーブルは？ ↓ 必要なら削除済みTABLEを作る不要ならDELETEする

106. とりあえず削除フラグ関連したテーブルは？ ↓ 必要なら削除済みTABLEを作る不要ならDELETEする外部キー制約が使えればCASCADEも出来る

107. とりあえず削除フラグ関連したテーブルは？ ↓ 必要なら削除済みTABLEを作る不要ならDELETEする外部キー制約が使えればCASCADEも出来る事実のみを保存する

108. とりあえず削除フラグ •ユーザの状態(statusカラム） •課金状態（与信、請求済み） •カート情報（カゴの中、購入済み）類似例

109. とりあえず削除フラグ DBに状態を持たせるのは危ない

110. とりあえず削除フラグ DBに状態を持たせるのは危ない ↓ DBには事実のみを保存する

112. 困ったときの配列型とJSON型 PostgreSQLは型が豊富

113. 困ったときの配列型とJSON型配列型やJSON型を使うと

114. 困ったときの配列型とJSON型配列型やJSON型を使うと ↓ 1:Nを1つのカラムで表現出来る

115. 困ったときの配列型とJSON型 id title body 1 初めてのポスグレ … 2 pg9.5 beta リリース … 3 篠崎愛「おしのブログ」 … blog_id tag 1 postgres 1 beginner 3 魂 blog tag

116. 困ったときの配列型とJSON型 id title body 1 初めてのポスグレ … 2 pg9.5 beta リリース … 3 篠崎愛「おしのブログ」 … blog_id tag 1 postgres 1 beginner 3 魂 blog tag 1:N

117. 困ったときの配列型とJSON型 id title body tag 1 初めてのポスグレ … [ postgres , beginner ] 2 pg9.5 beta リリース … null 3 篠崎愛「おしのブログ」 … [ 魂 ] blog(配列型の使用例)

118. 困ったときの配列型とJSON型テーブルを減らす事が出来る

119. 困ったときの配列型とJSON型テーブルを減らす事が出来る ↓ しかもINDEXも効く

120. 困ったときの配列型とJSON型 JSON型の場合

121. 困ったときの配列型とJSON型 JSON型の場合 ↓ KeyValueを表現できる

122. 困ったときの配列型とJSON型 id title body properties 1 初めてのポスグレ … {tag:[ postgres , beginner ]} 2 pg9.5 beta リリース … null 3 篠崎愛「おしのブログ」 … {tag:[ 魂 ]} blog(JSON型の使用例)

123. 困ったときの配列型とJSON型 id title body properties 1 初めてのポスグレ … {tag:[ postgres , beginner ]} 2 pg9.5 beta リリース … null 3 篠崎愛「おしのブログ」 … {tag:[ 魂 ], event:[ 握手会 ]} blog(JSON型の使用例)

124. 困ったときの配列型とJSON型 id title body properties 1 初めてのポスグレ … {tag:[ postgres , beginner ]} 2 pg9.5 beta リリース … null 3 篠崎愛「おしのブログ」 … {tag:[ 魂 ], event:[ 握手会 ]} blog(JSON型の使用例) JSON型はドキュメント指向なスキーマレスを表現できる  →つまりDB構造を変更すること無く項目を追加できる

125. とりあえず削除フラグ注意点 ↓ トリガーは仕様変更に弱い例えばALTER文でカラムを増やすとトリガーが死ぬ

126. とりあえず削除フラグ注意点 ↓ トリガーは仕様変更に弱い例えばALTER文でカラムを増やすとトリガーが死ぬ JSON型ならDB構造を変えない →仕様変更時にトリガーが死なない

127. 困ったときの配列型とJSON型 JSON型はデータに柔軟性を与える

128. 困ったときの配列型とJSON型 JSON型はデータに柔軟性を与える ↓ それは整合性を犠牲にする

129. 困ったときの配列型とJSON型配列型もJSON型もデータを守る機能が弱い

130. 困ったときの配列型とJSON型外部キー制約→使えない CHECK制約→使えない

131. 困ったときの配列型とJSON型外部キー制約→使えない CHECK制約→使えない該当のカラムが紐づくテーブルを関連付けなれない

132. 困ったときの配列型とJSON型外部キー制約→使えない CHECK制約→使えない該当のカラムに入るデータを制限出来ない

133. 困ったときの配列型とJSON型 UPDATE文に弱い

134. 困ったときの配列型とJSON型 UPDATE文に弱い ↓ 特定の要素のみの更新が難しい

135. 困ったときの配列型とJSON型仕様が曖昧な時にJSON型

136. 困ったときの配列型とJSON型仕様が曖昧な時にJSON型 ↓ 仕様変更には強いので有効だが運用時にデータが守れない

137. 困ったときの配列型とJSON型処方箋

138. 困ったときの配列型とJSON型ちゃんと正規化する

139. 困ったときの配列型とJSON型ちゃんと正規化する ↓ 面倒でも正規化すれば運用フェーズで必ず救われる

140. 困ったときの配列型とJSON型ちゃんと正規化する ↓ 面倒でも正規化すれば運用フェーズで必ず救われる逆説的にリソースが許されるなら困ってから正規化の選択肢もアリ

141. 困ったときの配列型とJSON型使っていい場合

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

143. 困ったときの配列型とJSON型 •ブログのTags •可変なプロパティ •外部のWebAPIの結果具体例

144. 困ったときの配列型とJSON型 •ブログのTags •可変なプロパティ •外部のWebAPIの結果具体例例えばServerのOS情報などはディストリビューションの違いを気にしなくても良くなる

145. 困ったときの配列型とJSON型 •ブログのTags •可変なプロパティ •外部のWebAPIの結果具体例いつ仕様変更が来るかわからない →その変更に柔軟に対応できる

146. 困ったときの配列型とJSON型ご利用は計画的に

147. 困ったときの配列型とJSON型ご利用は計画的に ↓ 基本的に正規化しましょう

149. マテビューの功罪マテビューはPostgreSQL 9.3から

150. マテビューの功罪 •複雑なテーブルをシンプルに •遅いクエリを高速に •INDEXチューニングも可能メリット

151. マテビューの功罪 •表領域を使う •リフレッシュが必要 •リフレッシュのコストが高いデメリット

153. マテビューの功罪 •表領域を使う •リフレッシュが必要 •リフレッシュのコストが高いデメリット実体を持つのでデータファイルが作成される作った分だけディスクスペースを圧迫する

154. マテビューの功罪 •表領域を使う •リフレッシュが必要 •リフレッシュのコストが高いデメリット実体を持つのでデータファイルが作成される作った分だけディスクスペースを圧迫する参照元のテーブルの増加と合わせてマテビューが増えれば指数的にディスクスペースの使用量が増える

156. マテビューの功罪集計済み表課金log 計算結果をマテビューにする

157. マテビューの功罪集計済み表課金log 課金1 計算結果をマテビューにする課金2

158. マテビューの功罪集計済み表課金log 課金1 計算結果をマテビューにする課金2 リフレッシュ

159. マテビューの功罪集計済み表課金log 課金1 集計結果計算結果をマテビューにする課金2 リフレッシュ

160. マテビューの功罪集計済み表課金log 課金1 集計結果計算結果をマテビューにする課金2 集計結果を参照するので高速でシンプル！！

161. マテビューの功罪集計済み表課金log 課金1 集計結果計算結果をマテビューにする課金2 課金3

162. マテビューの功罪集計済み表課金log 課金1 集計結果計算結果をマテビューにする課金2 課金3 ☓ 更新失敗

163. マテビューの功罪集計済み表課金log 課金1 集計結果計算結果をマテビューにする課金2 課金3 ☓ 更新失敗前回の更新結果のままなので不整合

164. マテビューの功罪更新が失敗した際の処理が必要

165. マテビューの功罪更新が失敗した際の処理が必要 ↓ 自動更新の場合にアプリケーションで制御出来ない

166. マテビューの功罪更新が失敗した際の処理が必要 ↓ 自動更新の場合にアプリケーションで制御出来ない DBはテストの自動化も大変未然にバグを検知しにくい

168. マテビューの功罪 •表領域を使う •リフレッシュが必要 •リフレッシュのコストが高いデメリット PostgreSQLには差分更新は無い →データがクエリの実行速度が遅ければ更新も遅い

169. マテビューの功罪 •表領域を使う •リフレッシュが必要 •リフレッシュのコストが高いデメリット PostgreSQLには差分更新は無い →データがクエリの実行速度が遅ければ更新も遅いデータが大きくなるにつれ、負荷も上がる →特に集約関数を使ったようなクエリはメモリに乗らなくなった瞬間に急激に遅くなる

170. マテビューの功罪 •表領域を使う •リフレッシュが必要 •リフレッシュのコストが高いデメリット PostgreSQLには差分更新は無い →データがクエリの実行速度が遅ければ更新も遅いデータが大きくなるにつれ、負荷も上がる →特に集約関数を使ったようなクエリはメモリに乗らなくなった瞬間に急激に遅くなる更新が遅くなった事に気づきにくい

171. マテビューの功罪処方箋

172. マテビューの功罪 DB状態を監視する

173. マテビューの功罪 DB状態を監視する ↓ 死活監視だけでは無くレコードの増加量やCPU使用率など

174. マテビューの功罪 DB状態を監視する ↓ 死活監視だけでは無くレコードの増加量やCPU使用率など Zabbixを使っているならpg_monzなどを使う

175. マテビューの功罪にも角にもマテビューはしない

176. マテビューの功罪にも角にもマテビューはしない ↓ マテビューを集計してマテビューのような闇を作らない

177. マテビューの功罪マテビューは便利だが銀の弾丸ではない ↓ 必要になった時、それは多くの場合設計に問題を抱えている

178. マテビューの功罪マテビューは便利だが銀の弾丸ではない ↓ 必要になった時、それは多くの場合設計に問題を抱えている

179. マテビューの功罪マテビューは便利だが銀の弾丸ではない ↓ 必要になった時、それは多くの場合設計に問題を抱えている根本的な解決策が必要なのでマテビューが必要になった時は設計を見直す

180. マテビューの功罪使わないに越した事は無い

181. マテビューの功罪使わないに越した事は無い ↓ 積極的に使うものではない

182. マテビューの功罪使わないに越した事は無い ↓ 積極的に使うものではない新機能は使いたくなるけども

184. まとめ PostgreSQLは高機能

185. まとめ PostgreSQLは高機能 ↓ 設計の不備を機能でカバー出来てしまう

186. まとめ機能に依存し過ぎない

187. まとめ機能に依存し過ぎない ↓ シンプルな設計は全てに勝る

188. まとめ愚者は経験に学び、賢者は歴史に学ぶ

189. まとめ周囲の経験談から学ぶ

190. まとめ周囲の経験談から学ぶ ↓ 積極的にコミュニティを利用する

191. 参考資料・公式ドキュメント(日本語) https://www.postgresql.jp/document/9.4/html/postgres-fdw.html ・postgresql-jp Slack(チャットルーム) https://postgresql-hackers-jp.herokuapp.com/

192. まとめデータの寿命はコードよりも長い

193. まとめ一度作ったDBは消せない

194. まとめ一度作ったDBは消せない ↓ 設計が大事

195. まとめより良い設計を一緒に考えて行きましょう

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

PostgreSQLアンチパターン

PostgreSQLアンチパターン

Recommended

More Related Content

What's hot

What's hot(20)

More from Soudai Sone

More from Soudai Sone(20)

PostgreSQLアンチパターン