Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
顧客が本当に必要だったもの - パフォーマンス改善編 / Make what is needed
Search
soudai sone
October 29, 2024
Technology
32
8.8k
顧客が本当に必要だったもの - パフォーマンス改善編 / Make what is needed
# 失敗から学ぶRDBの正しい歩き方
-
https://amzn.to/4e0CqfH
soudai sone
October 29, 2024
Tweet
Share
More Decks by soudai sone
See All by soudai sone
ソフトウェアエンジニアとしてキャリアの螺旋を駆け上がる方法 - 経験と出会いが人生を変える / Career-Anchor-Drive
soudai
13
2.6k
新婚19年目から学ぶ夫婦円満の正しい歩き方 / Life is beautiful
soudai
5
910
仕事を前に進めるためのコツ - 判断と決断と共有 / Aim for the goal
soudai
84
53k
アプリケーションが 正しく動作するということ - 自動テスト編 / Automated Testing
soudai
17
3.1k
Gitlab本から学んだこと - そーだいなるプレイバック / gitlab-book
soudai
8
1.9k
**強い**エンジニアのなり方 - フィードバックサイクルを勝ち取る / grow one day each day
soudai
125
120k
マルチテナントの実現におけるDB設計とRLS / Utilizing RSL in multi-tenancy
soudai
26
8.4k
キャッシュと向き合う、キャッシュと共に生きる / cache pattern
soudai
38
17k
RDBアンチパターンと戦う - 削除フラグ 完全攻略ガイド / delete flag
soudai
30
19k
Other Decks in Technology
See All in Technology
スパイクアクセス対策としての pitchfork 導入
riseshia
0
130
知らない景色を見に行こう チャンスを掴んだら道が開けたマネジメントの旅 / Into the unknown~My management journey~
kakehashi
8
1k
アジャイルテストの4象限で考える プロダクト開発の品質への向き合い方
nagano
1
480
データカタログを自作したけど 運用しなかった話@Findy Lunch LT「データカタログ 事例から学ぶメタデータ管理の実態」
ryo_suzuki
2
660
B11-SharePoint サイトのストレージ管理を考えよう
maekawa123
0
130
[GDG DevFest Bangkok 2024] - The Future of Retail E-commerce with Gemini AI
punsiriboo
0
290
LY Accessibility Guidelines @fukuoka_a11yconf_前夜祭
lycorptech_jp
PRO
1
140
Autonomous Database サービス・アップデート (FY25)
oracle4engineer
PRO
0
230
深層学習のリペア技術の最新動向と実際 / DNN Repair Techniques for AI Performance Alignment for Safety Requirements
ishikawafyu
0
420
ARRが3年で10倍になったプロダクト開発とAI活用の軌跡
akiroom
0
220
LINEヤフーにおける超大規模プラットフォーム実現への挑戦と学び / Challenges and Lessons in Building an Ultra-Large-Scale Platform at LY Corporation
hhiroshell
3
1.1k
LangChainとSupabaseを活用して、RAGを実装してみた
atsushii
0
140
Featured
See All Featured
Automating Front-end Workflow
addyosmani
1366
200k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
94
17k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
Building Your Own Lightsaber
phodgson
103
6.1k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.8k
It's Worth the Effort
3n
183
27k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
27
4.3k
A Modern Web Designer's Workflow
chriscoyier
693
190k
No one is an island. Learnings from fostering a developers community.
thoeni
19
3k
Agile that works and the tools we love
rasmusluckow
328
21k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5k
Transcript
【ハイブリッド開催】わたし史上、最高のチューニング 顧客が本当に必要だったもの - パフォーマンス改善編
What is it?
結論:仕様を正しく変更するのが 一番パフォーマンスに効く What is it?
What is it?
ずっと同じことを言ってる What is it?
ずっと同じことを言ってる ↓ 今日はもうちょっと具体例の話 What is it?
1. 自己紹介 2. 複雑な仕様がRDBを殺す 3. 特効薬 : 仕様を削る 4. まとめ
あじぇんだ
1. 自己紹介 2. 複雑な仕様がRDBを殺す 3. 特効薬 : 仕様を削る 4. まとめ
あじぇんだ
自己紹介 曽根 壮大(40歳) Have Fun Tech LLC 代表社員 株式会社リンケージ CTO
兼 COO そ • 日本PostgreSQLユーザ会 勉強会分科会 担当 • 3人の子供がいます(長女、次女、長男) • 技術的にはWeb/LL言語/RDBMSが好きです • コミュニティが好き たけ ね とも
1. 自己紹介 2. 複雑な仕様がRDBを殺す 3. 特効薬 : 仕様を削る 4. まとめ
あじぇんだ
複雑な仕様がスロークエリや ロングトランザクションを生む 複雑な仕様がRDBを殺す
複雑な仕様がRDBを殺す
複雑な仕様がRDBを殺す
これは本当に闇が深い 複雑な仕様がRDBを殺す
ECサイトの例 複雑な仕様がRDBを殺す
ECサイトの例 ↓ 購入のボタンがめちゃ重い 複雑な仕様がRDBを殺す
1. 商品の在庫を確保 2. ポイントの利用 3. クーポンの利用 4. キャンペーンの確認 5. 決済処理
6. 配送手続き処理 7. ポイント付与 8. 購入履歴の追加 9. 通知処理 複雑な仕様がRDBを殺す これを全部 1つのトランザクションまとめる
1. 商品の在庫を確保 2. ポイントの利用 3. クーポンの利用 4. キャンペーンの確認 5. 決済処理
6. 配送手続き処理 7. ポイント付与 8. 購入履歴の追加 9. 通知処理 複雑な仕様がRDBを殺す これを全部 1つのトランザクションまとめる いきなりUPDATEとかで ロックを取ると後続が詰まる
1. 商品の在庫を確保 2. ポイントの利用 3. クーポンの利用 4. キャンペーンの確認 5. 決済処理
6. 配送手続き処理 7. ポイント付与 8. 購入履歴の追加 9. 通知処理 複雑な仕様がRDBを殺す これを全部 1つのトランザクションまとめる 処理の数だけクエリを投げて集計する
1. 商品の在庫を確保 2. ポイントの利用 3. クーポンの利用 4. キャンペーンの確認 5. 決済処理
6. 配送手続き処理 7. ポイント付与 8. 購入履歴の追加 9. 通知処理 複雑な仕様がRDBを殺す これを全部 1つのトランザクションまとめる 処理の数だけクエリを投げて集計する 無理に1回のクエリで対応しようとして、 超複雑なクエリが生まれる
1. 商品の在庫を確保 2. ポイントの利用 3. クーポンの利用 4. キャンペーンの確認 5. 決済処理
6. 配送手続き処理 7. ポイント付与 8. 購入履歴の追加 9. 通知処理 複雑な仕様がRDBを殺す これを全部 1つのトランザクションまとめる 処理の数だけクエリを投げて集計する 無理に1回のクエリで対応しようとして、 超複雑なクエリが生まれる さらにN+1のループがあったりする
1. 商品の在庫を確保 2. ポイントの利用 3. クーポンの利用 4. キャンペーンの確認 5. 決済処理
6. 配送手続き処理 7. ポイント付与 8. 購入履歴の追加 9. 通知処理 複雑な仕様がRDBを殺す これを全部 1つのトランザクションまとめる 外部APIだったりする
1. 商品の在庫を確保 2. ポイントの利用 3. クーポンの利用 4. キャンペーンの確認 5. 決済処理
6. 配送手続き処理 7. ポイント付与 8. 購入履歴の追加 9. 通知処理 複雑な仕様がRDBを殺す これを全部 1つのトランザクションまとめる 外部APIだったりする しかも時々めちゃレスポンスが遅い ISUCON9の予選問題がこれ
1. 商品の在庫を確保 2. ポイントの利用 3. クーポンの利用 4. キャンペーンの確認 5. 決済処理
6. 配送手続き処理 7. ポイント付与 8. 購入履歴の追加 9. 通知処理 複雑な仕様がRDBを殺す これを全部 1つのトランザクションまとめる ここも外部APIだったりする 失敗したりするとロールバックでやり直し ここが終わってやっと画面遷移が終わる
全部を同時実行する必要はない 複雑な仕様がRDBを殺す
全部を同時実行する必要はない ↓ ユーザが知りたいのは購入できた事実 複雑な仕様がRDBを殺す
1. 商品の在庫を確保 2. ポイントの利用 3. クーポンの利用 4. キャンペーンの確認 5. 決済処理
6. 配送手続き処理 7. ポイント付与 8. 購入履歴の追加 9. 通知処理 複雑な仕様がRDBを殺す 在庫を確保できば後続は非同期にできる
1. 商品の在庫を確保 2. ポイントの利用 3. クーポンの利用 4. キャンペーンの確認 5. 決済処理
6. 配送手続き処理 7. ポイント付与 8. 購入履歴の追加 9. 通知処理 複雑な仕様がRDBを殺す 後続で処理して 失敗したら購入を取り消す
1. 商品の在庫を確保 2. ポイントの利用 3. クーポンの利用 4. キャンペーンの確認 5. 決済処理
6. 配送手続き処理 7. ポイント付与 8. 購入履歴の追加 9. 通知処理 複雑な仕様がRDBを殺す 商品次第ではここさえ確定できれば、 あとは非同期にできる
ロングトランザクション対策 複雑な仕様がRDBを殺す
ロングトランザクション対策 ↓ 分割する 複雑な仕様がRDBを殺す
???「でも全部同じテーブルなんですよ」 複雑な仕様がRDBを殺す
複雑な仕様がRDBを殺す
???「でも全部同じテーブルなんですよ」 ↓ ライフサイクルに合わせてテーブルは分割 複雑な仕様がRDBを殺す
ちゃんと正規化する 責務を正しく分ける 複雑な仕様がRDBを殺す
ここまでシンプルな実装を目指しましょうと強調してきました が、「シンプルな実装」とはなんでしょうか。RDBMSを使う上で シンプルな実装のヒントは正規化です。正規化のコツは次の ように表現できます。 • 事実だけを保存する • 重複がない
• 不整合がない • nullがない これらを意識して設計していくとシンプルな設計に近づいてい きます。 また正規化を行う際はここまで説明したとおり、種別と状態を 考えることも重要です。ライフサイクルが違うデータは往々に して状態や種別が異なります。 場合によってはnullになるよう なカラムやUPDATEが必要なレコードは状態を持っている可 能性があります。こうしたテーブルが見つかった場合はより 深く考察する必要があります。 https://agilejourney.uzabase.com/entry/2022/07/28/103000
そして最後にINDEXの数にも注目しましょう。主キーは必ずあ りますが、外部キー制約とユニーク制約を除いたINDEXは主 に検索のために必要なINDEXです。検索のWHEREの対象の 数だけそのテーブルの責務が大きいといえ、4つ以上の INDEXが必要な場合も同じく深く考察する必要があります。隠 れた状態をWHEREで絞り込んでいたり、種別をWHEREで絞り 込んでいるケースが見えてくることがあります。 このようにシンプルな設計を目指して考察を繰り返していくこ とが重要です。そして同じくらい重要なこととして認識すべき
はイージーとシンプルは両立できる、ということです。 シンプ ルを目指し考察を繰り返すことがまさにデータモデリングであ り、変化に強い設計につながっていくのです。 https://agilejourney.uzabase.com/entry/2022/07/28/103000
複雑な仕様がRDBを殺す
1. 自己紹介 2. 複雑な仕様がRDBを殺す 3. 特効薬 : 仕様を削る 4. まとめ
あじぇんだ
特効薬:仕様を削る
ずっとこれ言ってる 特効薬:仕様を削る
ずっとこれ言ってる ↓ 代表格を紹介します 特効薬:仕様を削る
ページャの原罪 特効薬:仕様を削る
ページャの原罪 ↓ ページャの業は深い 特効薬:仕様を削る
1つ目 対象総件数の表示 特効薬:仕様を削る
特効薬:仕様を削る
特効薬:仕様を削る このcount(*)が不要なクエリを生む
特効薬:仕様を削る 今はGoogleも表示していない
sql_culc_found_rows の呪い 特効薬:仕様を削る
sql_culc_found_rows の呪い 特効薬:仕様を削る MySQLで全体件数を取得するために使われていた MySQL 8.0.17で非推奨になった
通知の未読件数とかも一緒 基本的には未読かどうかわかれば良い 特効薬:仕様を削る アプリ 999 数字は不要
INDEXが活用できないcount()は めちゃめちゃ遅い 特効薬:仕様を削る テーブルスキャンだから
INDEXが活用できないcount()は めちゃめちゃ遅い 特効薬:仕様を削る テーブルスキャンだから 複雑な検索フォームの場合 テーブルスキャンになるケースで刺さる
2つ目 最終ページのリンク 特効薬:仕様を削る
特効薬:仕様を削る
ORDER BYの LIMIT OFFSETに刺さる 特効薬:仕様を削る
特効薬:仕様を削る
特効薬:仕様を削る
最終ページに行きたい? 昇順、降順で良い 特効薬:仕様を削る
そもそもユーザが必要なのは 検索フォームだったりする 特効薬:仕様を削る
そもそもユーザが必要なのは 検索フォームだったりする 特効薬:仕様を削る これもこれで闇が深いが … 部分一致とかORとか…
これらは単純に仕様を消せば 実装不要でパフォーマンスも改善する 特効薬:仕様を削る
特効薬:仕様を削る
What is it? 必要最小限を提供する
本当に必要なモノだけを 実装していますか? 特効薬:仕様を削る
1. 自己紹介 2. 複雑な仕様がRDBを殺す 3. 特効薬 : 仕様を削る 4. まとめ
あじぇんだ
複雑な仕様がRDBを殺す
まとめ Simple is Beautiful
まとめ Simple is Beautiful ↓ 常に追求した者だけが辿り着ける
まとめ 本当に必要なモノを実装する
まとめ 本当に必要なモノを実装する ↓ そのためにプロダクト、ドメインと向き合う
まとめ
まとめ 質を追求した結果 パフォーマンスは後からついてくる
良いソフトウェアを作ろう 目の前のプロダクトに向き合おう まとめ
昨日の自分に誇れる 今日の自分になろう まとめ
ご清聴ありがとうございました まとめ