はじめてのNoSQL

NoSQLとは

NoSQLは一般に(Not only SQL)と呼ばれ、NoSQLについて簡単に分類をするのならば、その名が指すようにPostgreSQLやMySQLなどのRDBではないものであると言われています。
NoSQLが生まれた背景として、ビックデータの存在があります。
ビックデータとは、一般的なデータ管理・処理ソフトウエアで扱うことが困難なほど巨大で複雑なデータの集合を表す用語です。
例えば、Twitterは一日あたり10テラバイトものデータを扱っていると言われています。
このようなデータは従来のRDBで扱いきれるデータ量ではなかったので、NoSQLという技術が生まれました。

NoSQLの特徴

RDBとNoSQLはどの点が違うのかはよく比較される話題です。
NoSQLの特徴について、その点を踏まえて上げていきます。

1.スキーマレス

RDBでは、データを格納する前にかならずスキーマを定義する必要があります。
一方で、NoSQLではレコードは通常JSONとして保存されており、スキーマ定義なしでデータを格納することができます。
そのため、階層的な構造を持っていたり、構造が変更されることもしばしばあります。
しかし、すべてのNoSQLが完全にスキーマを持たないということではありません。
スキーマ定義が必須になっていたり、オプションになっていたりします。
例えば、Firebase Databaseはデータベースにデータを挿入する際にデータ構造を検証するルールを定義します。

2.リレーションを持たない

その名の通り、NoSQLはRDBのようなリレーションを持ちません。
これは、リレーションによる結合が、パフォーマンスやスケーラビリティの面で悪影響を及ぼすからです。
では、結合を持たないNoSQLはどのようにデータを格納しているのでしょうか。
基本的な考え方は

3.トランザクションがない

ご存知の通り、RDBはACID特性を持ちます。ACID特性の詳細は以下の通りです。(https://aws.amazon.com/jp/nosql/)

アトミック性によって、トランザクションは必ず、完全に実行されるか、まったく実行されないかのいずれかになります。
一貫性は、いったんトランザクションが実行されたら、データが必ずデータベーススキーマに従うことを指します。
分離性は、同時発生したトランザクションが相互に独立して実行されることを指します。
耐久性は、予期しないシステム障害や停電が発生しても、異常発生前の最後の状態まで復旧できることを指します

NoSQL データベースでは、多くの場合、リレーショナルデータベースの ACID 特性の一部を緩和することと引き換えに、水平方向に拡張できるもっと柔軟なデータモデルを実現しています。
つまり、データの整合性よりも大量のデータを素早く処理することを優先しているのです。
ここで、NoSQLの特徴としてとして、結果整合性でよいという考えがあります。
これは、一時的に整合性がない状態になったとしても、最終的には整合性がたもれ保たれる状態のことです。

4.スケールアップしやすい

リレーショナルデータベースでは通常、ハードウェアの演算機能を増強してスケールアップするか、読み取り専用ワークロードのレプリカを追加してスケールアウトします。
つまり、垂直方向にスケールアップをする必要があり、物理的な限界があります。
NoSQLでは、水平方向のスケールアップができるように設計されており、ほぼ無限の規模でスループットを高め、一貫したパフォーマンスを維持することができます。

NoSQLのデータモデル

NoSQLには様々なデータモデルが存在します。

1.キーバリュー型

KVSと呼ばれるものです。その名の通り、キーとバリューをもつシンプルなデータモデルです。
高度なパーティション化に対応しており、データモデルが単純なので、スケールアウトしやすいという特徴を持ちます。
Redis, Riakなどがあります。

2.カラム指向型

これはRDBのように表を持ちますが、RDBは行単位で処理を行うのに対して、カラム指向型のNoSQLは列単位で処理をします。
行ごとに好きな名前のカラムを好きな数だけ格納できるところが特徴で、例えばRDBではnullで表現していたところは、そもそもカラムをもつ必要がありません。
また、ほかの行には存在しないカラムをもつことも可能です。
Cassandra、HBaseなどがあります。

3.ドキュメント指向型

オブジェクトまたは JSON のようなドキュメントとしてデータが表現されます。
アプリケーションコードで使用しているオブジェクトをそのままデータベースに保存することができます。
スキーマレスで格納ができます。
MongoDB、CouchDBなどがあります。

4.グラフ型

データをグラフ型で保持し、緊密なつながりのあるアプリケーションを扱います。
例えば、Facebookなどのユーザー同士のつながりや、推奨エンジン、詐欺検出、知識グラフなどです。
Neo4j、Giraphなどがあります。

CAP定理

分散型データベースシステムの三大要件として、整合性(Consistency) 、可用性(Availability)、分断耐性(Partition Tolerance)が挙げられます。

分断耐性とは、複数のノードからなる分散型システムのネットワークが分断されたとしても、間違った結果を引き起こさないという特性です。
間違った結果とは、データの不整合で例えば一つのサーバでデータが破損したとしても別のサーバから正しいデータを取得できることを意味します。

これらの頭文字をとってCAP定理と呼ばれています。
これは、分散システムにおいては「3つのうち最大2つしか満たすことができない」という定理です。
この3つの要素どれを重視するかによって、データベースのシステムの特徴が変わってきます。
基本的には、NoSQLはCP(整合性と分断耐性)またはAPに(可用性と分断耐性)に分類されます。

CA

可用性と整合性を重視したCAに分類されるものは、MySQLやPosgresなど従来のRDBに相当します。
この分類はACID特性を満たすものとなります。

CP

整合性と分断耐性を重視したCPに分類されるものにMangoDBやHBaseなどが相当します。
ネットワークが分断された場合には、1つのグループのみでユーザーのリクエストを受理し、残りのグループでは参照も更新もできないようにデータベース全体にロックをかけます。

AP

可用性と分断耐性う重視したAPに分類されるものは、DynamoはCasssandraなどがあります。
ネットワークが分断が生じた場合にも、すべてのノードがリクエストを受理しつづけます。
その結果、整合性が失われることもありますが、それを犠牲にする代わりに可用性を保っています。

まとめ

ビックデータの需要の高まりとともに、NoSQLの特性がマッチして注目を集めているということがわかりました。
また、NoSQLは従来のRDBに取って代わるものではなく、それぞれの特性に応じた使い方がされるべきです。

参考
https://aws.amazon.com/jp/nosql/
https://tracpath.com/works/development/nosql_overview/
https://tech-blog.rakus.co.jp/entry/20180919/nosql/bigdata
https://www.atmarkit.co.jp/ait/articles/1703/01/news204_2.html
https://qiita.com/t_nakayama0714/items/0ff7644666f0122cfba1
https://ja.wikipedia.org/wiki/NoSQL
https://www.youtube.com/watch?v=ZS_kXvOeQ5Y
https://www.youtube.com/watch?v=WacqhiI-g_o&index=8&list=PLl-K7zZEsYLlP-k-RKFa7RyNPa9_wCH2s