harumaxy.com

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 になる