Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
データベースの世界 SQL vs NoSQL
Search
MIKIO KUBO
July 10, 2025
Programming
0
18
データベースの世界 SQL vs NoSQL
データベースの世界
## SQL vs NoSQL
### あなたのデータに最適なのはどっち?
MIKIO KUBO
July 10, 2025
Tweet
Share
More Decks by MIKIO KUBO
See All by MIKIO KUBO
Connecting Theory and Practice V
mickey_kubo
0
6
PyMongo入門
mickey_kubo
0
3
Pythonで学ぶSQL入門
mickey_kubo
0
12
AutoGluon 時系列予測モデルの解説
mickey_kubo
0
15
AutoGluon Tabularモデル入門
mickey_kubo
1
11
AutoGluon: State-of-the-Art Automated Machine Learning
mickey_kubo
0
40
AutoGluon: State-of-the-Art Automated Machine Learning (English)
mickey_kubo
1
13
Python型ヒント完全ガイド 初心者でも分かる、現代的で実践的な使い方
mickey_kubo
1
120
SQLModel 入門
mickey_kubo
0
29
Other Decks in Programming
See All in Programming
Azure AI Foundryではじめてのマルチエージェントワークフロー
seosoft
0
170
Quand Symfony, ApiPlatform, OpenAI et LangChain s'allient pour exploiter vos PDF : de la théorie à la production…
ahmedbhs123
0
190
「Cursor/Devin全社導入の理想と現実」のその後
saitoryc
0
820
ソフトウェア品質を数字で捉える技術。事業成長を支えるシステム品質の マネジメント
takuya542
1
13k
GitHub Copilot and GitHub Codespaces Hands-on
ymd65536
2
150
ニーリーにおけるプロダクトエンジニア
nealle
0
840
NPOでのDevinの活用
codeforeveryone
0
840
なぜ適用するか、移行して理解するClean Architecture 〜構造を超えて設計を継承する〜 / Why Apply, Migrate and Understand Clean Architecture - Inherit Design Beyond Structure
seike460
PRO
3
770
Is Xcode slowly dying out in 2025?
uetyo
1
270
脱Riverpod?fqueryで考える、TanStack Queryライクなアーキテクチャの可能性
ostk0069
0
140
Google Agent Development Kit でLINE Botを作ってみた
ymd65536
2
250
AI時代のソフトウェア開発を考える(2025/07版) / Agentic Software Engineering Findy 2025-07 Edition
twada
PRO
87
29k
Featured
See All Featured
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
107
19k
Writing Fast Ruby
sferik
628
62k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.7k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Statistics for Hackers
jakevdp
799
220k
Visualization
eitanlees
146
16k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
GraphQLとの向き合い方2022年版
quramy
49
14k
A Tale of Four Properties
chriscoyier
160
23k
The Cult of Friendly URLs
andyhume
79
6.5k
Transcript
データベースの世界 SQL vs NoSQL あなたのデータに最適なのはどっち? 1
データベースってそもそも何? データベースとは、データを効率的に保存・検索・管理するために整理された「データの集まり」 です。 そして、そのデータベースを管理するためのソフトウェアが**データベース管理システム (DBMS)**です。 なぜDBMS が重要? データの 一貫性や 安全性を守ってくれます。
複数人での同時アクセスをうまくさばいてくれます。 開発者は面倒なファイル管理から解放され、アプリケーションのビジネスロジックに集中 できます。 2
データベースの設計図:「スキーマ」 スキーマとは、データベースの「論理的な構造」を定義した設計図です。 テーブル/ コレクション: データの主な入れ物。 列/ フィールド: データの属性(名前、年齢など)。 制約 (
ルール): PRIMARY KEY (重複禁止のID), NOT NULL (空欄禁止)など、データの品質を保つた めのルール。 SQLデータベースでは、このスキーマを 厳格に守らせます。 これにより、アプリケーション側のコードがシンプルになり、不正なデータが入るのを防ぎます。 3
パラダイム① リレーショナルデータベース (SQL) 4
SQL の世界観:整理整頓された「表」 リレーショナルデータベースは、データをExcelのシートのような**テーブル(表)**で管理しま す。 行 ( レコード): 個々のデータ(例: ある一人の顧客情報)。 列
( カラム): データの属性(例: 顧客ID , 名前 , メールアドレス )。 キー (Key): 主キー: 各行をユニークに識別する「ゼッケン番号」。 外部キー: 他のテーブルの主キーを参照し、テーブル同士を「関連付ける」ためのもの。 この「関連付け」がリレーショナルデータベースの心臓部です。 5
SQL の強み:データの整合性を守る「ACID 特性」 リレーショナルデータベースは、金融取引のような「絶対に失敗が許されない」処理のために、 ACIDという4つの特性を保証します。 Atomicity (原子性): トランザクションは「全部成功」か「全部失敗」のどちらか。中途半端な状 態にしない。 Consistency
(一貫性): データは常にルール(制約)に従った正しい状態を保つ。 Isolation (独立性): 複数の処理が同時に動いても、お互いに干渉しない。 Durability (永続性): 一度成功した処理の結果は、システム障害が起きても失われない。 → 信頼性が求められるシステムに不可欠! 6
SQL の代表選手たち データベー ス 特徴 最適な用途 MySQL 最も広く使われているオープンソース。 Webアプリのバックエンドに強く、パフォ ーマンスと信頼性に定評がある。
Webアプリケーション、オンライン 取引処理(OLTP)、SaaS PostgreSQL 高機能で拡張性が高い。厳格なSQL標準準 拠と高度なデータ分析機能が特徴。 データ分析、地理空間情報システ ム、高い信頼性が求められるエンタ ープライズシステム SQLite サーバー不要の軽量な組み込み型データベ ース。ファイル1つで完結し、設定も不 要。 モバイルアプリ、ブラウザ、小規模 アプリ、プロトタイピング 7
パラダイム② 非リレーショナルデータベース (NoSQL) 8
NoSQL の登場背景:現代のデータ課題 SQLは強力ですが、現代のWebスケールアプリケーションでは限界に直面することがあります。 スキーマの厳格さ: 事前に決めた構造の変更が大変。アジャイル開発のスピードを妨げること も。 スケールの限界: 1台のサーバー性能を上げる「スケールアップ」には物理的・コスト的な限界 がある。 多様なデータ:
JSONのような構造が固定でないデータを扱うのが苦手。 →これらの課題を解決するために**NoSQL (Not Only SQL)**が生まれました。 9
NoSQL の世界観:柔軟性と拡張性 NoSQLデータベースは、SQLとは異なるアプローチを取ります。 柔軟なスキーマ: スキーマレス、または動的なスキーマを持ちます。同じコレクション内でもデ ータ構造が違うことが許容されます。 水平スケーラビリティ ( スケールアウト): サーバーの台数を増やすことで、性能をリニアに向上
させることができます。ビッグデータに最適です。 多様なデータモデル: 用途に合わせて最適なデータモデルを選べます。 結果整合性: 多くのNoSQLは「最終的にデータは一致する」という考え方(結果整合性)を採用 し、可用性や分散処理能力を優先します。 10
NoSQL の様々なタイプ:「適材適所」で選ぶ タイプ データモデル 代表例 最適なユースケース ドキュメ ント JSON/BSON形式の柔軟なド キュメント
MongoDB, Firebase コンテンツ管理、ユーザープロフ ァイル、変化の激しいデータ キーバリ ュー シンプルなキーと値のペア Redis, DynamoDB キャッシュ、セッション管理、リ アルタイムリーダーボード カラムフ ァミリー 行と列で構成されるが、列 は行ごとに可変 Cassandra, HBase IoTデータ、時系列データ、大規模 な分析クエリ グラフ ノード(点)とエッジ(線)で関 係性を表現 Neo4j, Neptune ソーシャルネットワーク、不正検 知、レコメンドエンジン 11
SQL vs NoSQL: どちらを選ぶ? 究極の問いですが、答えは**「アプリケーションの要件による」**です。 12
SQL が輝くとき データの整合性と信頼性が最優先される場合 金融システム、在庫管理、予約システムなど。 データ構造が明確で、変更が少ない場合。 複雑なクエリやデータ間の関連付けが頻繁に必要な場合。 キーワード: 構造化データ, 一貫性, 信頼性,
トランザクション 13
NoSQL が輝くとき 膨大なデータ量と高いスループットが求められる場合(ビッグデータ)。 スキーマが頻繁に変わる、または未定義の場合。 高い可用性と高速な読み書きが必要な場合。 水平方向のスケーラビリティが不可欠な場合。 キーワード: 非構造化データ, スケーラビリティ, 柔軟性,
パフォーマンス 14
まとめ SQLとNoSQLは敵対するものではなく、それぞれに得意な領域がある 補完的な関係です。 SQL: データの 整合性と 信頼性を保証する、伝統的で堅牢な選択肢。 NoSQL: 柔軟性と スケーラビリティを武器に、現代の多様なデータ課題に対応する革新的な選択
肢。 アプリケーションの目的、データの性質、将来の成長を見据えて、最適なデータベースを選択する ことが、成功するシステム開発の鍵となります。 15