【NoSQL】概要（ビッグデータ、活用事例、本番運用時の注意）

NoSQL(Not only SQL)とは？

大量にある多様な非構造化データを高速に処理するための言語です。

「Not only SQL」の略で、SQL以外でもデータを扱えることを強調しています。

近年の動向

データ量が増加している

たくさんユーザーがいるWebサービスであれば、数十テラバイトのデータがやり取りされることは珍しくないです。

ビッグデータ

モバイル端末が普及して様々な情報が扱えるようになりました。

Twitterなどでは10TBを超えるデータが1日でやりとりされているようです。現代の需要としては、大量で多様なデータを高速に処理する需要があります。

予め構造を決めておいてそれに合わせて管理されるRDBMSの構造化データではなく、非構造化データになりデータの形式や内容に決まりを設けずに管理されるデータでインターネットなどを利用して集められるデータで、画像、動画、音声などを含みます。

Volume

データ量の多さ

Variety

データ形式の多様さ（数値、文字、画像、音声、動画など）

Velocity

データ処理の速さ。リアルタイムで分析するには速度も求められます。

処理速度が増加している

インターネットの高速化や、スマホの普及により高速化された。結果として秒間に何万ものアクセスがあるサイトも珍しくはないです。

多様性が増加している

ソーシャルメディアのデータや、マルチメディアなバイナリデータや、XML、JSONなど。

RDBMSとの比較

RDBMS	NoSQL
ストレージに最適化	計算リソースに最適化
正規化/リレーショナル	非正規化/階層構造
SQLを使用	各データベースにより異なるクエリ方法
トランザクション処理	トランザクション処理は限定的
データの堅牢性/一貫性	データの堅牢性/一貫性はDBによる
スケールアウトの乱雑さ	高いスケーラビリティ

NoSQLの種類

キーバリュー型

データをデータを識別する鍵（キー）と、それに対応する値（バリュー）で扱う非常にシンプルなタイプのデータベース。

OSSでいえば「Redis」、「Memcache」、AWSのサービスで言えば「ElasticCache」、「DynamoDB」が該当します。

カラム指向型

RDBが行単位でデータを扱うのに対して、カラム指向型はデータを1列（カラム）単位で扱う。

行の追加や削除などの処理は苦手ですが、列で考える集計処理などは得意。

OSSでいえば「HBase」、AWSのサービスで言えば「RedShift」が該当します。

ドキュメント指向型

XMLやJSONなどのように半構造化されたドキュメント形式のデータを扱うデータベース。

XMLやJSONなどを扱うアプリはそのままデータを格納できる。

OSSでいえば「MongoDB」、AWSのサービスで言えば「DocumentDB」が該当します。

グラフ型(グラフDB)

ノード、エッジ、プロパティから構成されるグラフ構造でデータを格納するデータベースです。

Facebookの友達関係の追加、削除などネットワークを扱うアプリで使うと便利。

OSSでいえば「Neo4j」、AWSのサービスで言えば「Neptune」が該当します。

特徴

スケールアウトできないが、RDB以上に複雑なデータ処理が可能

歴史的背景

KVSやドキュメントDBとは全く違った歴史を歩んできたデータベース。ビッグデータ処理は苦手としているが、単純にRDBではないためNoSQLの一種とカテゴライズされている。

グラフとは？

棒グラフなどのことではなく、「ノード」と「ノード間関連」からなるデータ構造のこと。

例

SNSにおける人物間の関連のこと。人物がノードで、人物間の関係（友達、フォロー関係、交際関係など）が関連です。

これをRDBでやろうとすると・・・。

「友達の友達の友達」というように結合を多用することになり低速になってしまう。（本当か？？）

グラフDBを使えば、そのグラフ構造をそのままデータモデルとして使えてクエリも直感的に記述することが可能です。

KVS

キーバリューデータベース

例えば

hostname="ap1"というキーバリューがある場合にこれをRDBに格納しようとしたら値の型ごとに表を用意しなければならない。

NoSQLのメリット

多様で大量の非構造化データを高速に処理することができる。

安価なサーバーを並列につなげてパフォーマンスを向上させることができる。（スケールアウト）RDBの場合は、サーバーの数を増やすとデータの整合性をとることが難しくなるので、パフォーマンスを上げたい場合は、サーバーの数を増やすのではなく性能を上げる必要があります。（スケールアップ）

NoSQLのデメリット

ACID特性(要はトランザクションとかで行うデータ間の整合性など)を維持する機能が弱いこと。

活用事例

RDBの値をKVSに保持する。

RDBの値をそのままセット

メリット

• RDB→KVSへのキャッシュ処理をシンプルに実装できる。
• 値をRDBから取得しても、KVSから取得しても同じように扱うことができる。
• データ更新時のRDB→KVSへのキャッシュを簡単に行うことができる。

デメリット

• データの持ち方によってはKVSへのアクセス回数が増える。
• データの加工が必要な場合、取得した後に操作が必要になる。
• 「そのまま」データを持つのでサイズが大きくなってしまう場合がある。

RDBの結果を加工してセット

メリット

• データ取得後にそのまま活用できる。
• 負荷がかかるデータ加工、操作の回数を減らせる。
• 必要なデータを選択することでサイズを減らすことができる。

デメリット

• プログラム側でのデータ操作・加工が必要になる。
• RDBのデータ変更がされた場合、KVSへのキャッシュが複雑になる。

レコードの統計情報をセット

メリット

• RDBやプログラムで統計処理の回数を減らせる。
• RDBで統計情報を冗長的に持たなくて良くなる。
• 時間のかかる統計処理の結果を活用することができる。（統計に時間がかかると、リアルタイム活用が困難になる。）

デメリット

• プログラム側でデータ集計処理の実装が必要になる。
• データが変更された時、再集計が必要になる。
• 実データと集計データに差が出ない工夫が必要になる。

本番運用時の注意

データのバリデーションがないので何でも入れられる点

数字を入れないといけないところで、文字列を入れられてしまう。アプリケーションを動かした際に初めて間違いに気づく。

また、人為的な打ち間違いなどにも気付けない。（NoSQLを本番運用している案件の障害の一定数はコマンドの打ち間違いによるもの）

対策

アプリケーション側でスキーマのバリデーションをするラッパーを利用する。

昨今では様々なNoSQLが対応し始めている。

MongoDBや、Azureの DocumentDBはバリデーション機能を提供していますし、Cassandraはバージョン0.8からスキーマの定義を必須としている。