NoSQLとは|RDBとの違いを易しく解説

データベースには、いくつものアーキテクチャがあり、現在はNoSQLが注目されています。「Not Only SQL」と呼ばれる方式であり、一般的に利用されているリレーショナルデータベース(RDS)とは異なった考え方です。
一般的には、RDSが多用されることから、NoSQLの理解は進んでいません。ただ、状況によってはRDSよりもNoSQLが適していることもあります。今回は、これらのデータベースが、どのようなものであるのかそれぞれ解説します。
NoSQLとは

最初に、今回の説明対象であるNoSQLとはどのような技術であるのか、理解を深めておきましょう。
NoSQLの概要
「NoSQL」という種類のデータベースがあると思われがちですが、この理解は誤っています。実際には、RDBに該当しないデータベースすべてが「NoSQL」です。具体的な製品名でもないため、総称であることを最初に理解しなければなりません。
今まで、データベースを利用するといえば「RDB」が活用されてきました。データベースの代名詞であると表現しても、過言ではない程度に活用されています。皆さんの認識も同じではないでしょうか。
しかし、技術の変化に伴って、RDBでは対応できない場面が増えてきています。決して、RDBが悪いものではありませんが、当初は想定されていなかった使われ方が増えているのです。そのため、新しく生じた課題を解決するための手段として、NoSQLが利用されています。
なお、NoSQLとは「Not Only SQL」を省略した表現であり「No SQL」ではありません。SQLを利用しなくとも操作できるデータベースであるとイメージしておくと、理解しやすいでしょう。
RDBとの違い
NoSQLでは、RDBと違って結合(JOIN)などの考え方はサポートされていません。対応しているデータベースも存在しますが、必須の機能ではないと理解しておきましょう。この点で、NoSQLとRDBには大きな違いがあります。RDBでは当たり前に処理できる内容でも、NoSQLでは処理できないことがあるのです。
また、排他処理の制御はRDBほど厳しくなく、整合性に問題が生じてしまうことがあります。RDBは処理速度よりも整合性を重視していますが、NoSQLの大半はそうではありません。この違いが実装の違いにもつながるため、正しい理解が必要です。
NoSQLが注目される背景
NoSQLは、近年になって大きく注目されるようになりました。その理由について、2つの観点から解説します。
高速な処理
NoSQLが注目される理由として、高速な処理を実現できることが挙げられます。また、RDBの処理速度が遅いことも理解していると良いでしょう。特に、RDBは大量のデータを保存している場合に、性能が劣化してしまうという特徴があります。
近年は、ビッグデータの活用など、大量のデータを処理することが増えてきました。ただ、上記の通りRDBでは、処理速度がネックとなりこれを活用できないのです。また、どうしても活用する場合には、時間をかけて処理するしかありませんでした。
しかし、NoSQLのように高速なデータベースを利用すれば、このような問題が生じません。ビッグデータをはじめとした、大量のデータを効率よく処理できるのです。「ビッグデータ分析」などのトレンドが生まれたことで、NoSQLが今まで以上に注目されるようになりました。
拡張・分散
NoSQLは、システムの拡張や分散に優れています。近年は可用性の高いシステムが求められているため、これに応えるためにはNoSQLが適しているのです。
現在多用されているRDBのシステムは、基本的に1台のデータベースで処理する前提で考えられています。複数のサーバで処理することもできますが、これは拡張機能なのです。1台で処理する前提であることから、RDBでは性能面で限界を迎えてしまいます。
そこで、データベースを容易に拡張できるNoSQLが注目されるようになりました。大量のデータを処理したいならば、サーバを増やすなど「スケールアウト」すれば良いのです。RDBでは簡単にシステムの拡張や分散を実現できませんが、NoSQLは容易に実現できるため、急速に注目されています。
NoSQLの種類
NoSQLは総称であり、細分化すると4種類に分かれます。それぞれ、どのようなデータベースであるのか理解しておきましょう。
キーバリュー型
キーバリュー型は、データを識別する「キー」と、キーに紐づく「バリュー」から構成されるデータベースです。一意のキーによって、バリューが特定できるようになっていれば、バリューの内容が異なっても差し支えありません。例えば以下のとおりです。

キーバリュー型は、NoSQLの中でも非常にシンプルな構造であることが特徴です。そのため、他のデータベースと比較しても、より高速な処理を実現できます。スピード重視であれば、キーバリュー型が適していると考えましょう。
ただ、シンプルな構造であるが故に、複雑な検索を必要とする処理には適していません。簡単な構造のデータベースで、とにかく処理スピードを重視する場合に利用すると考えましょう。
カラム指向型
カラム指向型は、キーバリュー型に「カラム」を追加したデータベースです。キーに対して、任意のカラムを追加することで、効率よくデータを管理できます。複数のカラムを用意した場合、すべてのカラムにデータが格納されている必要はありません。柔軟にデータを保存できることが特徴です。キーバリュー型のデータを参考にすると以下のとおりです。

カラムのすべてに値が入力されている必要はありません。未入力の情報があっても、正しく処理が可能です。
ドキュメント型
ドキュメント型は、その名のとおりドキュメント形式でデータを管理できるデータベースです。JSONやXMLなどのドキュメント形式に対応していて、参照するドキュメントごとに異なる形式を採用することも可能です。
ドキュメント形式のデータベースならば「ドキュメント」をそのまま扱えます。例えば、見出しや改行の多いドキュメントファイルでも、ドキュメント型では差し支えないのです。
なお、ドキュメント型のデータベースとしてはMongoDBが世界的に利用されています。可用性やスケーラビリティに優れていて、ドキュメント型を検討する際に候補に入れてもらいたいデータベースです。
グラフ型
グラフ型は、データ同士の関連性を重視したデータベースです。一般的にグラフといえば、資料などで提示される図形を思い浮かべますが、データベースでのグラフとは「グラフ理論」を指します。
グラフ理論には3つの要素があり「ノード」「エッジ」「プロパティ」と呼ばれます。グラフ型データベースでは、これらの様子を活用して、データの関連性を表現するのです。その点では、RDBに近い考え方があると理解して良いでしょう。ただ、結合するという考えはなく、事前に定められた関連性でのみ表現できます。
グラフ型のデータベースは、検索速度が早いことが特徴です。Neo4jやInfiniteGraphなどのデータベースがこれに該当し、高速な処理が必要な場面で活用されています。
NoSQLが適した3つのケース

データの内容によって、NoSQLが適しているかRDBが適しているかは変化します。以下では、NoSQLが適しているケースを紹介します。
非構造化・半構造化データの採用
保存するデータが、非構造化や半構造化ならば、NoSQLがおすすめです。構造化データとは、CSVやExcelなどの「構造」が明確なデータであり、非構造化や半構造化はそれら以外のデータを指します。
RDBでは、その特徴から非構造化や半構造化の情報は扱いにくくなっています。絶対に扱えないわけではありませんが、適していないと考えましょう。それに対して、NoSQLならばこれらのデータも簡単に処理が可能です。
このようなデータにも対応できる理由は、NoSQLが表形式のデータベースではないからです。RDBは表形式であるため、格納できるデータに制限が生じますが、NoSQLにはこれが生じません。
拡張性を重視
システムの拡張性を重視するならば、NoSQLが適しています。サーバー台数を増やしたい場合など、どのような拡張にも対応できることが特徴です。スモールスタートで、徐々にスケールアップしていくこともできます。
先ほど解説したとおり、RDBは1台のサーバで処理することが前提です。そのため、後になってから拡張したり負荷分散したりしようとしても、スムーズに実現できない可能性があります。特に複数のサーバに分散することは、RDBの苦手分野だと考えておきましょう。
RDBの欠点を踏まえ、拡張性を意識するならば、NoSQLがおすすめです。システムの将来性などを踏まえて、検討することが求められます。
スピードを最優先
データの処理スピードが最重要ならば、NoSQLを選択した方が良いでしょう。RDBと比較して、非常に高速なデータベースであるため、データベースがボトルネックになる可能性を下げられます。
例えば、ビッグデータ解析など処理スピードが重要ならば、RDBよりNoSQLが適しています。データ量が多いと、1トランザクションあたりの処理時間の差が積み重なってしまい、大きな差になってしまうからです。
処理速度をどの程度重視するかは、状況によって大きく異なります。他の要素と比較して、最終的な判断を下さなければなりません。
NoSQLとRDBは使い分けが必要
今回は、NoSQLの概要やメリットを解説しました。その結果「RDBを利用するよりもNoSQLを利用した方が良いのではないか」と考える人がいるかもしれません。ただ、実際には臨機応変に使い分けが必要であるため、その点についても解説します。
複雑なデータ構造には不適
NoSQLは、RDBのように明確なカラム構造を持つ仕組みではありません。そのため、複雑なデータ構造は、扱いにくいというデメリットがあります。データ同士の結合が必要になるなど、複雑な構造を実現するためには、RDBがおすすめです。
もちろん、NoSQLでも似たようなデータ構造を実現することは可能です。自由度の高いデータベースであるため、カラムを駆使してデータを登録すれば、不可能な構造ではありません。ただ、NoSQLの良さを失ってしまうため、複雑なデータ構造を扱うのは積極的におすすめできる使い方ではないのです。
NoSQLの特徴を理解する
どのようなシステムでも「とにかくNoSQLを採用しておけば問題ない」ということはありえません。システムの設計は、難しい部分が多くありますが、データベースについての詳細な理解が必要です。
また、どちらのデータベースが良いとも言い切れないことがあるでしょう。このような状況においては、双方のメリットやデメリットを比較して、最終的な判断を下す必要があります。偏った考え方だけで、どちらのデータベースが良いと決めつけてはなりません。
なお、データベースは非常に複雑であり、専門的な知識が必要とされるものです。そのため、可能な限りデータベースエンジニアを交えて、システムを設計しましょう。
まとめ
データベースのくくりであるNoSQLとは何かについて解説しました。RDB以外のデータベースをNoSQLと呼ぶため、まずはこれを正しく理解しましょう。NoSQLという名称のデータベースが存在するわけではありません。
どちらも同じデータベースではありますが、その特徴には大きな違いがあります。用途にも違いがあるため、正しく理解してシステムの実装へ活かさなければなりません。誤って選択すると、システムの挙動などに悪影響を与える可能性が高まります。