エンジニアリングSep 10, 202111 分 READ

SQL データベースと NoSQL の比較と解説

Senior Manager, Marketing Insights and Strategy

アプリケーション開発において、データベースの選択肢は大きく 2 つに分けられます。SQL (Structured Query Language = 構造化照会言語) データベースと NoSQL (Not Only SQL = SQL だけじゃない) データベースです。 SQL データベースはリレーショナルデータベースとも呼ばれ、使われ続けて 40 年以上の歴史を持ちます。その古さにもかかわらず、開発者からの人気は今もなお絶大。 2021 年 9 月時点の DB-Engines データベース管理システム人気ランキングでは、トップ 10 のうち 6 つを SQL (リレーショナル) データベースが占めています。

一方、NoSQL データベース (非リレーショナルデータベース) は、この 10 年間で人気を博し、導入に広がりが見られています。採用率の高い NoSQL データベースである MongoDB は、DB-Engines ランキングでは 5 位と、同ランキングのトップ 10 に含まれる非リレーショナルデータベースの最上位につけています。

さて、SQL と NoSQL は何が違うのでしょう？そして、みなさんが次に開発するアプリケーションで採用すべきデータベースはどちらなのでしょうか？この記事では、両データベースのメリットとデメリットを詳しく解説します。

SQL データベース

SQL はアメリカ規格協会 (ANSI) が定めた言語規格であり、PL/SQL (Oracle で実装) や T-SQL (Microsoft SQL Server で実装) などの派生言語が存在しています。 ANSI 規格に従って SQL を記述するメリットは、SQL データベース間でスクリプトを移植しやすいことです。

一般的な SQL データベースには、Oracle、MySQL、Microsoft SQL Server、PostgreSQL などがあります。それでは、SQL が開発者に選ばれる理由となった特徴をいくつか見てみましょう。

SQL はリレーショナル

よく誤解されがちなのですが、SQL データベースがリレーショナル (関係に基づく) と言われる理由は、外部キーによりデータベース内のレコード間の関係を定義できるからではありません。 “リレーショナル” の名の所以は、数学における関係の考え方に基づいており、独自のタプルが採用されていることにあります。タプルとは、順序づけられた値の集まりです。

SQL データベースでは、関係をテーブルとして表し、関係を構成するタプルがテーブルの行 (通称 “レコード”) になります。つまり、ソフトウェア用に形式化された巨大な Excel スプレッドシートのようなものです。このようなテーブルと行から成る定義は、スキーマと呼ばれます。

リレーショナルデータベースでは、データの保存についての冗長性をなくすことで、データの正規化を行えます (一般に必須とされています)。ストレージが高額だった時代には、データを正規化することでストレージ容量を節約していたのです。

SQL は堅牢

スキーマにはメリットもデメリットもあります。メリットは、アプリケーションで想定されるエンティティと値を常に把握できること。デメリットは、動的なデータを扱いづらいことです。

スキーマを定めると、データのバリデーションが可能になります。たとえば、ID フィールドは一意であることを必須とし、NULL (空値) は許容しない、のように設定できます。外部キー制約を適用して、あるレコードから、そのレコードが含まれるデータベースに存在しないレコードを参照できないようにすることも可能です。

データベースを正規化し、こうしたバリデーションを活用すれば、データの信頼性を確保できます。 SQL には他にもトランザクションなどの独自機能が備わっており、ほぼすべての SQL データベースは高速で、信頼性と堅牢性に優れています。

NoSQLとは？

NoSQL データベースに関するよくある誤解として、”No” はデータベースから SQL を排除する意味合いだと考える人がいます。前述のとおり、”No” は “Not Only = だけじゃない” の略です。実際、SQL が使われている NoSQL データベースもあります。

このような誤解が生まれる原因は、NoSQL データベースの定義が統一されていないことにもあります。事実、NoSQL データベースには、大まかに 4 種のカテゴリが存在しています。

ドキュメントストア
グラフデータベース
キーバリューストア
ワイドカラム型データストア

Cosmos DB のように複数のカテゴリに対応しているデータベースもありますが、互換性のある NoSQL データベースはほぼ存在せず、データベース間の類似性はまずありません。一般的な NoSQL データベースに共通している特徴は、堅牢性をある程度犠牲にしてスピードとスケーラビリティを高めていることです。

ドキュメントストア

ドキュメントストアは、最もポピュラーな NoSQL データベースです。 NoSQL データベースの中では従来の SQL データベースに最も似ていますが、スキーマと正規化はありません。行と列はなく、なんらかのデータをまとめたコレクションを格納するだけです。

エンティティに新しいフィールドを簡単に追加できますが、追加したフィールドが定義されるのは対象のエンティティのみです。同一のエンティティを、異なる値で複数格納することも可能です。そのため、データベースの中身が散らかってしまいがちです。

とは言え、このようなデータベースがさまざまな環境で根強く採用されているのは、SQL データベースに比べてデータを動的に管理しやすく、スケーラビリティも優れているからです。ドキュメントストアは複数のサーバーでの運用に対応したものが一般的ですが、普通の SQL データベースは 1 つのサーバーに紐づけられています。ドキュメントストアにはめんどうなフィールドのバリデーションが存在しないので、驚くほど高速です。

よく採用されているドキュメントストアには、MongoDB、DynamoDB、Couchbase、Firebase、Cosmos DB などがあります。

グラフデータベース

グラフデータベースは、NoSQL データベースの中でも極めて用途が限定されたニッチなタイプです。

このデータベースの一般的なユースケースは、”知り合い候補の紹介” です。つまり、Facebook や LinkedIn などのソーシャル Web サイトのように、友人の知り合いを提示する用途です。

グラフデータベースでは、すべての人物がノードとして表現され、人物間の関係性がエッジとして表現されます。友人の友人を探すには、適当なノードを始点として、エッジを “たどる” だけです。まずは友人へとつながるエッジをたどり、そこから友人の友人へとつながるエッジをたどることになるでしょう。仮に友人が 200 ～ 300 人いて、友人のそれぞれに友人が (多少の重複はあるとして) 200 ～ 300 人いる場合、20,000 ～ 60,000 個のノードを探索することになります。これらのノードにつながるすべてのエッジを調べるだけでも、探索の深度は深くなりかねません。

グラフデータベースで友人の友人をすべてフェッチする場合、ある程度大きなデータセットでも数秒で終わります。 SQL データベースで同じことをしようとすれば、あっという間に行き詰まるでしょう。まず、数百万のユーザーを照合しなければなりません。そして、そのすべてについて、それぞれが関係する数百万のユーザーと照合し、最後には数十億の (重複した) ユーザーをフィルタリングしなければならないからです。

グラフデータベースが必要な場合は、Neo4j、ArangoDB、Cosmos DB などが人気です。

キーバリューストア

NoSQL データベースの中でも最も単純明快なものは、キーバリューストアでしょう。その名前のとおり、キーバリューストアではキーと値のペアを格納します。値は自由であり、数値はもちろん、サブオブジェクトを含む複雑なオブジェクトも格納できます。

応用の幅はあまりありませんが、セッションデータのキャッシュや保存にはキーバリューストアが最適です。

Redis、Memcached、Cosmos DB などが一般的です。

ワイドカラム型データストア

ワイドカラム型データストアは、キーバリューストアにやや似ています。ただし、キーが保持するのは単一の値ではなく、列へのアクセスです。

値には数十億の列を含めることができ、動的に変更可能です。たとえるなら、キーバリューストアの内部にスキーマレス SQL データベース (つまりドキュメントストア) があるようなものです。

ワイドカラム型データストアはスケーラビリティに優れ、ペタバイトにも及ぶデータを格納できます。ユースケースはさまざまであり、時系列データ (複数サーバーの CPU 使用率の時間変化) や財務データマーケティング、モノのインターネット (IoT)、グラフデータなどに使われています。

一般的なものには、Cassandra、HBase、Bigtable、Cosmos DB などがあります。

その他の NoSQL データベース

NoSQL データベースには他にも、フラットファイル指向のものなどがあります。また、SQL の登場以前に存在していたすべてのデータベースは、NoSQL に分類できることも忘れないでください。その筆頭が検索エンジンです。

検索エンジンは、データコンテンツの検索に特化した NoSQL データベースです。一般には、複雑な検索クエリ、全文検索、結果のランクづけおよびグループ分け、スケーラビリティを高める分散検索がサポートされています。代表的な検索エンジンとしては、Elasticsearch や Solr、Splunk などがあります。

ここまで読んできた方なら、Azure で実行されるクラウドデータベースの Cosmos DB が、あらゆるものに対応したデータベースであることに気づいているかもしれません。 Cosmos DB のようなマルチモデルデータベース、つまりデータを複数の方法で格納できるデータベースは各種存在します。 Amazon では、AWS 上で実行されるマルチモデルデータベースの DynamoDB が提供されています。

マルチモデルデータベースにはいくつかの制限があります。たとえば、単一のデータベースに複数のアプローチを適用することはできません。ただし、インスタンスを複数作成すれば、それぞれで異なる手法を利用できます。

NewSQL データベース

ときには、NoSQL しか選択肢がないこともあります。一方で、SQL データベースも進化を続けており、SQL でありながら NoSQL のメリットも備えたデータベースも登場しています。たとえば、Oracle や SQL Server では、動的な JSON を格納できるうえに、これらの値に対してインデックスやクエリフィルターを適用できます。

さらに先へ進んでいるデータベースもあります。その代表格が、クラウドでホストされる分散型 SQL データベースの Snowflake です。これなら、スケーラビリティが低いという SQL の課題を、100% SQL のまま解決できます。こうしたタイプのデータベースは、NewSQL とも呼ばれています。

NewSQL データベースの普及拡大を実感できる例が、Snowflake です。DB-Engine のランキングにおいて、2020 年 9 月から翌年同月までの 1 年間で Snowflake は順位を 107 も上げ、21 位にランクインしました (Cosmos DB と 5 位差)！

他に人気のある NewSQL データベースとしては、CockroachDB や Spark SQL があります。

SQL と NoSQL、どちらを選ぶべき？

データベースにはこれだけの種類があるので、自分に合ったデータベースを選ぶのはむずかしいものです。「仕事に最適なツールを選ぼう」とはよく聞く言葉ですが、最適なツールとは、みなさんのチームが使い慣れているツールのことかもしれません。目的には最善ではあるものの不慣れなデータベースでは、プロジェクトに支障が出かねません。一方、次善ながら使い慣れているツールで事足りるということもありえます。

新しいデータベースを導入することに決めたのなら、SQL、NoSQL、NewSQL のどれであれ、適切に実装を進めるうえで必要なトレーニングやガイダンスをチームに提供することを忘れないでください。

SQL はほとんどのプロジェクトに使えるオールラウンダーなので、たいていはこれがお勧めです。しかし、作業の専門性が高い場合には、NoSQL データベースの方が良いでしょう。たとえば、キャッシュ用途には Redis がよく選ばれています。また、スピードとスケーラビリティに優れたデータベースが必要であり、堅牢性はそこまで気にしないというのであれば、MongoDB の出番です。

新しさだけを追い求めて、最新の流行にとらわれないように注意しましょう。プログラマーというのは新しもの好きですが、現在流行っている製品でも 5 年後にはサポートが終了しているかもしれません。サポートが終了した製品を扱える人員や支援を得るのは困難であり、プロジェクト半ばでデータベースを変えると高くつきがちです。

結局、「次のプロジェクトに使うべきデータベースは？」という質問への答えは 1 つ。「状況による」です。幸いなことに、マイクロサービスのようなモダンアーキテクチャでは、SQL と NoSQL のどちらかしか選べないということはありません。 1 つのアプリケーションランドスケープに両方を共存させられるのです。

まとめ

モダンなソフトウェア開発では、SQL と NoSQL のそれぞれに役割があります。また、どちらにもメリットとデメリットが存在しています。 SQL の要素にも対応した NoSQL データベースがある一方、機能更新により NoSQL のメリットが追加された SQL データベースもあれば、十分に成熟してきた NewSQL もあります。

SQL と NoSQL のどちらにせよ、データベースを選ぶ際には、抱えているニーズと、チームに最も適したデータベースは何かということを忘れないでください。