NoSQLについて

はじめに

NoSQLのデータベースを触る機会がありそうだったので、まとめてみる。
※GoogleのFirebaseのデータベースがNoSQLだったため

NoSQLとは

NoSQLは「Not Only SQL」の略称で、基本的にリレーショナルデータベース（MySQLやOracleDatabaseなど）以外のデータベース全般を指す。

SQLとNoSQLの違い

SQL

SQLを使用しているリレーショナルデータベースは表形式のデータ構造を持ち、関連付けをすることで複雑なデータ管理を可能とする形式となっている。
テーブル1

名前	年齢	所在地コード
Aさん	26	01
Bさん	23	02

テーブル2

ID	地名
01	北海道
02	東京

上記のような形でIDなどのキーでデータを正規化し管理、必要であればテーブル同士を結合して情報を取得できる。

またトランザクションという処理単位で処理を行っているため、最新のデータが常に参照可能となり、データの整合性が保たれる。

NoSQL

リレーショナルデータベースとは違って、表形式の構造を持たず、データの整合性が完全には担保されない代わりに、データの処理速度が高速になっている。
また、構造化データ（ExcelやCSVなどの構造が整形されたデータ）以外も扱え、近年のビッグデータ処理を行うために注目されているらしい。
構造化データ以外とは、画像や動画などのデータを指す。

NoSQLの構造は大きく4種類存在している。

キーバリュー型

一意なキーに対して、値が存在している形式。
値は複数の項目を持つことができ、辞書型の構造に似ている。
値の項目に関しては、キーごとで一致している必要は無い。

キー	値
Aさん	{年齢:26, 所在地:北海道、趣味:ゲーム}
Bさん	{年齢:23, 所在地:東京、好きな食べ物:カレー}

構造がシンプルであるため、高速に処理でき多くのデータを保存するのに適している。
ただし、複雑な検索には適していない。

主なデータベースは、RedisやDynanoDBなど。

カラム指向型

キーバリューの値の部分が1つ以上のカラム（列）になった形式。
見た目はリレーショナルデータベースと似ている。
リレーショナルデータベースと違って、動的にカラムを追加することができ、行ごとに列の数は自由となる。

キー	カラム
Aさん	ここに年齢・所在地・趣味のカラムがあるイメージ
Bさん	ここに年齢・所在地・好きな食べ物のカラムがあるイメージ

キーバリュー型と違って、列単位でのデータの処理を行えるため、検索・集計処理を得意とする。
行単位で列は自由ではあるが、例えば上記だと年齢に絞って検索や集計等が行える。

主なデータベースは、CassandraやBigTableなど。

ドキュメント型

キーに紐づくデータをドキュメント（JSONなど）の形式で管理できる。
複雑なデータの持ち方（階層構造）なども持つことが可能。

ドキュメント形式の複雑なデータをそのまま扱えるのがそのままメリットになる。
Webのやり取りはJSON形式が標準であることが多いため、Webでの取り扱いに適している。

{
  "Aさん": [
    {
      "年齢": "26",
      "趣味": "ゲーム",
      "タスク": {
                  "A" : "明日まで",
                  "B" : "明後日まで",
                  "C" : "1週間後",
		}
    }
  ],
  "Bさん": [
    {
      "年齢": "111.18",
      "好きな食べ物": "109.75"
    }
  ]
}

主なデータベースは、MongoDBなど。

グラフ型

ノード、エッジ、プロパティの3つの要素でデータ同士の関係性を表現している、グラフ理論に基づいた形式。

ノード：Aさん、Bさんの各1まとまりの情報
エッジ：Aさん、Bさんの関係性
プロパティ：Aさん、Bさんの情報（年齢や部署など）

ノード同士が関係性を持つ、経路探索や購入履歴からのリコメンドなどの場合に有用。

主なデータベースは、Neo4jやJanusGraphなど。

使い分け

NoSQLには厳密な整合性が取れないため、正確に情報を管理しなければならない場合（勘定系や在庫管理など）はリレーショナルデータベースでの管理が適切。
逆に大量のデータを素早く捌かなければいけない場合（ビッグデータや時系列データのリアルタイム処理）はNoSQLが適している。