はじめに

普段はフロント技術の勉強をしていますが、NoSQLについて勉強する機会があったので、ノート代わりまとめてみました。
##NoSQLとは？

Not only SQL と解釈されており、
関係データベース管理システム(RDBMS)以外のデータベース管理システムの大まかな分類語。
関係データベース以外の構造のデータベースの利用・発展を促進させようとする運動の標語としての意味合いを持つ。
でも結局明確に定義されてはいないらしい

なぜNoSQLなのか

NoSQL自体は2000年頃から存在していたが、
あまり注目を浴びるものではなかったらしい。
しかし、近年どんどん需要が高まっている現状をNoSQLの背景から読み解いていきたいと思います。

NoSQLの誕生について簡潔にまとめると

1970年～1990年にRDBMSがITシステムへ浸透。ビジネスフィールドへのITシステム導入が急速に進みだしました。
↓
↓
ネット人口が増え、回線も早くなり、
それに伴い、**複雑でない巨大なデータ(ビックデータ)**を扱うことが増えてきました。
↓
↓
増えていくビックデータは既存のRDBMS（リレーショナルデータベース)で扱うにはデータ量が多くなりすぎ、
また、ビッグデータの主なデータは、非構造化データ（テキストや画像など）と半構造化データ（JSONなど）で占められており、集合論を根底に置くRDBMSには不向きなものでした。
↓
↓
従来のRDBMSでは、大量のデータや複雑なデータ形式に対して実用上の不都合があったため、RDBMSの良さを一部犠牲にしてでもその不都合を解決する、NoSQLが誕生しました。

まとめると?

NoSQLという運動は増え続けるデータを永続的に保持し、かつ効率的にアクセスするための手段の探求から考えだされたものであり、ビックデータを扱うことが増えたことで、さらに脚光を浴びるようになった。

##NoSQLの大まかな仕組み
AWSによる説明によると、

NoSQLデータベースでは、ドキュメント、グラフ、キー値、インメモリ、検索などのデータへのアクセスと管理のためにさまざまなデータモデルを使用します。このようなタイプのデータベースは、他のデータベースのデータ一貫性の制限の一部を緩和することで実現している、大容量のデータボリューム、低レイテンシー、柔軟なデータモデルを必要とするアプリケーション向けに最適化されている。

らしいです。
とりあえずは仕組みを簡単に言うと、
他の制約を緩めることでデータの出入りをしやすくしてると言ったような認識で大丈夫だと思います。

##NoSQLの特性
NoSQLデータベースは、RDBMSとは違った特性を持っています。
主な特性は、以下の4つです。

###スキーマレス
RDBMSでは、データを格納する前にスキーマを定義する必要がありますが、NoSQLデータベースではスキーマ定義なしでデータを格納することができます。
twitterなどのWeb APIが返すデータはJSONが一般的で、階層的な構造を持っていることも多く、構造が変更されてしまうこともあります。
このため、RDBMSにスキーマ定義をして格納することは困難です。後述する、NoSQLデータベースの一種であるドキュメントDBであれば、スキーマ定義なしでJSONをそのまま格納することができます。素晴らしい！

###リレーションを持たない
NoSQLデータベースは、速度やスケーラビリティに重点を置いているため、基本的には、**リレーションを持っていません。**これは、リレーションによる結合が、速度やスケーラビリティに悪影響を与えるためです。もちろん、スキーマ設計上でリレーションをもたせることは可能なので、まったくリレーションを持てないわけではありません。しかし、あまりにリレーションが多くなりすぎると性能の悪化をまねいてしまうので、そんな時はRDBMSの方が適切かもしれません……

###トランザクションがない
NoSQLデータベースのほとんどは、トランザクションをサポートしていません。サポートしているDBでも、RDBMSほどの強力ではありません。これは、NoSQLデータベースが**”結果整合性”(一時的には整合性がない状態になるとしても、最終的には整合性が保たれること。)**という考え方を元に設計されているためです。
NoSQLデータベースでは、代わりにアプリケーション側で整合性を維持する必要があります。そのため、ECサイトやお店の予約サイトなど厳密な整合性が必要とされる分野では、RDBMSの方が適しています。

###スケールアウトがしやすい
RDBMSでは性能が問題になることが多いです。チューニングでどうにかなる場合はいいですが、そうでない場合には、DBサーバー自体の増強が必要になってきます。しかし、RDBMSはスケールアウト（水平スケール）が容易ではなく、スケールアップ（垂直スケール）に頼ることになります。スケールアップには、物理的に限界があり、大量のデータを処理するシステムでは性能が頭打ちになってしまいます。

NoSQLデータベースは、スケーラビリティが高く、容易にスケールアウトが可能なように設計されています。このため、大量のデータを分散して処理することができ、ビッグデータを高速に処理することが可能です。また、スケールアウトにより障害耐性を高めることもできます。

###簡単にRDBMSと比べてみると

RDBMS　･･･複雑なデータに向いている。データの肥大化による性能劣化が起きることがある。
NoSQL･･･単純なデータに向いている。データが肥大化しても性能劣化が起こりづらいが、複雑なデータは苦手。

お互い得意なことと不得意なことが明確に分かれてますね。

##NoSQLの様々なデータモデル
前述の通りNoSQLデータベースは、様々なアプリケーションに合わせて最適化されていますが、基本的にデータモデルによって分類できます。
大きく分けて以下の4種類です。

###1.キーバリュー型DB

キーとバリューをペアにして格納する、一番シンプルなデータベースです。プログラミングでいうと、連想配列やディクショナリ型のようなもので、作成／更新時には、キーとバリューと指定し、キーを指定して読み取り／削除を行います。なお、バリューは単一の値だけでなく、リストやセットなどで複数の値を持つことができます。

####適したユースケース
ゲーム、広告技術、IoTなどの、他のタイプのデータベースでは達成できない大規模な水平スケーリングが必要な場合。

###2.ドキュメント型DB

JSONやXMLなどのドキュメントを、そのまま格納することができるデータベースです。RDBMSではスキーマ定義が複雑になりがちなJSONを、シンプルに格納できます。作成時にドキュメント全体を格納し、読み取り／更新／削除をドキュメントの一部もしくは全体に対して行うことができます。ドキュメント型DBのひとつであるMongoDBは世界で最も使われているNoSQLデータベースで、Oracle、MySQL、SQL Serverなどに続き第5位（2019年3月現在）と増加傾向にあリます。

####適したユースケース
カタログ、ユーザープロファイル、コンテンツ管理システムなどの、
各ドキュメント固有のものであり、時間の経過とともに進化するシステムが必要な場合。

###3.カラム型DB（列指向型）

RDBMSはロー（行）単位で処理を行いますが、逆にカラム型DBはカラム（列）単位で処理を行います。行を取り出すのではなく、列を取り出すといった形です。それにより、列単位でまとまった処理があるシステムでは、RDBMSよりも高速に処理できます。

####適したユースケース
情報分析システム、ビッグデータ分析用のミドルウェアなどの、
行単位で集計する処理が多い場合。

###4.グラフ型DB
グラフ理論を元にしたデータベースで、データをグラフ構造で格納します。他のものとは少し違い、一風変わった存在です。FacebookなどのSNSのユーザー同士のつながりなど、ネットワーク状のデータを格納するのに適しています。データ間の関連（リレーション）に重心を置いたデータベースといえます。

####適したユースケース
ソーシャルネットワーキング、推奨エンジン、詐欺検出、知識グラフなどの、
緊密なつながりのあるデータセットを扱うアプリケーションの構築と実行する場合。

##まとめ
NoSQLはRDBMSとお互いを置き換え合う関係ではないため、どちらがいいというものではなく、適材適所で有効に利用していく場面を見極めることが重要です。

##雑談
全く0から勉強しましたが、ここまでたくさんの種類があって、そこから最適なものを選ぶなんて、大変だなぁと思いました(フロントエンド感)。
今回まとめたのはほんの一部なのでより詳しく調べるともっと理解が深まるかもしれません。
今回でNoSQLの雰囲気だけでも掴んで頂けたら幸いです。