どれ使う?DBの種類とメリットデメリットまとめ
こんにちは!ヒロケイと申します。
個人開発やインターンなどで複数種類のDBを使ってきたので、それぞれのDBの特徴や使用シーンなどをまとめておきます。
DBを使ったソフトウェアを作る上で、用途やメリットを知っておくことで技術選定の足がかりにしていただければと思います。
想定する読者
- CRUD操作ができるアプリが作れるようになった新米さん
- DBという言葉だけ知ってる初学者さん
- 個人開発でDBの技術選定をしたい駆け出しエンジニア
読むと得られるもの
- DBの種類とそれぞれが得意な領域について理解できる
- DBにおいて、特徴とニーズを踏まえた上で技術選定ができるようになる
扱わないテーマ
- DBの操作方法
- データ操作の実演
- タイムリーなアップデート内容
DBは大きく分けて以下の4種類があります。
種類 | 例 | メリット |
---|---|---|
RDB | MySQL, PostgreSQL | ACIDトランザクションをサポートし、信頼性を確保できる |
KVS | Redis, DynamoDB | 高速な読み書きが可能。スケーラビリティに優れている |
ドキュメントストア | MongoDB, Couchbase | 変化するデータ構造に対応できる |
それぞれ詳しく見ていきましょう。
RDB (Relational-DataBase)
まずはRDBです。
RDBは関係データベースやリレーショナルデータベースとも呼ばれます。
SQLコマンドでデータを操作できるDBですね。
データを表形式で管理できるのが大きな特徴です。
表形式のデータを他の表と関連づける特徴があることから、関係データベースと呼ばれているのですね!
メリット
- SQLによって複雑な検索、集計操作ができる。
- ACIDトランザクションをサポートし、データの信頼性を確保できる。
トランザクションとは?
データの一連の操作を一つの作業単位として扱う仕組み。
例: お金を別口座へ振り込み
振り込みの例で言うと、
- 元口座からお金を引き出し
- 振込先口座へ入金
システムで2つの操作をしていることがわかる。
そこで2の処理で何らかのエラーが発生した時、元口座でお金が引き出されただけで処理が終わってしまう。
そこでトランザクションを張って振り込み操作を一つの処理単位として扱うことで、途中でエラーが発生した時に元の状態に戻ってくれる(ロールバック)
トランザクション設定後の操作フローは以下
- トランザクション開始
- 元口座からお金を引き出し
- 振込先口座へ入金
- トランザクション確定
ACID: トランザクションで実現できる性質
属性名 | 意味 |
---|---|
Atomicity(原子性) | トランザクション内のすべての操作は、すべて成功するかすべて失敗するかのいずれかであり、途中で途切れることはない。つまり、トランザクション内の操作は不可分であるということ。 |
Consistency(一貫性) | トランザクションの実行前後でデータベースの一貫性が保たれることを保証。トランザクションが実行される前後で、データベースの制約や整合性ルールが維持される。 |
Isolation(独立性) | 複数のトランザクションが同時に実行される場合でも、操作対象のテーブルをロックし、各トランザクションは互いに影響を与えず、それぞれ独立して実行されているかのように振る舞う。 |
Durability(永続性) | トランザクションが正常に完了すると、その結果はデータベースに永続的に保存される。システムの障害や電源の喪失などが発生しても、トランザクションの結果は失われない。 |
(ちなみに元々操作が一つしかない処理でも、トランザクションを張るメリットはあるよ〜)
- 正規化によってデータの重複や不整合を防げる
正規化とは?
データベースのテーブルを関連付けて効率的に構造化することで、データの重複や不整合を最小限に抑える行為。
噛み砕いて言えば、データを扱いやすくする作業。
例: ディズニーヲタク共を正規化する
これらの人がいたとする。
- 22歳の男性、タロウ君:シンデレラは好きで、ジャファーは嫌い
- 19歳の女性、サクラさん:ミッキーマウスもデイジーダックも大好き
- 40歳の男性、ケンジさん:アラジンは好きで、ピーターパンは嫌い
- 39歳の女性、ナオミさん:エルサもアナも好き
- 60歳の男性、ユウジさん:ムーランもティンカーベルも嫌い
- 58歳の女性、ミキさん:アリエルもシンデレラも好き
- 30歳の男性、トシオさん:ミッキーマウスもムーランも嫌い
この状態では、ディズニーヲタク共のデータがぱっと見で見づらい。
- ディズニーヲタクの人気キャラは誰?
- 年齢層は?
では、次のように変形してみる。
■年齢:
- タロウ君:22歳
- サクラさん:19歳
- ケンジさん:40歳
- ナオミさん:39歳
- ユウジさん:60歳
- ミキさん:58歳
- トシオさん:30歳
■好きなキャラクター:
- タロウ君:シンデレラ
- サクラさん:ミッキーマウス、デイジーダック
- ケンジさん:アラジン
- ナオミさん:エルサ、アナ
- ユウジさん:なし
- ミキさん:アリエル、シンデレラ
- トシオさん:なし
■嫌いなキャラクター:
- タロウ君:ジャファー
- サクラさん:なし
- ケンジさん:ピーターパン
- ナオミさん:なし
- ユウジさん:ムーラン、ティンカーベル
- ミキさん:なし
- トシオさん:ミッキーマウス、ムーラン
属性によって分割することで、データがかなり扱いやすくなった。
データをどう扱うかによって、正規形か非正規形が変わるので、状況に応じた設計が必要。
デメリット
- スケーラビリティに課題があり、大規模(データが増える、またはデータ量が大きくなる)になると処理速度が遅くなる。
- テーブルの変更に柔軟に対応できず、拡張しにくい。
- 音声、画像、映像などのデータに対応できない。
使用シーン
- Eコマース
- 顧客情報
- 決済情報
- 商品詳細情報
- 注文詳細
- 予約管理
- 予約詳細
- 在庫管理
- 在庫商品の履歴
- 資材の配分情報
- 教育管理
- 学生情報
- 時間割
- 成績
- などなど。。。
KVS (Key-Value-Store)
次がKVSです。
キーと値のペアを保存するデータストレージシステムです。基本的には、各キーに対応する値を格納し、キーを使用して値を取得することができます。
JSONやXML, バイナリデータなどの様々なデータ構造に対応できるところが大きな特徴です。
メリット
- キーと値の単純なペアを保存するため、シンプルなデータ構造で高速な読み書きが可能。
- メモリ領域を使用するDBで高速なため、一時的に情報を保存しておくキャッシュとして利用可能。
- 負荷分散によるスケーラビリティに優れ、大規模なデータセットに対して高いパフォーマンスを提供できる。(ノードを複数用意することによる水平分散が可能)
デメリット
- 複雑なクエリやトランザクションのサポートが限られている場合がある。
- メモリに保存するため、システム障害や電源の喪失によってデータの整合性や一貫性の管理が難しい場合がある。
- 関連するデータを結合して取得することが困難であり、RDBのような複雑なクエリや集計を実行することができない。
- 負荷分散しやすいが単一ノードあたりの処理能力には限界があるため、スケーラビリティは考慮する必要あり。
使用シーン
- キャッシュ: 頻繁にアクセスするデータをKVSで管理することにより、応答時間を短くできる。
- SQLクエリの結果
- APIレスポンス
- 計算結果
- セッション管理: データを一時的に保存しておくことで、セッション状態をメモリ上で管理できる。
- ユーザーのログイン情報
- カートに入れた商品
- フォームの入力内容
ドキュメントストア
次がドキュメントストアです。
JSONやXMLなどのドキュメント形式でデータを格納するデータベースです。ドキュメントストアは、柔軟なデータ構造を持つことが特徴であり、それぞれのドキュメントはフィールドと値のペアの集合で構成されます。
メリット
- JSONなどのドキュメント形式での保存により、柔軟に変化するデータ構造に対応できる。
- 複数ノードへの負荷分散が可能なので、スケーラビリティに優れている。
- スキーマを事前に設定することなく、データの追加や変更が容易。
デメリット
- 複雑な関連性を持つデータを効率的に取得するのは困難。
- スキーマレスなため、データの整合性が保てない。
- 一部のDBでトランザクションがサポートされていないので、信頼性が保証されない
- メモリ領域にデータを保存するため、永続性が保証されない。
使用シーン
- 保存する型が頻繁に変わる可能性のあるもの
- ブログやニュースなどの記事
- 画像、価格、在庫状況などが含まれる可能性のある製品カタログ
- プレイヤーのステータスがアップデートによって頻繁に追加されるゲームデータ
KVSとの違いは?
KVSとドキュメントストアでは保存できるデータ型が似ているので、両者の違いをまとめます。
KVS | ドキュメントストア | |
---|---|---|
データ構造 | 任意の形式 | 構造化されたJSONやXML |
データの柔軟性 | データの構造がシンプルなので、柔軟性には欠ける | 複雑なデータ構造を柔軟に表現できる。 |
操作性 | シンプルで、高速に行える。 | APIやクエリ言語が豊富であり、複雑な検索や集計処理を実行することが可能 |
結論、シンプルと速さ重視ならKVS, 柔軟性重視ならドキュメントストア。
まとめ
RDB | KVS | ドキュメントストア | |
---|---|---|---|
データ構造 | テーブル形式で構造化されている | キーと値のペアで単純 | ドキュメント形式でネストされてる |
処理速度 | データ量が増えると遅くなる | 単純なキーによる読み書きが非常に高速 | 複雑なクエリ処理が可能で、高速なデータ取得が可能 |
分散性 | 分散処理が難しい場合がある | 水平分散可能 | 水平分散可能 |
拡張性 | 水平方向への拡張性が限定的 | 水平方向に簡単にスケール可能 | 水平方向に簡単にスケール可能 |
一貫性 | トランザクションをサポートし、一貫性が高い | 実装に依存 | 実装に依存 |
検索精度 | 複雑なクエリで検索できる | 柔軟な検索は限定的 | 複雑なクエリで検索できる |
向いているケース | 構造化されたデータやトランザクション処理が必要な場合 | 単純なキーによるデータの読み書きや高速なキャッシュが必要な場合 | 複雑なデータ構造や柔軟なクエリ処理が必要な場合 |
Discussion