RDB以外はNoSQL。だから種類も機能も多種多様
システム開発やデータ分析の仕事をしていると一度は目にする「NoSQL」と言うバズワード。直訳するとSQLを使わないデータベースのような感じもします。NoSQLのシステム事例や製品紹介では「速い・安定・高機能」のようなキラキラした言葉を並べる事が良くありますが、本当にそうなのでしょうか？ 今回は各種情報や実際に触ってみた経験などからNoSQLについて最低限抑えてほしいポイントだけご説明します。
※専門的なNoSQL製品の紹介は極力省いています
NoSQLとは
NoSQL専用製品は沢山ありますが、唯一共通する事は「RDB（リレーショナルデータベース）以外である事」だけです。一般的な ORACLE や SQL Server、MySQL などは全てRDBに該当し、行と列を持つ表形式のデータ（テーブル）によって管理されています。NoSQLはこの表形式のテーブル構造の枠に収まらない（収めない）データを扱うデータベース、またはデータ処理エンジンの事を指します。（本稿では纏めてデータベースで説明します）また、NoSQL直訳の「SQLを使わない」というのは間違いで、データ検索・取得の時にSQLに近い命令文で行えるNoSQL製品も存在し、操作の容易さからNoSQLのSQL命令対応化が進んでいます。
この様に完全に言葉の独り歩きを始めたNoSQLの種類分けは様々で、人や企業によって変わってきます。今回はシンプルにキーバリュー型、ドキュメント型、その他（グラフ型など）の3種類に分けて説明します。
キーバリュー型
キーバリュー(Key-Value)型は、「キー（Key）」に対して「値（Value）」が決まるNoSQLデータベースです。例えば社員番号「0010」は社員名「鈴木太郎」のようなデータを格納する場合、社員番号が「キー」、社員名が「値」になります。また、値を複数持てるキーバリューデータベースもあり、「キー」として社員番号、「値」として社員名、性別、部署、役職などを持たせることができ、「値」の数は固定ではありませんので「値」の役職がない状態でも登録できますし、新たに扶養家族数などの「値」も後から追加になってもデータベースのメンテナンスを行わずに登録可能です。
ドキュメント型
ドキュメント型と言っても自然言語のテキスト文章ではなく、JSON形式やXML形式のような階層型のデータを登録、検索するためのデータベースです。JSON形式データでは値の桁数や数、階層後続などのデータフォーマットが変わることが前提であるため、ドキュメントデータベースでも入力されるデータフォーマットが変わっても柔軟に登録、検索などが行えるようになっています。また、10年ほど前に「XMLデータベース」という製品カテゴリがありましたが、現在はドキュメントデータベースに分類されます。
NoSQLの中で最もメジャーなMongoDBはドキュメントデータベースに分類され、JSON形式のままデータインポートし、検索や集計処理など階層構造を意識した独特の命令文を使用したり、プログラムの一部のようにデータの読書きが行えるなど使い勝手が良いのが特徴です。
その他（グラフ型など）
RDB以外のデータベースが全てNoSQLに該当します。そのため、キーバリュー型やドキュメント型の発展型やどれにも該当しないNoSQLが存在し、特定の専門領域に対して威力を発揮します。
その中で最近注目されているのがグラフデータベースです。グラフデータベースは情報（ノード）と関係性（リレーション）が登録されていて、例えば「AさんとBさんが同級生関係 ＋ BさんとCさんも同級生関係 → AさんとCさんも同級生である可能性は高い」という分析に活用できるらしいです。実際にFacebookなどのSNSで使用されているらしいです。（なお、私自身はグラフデータベースの使う機会がなく、あまり詳しい事は説明できません）
NoSQLは「速い・安定・高機能」のか？
NoSQLは速いのか？
NoSQLの速さの理由はシンプルな作りにあります。RDBのようにテーブル間の整合性（関係性が崩れない状態）を保つためにトランザクションを行っていますが、NoSQLにはトランザクション自体がありません。そのため、他のプロセスと同期を取らずに読書きします。また、シンプルな構造であるため複数台のサーバーでクラスタリング（処理分担）が行いやすく、これによって高速に処理が可能な場合があります。
特にキーバリュー型はRDBと比較にならないほど高速であるため、Webアプリなどのユーザーセッション情報などデータ量が多くなく、高速で応答する必要がある一時保存領域として多く使われています。
NoSQLは安定しているのか？
NoSQLといってもデータベースです。ハードウェア障害にも対応できなければRDBと変わりません。その為にはクラスタリングによる冗長化（1台が故障しても他のサーバーでカバーできる）が必要になりますが、キーバリュー型のMemcachedなどは機能としてクラスタ構成がありません。
また、前項でも説明しましたがNoSQLにはトランザクションがありません。1つのデータストアに対して読書きを行う場合は問題ありません。しかし、複数のデータストア対して整合性を保ちながら読書きを行うことはデータベース単独では不可能なため、同時に複数個所からのデータ読書きが発生した場合は整合性が保てなくなる可能性があります。
NoSQLは高機能のか？
「どんなデータフォーマットが来てもデータベースのメンテナンスなしで柔軟に登録・検索が可能です」のような特徴のNoSQL製品はありますが、NoSQLはそこまで万能ではありません。
ドキュメントデータベースは、JSON形式の様々なデータフォーマットが来ても問題なく処理できます。RDBのように表形式の「型」はなく、値の桁数も自由自在です。そのため、データの読書きについてはNoSQLの方が処理速度、自由度の面で有利です。しかし、ドキュメントデータベースの製品の中には、RDBで行うような集計やソート、データソース間の結合に一部対応していない、または不向きな製品もあります。NoSQLは機能特化している製品が多いため、全てのシステム要件を1つの製品で対応できるものではありません。
また、Azure Cosmos DB はキーバリュー型、ドキュメント型、グラフ型の全てに対応していると紹介していますが、Azure Cosmos DB というプラットフォームに MongoDB などの様々なNoSQLエンジンをAPIとして選択可能なだけで、後からドキュメントデータベースからグラフデータベースようなに事は出来ないようです。
RDSに代わるものがNoSQLとは限らない
NoSQLはRDBにはない処理速度、自由度があり、特定の領域ではRDBより優れています。例えば、様々なデータフォーマットの大量データがリアルタイムで入り、高速に応答を返す必要なあるソーシャルゲームではフロント部分のデータベースとしてドキュメントデータベースが良いと思います。しかし、業務システムのように決まったデータを確実に複数のデータストアに登録する場合はRDBの方が優れています。
また、データ分析ではドキュメントデータベースに統一されていないデータフォーマットより、RDBの表形式の方が人間が理解しやすい場合があります。そのため、弊社ではドキュメントデータベースをデータウェアハウスとして扱い、その中から必要なデータをETL処理によってビッグデータ用のRDBに登録し、データ分析の深掘りをするような事を行っています。
