Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

顧客が本当に必要だったもの - パフォーマンス改善編 / Make what is needed

soudai sone
October 29, 2024

顧客が本当に必要だったもの - パフォーマンス改善編 / Make what is needed

# 失敗から学ぶRDBの正しい歩き方
- https://amzn.to/4e0CqfH

soudai sone

October 29, 2024
Tweet

More Decks by soudai sone

Other Decks in Technology

Transcript

  1. 自己紹介
 曽根 壮大(40歳)
 Have Fun Tech LLC 代表社員
 株式会社リンケージ CTO

    兼 COO
 
 そ
 • 日本PostgreSQLユーザ会 勉強会分科会 担当
 • 3人の子供がいます(長女、次女、長男)
 • 技術的にはWeb/LL言語/RDBMSが好きです
 • コミュニティが好き たけ
 ね
 とも

  2. 1. 商品の在庫を確保
 2. ポイントの利用
 3. クーポンの利用
 4. キャンペーンの確認
 5. 決済処理


    6. 配送手続き処理
 7. ポイント付与
 8. 購入履歴の追加
 9. 通知処理
 複雑な仕様がRDBを殺す これを全部 1つのトランザクションまとめる
  3. 1. 商品の在庫を確保
 2. ポイントの利用
 3. クーポンの利用
 4. キャンペーンの確認
 5. 決済処理


    6. 配送手続き処理
 7. ポイント付与
 8. 購入履歴の追加
 9. 通知処理
 複雑な仕様がRDBを殺す これを全部 1つのトランザクションまとめる いきなりUPDATEとかで ロックを取ると後続が詰まる
  4. 1. 商品の在庫を確保
 2. ポイントの利用
 3. クーポンの利用
 4. キャンペーンの確認
 5. 決済処理


    6. 配送手続き処理
 7. ポイント付与
 8. 購入履歴の追加
 9. 通知処理
 複雑な仕様がRDBを殺す これを全部 1つのトランザクションまとめる 処理の数だけクエリを投げて集計する
  5. 1. 商品の在庫を確保
 2. ポイントの利用
 3. クーポンの利用
 4. キャンペーンの確認
 5. 決済処理


    6. 配送手続き処理
 7. ポイント付与
 8. 購入履歴の追加
 9. 通知処理
 複雑な仕様がRDBを殺す これを全部 1つのトランザクションまとめる 処理の数だけクエリを投げて集計する 無理に1回のクエリで対応しようとして、 超複雑なクエリが生まれる
  6. 1. 商品の在庫を確保
 2. ポイントの利用
 3. クーポンの利用
 4. キャンペーンの確認
 5. 決済処理


    6. 配送手続き処理
 7. ポイント付与
 8. 購入履歴の追加
 9. 通知処理
 複雑な仕様がRDBを殺す これを全部 1つのトランザクションまとめる 処理の数だけクエリを投げて集計する 無理に1回のクエリで対応しようとして、 超複雑なクエリが生まれる さらにN+1のループがあったりする
  7. 1. 商品の在庫を確保
 2. ポイントの利用
 3. クーポンの利用
 4. キャンペーンの確認
 5. 決済処理


    6. 配送手続き処理
 7. ポイント付与
 8. 購入履歴の追加
 9. 通知処理
 複雑な仕様がRDBを殺す これを全部 1つのトランザクションまとめる 外部APIだったりする
  8. 1. 商品の在庫を確保
 2. ポイントの利用
 3. クーポンの利用
 4. キャンペーンの確認
 5. 決済処理


    6. 配送手続き処理
 7. ポイント付与
 8. 購入履歴の追加
 9. 通知処理
 複雑な仕様がRDBを殺す これを全部 1つのトランザクションまとめる 外部APIだったりする しかも時々めちゃレスポンスが遅い ISUCON9の予選問題がこれ
  9. 1. 商品の在庫を確保
 2. ポイントの利用
 3. クーポンの利用
 4. キャンペーンの確認
 5. 決済処理


    6. 配送手続き処理
 7. ポイント付与
 8. 購入履歴の追加
 9. 通知処理
 複雑な仕様がRDBを殺す これを全部 1つのトランザクションまとめる ここも外部APIだったりする 失敗したりするとロールバックでやり直し ここが終わってやっと画面遷移が終わる
  10. 1. 商品の在庫を確保
 2. ポイントの利用
 3. クーポンの利用
 4. キャンペーンの確認
 5. 決済処理


    6. 配送手続き処理
 7. ポイント付与
 8. 購入履歴の追加
 9. 通知処理
 複雑な仕様がRDBを殺す 在庫を確保できば後続は非同期にできる
  11. 1. 商品の在庫を確保
 2. ポイントの利用
 3. クーポンの利用
 4. キャンペーンの確認
 5. 決済処理


    6. 配送手続き処理
 7. ポイント付与
 8. 購入履歴の追加
 9. 通知処理
 複雑な仕様がRDBを殺す 後続で処理して 失敗したら購入を取り消す
  12. 1. 商品の在庫を確保
 2. ポイントの利用
 3. クーポンの利用
 4. キャンペーンの確認
 5. 決済処理


    6. 配送手続き処理
 7. ポイント付与
 8. 購入履歴の追加
 9. 通知処理
 複雑な仕様がRDBを殺す 商品次第ではここさえ確定できれば、 あとは非同期にできる
  13. ここまでシンプルな実装を目指しましょうと強調してきました が、「シンプルな実装」とはなんでしょうか。RDBMSを使う上で シンプルな実装のヒントは正規化です。正規化のコツは次の ように表現できます。 
 • 事実だけを保存する 
 • 重複がない


    • 不整合がない
 • nullがない
 これらを意識して設計していくとシンプルな設計に近づいてい きます。
 また正規化を行う際はここまで説明したとおり、種別と状態を 考えることも重要です。ライフサイクルが違うデータは往々に して状態や種別が異なります。 場合によってはnullになるよう なカラムやUPDATEが必要なレコードは状態を持っている可 能性があります。こうしたテーブルが見つかった場合はより 深く考察する必要があります。 
 https://agilejourney.uzabase.com/entry/2022/07/28/103000