SQL 対 NoSQL : 長所と短所

データの保存、保護、アクセスに最適な方法は何か。これは、基本的かつ重要な意思決定です。結局のところ、データは現代のあらゆる組織が成功するために不可欠なのです。多くの企業では、SQLまたはNoSQLのいずれかのデータベースを選択することになります。それぞれが独自の長所と短所を持っています。

SQLデータベースは、1970年代から実績があります。SQLデータベースは、行と列からなる高度に構造化されたテーブルで構成されており、共通の属性によって互いに関連付けられます。すべての列は、対応する行に対応する値を持つことが要求されます。NoSQL (Not Only SQLまたはNon-SQL) データベースは、構造化されたデータと非構造化データのどちらも、あらゆるデータタイプを一緒に保存しアクセスすることができ、リレーショナルデータベースの限界をなくすために後から登場しました。このデータベースは優れた柔軟性により、開発者が仕事をするのが簡単です。SQLとNoSQLのデータベースの基本的な違いについて、詳しくはこちらをご覧ください。

最適な選択は？クエリ、可用性、コンプライアンスなどのニーズや、さまざまなデータタイプ、予想される成長など、さまざまな要因によって異なります。

SQLとNoSQLの比較表

正しい選択をするために、SQLとNoSQLの長所と短所を詳しく見ていきましょう。

SQLの長所

標準化されたスキーマ

SQLデータベースの標準化されたスキーマは、硬直的で変更がしにくくなりますが、いくつかの利点もあります。データベースに追加されるすべてのデータは、行と列で構成されるリンクされたテーブルの既知のスキーマに準拠する必要があります。これを制限を「限定的」と感じる人もいるかもしれませんが、データの一貫性、整合性、セキュリティ、コンプライアンスを重要視される場合に役立ちます。

大規模なユーザーコミュニティ

SQLプログラミング言語は50年近い歴史を持ち、成熟し、今でも広く使われています。SQLには強力なコミュニティがあり、数えきれないほど多くのエキスパートが、さまざまなヒントや確立されたベストプラクティスを共有しています。スキルを磨き、そして協力しあう機会もたくさんあります。必要に応じてコンサルタントやSQLベンダーが追加のサポートを提供することも可能です。SQLを使用することで、開発者は必要な答えを見つけることができるのです。

コード不要

SQLはユーザーフレンドリーな言語です。データベースの管理やクエリは、コーディングはほとんどまたはまったく必要とせず、シンプルなキーワードを使用して行えます。海外では、多くの開発者が、大学でSQLを教わっています。

ACID要件を満たす

リレーショナルデータベースのテーブルは構造化されているため、SQLデータベースはACID要件を満たすことができます。この準拠レベルは、テーブルの同期を維持し、トランザクションの有効性を保証します。エラーの許されないアプリケーションを実行し、最高レベルのデータ整合性を必要とする場合に、SQLは正しい選択であると言えるでしょう。

ACID特性は以下のとおりです。

• アトミック性 (Atomicity) : データとトランザクションの全ての変更はシングルオペレーションとして完全に実行されます。それが不可能な場合には、どの変更も全く実行されません。つまり完全に実行されるか全く実行されないかのいずれかになります。
• 一貫性 (Consistency) : トランザクションの開始時と終了時で、データは有効で一貫性 (整合性) が保たれていなければなりません。
• 分離性 (Isolation) : 同時発生したトランザクションが互いに競合することなく実行されます。言い換えると、連続して発生しているかのように実行されます。
• 耐久性 (Durability) : 一旦トランザクションが完了すると、その関連データが失われることも変更されることもありません。

SQLの短所

ハードウェア

SQLデータベースは垂直方向にスケールアップするのが一般的で、既存のサーバーのRAM、CPU、SSDなどを機能拡張するか、より大規模で高価なサーバーに移行する必要があります。データの増加に伴い、ハードディスクの容量を継続的に増やす必要があり、進化する高度なテクノロジーを実行するためには、より高速なマシンが必要になります。使用するデータベースベンダーは、その最新リリースを実行するためだけに定期的にハードウェアのレベルアップを要求する可能性があります。このような環境では、ハードウェアはすぐに時代遅れになります。アップグレードのたびに、コストとリソースを消費することは確実です。SQLのハードウェア要件には、継続的で日常的なメンテナンスと運用コストも含まれています。これは、終わりのない追いかけっこのようなものです。

データの正規化 (分解)

データのストレージコストが高かった時代に開発されたリレーショナル・データベースは、データの重複を排除しようとします。各テーブルは異なる情報があり、共通の値を使って接続しクエリを実行できます。ただしSQLデータベースが大きくなると、多数のテーブル間でルックアップと結合が必要になり、処理速度が低下する可能性があります。

硬直性 (Rigidity)

SQLデータベースのスキーマは、使用前に定義する必要があります。一度定義すると柔軟性に欠け、変更も通常は困難で、そしてリソースも多く必要とします。そのため、データベースが本番稼動する前に、事前のプランニングにかなりの時間を費やす必要があります。したがって、すべてのデータが構造化されていてボリュームやデータタイプのいずれかに大きな変更がない場合にのみ適しているといえます。

リソースインテンシブなスケーリング

前述したように、SQLデータベースは通常ハードウェアへの投資を拡大することで垂直方向にスケーリングします。これには費用と時間がかかります。場合によっては組織がパーティショニングによって、SQLデータベースを水平方向にスケーリングしようとすることもあります。このように複雑さが増すと、費やされる時間やリソースが増加します。この作業にはコーディングが含まれる可能性が高く、高度なスキルと高給の開発者が必要になります。データ量が増えるにつれ、SQLデータベースのスケーリングは完璧な設定が常に手の届かないところにあり、これでは終わりのない鬼ごっこをしているようなものです。一方、NoSQLデータベースは水平方向にスケールアウトし、このことが容量の拡張をより簡単に、そしてコスト効率に優れたものにしています。これらは、クラウドコンピューティングや、非常に大規模で急速に増大するデータセットの処理に適しています。

NoSQLの長所

継続的な可用性 :

NoSQLでは、データは複数のサーバーや地域に分散されるため、単一障害点が存在しません。その結果、NoSQLデータベースは安定性と回復力に優れ、継続的な可用性とダウンタイムをゼロにすることができます。

クエリ速度

NoSQLデータベースは非正規化されており、データ重複の心配がないため、特定のクエリに必要なすべての情報がすでに一緒に格納されていることが多くJOIN(結合)を必要としません。このため特に大量のデータを扱う場合には、ルックアップが容易になります。単純なクエリであれば、NoSQLは超高速な処理が可能です。間違いなく、SQLデータベースも超高速にクエリを返すことができます。また、構造化データに対する複雑なクエリもサポートします。ただしSQLデータベースが拡大し複雑なJOIN要件が増加するにつれ、クエリ速度は低下する可能性があります。

機敏で柔軟 (Agility)

NoSQLデータベースが開発されたのは、データストレージのコストが劇的に下がり始め、開発者のコストが上昇し始めた頃でした。データの重複は、もはや懸念事項ではありませんでした。その代わりに、開発者にできるだけ多くの柔軟性を与え、創造性と生産性を高めるためにNoSQLが設計されました。行や列の制約を受けないNoSQLデータベーススキーマは、あらかじめ定義されている必要はありません。構造化、半構造化、非構造化、ポリモーフィックなど、あらゆるタイプのデータを扱うことができる動的なものです。NoSQLデータベースはその構造定義に時間をかけることなく起動でき、ダウンタイムなしで、その場で簡単にデータ型やフィールドを追加することができます。これらすべてのことが、NoSQLを現代のアジャイル開発チームに最適なものにしています。開発者は、事前の計画に時間と労力を費やすことなく、すぐにデータベースの構築を開始することができます。要件が変わり、新しいデータ型が追加されても、すぐに修正を加えることができます。NoSQLデータベースの柔軟性と適応性は、さまざまなデータタイプを持ち、継続的に新しい機能を追加していきたい組織に最適です。

NoSQLデータベースは、万能ではありません。SQLデータベースとは異なり、NoSQLデータベースは、単一のサーバーに格納されるような硬直した集中型のデータモデルに制約を受けることはありません。代わりに、NoSQL には、多くのサーバーに分散できる異種のデータベースモデルのタイプを接続できる柔軟性があります。NoSQLにはいくつかのデータベースタイプがあり、開発者はデータやユースケースに最適な組み合わせを見つけることができます。NoSQLデータベースの主なタイプは キー／バリュー、ドキュメント、表形式（またはワイドカラム）、グラフ、マルチモデルです。

低コスト

NoSQLデータベースは水平方向にスケールアウトするため、コスト効率よく容量を拡張することができます。高価なハードウェアをアップグレードするのではなく、一般的なサーバーやクラウドインスタンスを追加するだけで、安価に拡張することができます。また、オープンソースのNoSQLデータベースは、多くの企業にとって手頃な価格の選択肢となります。クラウドコンピューティングや、非常に大規模で急速に増大するデータセットの処理に適しています。

NoSQLの短所

標準化された言語がない：

NoSQLのクエリを行うための標準言語はありません。データ照会に使用する構文は、NoSQLデータベースのタイプによって異なります。習得しやすい言語が１つだけのSQLとは異なり、NoSQLは学習曲線が急峻です。例えば、グラフデータベースの構築と管理しか経験のない開発者が、ワイドカラムデータベースに即座に対応するのは難しいかもしれません。

小規模なユーザーコミュニティ

開発者は10年以上前からNoSQLデータベースを使用しており、コミュニティは急速に成長しています。しかし、SQLのコミュニティほど成熟はしていません。そのためドキュメント化されていない問題を解決するのは、より困難になる可能性があります。NoSQL側のコンサルタントや専門家の数も多くはありません。

複雑なクエリによる非効率性

柔軟性には代償がつきものです。NoSQLデータベースにはさまざまなデータ構造が存在するため、クエリ実行は効率的ではありません。SQLデータベースとは異なり、複雑なクエリを実行するための標準的なインターフェイスは存在しません。単純なNoSQLクエリであっても、プログラミングの経験が必要になる可能性があります。つまり、開発者やデータサイエンティストのような、より技術的でコストのかかるスタッフがクエリを実行する必要があることを意味しています。

データ取り出しの不整合

NoSQLデータベースは分散型であることから、データをより早く利用することができます。しかし常に一貫性のあるデータを確保することが難しい場合もあります。クエリが常に更新されたデータを返すとは限らず、不正確な情報を受け取る可能性があります。分散型のアプローチでは、どのサーバーでクエリが実行されたかによって、データベースが異なる値を同時に返すこともあり得ます。これが、NoSQLがACIDレベル準拠を達成できない理由のひとつです。一貫性とはACIDの「C (Consistancy) 」のことで、トランザクションの開始時と終了時にデータが有効で一貫していなければならないとするものです。その代わりにほとんどのNoSQLデータベースは、「E」が結果整合性 (eventual consistency) を表すBASE整合性モデルに依存しています。つまりデータは、後のある時点で整合性が保たれることになります。現実の世界では、これはほとんどの場合、わずか数ミリ秒の小さな遅延です。多くのアプリケーションは、例えばソーシャルメディアの投稿がライブになったり、オンラインショッピングカートが更新されたりするようなことは、おそらく問題にはならないでしょう。これらの状況では、ネットワークの大部分でより高速な可用性を実現することが、すべてのユーザーにまったく同じデータを同時に提供することの価値を上回ります。しかし、オンラインで株を購入すなどいくつかのケースでは、まさに重要な問題になり得ます。NoSQLは一貫性よりもスピードと可用性に重きを置いています。それぞれの組織が、このNoSQLの特性が自分たちの目的に沿ったものかどうかを判断する必要があります。

選択肢を検討する

SQLとNoSQLのデータベースがは互いに、それぞれの特定ニーズやユースケースに非常によく対応しています。組織のデータ環境と目標によっては、それぞれの長所と短所がより強調されることもあります。それぞれのデータベースの長所を生かしながら、両方を使用することがベストな解決策となるかもしれません。多くの組織がクラウドアーキテクチャでSQLとNoSQLデータベースの両方を使用しており、場合によっては同じアプリケーションの中で使用することさえあります。繰り返しになりますが最良の選択肢とは、その欠点を最小限に抑えつつ柔軟性、継続的な可用性、スケーラビリティといったNoSQLならではのメリットを活用できるDataStax Astra DBのようなクラウドサービスのソリューションを見つけることです。

Astraは、Apache CassandraとKubernetesをベースにマイクロサービスアーキテクチャで構築された、マルチクラウド対応のDBaaS (Database as a Service) です。Azure、Google Cloud Platform、AWSの中からお好きなクラウドを選び、数クリックで立ち上げることができます。一度そうすることで、アプリケーション開発が劇的に簡素化します。AstraはオープンソースでデータAPIレイヤーのStargateを組み込み、方程式からドライバーを除外しながら、Cassandra Query Language (CQL) を学習することなく、データをクエリしたりテーブルやスキーマを作成することができます。Stargateは、スキーマレスJSON、REST、およびGraphQLを含む最新のAPIを使用してデータ操作を可能にします。また、Astra の Storage Attached Indexing (SAI) を使用することでプライマリキーに制限されることなく、テーブル内の任意の列をクエリできます。

Astraを詳しく見てみましょう