時代の流れとともにニーズが変化しデータソースの機能も進化してきた。しかし、いろいろなタイプのデータベースが存在するのはなぜだろうか。理由はデータの整合性、同時書き込み、大量データの処理、大量のトランザクションのどれかを強化しようとすると何かが犠牲になってしまうからである。コストを掛ければ全てを満すことも不可能ではないようだが今のところ現実的ではない（CAP定理）。
データ量が少ない時代では、RDBが基本で増えてくるとDWHでなんとかなったが、現在では限界がきており分散システムやNoSQLが登場している。
ニーズの特性に合わせて何を優先して何を犠牲にできるかを明確にすることがデータベースを選ぶ上で最重要である。ニーズによって以下のようなデータベースが使われる。
リレーショナルデータベース(例:Oracle)
ニーズ：基幹業務でトランザクション処理を同時に実行したい。
特徴：トランザクション処理の正確さを重視。データ整合性を重視した結果、同時書き込みに限界がある。Oracle RACのようににある程度はDBサーバーをクラスタ化できるがハードウェアの限界にぶつかる。GoogleのCloud SpannerはRDBでありながら、実質上、限界なしにスケールアウト可能なようであるが、Managedサービスでありコストをかけてなんとかした特殊ケース。
下記図ではサーバー2にレプリケートしているが、サーバー2へのレプリケートが完了するまでユーザーは待つことになる。もしレプリケート前にコミットしてしまうと、別のトランザクションがサーバー1、サーバー2の両方を使ってアクセスしたとき、サーバー1とサーバー2でデータに相違があり不整合が発生する。
結局、一般的な基幹システムで要求される”同時書き込みが発生しかつデータ整合性が譲れない”のパターンは選択肢はRDBしかない。
データウェアハウス(例:Tera Data）
ニーズ：基幹システムで蓄積した大量のデータを分析で活用したい。
特徴：大量データ処理の高速化を重視。シーケンシャルIOで大きなブロックサイズで処理することを基本としている。そのため少量データの同時書き込みは非常に弱い。製品によっては、ブロック単位どころかパーティション単位でIOする。そうすることで、データの並び順を維持できるのでシーケンシャルIOをフルに活用できる。
NoSQLデータベース(例:MongoDB)
ニーズ：インターネットの不特定多数のアクセスのような非常に大量の同時書き込みを実現したい。
特徴：データの整合性よりも書き込み性能を優先（結果整合性）。並列度を上げればいくらでも書き込み性能を向上させることができる。掲示板等の同時書き込みが重要な場合に有効。銀行のトランザクションのようなデータ整合性が絶対に譲れない（強整合性）場合は使えない。
上記RDBの場合と異り、レプリケーションの前にコミットを完了するので高速。サーバー1とサーバー2でのデータの相違が許容できない場合は使えない。
分散システム（例:データレイク、Hadoop HDFS）
ニーズ：スマフォやIoTが普及した結果、DWHでも難しいぐらいの大量データを扱う必要性が出て来た。
特徴：データが超大量になるとDWHでも処理しきれない。多くのサーバーにデータを分散させて並列に処理できるようにしている。複数サーバーに分散させた結果、少量データの検索、書き込みともオーバーヘッドが発生し不得意。少量データを大量のトランザクションで扱うような用途には向かない。
下記のように大量データを並列に扱うケースに強い。
下記のようにデータが少量で並列処理が活かせない場合にはメリットがない。
