$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Webアプリ開発におけるRDBMS基礎
Search
Shodai Suzuki
April 19, 2023
Technology
0
140
Webアプリ開発におけるRDBMS基礎
法人向けDB新卒研修の講演資料です。
Shodai Suzuki
April 19, 2023
Tweet
Share
More Decks by Shodai Suzuki
See All by Shodai Suzuki
急成長期の品質とスピードを両立するフロントエンド技術基盤
soarteclab
0
790
20240711_MOSHでのフロントエンドリアーキテクチャの選定技術の紹介
soarteclab
0
760
ClassiのRuby/Railsバージョンアップ始動物語
soarteclab
1
940
Other Decks in Technology
See All in Technology
How is Cilium Tested?
yutarohayakawa
5
300
Kubernetesトラフィックルーティング徹底解説/Kubernetes-traffic-deep-dive
oracle4engineer
PRO
3
540
お悩みハンドブック紹介資料
grafferhandbook
0
1.5k
間違いだらけのポストモーテム - ホントに役立つレビューはこうだ!
jacopen
5
1k
My Generation 年配者がこの先生きのこるには (Developers CAREER Boost 2024 Edition)/My Generation How elder engineers can survive
kwappa
3
380
属人化したE2E自動テストを ひも解く
honamin09
1
110
re:Inventで発表された Bedrockの新機能を色々使って、マルチRAGエージェントにクラウド選定させてみた件
minorun365
PRO
3
240
12/4(水)のBedrockアプデ速報(re:Invent 2024 Daily re:Cap #3 with AWS Heroes)
minorun365
PRO
2
420
Amazon Bedrock Multi-Agent Collaboration Workshop の紹介 - ワークショップでAIエージェントを学ぼう
nasuvitz
3
330
「品質とスピードはトレード・オンできる」に向き合い続けた2年半を振り返る / Quality and speed can be traded on.
mii3king
0
740
ファインディの4年にわたる技術的負債の返済 / Repaying 4 Years of Technical Debt at Findy
ma3tk
7
3.8k
12/2(月)のBedrockアプデ速報(re:Invent 2024 Daily re:Cap #1 with AWS Heroes)
minorun365
PRO
2
310
Featured
See All Featured
Site-Speed That Sticks
csswizardry
1
150
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.3k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
For a Future-Friendly Web
brad_frost
175
9.4k
A designer walks into a library…
pauljervisheath
204
24k
4 Signs Your Business is Dying
shpigford
181
21k
Code Review Best Practice
trishagee
64
17k
Automating Front-end Workflow
addyosmani
1366
200k
Fireside Chat
paigeccino
34
3.1k
Side Projects
sachag
452
42k
How GitHub (no longer) Works
holman
310
140k
Transcript
Webアプリ開発における RDBMS基礎 Shodai Suzuki @SoartecL 法人向けDB新卒研修 2023.04.19
自己紹介 • 鈴木翔大 @SoartecL • ソフトウェアエンジニア • OSSコントリビューター ◦ rails
◦ erb-lint ◦ redis-actionpack • エンジニアになる前は建設現場で施工 管理をしていた経験もあります!
ゴール
ゴール 1. WebアプリケーションでRDBMSが使われるケースが多い理由 2. データ型、制約などRDBMSの仕組み 3. インデックスを用いたパフォーマンスの最適化について (おまけ)少し飛躍しますがRDBMSをrailsで扱う際のトレードオフについて
メイン講義 基礎編
4-1 WebアプリケーションとRDBMS Why なぜWebアプリケーションでは RDBMSを使うことが多いのか?
4-1 WebアプリケーションとRDBMS Why (再掲) なぜWebアプリケーションでは RDBMSを使うことが多いのか? Answer 1. 間違いが無い様にデータを保存する 2.
高速に読み込んだり書き込んだりする
4-2 間違いが無い様にデータを保存する Why (再掲) なぜWebアプリケーションでは RDBMSを使うことが多いのか? Answer 1. 間違いが無い様にデータを保存する 2.
高速に読み込んだり書き込んだりする RDBMSに備わっている基本的な機能を 2つ紹介 • データ型 • 制約
4-2 間違いがないように保存する RDBMSには基本的な機能を2つ紹介 • データ型 • 制約(constraints) 数値データ型か文字列データかデータ型を理解する ex.) 23,
1, 114を 昇順に並び替え →1, 23, 114 (数値) “23”, “1”, “114”を 昇順に並び替え →”1", "114", "23" (文字列) その他のデータ型:
4-2 間違いがないように保存する RDBMSには基本的な機能を2つ紹介 • データ型 • 制約(constraints) 制約をつける事でデータの整合性や完全性を維持する。 代表的な制約 ▪
not null制約 →「データが存在しない = NULL」が無いことを宣言 →ではなくではなく0や’’という値を明示する NULL 値に関する問題: https://dev.mysql.com/doc/refman/8.0/ja/problems-with-null.html ▪ UNIQUE制約
4-2 間違いがないように保存する RDBMSには基本的な機能を2つ紹介 • データ型 • 制約(constraints) 制約をつける事でデータの整合性や完全性を維持する。 代表的な制約 ▪
not null制約 →「データが存在しない = NULL」が無いことを宣言 →ではなくではなく0や’’という値を明示する NULL 値に関する問題: https://dev.mysql.com/doc/refman/8.0/ja/problems-with-null.html ▪ UNIQUE制約 →データを重複することを防ぐ
4-3 高速に読み込んだり書き込んだりする Why (再掲) なぜWebアプリケーションでは RDBMSを使うことが多いのか? Answer 1. 間違いがないように保存する 2.
高速に読み込んだり書き込んだりする Index インデックスは特定のカラム値のある行をすばやく見つけるために使用されます。
4-3 高速に読み込んだり書き込んだりする Index (再掲) インデックスは特定のカラム値のある行をすばやく見つけるために使用されます。 例: B -treeインデックスのイメージ
4-3 高速に読み込んだり書き込んだりする 例: カーディナリティが高い カーディナリティが低い 例えばパターンが 1、2、3の3通りしかないstatusカラムがあり、Index を付与した場合 1対1 1対多
4-3 高速に読み込んだり書き込んだりする Indexはたくさんあれば良いというものではない。 以下のようなテーブルではインデックスは使用されないので 不要になります。 • 小さなテーブル • テーブル内のレコードの大半またはすべてを処理するクエリ 他の留意点
• 不要なインデックスはストレージ領域を無駄にします。 • MySQLが使用するインデックスを判断するための時間を無駄にします。 • レコードの変更に合わせて各インデックスを更新する必要があるため、インデックスは挿入、更新、削除のコストも追加します。 ⇒ 最適なインデックスのセットを使用して、高速のクエリを実現するために、適切なバランスを見つける必要があります。 MySQL :: MySQL 8.0 リファレンスマニュアル :: 8.3 最適化とインデックス
WebアプリケーションでRDBMSを扱う事で重要な 1. 間違いが無い様にデータを保存する 2. 高速に読み込んだり書き込んだりする に対して、 - 正しいデータ型を扱う - 制約などの仕組みを使う
事でバグを防いだりパフォーマンスが高いアプリケーションを構築することが可能 パフォーマンスの向上させる方法としてインデックスがある 4-4 サマリー
メイン講義 応用編
5-1 パフォーマンスの良いSQLを書く ▪ カバリングインデックス mysqlは 問い合わせたクエリとインデックスの状況から判定してくれる機能をカバリングインデックスと言います。 読み込み範囲が狭い →必要最小限だから速度が早い https://dev.mysql.com/doc/refman/8.0/ja/optimizing-innodb-queries.html
5-2 クエリの最適化方法とexplainの読み方 2. 絞り込みや並び替えの際に、インデックスが使用されているか <explain一覧> 参照 https://dev.mysql.com/doc/refman/8.0/ja/using-explain.html
5-2 クエリの最適化方法とexplainの読み方 2. 絞り込みや並び替えの際に、インデックスが使用されているか
5-3 RDBMS以外の紹介
5-4 railsとRDBMS ActiveRecord 事象 • 「アプリケーションのモデル」と「データベースのテーブル」が 1対1の関係になってしまうことで、データベースのテーブルに ア クセスするため”だけ”のモデルクラスを作る必要 がある。
• データベースにアクセスするため だけに必要なモデルクラスが発生する ◦ ドメイン知識をどのモデルクラスに持たせるか判断が難しくなる 引用:Instagram風簡易SNSアプリを作りながら、 Ruby on Rails 6のアプリケーション開発を学ぼう 5-1モデルの作成 https://www.techpit.jp/courses/2/curriculums/3/sections/18/parts/61
5-4 railsとRDBMS ActiveRecord 課題 ▪ 保守性の低下 モデルにDBアクセスだけの役割しか与えず、本来モデルが持つべきメソッド定義をせずに、部分最適的にコントローラーに処理をべた 書きする事で、同じ処理が複数の箇所に書かれていたり、微妙に仕様が異なっていたりと バグや保守性の低下 につながる
▪ 修正コストが高い テーブルのリファクタリングや新しい構造を加えた場合に モデルクラスの変更も必要 になる。 アプリケーションではそのモデルクラスを参照しているコントローラレイヤーも 同時に修正が必要 など、影響範囲が大きく修正コストが 高くなってしまう。
5-4 railsとRDBMS
5-4 railsとRDBMS ActiveRecord 解決策:アプリケーションレイヤーやユースケースレイヤーを用いて 振る舞いをカプセル化する ユーザテーブルのnameカラムをリファクタリングして first_name, last_nameに分けた時に、user.nameと参照しているコントローラすべて に変更加える必要がある。 一方で使い方を集約しているユースケースレイヤーを用いることで、
そこ だけ修正すればよく なるため影響範囲が限定される。
もっと学びたい方に
より学習したい人 SQL 第2版 ゼロからはじめるデータベース操作 (プログラミング学習シリーズ ) https://www.amazon.co.jp/dp/4798144452 達人に学ぶSQL徹底指南書 第2版 https://www.amazon.co.jp/dp/B07GB4CNKP
失敗から学ぶ RDBの正しい歩き方 https://www.amazon.co.jp/dp/B07P8PMHLL SQLアンチパターン https://www.amazon.co.jp/dp/4873115892
最後に
研修のゴールの再確認 1. WebアプリケーションでRDBMSが使われるケースが多い 理由 1. データベースにはどのような種類と特性がありますか? 2. その上でウェブアプリケーションでRDBMSを使用されるケースが多いのは何故でしょうか? 2. データ型、制約などRDBMSの仕組み
1. これらの機能はなぜ必要なのでしょうか? 3. インデックスを用いた パフォーマンスの最適化 について 1. インデックスを用いるとなぜパフォーマンスが良くなるのでしょうか?
APENDIX
パフォーマンス劣化につながるケース ▪ N+1 アプリケーションレイヤーの話のためここでは割愛 ▪ temp落ち(memory swap) 基本編で話したデータ型を可能な限り小さいものを選ぶときに役立つ temp落ち(memory swap)とは
joinしたりgroup byでの 集計を行う場合に、 内部メモリに一時テーブルを作成する。一時テーブルのデータ量が大きくメモリに乗らない 場合はディスクに書き込みを行い パフォーマンスが大きく低下する。この現象を temp落ちと言う
他のパフォーマンス最適化方法 1. 最小限のデータのみ取得するように絞り込みされているか 例えば、railsアプリケーションでユーザ一覧画面に`User.all`と 書かれていると全件取得しているのでサービスの成長とともにパ フォーマンスが低下していきます。 対策は、アプリケーションはページネーションを入れる事でDB アクセスとしてlimit, offfsetが 指定されることによりデータの絞り込み
が行われパフォーマンス劣化を防ぐことができます。 User.all 絞り込み