DB設計アンチパターン
https://zenn.dev/koduki/articles/d3e8984f420b370681f9
しないほうが良いこと
- バッチを分割して疑似的な並列インサートをする
- 一括で入れよ
- 現代のRDBは読み取り性能重視で、書き込み性能(特に並列)が実は弱い
- 何でもインデックスつける
- 書き込みが遅くなる、書き込みは問題なくてもマイグレーションで死ぬ
- Update多用
- シーケンスをPKにする
- B-treeの同じリーフに更新が集中してロックが掛かる(書き込みコストの話?)
- クライアントサイド JOIN, Filter
- DBに高価な処理をさせてはいけない風潮があった?
- むしろ、DBでフィルタしないで全件取得することで I/O リソースの大量消費により DB への負荷がむしろデカイ
- I/Oは貴重なリソースで、他のクエリにも影響が出る
なので1GBのデータをDBで1KBにして転送したほうがNWコストが小さくなるので、JOIN/WHERE句をDBでした方がパフォーマンスが良くなるのはイメージがしやすいですね?
JOIN のコスト
int vs text
整数値のほうが比較が早い (が、UUIDなどでも成り立ってるサービスは多いのであんまり重要じゃないかも)
インデックスの重要性
http://www.code-magagine.com/?p=14618
Join に使うキーにインデックスを作る (基本、JOINキー は PK を使っとけば自動でindexされてるので大丈夫)
100 x 100行のJOINの場合、インデックスがあればスキャンコストは 200 だがなければ 10000 になる