🗄️

【AWS】ふわっとDBを理解した気になってみたい

に公開
SQL
初心者
Database
RDBMS
tech

はじめに

MySQL、PostgreSQL、Aurora、DynamoDB、Redis...データベースの世界には多くの技術が存在し、それぞれに特徴があります。それぞれの専門用語がどのような関係性なのか私は 1 ミリも理解できていませんでした。この記事では、これらの技術がどのような関係性にあり、どんな場面で使い分けるべきかを体系的に整理します。

この記事で学べること

  • データベース技術の全体像と関係性
  • リレーショナル vs NoSQL の使い分け
  • MySQL, PostgreSQL, Oracle などの RDBMS 比較
  • AWS データベースサービスの位置づけ
  • 実際の選択指針とメリット・デメリット

対象読者

  • データベース技術の関係性を整理したい方
  • クラウド時代のデータベース選択に迷っている方
  • MySQL や PostgreSQL の違いを知りたい方

1. データベースの世界地図

データベースの大分類

現代のデータベースを大きく 2 つに大別します：

データ保存の手法
├── リレーショナルデータベース（RDBMS）
│   └── 表形式でデータを構造化、SQL使用
└── NoSQLデータベース
    ├── ドキュメント型（MongoDB）
    ├── キー・バリュー型（DynamoDB, Redis）
    └── 列指向型（Cassandra）

リレーショナル vs NoSQL の根本的違い

項目 リレーショナル NoSQL
データ構造 固定スキーマ（表形式） 柔軟スキーマ
整合性 ACID 特性で強い整合性 結果整合性
クエリ言語 SQL（標準化） 製品固有の API
適用場面 金融、会計、在庫管理 SNS、ログ、IoT

ACID 特性とは

リレーショナルデータベースの強い整合性を支える 4 つの特性：

🔒 Atomicity（原子性）

  • トランザクション内の処理は「全て成功」または「全て失敗」
  • 例：銀行振込で「引き出し」と「預け入れ」が両方成功するか、両方失敗

🔄 Consistency（一貫性）

  • データベースの制約やルールが常に保たれる
  • 例：在庫数がマイナスになることを防ぐ制約

🚧 Isolation（分離性）

  • 同時実行されるトランザクションが互いに影響しない
  • 例：同時に残高照会しても、途中の振込処理が見えない

💾 Durability（永続性）

  • 確定したトランザクションは障害があっても失われない
  • 例：システム停電後も確定した取引データは残る

ACID vs NoSQL の設計思想：

  • RDBMS: データの正確性を最優先（ACID 重視）
  • NoSQL: パフォーマンス・可用性を優先（ACID を一部緩和）

どちらを選ぶべきか

リレーショナルを選ぶべき場面：

  • データ間の関係が複雑
  • データの整合性が重要（金融取引など）
  • 複雑な検索・集計が必要
  • チーム全員が SQL を知っている

NoSQL を選ぶべき場面：

  • 大量のデータを高速処理したい
  • スキーマが頻繁に変わる
  • 地理的に分散したシステム
  • シンプルなキー検索が中心

2. リレーショナルデータベースの基礎

リレーショナルデータベースとは

  • 特徴: テーブル形式でデータを管理、SQL 使用
  • 代表例: MySQL、PostgreSQL、Oracle
  • 得意分野: 複雑なデータ関係、トランザクション処理
  • 苦手分野: 大規模分散、頻繁なスキーマ変更

3. RDBMS 製品の関係性と選び方

MySQL ファミリーの関係性

MySQL生態系
├── MySQL（Oracle社）
│   ├── メリット: 学習コスト低、豊富なリソース、高速
│   └── デメリット: 機能限定、レプリケーション設定複雑
└── MariaDB（MySQL派生）
    ├── メリット: MySQL互換、オープンソース、活発開発
    └── デメリット: MySQL比で知名度低い

MySQL vs MariaDB の選択指針：

  • MySQL: 既存システムとの互換性重視、大手企業での実績
  • MariaDB: 新規開発、オープンソース重視、最新機能

PostgreSQL の高機能性

PostgreSQL の特徴
├── 高度なSQL機能（ウィンドウ関数、CTE等）
├── 豊富なデータ型（JSON、配列、地理情報）
├── 拡張性（プラグイン、カスタム関数）
└── 厳密な標準SQL準拠

4. AWS データベースサービスの選び方

AWS のデータベースサービス体系

AWSデータベースサービス
├── リレーショナル（RDS ファミリー）
│   ├── RDS for MySQL/PostgreSQL/Oracle/SQL Server
│   └── Aurora（AWS独自のクラウドネイティブ）
├── NoSQL
│   ├── DynamoDB（キー・バリュー型）
│   └── DocumentDB（MongoDB互換）
├── インメモリ
│   └── ElastiCache（Redis/Memcached）
└── 分析
    └── Redshift（データウェアハウス）

RDS ファミリーの選択

Amazon RDS（従来型エンジン）

RDS（Relational Database Service）
├── 対応エンジン
│   ├── MySQL
│   ├── PostgreSQL
│   ├── Oracle
│   ├── SQL Server
│   └── MariaDB
├── 特徴: 既存エンジンのマネージド版
└── 適用: 既存システムの移行、特定エンジン要件

Amazon Aurora（クラウドネイティブ）

Aurora の位置づけ
├── RDSの一部として提供
├── MySQL/PostgreSQL互換のみ
├── AWS独自の分散ストレージ
└── 適用: 新規開発、高可用性要件

RDS エンジン選択の指針

要件 推奨選択
Oracle/SQL Server 必須 RDS（従来型）
最高パフォーマンス Aurora
コスト重視 RDS MySQL/PostgreSQL
既存システム移行 RDS（同一エンジン）
新規クラウド開発 Aurora

その他の AWS データベースサービス

DynamoDB

  • 特徴: サーバーレス NoSQL
  • 適用: セッション管理、IoT データ、ゲーム

ElastiCache

  • 特徴: Redis/Memcached のマネージド版
  • 適用: キャッシュ、セッション、リアルタイムランキング

Redshift

  • 特徴: 列指向データウェアハウス
  • 適用: BI、大規模分析、データレイク連携

5. NoSQL・キャッシュ戦略

MongoDB のドキュメント型メリット

ドキュメント型の特徴

{
  "_id": "user123",
  "name": "田中太郎",
  "profile": {
    "age": 30,
    "interests": ["プログラミング", "読書"]
  },
  "orders": [{ "date": "2024-01-15", "amount": 1500 }]
}

メリット：

  • JSON ライクな直感的構造
  • スキーマレスで柔軟
  • 水平スケールが容易
  • アプリケーションとの親和性

デメリット：

  • 複雑な関係表現が困難
  • データ整合性が緩い
  • メモリ使用量が多い

Redis vs ElastiCache

Redis（オープンソース）

Redisの特徴
├── インメモリキー・バリューストア
├── 豊富なデータ構造（リスト、セット、ハッシュ）
├── 永続化オプション（RDB、AOF）
└── Pub/Sub、Lua スクリプト対応

ElastiCache（Redis のマネージド版）

ElastiCache for Redis
├── Redis の運用自動化
├── 自動フェイルオーバー
├── 監視・アラート機能
└── VPC統合・セキュリティ強化

選択指針：

  • Redis: オンプレミス、細かい制御必要
  • ElastiCache: AWS 環境、運用負荷軽減重視

DynamoDB のサーバーレス特性

DynamoDB の独自性

DynamoDB の特徴
├── サーバーレス（容量計画不要）
├── 無制限スケール
├── 一桁ミリ秒のレスポンス
└── フルマネージド（運用作業ゼロ）

メリット：

  • 運用負荷ゼロ
  • 従量課金
  • 高可用性標準
  • Lambda との連携

デメリット：

  • SQL が使えない
  • 複雑なクエリ困難
  • AWS 依存
  • コスト予測困難

6. 大規模化への対応

データベースのスケーリング基本

  • 垂直スケール: サーバースペック向上（簡単だが限界あり）
  • 水平スケール: サーバー台数増加（複雑だが無限拡張）
  • キャッシュ活用: Redis/ElastiCache で負荷軽減
  • 読み書き分離: リードレプリカ（読み取り専用のデータベース複製）で読み取り処理を分散

分析用途での Redshift

  • 特徴: 列指向ストレージ、並列処理、高圧縮率
  • 得意分野: 大量データ集計、BI、レポーティング
  • OLTP vs OLAP: リアルタイム処理 vs 分析処理の違い

まとめ

データベース技術は用途と要件に応じて適切に選択することが重要。

重要なポイント

  • 銀の弾丸は存在しない - 要件に応じた適切な選択が重要
  • 関係性を理解する - 各技術がどう関連しているかを把握
  • メリット・デメリットを天秤にかける - 完璧な技術はない
  • 運用を考慮する - 開発だけでなく運用面も重要

次のアクションアイテム

  • もう少し DB 設計に踏み込んで考える

Discussion