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
データベースの種類と特徴 / Explanation-of-database-types
Search
soudai sone
May 23, 2020
Technology
6
1.5k
データベースの種類と特徴 / Explanation-of-database-types
RDBとNOSQLの違いにフォーカスしながら種類と特徴について解説する資料です。
soudai sone
May 23, 2020
Tweet
Share
More Decks by soudai sone
See All by soudai sone
抽象化をするということ - 具体と抽象の往復を身につける / Abstraction and concretization
soudai
16
4.2k
目の前の仕事と向き合うことで成長できる - 仕事とスキルを広げる / Every little bit counts
soudai
24
7.1k
ソフトウェアエンジニアとしてキャリアの螺旋を駆け上がる方法 - 経験と出会いが人生を変える / Career-Anchor-Drive
soudai
16
4.6k
新婚19年目から学ぶ夫婦円満の正しい歩き方 / Life is beautiful
soudai
12
4.4k
顧客が本当に必要だったもの - パフォーマンス改善編 / Make what is needed
soudai
33
9.5k
仕事を前に進めるためのコツ - 判断と決断と共有 / Aim for the goal
soudai
86
60k
アプリケーションが 正しく動作するということ - 自動テスト編 / Automated Testing
soudai
17
3.4k
Gitlab本から学んだこと - そーだいなるプレイバック / gitlab-book
soudai
8
2k
**強い**エンジニアのなり方 - フィードバックサイクルを勝ち取る / grow one day each day
soudai
130
130k
Other Decks in Technology
See All in Technology
開発組織のための セキュアコーディング研修の始め方
flatt_security
3
2.3k
自動テストの世界に、この5年間で起きたこと
autifyhq
10
8.5k
7日間でハッキングをはじめる本をはじめてみませんか?_ITエンジニア本大賞2025
nomizone
2
1.8k
RECRUIT TECH CONFERENCE 2025 プレイベント【高橋】
recruitengineers
PRO
0
160
スタートアップ1人目QAエンジニアが QAチームを立ち上げ、“個”からチーム、 そして“組織”に成長するまで / How to set up QA team at reiwatravel
mii3king
2
1.5k
Culture Deck
optfit
0
420
滅・サービスクラス🔥 / Destruction Service Class
sinsoku
6
1.6k
レビューを増やしつつ 高評価維持するテクニック
tsuzuki817
1
710
地方拠点で エンジニアリングマネージャーってできるの? 〜地方という制約を楽しむオーナーシップとコミュニティ作り〜
1coin
1
230
リーダブルテストコード 〜メンテナンスしやすい テストコードを作成する方法を考える〜 #DevSumi #DevSumiB / Readable test code
nihonbuson
11
7.2k
OpenID Connect for Identity Assurance の概要と翻訳版のご紹介 / 20250219-BizDay17-OIDC4IDA-Intro
oidfj
0
270
次世代KYC活動報告 / 20250219-BizDay17-KYC-nextgen
oidfj
0
250
Featured
See All Featured
Facilitating Awesome Meetings
lara
52
6.2k
What's in a price? How to price your products and services
michaelherold
244
12k
Writing Fast Ruby
sferik
628
61k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
6
550
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.6k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.5k
We Have a Design System, Now What?
morganepeng
51
7.4k
Making the Leap to Tech Lead
cromwellryan
133
9.1k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.3k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
4
410
Code Review Best Practice
trishagee
67
18k
How GitHub (no longer) Works
holman
314
140k
Transcript
データベースの種類と特徴 RDBとNOSQLの違いを理解して正しく選ぶ tech.make #1
データベースを正しく選択すること What is it?
データベースを正しく選択すること ↓ プロジェクトの成功には必要不可欠 What is it?
データベースは 何を基準に選んでいますか? What is it?
データベースの選ぶには 特徴を掴むことが大切 What is it?
データベースの 種類と特徴を理解しよう! What is it?
1. 自己紹介 2. RDBとNOSQL 3. ACIDとCAP定理とBASE 4. アーキテクチャとデータモデル 5. まとめ
あじぇんだ
1. 自己紹介 2. RDBとNOSQL 3. ACIDとCAP定理とBASE 4. アーキテクチャとデータモデル 5. まとめ
あじぇんだ
自己紹介 曽根 壮大(35歳) Have Fun Tech LLC 代表社員 そ
ね たけ とも • 日本PostgreSQLユーザ会 勉強会分科会 担当 • 3人の子供がいます(長女、次女、長男) • 技術的にはWeb/LL言語/RDBMSが好きです • コミュニティが好き
None
本書きました
1. 自己紹介 2. RDBとNOSQL 3. ACIDとCAP定理とBASE 4. アーキテクチャとデータモデル 5. まとめ
あじぇんだ
RDBとNOSQL RDBとNOSQL
RDBとNOSQL ↓ なにが違うのか? RDBとNOSQL
RDBとNOSQL アーキテクチャ / データモデル マスタ型 P2P型 その他 リレーショナル MySQL PostgreSQL
ProxySQL pgpool-2 キーバリュー Redis Memcached Redis Cluster カラム指向 Redshift Cassandra ドキュメント指向 MongoDB グラフ指向 Neo4J InfiniteGraph ※代表的なデータベースのソフトウェアの抜粋
RDBとNOSQL アーキテクチャ / データモデル マスタ型 P2P型 その他 リレーショナル MySQL PostgreSQL
ProxySQL pgpool-2 キーバリュー Redis Memcached Redis Cluster カラム指向 Redshift Cassandra ドキュメント指向 MongoDB グラフ指向 Neo4J InfiniteGraph ※代表的なデータベースのソフトウェアの抜粋
リレーショナルデータモデルに 最適化されたデータベース 現在も多くのシステムで広く使われている RDBとNOSQL RDB
RDB以外のDBシステムの総称 (Not Only SQL) グラフデータモデルをはじめ、 RDBの不得意な分野に特化している RDBとNOSQL NOSQL
つまり、RDB以外はすべてNOSQL RDBとNOSQL
RDBと根本から違う RDBとNOSQL
• データモデルが違うのでデータ設計も違う • スケールアウトやスケールアップの有効性が違う • パフォーマンスチューニングの方法が違う • アプリケーションからの接続や扱い方が違う RDBとNOSQL RDBとNOSQLの違い
違いを捉えて特徴を掴む RDBとNOSQL
1. 自己紹介 2. RDBとNOSQL 3. ACIDとCAP定理とBASE 4. アーキテクチャとデータモデル 5. まとめ
あじぇんだ
違うを知るための考え方を知る ACIDとCAP定理とBASE
ACID ACIDとCAP定理とBASE
関連する複数の処理を 一つの処理単位にまとめて管理する トランザクション処理に 求められる4つの特性 ACIDとCAP定理とBASE ACID
• 原子性(Atomicity) • 一貫性(Consistency) • 独立性(Isolation) • 永続性(Durability) ACIDとCAP定理とBASE ACID
• 原子性(Atomicity) • 一貫性(Consistency) • 独立性(Isolation) • 永続性(Durability) ACIDとCAP定理とBASE ACID
トランザクションに含まれる個々の手順が すべて実行される or すべて実行されない のどちらかになる性質
• 原子性(Atomicity) • 一貫性(Consistency) • 独立性(Isolation) • 永続性(Durability) ACIDとCAP定理とBASE ACID
トランザクションの前後でデータの整合性が保たれ、 矛盾の無い状態が継続される性質
• 原子性(Atomicity) • 一貫性(Consistency) • 独立性(Isolation) • 永続性(Durability) ACIDとCAP定理とBASE ACID
トランザクション実行中の処理過程が 外部から隠蔽され、 他の処理などに影響を与えない性質
• 原子性(Atomicity) • 一貫性(Consistency) • 独立性(Isolation) • 永続性(Durability) ACIDとCAP定理とBASE ACID
トランザクションが完了した場合に、 その結果は記録され、失われることはない性質
CAP定理 ACIDとCAP定理とBASE
分散データベースにおける、 Webサービスを想定した作られた定理 ノード間のデータ複製に置いて、 同時に3つの保証を提供することはできない ACIDとCAP定理とBASE CAP定理
分散データベースにおける、 Webサービスを想定した作られた定理 ノード間のデータ複製に置いて、 同時に3つの保証を提供することはできない ACIDとCAP定理とBASE CAP定理 CAP定理を見直す。“CAPの3つから2つを選ぶ”と いう説明はミスリーディングだった --
Eric Brewer 引用元 : https://www.publickey1.jp/blog/13/capcap32.html
• 一貫性(Consistency) • 可用性(Availability) • 分断耐性(Partition-tolerance) ACIDとCAP定理とBASE CAP定理
• 一貫性(Consistency) • 可用性(Availability) • 分断耐性(Partition-tolerance) ACIDとCAP定理とBASE CAP定理 全てのクライアントが
常に同一のデータ、またはエラーを参照する性質
• 一貫性(Consistency) • 可用性(Availability) • 分断耐性(Partition-tolerance) ACIDとCAP定理とBASE CAP定理 全てのクライアントが
読み込みと書き込みが出来る性質
• 一貫性(Consistency) • 可用性(Availability) • 分断耐性(Partition-tolerance) ACIDとCAP定理とBASE CAP定理 物理ネットワークが分断されても
間違った結果が発生しない性質
ACIDとCAP定理とBASE CAP定理 一貫性(C) 可用性(A) 分断耐性(P)
ACIDとCAP定理とBASE CA重視型 一貫性(C) 可用性(A) 分断耐性(P) PostgreSQL MySQL RDBMS 全般
ACIDとCAP定理とBASE AP重視型 可用性(A) 分断耐性(P) 一貫性(C) DyamoDB Cassandra ...など
ACIDとCAP定理とBASE CP重視型 一貫性(C) 分断耐性(P) 可用性(A) MongoDB Redis ...など
BASE ACIDとCAP定理とBASE
一貫性(C)と可用性(A)を重視した場合はACIDを 満たす必要がある それに対し、一貫性(C)よりも可用性(A)と分断耐 性(P)を重視する場合はBASEを満たす必要が ある ACIDとCAP定理とBASE BASE
• Basically Available • Soft-State • Eventually Consistent ACIDとCAP定理とBASE BASE
• Basically Available • Soft-State • Eventually Consistent ACIDとCAP定理とBASE BASE
可用性が高く、常に利用可能である どんなときもアプリケーションが動く
• Basically Available • Soft-State • Eventually Consistent ACIDとCAP定理とBASE BASE
厳密なステータスではなく、 送られてくる情報によって変化する 常に整合性を保たなくて良い
• Basically Available • Soft-State • Eventually Consistent 最終的に一貫性が保たれる 結果整合性
ACIDとCAP定理とBASE BASE
ACID(CA型)とBASE(AP型) ACIDとCAP定理とBASE
データベースの背景を知ると 特徴が見えてくる ACIDとCAP定理とBASE
1. 自己紹介 2. RDBとNOSQL 3. ACIDとCAP定理とBASE 4. アーキテクチャとデータモデル 5. まとめ
あじぇんだ
ACID、CAP定理、BASEを紐解くと アーキテクチャで重視した部分が見えてくる アーキテクチャとデータモデル
ACID(CA型)とBASE(AP型) アーキテクチャとデータモデル
ACID(CA型)とBASE(AP型) ↓ どのように実現をするか アーキテクチャとデータモデル
アーキテクチャが見えてくる アーキテクチャとデータモデル
マスタ型とP2P型 アーキテクチャとデータモデル
アーキテクチャとデータモデル マスタ型 マスタ スレーブ スレーブ スレーブ
アーキテクチャとデータモデル P2P型 マスタ マスタ マスタ マスタ
データモデル アーキテクチャとデータモデル
アーキテクチャとデータモデル リレーショナル user_id name 1 hoge 2 fuga 3
foo user_id role_id 1 1 1 3 3 2 4 4 role_id name 1 開発部 2 営業部 3 運用部 4 総務部
アーキテクチャとデータモデル リレーショナル user_id name 1 hoge 2 fuga 3
foo user_id role_id 1 1 1 3 3 2 4 4 role_id name 1 開発部 2 営業部 3 運用部 4 総務部 集合を定義する 関係を定義する
アーキテクチャとデータモデル キーバリュー key value 1 hoge 2 fuga 3 foo
4 bar fuga 次郎 hoge 太郎 foo 花子
アーキテクチャとデータモデル キーバリュー key value 1 hoge 2 fuga 3 foo
4 bar fuga 次郎 hoge 太郎 foo 花子 1:1の関係を保持する
アーキテクチャとデータモデル カラム指向 name hoge fuga bar foo test 部門 開発
営業 総務 企画 経理
アーキテクチャとデータモデル ドキュメント指向 name : hoge role : 開発 age :
30 name : fuga role : 開発,営業 from : 広島 age : 30 name : foo role : 総務 それぞれが独立したドキュメント ドキュメントにはユニークなIDでアクセス
他にも多種多様にデータモデルはある アーキテクチャとデータモデル
RDBとNOSQL アーキテクチャ / データモデル マスタ型 P2P型 その他 リレーショナル MySQL PostgreSQL
ProxySQL pgpool-2 キーバリュー Redis Memcached Redis Cluster カラム指向 Redshift Cassandra ドキュメント指向 MongoDB グラフ指向 Neo4J InfiniteGraph ※代表的なデータベースのソフトウェアの抜粋
1. 自己紹介 2. RDBとNOSQL 3. ACIDとCAP定理とBASE 4. アーキテクチャとデータモデル 5. まとめ
あじぇんだ
アーキテクチャ x データモデル ↓ データベースの種類と特徴を決める まとめ
保存したいデータモデル + 重視したいアーキテクチャ まとめ
ACIDとCAP定理とBASE 軸を持って比較する まとめ
長所と短所を知る ↓ 要件に合わせる まとめ
“もし現在のアプリケーションがRDBで 上手く動いているのであれば、 それをNOSQLに置換する理由は無いし、 それを勧めたりはしない” Nate McCall (@zznate)
データベースの種類と特徴を捉えて 適切なデータベースを選ぶ まとめ
ご清聴ありがとうございました まとめ