SQL と NoSQL – 次のプロジェクトにはどちらを使用するべきですか?

最もよくある質問の 1 つは、どのデータベースを使用すればよいのかということです。

SQL は Structured Query Language の略です。 NoSQL データベースは 1970 年代に IBM 研究者のチームによって初めて開発されました。一方、NoSQL データベースは 1998 年に Carlo Strozzi によって初めて使用されました。

これら 2 つのデータベース (DB) システムの最も一般的な違いは、SQL がリレーショナルであるのに対し、NoSQL は非リレーショナルであるということです。

次にプロジェクト用のデータベースを検討する際に、より適切な情報を得るために、これら 2 つのデータベースについて詳しく見てみましょう。

データベース構造

構造化について話しましょう。

SQL

SQL データベースには明確なスキーマ構造があります。

スキーマにはテーブルが含まれており、各テーブルには一定数の列が含まれています。つまり、ユーザーはテーブルに指定された列数を超えてテーブルを更新できません。これは、データの整合性を維持する必要がある場合や、データベースに保存されるデータの種類を確認する必要がある場合に特に役立ちます。

SQL データベース内の各テーブルは関連付けることができます。つまり、テーブル間にリレーションシップを持たせることができます。これらの関係は、1 対多、多対多、または 1 対 1 のいずれかになります。実装する関係のタイプは、必要なものによって異なります。

たとえば、仮定の状況を考えてみましょう。ユーザーと会社があり、ユーザーは商品を注文することができます。次に、ユーザーは複数の注文を作成できるが、各注文を作成できるのは 1 人のユーザーのみであると決定できます。これは 1 対多の関係、つまり 1 人のユーザーと多数の注文の関係になります。したがって、両方のテーブルのテーブル構造は以下のようになります。

DB には、次のような構造の users テーブルを含めることができます。

 users_table
----------------------------------------------------
id          |          name       |           email
-----------------------------------------------------
1                    Idris              idris@idrislawal.com

また、注文テーブルも作成できます

orders_table
---------------------------------------------------------------------------------
id                   |             user_id             |             order_number
---------------------------------------------------------------------------------
1                                      1                               20000001

注文テーブルの user_id により、注文テーブルの各注文をそれが属するユーザーに簡単にマッピングできます。 1 対 1 の関係の場合、関連する注文 ID によってユーザーを取得することにした場合、 users_table にも order_id を含めることができます。

多対多の状況では、通常、ピボット テーブルと呼ばれる追加のテーブルが関係します。これにより、複数のレコードを相互にマッピングできるようになります。上記のインスタンスを使用します。私たちはそうするだろう、

 users_table
-------------------------------------------------------------------------------------
id               |                    name                   |                  email
-------------------------------------------------------------------------------------
1                               Idris                             idris@idrislawal.com

注文テーブルは次のようになります

orders_table
---------------------------------------------------------
id                      |                    order_number
---------------------------------------------------------
1                                             2000001

その後、ピボット テーブルは両方の ID を外部キーとして保持します。

 users_orders_table
------------------------------------------------------------------------------
id               |                  order_id              |           user_id
------------------------------------------------------------------------------
1                                     1                                 1

SQL によって提供されるこの構造に基づいて、1 つのクエリで結合された異なるテーブルのデータを提供するテーブル間の結合を簡単に作成できます。

NoSQL

NoSQL データベースは、SQL DB よりも柔軟になるように構築されており、大量のデータを含めることもできます。

NoSQL DB には、事前定義されたスキーマやテーブルはありません。コレクションがあり、各コレクションにはドキュメントがあります。これにより、データを受信したときにさまざまな形式で保存できます。 1 つのコレクションにさまざまなフィールドを持つ複数のさまざまなドキュメントを含めることを選択できます。コレクション間の関係を手動で構築することも可能です。ただし、そのような目的には適していません。代わりに、単一のクエリに必要なものをすべて同じコレクションに保存できます。

SQL 担当者であれば、コレクションをテーブル、ドキュメントをテーブルを含む行と考えるかもしれません。ただし、テーブルに追加できるデータの列に制限はありません。

先ほど定義した、ユーザーと注文を持つ会社の仮想インスタンスに戻ります。

ユーザー コレクションは次のように定義できます。

 {id: 1, name: 'idris', email: 'idris@idrislawal.com'}

そして、Orders コレクションは次のように定義できます。

 {id: 1, order_number: 2000001, user_id:1}

ただし、この場合、両方のコレクションを手動で結合する必要は避けたいと考えています (この場合は、結合すべきではありません)。最も多く読まれたエントリをコレクションに保存できます。 (この例では) Orders コレクションにすることにしました。

 {id:1, order_number:200001, user{id:1, name: 'idris', email:'idris@idrislawal.com'}}

この場合、Users コレクションから読み取る必要はなくなり、Orders コレクションから読み取るだけで済みます。これで、必要なデータがすべて含まれます。

ここで注意すべき重要な点: 書き込みよりも読み取りを多く行うアプリを構築している場合は、NoSQL オプションの方が適している可能性があります。すべてのデータを同じコレクションに保存でき、そのソースから快適に読み取り、必要なデータをすべて取得できるからです。

ただし、その規模で大量の書き込み (1 秒あたり約 10,000 回の書き込み) を必要とするアプリケーションの場合、同じデータを複数の場所に書き込む必要がある NoSQL オプションを使用することは得策ではありません。この状況では、すべてのテーブルにリレーションが存在し、同じデータを複数の場所に繰り返し書き込む必要がなく、1 つの場所で更新されたデータを、既存の関係。もちろん、これは、これらのデータベースのそれぞれがスケールに対応できないという意味ではありません。

スケーリング

スケーリングがどのように機能するかを見てみましょう。

SQL

SQL DB は水平方向に拡張することはできず、垂直方向にのみ拡張できます。これは一体何を意味するのでしょうか？

水平スケーリングとは、負荷を軽減するために 1 つの DB から複数のデータベースにデータを分割することを意味します。ただし、その厳密な性質により、SQL データを別の DB に分割することはできません。 SQL DB を拡張するには、既存の DB サーバーの CPU、メモリ、ディスク容量を増やすことが適切であり、これが垂直方向に拡張することを意味します。

NoSQL

NoSQL DB は水平方向と垂直方向の両方にスケーリングできます。これは、データ ストレージの柔軟性によるものです。したがって、これにより、水平スケーリングの場合と同様に、そのデータを複数のデータベースに分割することができます。必要に応じて垂直方向に拡大縮小することもできます。

ここで注意すべき重要な点は、 スケーリングに関しては、SQL データベースと NoSQL データベースの両方を効果的にスケーリングできることです。ただし、SQL DB の場合、垂直方向のスケーリングが制限となる場合があります。単一の DB サーバーが搭載できるコンピューティング能力には制限があります。

ここで、構築するアプリケーションのほとんどはサーバーのコンピューティング能力の最大値に達しない可能性があることに注意することも重要ですが、この点を念頭に置いておくと役立ちます。ただし、SQL を実装する大規模なビジネス アプリケーションの場合、この制限を克服する一般的なオプションはシャーディングです。

シャーディングとは何ですか?

シャーディングは、大きなテーブルをシャードと呼ばれる小さなチャンクに分割するプロセスです。シャーディングは、データベースを水平に分割することで実行できます。これを水平および垂直スケーリングと混同しないでください。水平パーティショニングとは、テーブルの行を複数のデータベース ノードに格納するプロセスを指します。一方、垂直パーティション化では、テーブルの列を異なるノードに保存する必要があります。これにより、データベースを効果的に拡張し、パフォーマンスを向上させることができます。

データベースの例

SQL

• MySQL – 非常に人気のあるオープンソース データベース。ただし、多くの PHP 開発者が選択するデータベースは、Node.js、C#、C++、Java、Perl、Ruby、Python でも使用できることは明らかです。
• MSSQL – Microsoft SQL は Microsoft から直接開発されているため、多くの安定性を提供し、災害復旧の面でもある程度のサポートを提供します。
• MariaDB – これは MySQL の作成者によって MySQL 上に構築されており、MariaDB を永久無料バージョンとして維持することを目的としています。
• PostgresSQL – 非常に人気のあるオープンソース データベース。世界で最も先進的なオープンソース データベースとしての自負
• Oracle – これは通常、Oracle のエンタープライズ ソリューションに合わせて調整されていますが、無料版にはいくつかの制限があります。

NoSQL

• MongoDB – おそらく最もよく知られている NoSQL DB で、MERN スタック (MongoDB、Express、React、Node) または MEAN スタック (MongoDB、Express、Angular、Node) を使用するアプリケーション開発者の間で一般的です。
• Firebase – 2011 年に導入され、2014 年に Google に買収され、Web およびモバイル アプリケーション開発者によって広く使用されています。
• Apache Couch DB – データを JSON として保存するドキュメントベースの NoSQL DB。
• Redis: これは NoSQL DB であり、オプションの存続期間を指定してデータを保存する際に使用することでおそらく最もよく知られています。スピードが速いことでも有名です。

結論

SQL データベースまたは NoSQL データベースを使用して、あらゆる種類のアプリケーションを作成できます。それはあなたの要件によって異なります。読み取りが多く書き込みが少ないデータベースを検討している場合は、NoSQL が良い選択肢になる可能性があります。ただし、読み取りよりも書き込みの多いアプリの構築を検討している場合は、SQL の方が優れたソリューションとなる可能性があります。スケーラビリティに関しては、アプリが非常に大規模になると、両方の DB を使用することになる可能性があります。