| Master-Slave レプリケーション |
マスターが書き込み、スレーブが読み込みを行う |
データの冗長性確保、高速な読み取りが可能 |
マスター障害時にはスレーブの昇格が必要で、ダウンタイムが発生する可能性 |
読み取り負荷の分散、バックアップ |
MySQLのレプリケーション (例: WordPressサイトのスケーリング) |
| シャーディング (Sharding) |
データを複数のノードに分散して格納 |
データ量の増加に対応可能、スケーラビリティが高い |
データの分割が複雑になり、クエリが難しくなる |
高トラフィックのWebサービス、ECサイト |
MongoDB (例: eBayの大規模トランザクション処理)、Cassandra (例: Instagramのメッセージシステム) |
| データレイク (Data Lake) |
構造化・非構造化データをそのまま保存 |
データ形式の自由度が高く、さまざまな種類のデータをそのまま保存可能.大量のデータを低コストで保存できる。 |
データの整備が必要で、検索速度が遅くなることがある |
ログ・動画・音声などのデータ分析 |
Amazon S3 (例: Netflixの視聴履歴分析)、Azure Data Lake (例: IoTデータ蓄積) |
| データウェアハウス (Data Warehouse) |
構造化データの集計や分析に特化 |
高速なクエリ性能、データの一元管理が可能 |
バッチ処理が主体で、リアルタイム更新は難しい場合がある。大規模データではコストが高くなることがある |
BIツールによる分析、経営データの集計 |
Amazon Redshift (例: ユーザー行動分析)、Snowflake (例: デジタルマーケティングの効果測定) |
| NewSQL |
SQLの利便性とNoSQLのスケーラビリティを両立 |
一貫性の維持が可能、分散アーキテクチャに対応 |
新興技術のためエコシステムが発展途上であり、学習コストが高い |
トランザクション処理の多いシステム、金融系サービス |
CockroachDB (例: Bank of Americaの決済システム) |
| NoSQL |
スキーマレスで非構造化データに対応 |
柔軟なスキーマ設計、水平スケールが容易で、大規模データの分散管理に強い |
複雑なクエリが苦手、データの整合性を担保しづらい |
ソーシャルメディア、IoTデータの蓄積 |
Cassandra (例: Facebookのメッセージ送信システム) |
| インメモリデータベース |
データをメモリ上に格納し、高速アクセスを実現 |
圧倒的な高速処理が可能、キャッシュとしても利用可能 |
メモリ障害時にデータ損失のリスクがある |
リアルタイム分析、キャッシュ、セッション管理 |
Redis (例: Twitterのタイムラインキャッシュ)、Memcached (例: YouTubeの動画視聴履歴キャッシュ) |