Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
Webアプリ開発におけるRDBMS基礎
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
Shodai Suzuki
April 19, 2023
Technology
290
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Webアプリ開発におけるRDBMS基礎
法人向けDB新卒研修の講演資料です。
Shodai Suzuki
April 19, 2023
More Decks by Shodai Suzuki
See All by Shodai Suzuki
技術戦略としてのデザインエンジニアリング / Design System Study by dip and MOSH
soarteclab
1
220
AI時代における開発生産性と進化可能性を高める技術戦略 / AI DevEX Conference 2026
soarteclab
10
5.9k
TypeScriptで実現する既存APIを活用したリモートMCPサーバー構築 / TSKaigi 2026
soarteclab
2
810
lambda-lithアーキテクチャと移植性 / TECH BATON Lambda
soarteclab
1
1k
Full-Stack TSでのマルチプロダクト基盤開発 / TSKaigi Hokuriku 2025
soarteclab
4
2k
OpenAPIでのBackend TypeScriptスキーマ駆動開発
soarteclab
2
1.1k
リアーキテクチャとAI活用で実現する急成長プロダクトの開発生産性向上
soarteclab
3
19k
チーム再始動から6ヶ月でデプロイ数を9倍にするまでの取り組み
soarteclab
3
560
400超Lambda構成アプリケーションの漸進的リアーキテクチャ
soarteclab
3
1.4k
Other Decks in Technology
See All in Technology
OSC2026on_the-world-is-waiting-for-your-voice.pdf
naruoga
0
370
AI駆動開発の時代になったのでトヨタ生産方式から見直す
terurou
6
5.5k
自作バイナリを動かす「入口」8選
puhitaku
1
1.2k
V8のArray.prototype.flatを最大約20倍速くするまでと、巨大OSSへの大規模コミットの道のり
riyaamemiya
0
120
不可逆な意思決定を避けながら10億超の顧客データを AI Ready にするデータ基盤設計
baseballyama
1
250
プロダクト価値を、 チームが使える判断軸に変える
vivion
0
140
契約書画像からの情報抽出に特化した視覚接地モデルを育てる話
sansantech
PRO
1
160
事業活動を AI Ready にする攻めと守りのデータエンジニアリング / data-engineering-for-ai-ready-business
pei0804
6
2.3k
LLM機能を自作して分かるSnowflake Cortex AIの強み
nayuts
0
340
実践! SRE × AI - ABEMA における AIOps -
tetsuya28
7
2.6k
Execution in the Kingdom of Agents: Reflections on Abstraction and Complexity
bcantrill
0
900
AI 時代の Azure エンジニアリング ~ 私たちは何を磨き、何を任せるのか ~
chack411
1
560
Featured
See All Featured
Un-Boring Meetings
codingconduct
0
450
Sam Torres - BigQuery for SEOs
techseoconnect
PRO
0
570
Beyond borders and beyond the search box: How to win the global "messy middle" with AI-driven SEO
davidcarrasco
3
280
Crafting Experiences
bethany
1
380
Discover your Explorer Soul
emna__ayadi
2
1.3k
How to Align SEO within the Product Triangle To Get Buy-In & Support - #RIMC
aleyda
2
1.8k
Ruling the World: When Life Gets Gamed
codingconduct
0
390
Practical Orchestrator
shlominoach
192
12k
Organizational Design Perspectives: An Ontology of Organizational Design Elements
kimpetersen
PRO
1
840
Building Better People: How to give real-time feedback that sticks.
wjessup
370
20k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
16k
Building a Modern Day E-commerce SEO Strategy
aleyda
45
9.2k
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 絞り込み