NoSQLは、「Not Only SQL」または「非SQL」とも呼ばれ、リレーショナル・データベースに見られる従来の構造の外部でデータの保存と照会を可能にするデータベース設計の手法です。
NoSQLは引き続きリレーショナル・データベース管理システム（RDBMS）内にあるデータを保存できますが、ただRDBMSとは保存方法が異なります。リレーショナル・データベースと非リレーショナル・データベースのどちらを使用するかは、主に状況に応じて決定され、ユースケースによって異なります。
NoSQLデータベースは、リレーショナル・データベースの典型的な表構造の代わりに、JSONドキュメントなど1つのデータ構造内にデータを格納します。この非リレーショナル・データベース設計にはスキーマが不要なため、通常は大規模な非構造化データ・セットを管理するために必要な拡張性を素早く提供します。
NoSQLは分散データベースの一種でもあり、情報はリモートまたはローカルのさまざまなサーバーにコピーおよび保存されるため、データの可用性と信頼性が確保されます。データの一部がオフラインになっても、データベースの残りの部分は引き続き実行できます。
今日、ほぼすべての業界の企業が、最新のWebアプリケーションを実行できるよう迅速にスケールアップできる機能で大量のデータを高速で管理する必要があります。クラウド、ビッグデータ、モバイル、およびWebアプリケーションが成長するこの時代において、NoSQLデータベースはそのようなスピードと拡張性を実現し、そのパフォーマンスと使いやすさの点で人気の選択肢となっています。
構造化照会言語（SQL）は通常、NoSQLに関連して参照されます。データベースから特定の情報を取得するために使用されるプログラミング言語、SQLの歴史を理解すると、NoSQLとSQLの違いをより深く理解できるでしょう。
リレーショナル・データベースが登場する以前、企業はデータ・テーブルにツリー状の構造を備えた階層データベース・システムを使用していました。これらの初期のデータベース管理システム（DBMS）により、ユーザーは大量のデータを管理できるようになりました。ただし、それらは複雑で、多くの場合、特定のアプリケーションに固有のものであり、データ内で発見できる方法は限られていました。このような制限により、最終的にはデータを表で整理するリレーショナル・データベース管理システムが開発されました。SQLはリレーショナル・データを操作するためのインターフェースを提供し、アナリストが共通のフィールドをマージしてテーブルを接続できるようにしました。
時が経つにつれ、eコマース・アプリケーションのような新興テクノロジーでは、より多様な大規模データセットをより速く利用したいという要求がますます重要になってきました。プログラマーが必要としていたのはSQLデータベースよりも柔軟性の高いもの（つまり、リレーショナル・データベース）であり、NoSQLがその代替手段となりました。
NoSQLはSQLの代替手段となりましたが、この進歩は決してSQLデータベースに取って代わるものではありません。たとえば、ある会社で小売注文を管理しているとします。リレーショナル・モデルでは、個々の表が顧客データ、注文データ、製品データを個別に管理し、顧客IDや注文IDなどの一意の共通キーを介して結合されます。これはデータを迅速に保存および取得するのに最適ですが、大量のメモリーを必要とします。メモリーを追加したい場合、SQLデータベースは水平方向ではなく垂直方向にのみ拡張できます。つまり、メモリーを追加できる能力は、使用しているハードウェアによって制限されます。そのため、垂直方向のスケーリングによって最終的には企業のデータの保存と取得が制限されてしまいます。
それに比べ、NoSQLデータベースは非リレーショナルであるため、表を接続する必要がありません。組み込みのシャーディング機能と高可用性機能により、水平方向のスケーリングが容易になります。単一のデータベース・サーバーがすべてのデータを保存したり、すべてのクエリーを処理したりするのに不十分な場合、ワークロードを複数のサーバーに分散して、企業がデータを水平方向に拡張できるようにします。
各タイプのデータベースには独自の利点がありますが、企業は一般に、単一のアプリケーションでNoSQLデータベースとリレーショナル・データベースの両方を利用しています。現在のクラウド・プロバイダーは、SQLデータベースまたはNoSQLデータベースをサポートできます。どのデータベースを選択するかは、目的によって異なります。
2つの選択肢の相違について詳しくは、「 SQLデータベースとNoSQLデータベースの相違とは」を参照してください。
生成AIの主な利点と、組織が生成AIと機械学習をビジネスに組み込む方法について学びます。
Prestoに関する電子ブックに登録する
NoSQL は、さまざまな方法でデータを整理するための他のオプションを提供します。 多様なデータ構造を提供することで、NoSQLはデータ分析、ビッグデータの管理、ソーシャル・ネットワーク、モバイル・アプリ開発にも応用できます。
NoSQLデータベースは、次の主要なデータ・モデルのいずれかを使用して情報を管理します。
キー値ストア
これは通常、NoSQL データベースの最も単純な形式とみなされます。このスキーマのないデータ・モデルは、キーと値のペアの辞書で構成され、各項目はキーと値を持ちます。キーは、ショッピング・カートIDなど、SQLデータベースで見られるものと似ていますが、値はユーザーのショッピング・カート内の個々の商品などのデータの配列です。これは、ショッピング・カートなどのユーザー・セッション情報のキャッシュと保存によく使用されます。ただし、一度に複数のレコードを取得する必要がある場合には理想的ではありません。RedisとMemcachedは、オープンソースのキーと値のデータベースの一例です。
ドキュメント・ストア
名前が示すように、ドキュメント・データベースはデータをドキュメントとして保存します。半構造化データの管理に役立ち、データは通常JSON、XML、BSON形式で保存されます。これにより、アプリケーションでデータを使用する際、データをまとめておくことができ、データを使用するために必要な翻訳の量を減らすことができます。また、データ・スキーマがドキュメント間で一致する必要がないため、開発者はより柔軟性を得ることができます（例：nameとfirst_name）。しかし、これは複雑なトランザクションでは問題となり、データの破損につながる可能性があります。ドキュメント・データベースの一般的なユースケースとしては、コンテンツ管理システムやユーザー・プロファイルなどがあります。ドキュメント指向データベースの例としては、MEANスタックのデータベース・コンポーネントであるMongoDBがあります。
MongoBDの詳細はこちらIBM Cloud Databases for MongoDB の使用を開始する方法については、IBMチュートリアルをご覧ください。
ワイドカラム・ストア
これらのデータベースは列に情報を格納するため、ユーザーは無関係なデータに追加のメモリを割り当てることなく、必要な特定の列にのみアクセスできます。このデータベースは、キー値ストアとドキュメント・ストアの欠点を解決しようとしますが、管理がより複雑なシステムになる可能性があるため、新しいチームやプロジェクトでの使用はお勧めしません。Apache HBaseとApache Cassandraは、オープンソースのワイドカラム・データベースの例です。Apache HBaseは、多くのビッグデータの応用で一般的に使用されているスパース・データ・セットを格納する方法を提供するHadoop分散ファイル・システム上に構築されています。一方、Apache Cassandraは、複数のサーバーと複数のデータセンターにまたがるクラスタリングにまたがる大量のデータを管理するように設計されています。ソーシャルネット・ワーキングWebサイトやリアルタイムでのデータ分析など、さまざまなユースケースで使用されています。
グラフ・ストア
このタイプのデータベースは通常、ナレッジ・グラフのデータを格納します。データ要素はノード、エッジ、プロパティーとして保存されます。あらゆるオブジェクト、場所、人物がノードになることができます。エッジはノード間の関係を定義します。たとえば、ノードはIBMのような顧客や、Ogilvyのような代理店である可能性があります。エッジは、この関係をIBMとOgilvy間の顧客関係として分類します。
グラフ・データベースは、グラフ内の要素間の接続ネットワークを保存および管理するために使用されます。Neo4j（IBM外部のリンク）は、Javaに基づくグラフベースのデータベース・サービスで、オープンソース・コミュニティー・エディションがあり、ユーザーはオンライン・バックアップと高可用性拡張機能のライセンスを購入したり、バックアップと拡張機能が含まれたパッケージ済みのライセンス・バージョンを購入したりできます。
インメモリー・ストア
IBM SolidDBなどこのタイプのデータベースでは、データはディスク上ではなくメイン・メモリーに存在するため、従来のディスクベースのデータベースよりもデータ・アクセスが高速になります。
NoSQLデータベースの例
多くの企業がNoSQL環境を開始しています。上記以外にも、一般的なNoSQLデータベースをいくつかご紹介します。
- Apache CouchDBはは、クエリー言語としてJavaScriptを使用する、JSONドキュメントベースのオープンソース系データベースです。
- Elasticsearchは、全文検索エンジンを含むドキュメントベースのデータベースです。
- Couchbaseはキー値およびドキュメント・データベースで、開発者はこのデータベースを使用して、クラウド、モバイル、エッジ・コンピューティング向けの応答性と柔軟性に優れたアプリケーションを構築できます。
データベースの状態の詳細については、「データベースの状況の概要」を参照してください。
各タイプのNoSQLデータベースには、特定のユースケースに適した強みがあります。しかし、いずれも開発者にとって次のような利点があり、顧客により良いサービスを提供するためのフレームワークを築きます。
- 費用対効果：ハイエンドの商用RDBMSを維持するにはコストがかかります。ライセンスの購入、訓練を受けたデータベース・マネージャー、垂直方向に拡張するための強力なハードウェアが必要です。NoSQLデータベースを使用すると、水平方向に迅速に拡張でき、リソースを適切に割り当ててコストを最小限に抑えることができます。
- 柔軟性：水平方向の拡張性と柔軟なデータ・モデルによりNoSQLデータベースは、急速に変化する大量のデータに対応することができ、アジャイル開発、迅速な反復、頻繁なコード・プッシュに最適です。
- 複製： NoSQLの複製機能は、複数のサーバー間でデータをコピーして保存します。この複製により、データの信頼性が確保され、ダウンタイム中でも確実にアクセスでき、サーバーがオフラインになってもデータ損失を防止できます。
- 迅速：NoSQLを使用すると、開発者から営業チーム、顧客まであらゆるユーザーが、より高速で俊敏な保存と処理を実現できます。また、高速であるため、NoSQLデータベースは通常、最新の複雑なWebアプリケーション、Eコマース・サイト、またはモバイル・アプリケーションに最適です。
一言で言えば、NoSQLデータベースは高いパフォーマンス、可用性、スケーラビリティを実現します。
選択すべきNoSQLデータベースの構造とタイプは、組織がそれをどのように使用するかによって異なります。ここでは、さまざまなタイプのNoSQLデータベースの具体的な用途をいくつか紹介します。
- データ関係の管理：データの複雑な集約とこれらのポイント間の関係の管理は通常、グラフベースのNoSQLデータベースで処理されます。これには、レコメンデーション・エンジン、ナレッジ・グラフ、不正検出アプリケーション、各種データ型を使って人々のつながりが確立されるるソーシャル・ネットワークが含まれます。
- 低遅延パフォーマンス：ゲーム、家庭用フィットネス・アプリケーション、広告テクノロジーはすべて、リアルタイムのデータ管理のために高いスループットを必要とします。このインフラストラクチャーは、市場入札の更新でも、最も関連性の高い広告の表示でも、消費者に最大の価値をもたらします。Webアプリケーションは、ディスク・ストレージで生じる遅延なしに、迅速な応答時間を実現し、使用量の急増を管理するために、インメモリーNoSQLデータベースが必要です。
- 拡張と大容量データ：Eコマースでは、一日限りの販売であれ、ホリデーシーズンのショッピングであれ、使用量の急増を管理する能力が求められます。キー値データベースは単純な構造なので、トラフィックが多いときに簡単にスケールアップできるため、Eコマース・アプリケーションで頻繁に使用されています。この俊敏性は、ゲーム、アドテック、モノのインターネット（IoT）アプリケーションにとって価値が高いものです。
大企業では、遅延なくサービスを提供し、より迅速に拡張する必要があることから、マイクロサービスの成長に拍車がかかり、企業は各種アプリケーションにどのようなタイプのデータベースを使用するかを検討するようになりました。
企業は、アプリケーションのすべてのコンポーネントに単一のリレーショナル・データベースを使用することには、限界があることに気付きました。特定のコンポーネントに代替物がある場合はなおさらです。マイクロサービスは、アプリケーション全体に対して単一の共有データ・ストアが不要になるという点でも魅力的な選択肢です。その代わり、アプリケーションには緩く結合された個別に導入可能なサービスが数多くあり、それぞれが独自のデータ・モデルとデータベースを持ち、APIゲートウェイまたはiPaaSを介して統合されています。
単一アプリケーション内で複数のデータベースを使用するパターン（ポリグロット永続性とも呼ばれます）によって、市場にNoSQLデータベースが繁栄する余地が生まれました。現在、開発者は、単一のリレーショナル・データベースのコンテキストですべてを機能させようとせずに、適切なマイクロサービスに対して適切なデータベースを活用できます。