NoSQL
NoSQLの定義は曖昧
>NoSQLという技術や製品の名称は定着した感がありますが、実はあまり明確な定義がありません。当初はNoRelという言葉も提唱されましたが、これが端的に表すように「RDBとは異なるアーキテクチャやデータモデルに基づくデータベース」という程度の緩い定義です。
目的
RDBの持つ次の問題に対処
パフォーマンス
データモデル
グラフや再帰構造を扱えない
トレードオフ
>「ACID」のスローガンでよく知られるトランザクション管理によるデータ整合性や耐久性、あるいはSQLで実現していた高度なデータ操作、テーブル間の関連を表す機能などを（承知のうえで）犠牲にしています。
種類
KVS: パフォーマンスの問題を解決
データモデルを単純化
スケールアウト可能
例: Redis
データモデルの問題を解決
ドキュメント指向型DB
JSONやXMLをそのまま扱える
最近はRDBもJSON型をサポートしてる
グラフを扱える
大量データを即時レスポンスしたい
scale outできないRDBに対して、（トレードオフを対価にして）できるNoSQL
スケールアウト <-> スケールアップ / レスポンス重視 <-> スループット重視 で見分ける
>リレーショナルデータベースシステム (RDBMS) と NoSQL データベースにはそれぞれ異なる長所と短所があります。
> RDBMS では、データは柔軟にクエリできますが、クエリは比較的コストが高く、トラフィックが多い状況ではスケールがうまくいかない場合があります
> 一方、NoSQL データベース (例: DynamoDB) では、データは限られた数の方法で効率的にクエリできますが、その範囲外では、クエリは高コストで低速になりがちです。
> これらの相違点により、2 つのシステム間でデータベース設計が非常に異なるものになります。
> RDBMS では、実装の詳細やパフォーマンスを気にせずに柔軟に設計できます。クエリの最適化は一般的にスキーマ設計には影響しませんが、正規化は非常に重要です。
> DynamoDB では、最も一般的で重要なクエリをできるだけ速く、安価にするために、具体的にスキーマを設計します。データ構造は、ビジネスユースケースの特定の要件に合わせて調整されています。
NoSQLの位置付け
オンライン&リアルタイム処理