NoSQLデータベース管理システムとモデルの比較

序章

ほとんどの人がデータベースについて考えるとき、行と列で構成されるテーブルを含む従来のリレーショナルデータベースモデルを想像することがよくあります。 リレーショナルデータベース管理システムは依然としてインターネット上のデータの大部分を処理しますが、開発者がリレーショナルモデルの制限に対する回避策を模索しているため、近年、代替データモデルがより一般的になっています。 これらの非リレーショナルデータベースモデルは、それぞれ独自の長所、短所、およびユースケースを備えており、NoSQLデータベースとして分類されるようになりました。

この記事では、より一般的に使用されるNoSQLデータベースモデルのいくつかを紹介します。 それらの長所と短所のいくつかを比較検討し、データベース管理システムのいくつかの例とそれぞれの潜在的なユースケースを提供します。

リレーショナルデータベースとその制限

データベースは、論理的にモデル化された情報のクラスター、またはデータです。 一方、データベース管理システム（DBMS）は、データベースと対話するコンピュータープログラムです。 DBMSを使用すると、データベースへのアクセスの制御、データの書き込み、クエリの実行、およびデータベース管理に関連するその他のタスクの実行を行うことができます。 データベース管理システムは「データベース」と呼ばれることがよくありますが、2つの用語は完全に互換性があるわけではありません。 データベースは、コンピューターに保存されているデータだけでなく、任意のデータのコレクションにすることができますが、DBMSは、データベースとの対話を可能にする特定のソフトウェアです。

すべてのデータベース管理システムには、データの保存方法とアクセス方法を構造化する基盤となるモデルがあります。 リレーショナルデータベース管理システム（RDBMS）は、リレーショナルデータモデルを採用したDBMSです。 このモデルでは、データはテーブルに編成されます。テーブルは、RDBMSのコンテキストでは、正式にはRelationsと呼ばれます。 リレーショナルデータベース管理システムは通常、データベース内に保持されているデータを管理およびアクセスするために構造化照会言語（SQL）を採用しています。

歴史的に、リレーショナルモデルはデータを管理するために最も広く使用されているアプローチであり、今日最も人気のあるデータベース管理システムの多くはリレーショナルモデルを実装しています。 ただし、リレーショナルモデルには、特定のユースケースで問題となる可能性のあるいくつかの制限があります。

たとえば、リレーショナルデータベースを水平方向にスケーリングするのは難しい場合があります。 水平スケーリングまたはスケールアウトは、負荷を分散し、より多くのトラフィックとより高速な処理を可能にするために、既存のスタックにマシンを追加する方法です。 これは、多くの場合、既存のサーバーのハードウェアをアップグレードする垂直スケーリングとは対照的です。通常、RAMまたはCPUを追加します。

リレーショナルデータベースを水平方向にスケーリングすることが難しい理由は、リレーショナルモデルが整合性を保証するように設計されているという事実と関係があります。つまり、同じデータベースをクエリするクライアントは常に最新のデータを参照します。 リレーショナルデータベースを複数のマシンにまたがって水平方向にスケーリングする場合、クライアントが他のノードではなく1つのノードにデータを書き込む可能性があり、最初の書き込みと他のノードが変更を反映するように更新されました。

RDBMSによって提示される別の制限は、リレーショナルモデルが構造化データ、または事前定義されたデータ型と一致するか、少なくとも事前に定義された方法で編成されたデータを管理するように設計されていることです。 しかし、1990年代初頭のパーソナルコンピューティングの普及とインターネットの台頭により、非構造化データ —電子メールメッセージ、写真、ビデオなど。 —より一般的になりました。

これらの制限がさらに厳しくなるにつれて、開発者は従来のリレーショナルデータモデルに代わるものを探し始め、NoSQLデータベースの人気が高まりました。

NoSQLについて

ラベルNoSQL自体の定義はかなりあいまいです。 「NoSQL」は、データの管理にSQLを使用しないという理由だけで選択された、当時の新しいNoSQLデータベースの名前としてCarloStrozziによって1998年に造られました。

JohanOskarssonがCassandraやVoldemortのような「オープンソース、分散、非リレーショナルデータベース」の普及について話し合うためのミートアップを開催した2009年以降、この用語は新しい意味を持ちました。 Oskarssonはミートアップを「NOSQL」と名付け、それ以来、この用語はリレーショナルモデルを採用していないデータベースのキャッチオールとして使用されてきました。 興味深いことに、StrozziのNoSQLデータベースは実際にはリレーショナルモデルを採用しています。つまり、元のNoSQLデータベースは現在のNoSQLの定義に適合していません。

「NoSQL」は通常、リレーショナルモデルを採用していないDBMSを指すため、NoSQLの概念に関連する運用データモデルがいくつかあります。 次の表には、そのようなデータモデルがいくつか含まれていますが、これは包括的なリストではないことに注意してください。

これらの異なる基礎となるデータモデルにもかかわらず、ほとんどのNoSQLデータベースはいくつかの特性を共有しています。 1つは、NoSQLデータベースは通常、一貫性を犠牲にして可用性を最大化するように設計されています。 この意味で、一貫性とは、読み取り操作がデータベースに書き込まれた最新のデータを返すという考えを指します。 強一貫性のために設計された分散データベースでは、1つのノードに書き込まれたデータは、他のすべてのノードですぐに利用できます。 そうしないと、エラーが発生します。

逆に、NoSQLデータベースはしばしば結果整合性を目指します。 これは、新しく書き込まれたデータがデータベース内の他のノードで最終的に（通常は数ミリ秒で）利用可能になることを意味しますが、必ずしもすぐに利用できるとは限りません。 これには、データの可用性を向上させるという利点があります。書き込まれた最新のデータが表示されない場合でも、エラーを受け取る代わりに、以前のバージョンのデータを表示できます。

リレーショナルデータベースは、事前定義されたスキーマに適切に適合する正規化されたデータを処理するように設計されています。 DBMSのコンテキストでは、正規化データは、冗長性を排除するように編成されたデータです。つまり、データベースが占めるストレージスペースは可能な限り少なくなりますが、スキーマはデータベース内のデータがどのように構造化されているかの概要。

NoSQLデータベースは正規化されたデータを処理する機能を備えており、事前定義されたスキーマ内でデータを並べ替えることができますが、それぞれのデータモデルでは通常、リレーショナルデータベースによって課せられる厳格な構造よりもはるかに高い柔軟性が得られます。 このため、NoSQLデータベースは、半構造化データと非構造化データを格納するためのより良い選択肢であるという評判があります。 ただし、NoSQLデータベースには事前定義されたスキーマが付属していないため、アプリケーションにとって最も意味のある方法でデータを整理およびアクセスする方法を定義するのはデータベース管理者の責任です。

NoSQLデータベースとは何か、リレーショナルデータベースとの違いについてのコンテキストがわかったところで、より広く実装されているNoSQLデータベースモデルのいくつかを詳しく見ていきましょう。

Key-Valueデータベース

Key-Valueデータベースは、 Key-Valueストアとも呼ばれ、連想配列を格納および管理することで機能します。 ディクショナリまたはハッシュテーブルとも呼ばれる連想配列は、キーと値のペアのコレクションで構成され、キーは、関連付けられた値を取得するための一意の識別子として機能します。 値は、整数や文字列などの単純なオブジェクトから、JSON構造などのより複雑なオブジェクトまで何でもかまいません。

事前定義されたデータタイプを持つ行と列のテーブルで構成されるデータ構造を定義するリレーショナルデータベースとは対照的に、キー値データベースは、構造や関係のない単一のコレクションとしてデータを格納します。 データベースサーバーに接続した後、アプリケーションはキーを定義できます（たとえば、 the_meaning_of_life）そして一致する値を提供します（たとえば、 42）これは、後でキーを指定することで同じ方法で取得できます。 Key-Valueデータベースは、その中に保持されているすべてのデータを不透明なブロブとして扱います。 それがどのように構造化されているかを理解するのはアプリケーション次第です。

Key-Valueデータベースは、多くの場合、パフォーマンスが高く、効率的で、スケーラブルであると説明されています。 Key-Valueデータベースの一般的な使用例は、キャッシング、メッセージキューイング、およびセッション管理です。

人気のあるオープンソースのKey-Valueデータストアは次のとおりです。

柱状データベース

列型データベースは、列指向データベースと呼ばれることもあり、データを列に格納するデータベースシステムです。 これは従来のリレーショナルデータベースに似ているように見えるかもしれませんが、列をテーブルにグループ化するのではなく、各列はシステムのストレージ内の個別のファイルまたは領域に格納されます。

列データベースに格納されているデータはレコード順に表示されます。つまり、ある列の最初のエントリが他の列の最初のエントリに関連付けられています。 この設計により、クエリは、テーブル内のすべての行を読み取り、メモリに格納された後に不要なデータを破棄するのではなく、必要な列のみを読み取ることができます。

各列のデータは同じタイプであるため、さまざまなストレージおよび読み取りの最適化戦略が可能になります。 特に、多くの列型データベース管理者は、ランレングスエンコーディングなどの圧縮戦略を実装して、単一の列が占めるスペースの量を最小限に抑えます。 これには、クエリが通過する行が少なくなるため、読み取りが高速化されるという利点があります。 ただし、列データベースの欠点の1つは、各列を個別に書き込む必要があり、データが圧縮されたままになることが多いため、ロードパフォーマンスが遅くなる傾向があることです。 特に増分負荷、および個々のレコードの読み取りは、パフォーマンスの点でコストがかかる可能性があります。

列指向データベースは1960年代から存在しています。 ただし、2000年代半ば以降、列データモデルは高速クエリ処理に適しているため、列データベースはデータ分析に広く使用されるようになりました。 また、列内のデータの平均または合計を見つけるなど、アプリケーションが集計関数を頻繁に実行する必要がある場合にも有利であると見なされます。 一部の列型データベース管理システムは、SQLクエリを使用することもできます。

人気のあるオープンソースの柱状データベースは次のとおりです。

ドキュメント指向データベース

ドキュメント指向データベースまたはドキュメントストアは、データをドキュメントの形式で保存するNoSQLデータベースです。 ドキュメントストアは、 Key-Valueストアの一種です。各ドキュメントには一意の識別子（キー）があり、ドキュメント自体が値として機能します。

これら2つのモデルの違いは、Key-Valueデータベースでは、データが不透明として扱われ、データベースがその中に保持されているデータを認識または認識しないことです。 どのデータが保存されているかを理解するのはアプリケーション次第です。 ただし、ドキュメントストアでは、各ドキュメントに、データにある程度の構造を提供するある種のメタデータが含まれています。 ドキュメントストアには、多くの場合、ユーザーが含まれているメタデータに基づいてドキュメントを取得できるようにするAPIまたはクエリ言語が付属しています。 また、他のドキュメント内にドキュメントをネストできるため、複雑なデータ構造も可能になります。

特定のオブジェクトの情報が複数のテーブルまたはデータベースに分散しているリレーショナルデータベースとは異なり、ドキュメント指向データベースでは、特定のオブジェクトのすべてのデータを1つのドキュメントに格納できます。 ドキュメントストアは通常、データを JSON 、 BSON 、 XML 、または YAML ドキュメントとして保存し、PDFドキュメントなどのバイナリ形式を保存できるものもあります。 SQLのバリアント、全文検索、または独自のネイティブクエリ言語を使用してデータを取得するものもあれば、複数のクエリメソッドを備えているものもあります。

ドキュメント指向データベースは、近年非常に人気が高まっています。 柔軟なスキーマのおかげで、eコマース、ブログ、分析プラットフォーム、およびコンテンツ管理システムで定期的に使用されています。 ドキュメントストアは非常にスケーラブルであると見なされており、シャーディングが一般的な水平スケーリング戦略です。 また、構造が異なる大量の無関係で複雑な情報を保持するのにも優れています。

人気のあるオープンソースのドキュメントベースのデータストアは次のとおりです。

グラフデータベース

グラフデータベースは、データをドキュメントに格納し、データが事前定義されたスキーマに準拠していることを主張しないという点で、ドキュメントストアモデルのサブカテゴリと考えることができます。 ただし、違いは、グラフデータベースが、個々のドキュメント間の関係を強調表示することにより、ドキュメントモデルに追加のレイヤーを追加することです。

グラフデータベースの概念をよりよく理解するには、次の用語を理解することが重要です。

• ノード：ノードは、グラフデータベースによって追跡される個々のエンティティの表現です。 これは、リレーショナルデータベースのレコードまたは行、またはドキュメントストアのドキュメントの概念とほぼ同等です。 たとえば、音楽レコーディングアーティストのグラフデータベースでは、ノードは単一のパフォーマーまたはバンドを表す場合があります。
• プロパティ：プロパティは、個々のノードに関連する関連情報です。 レコーディングアーティストの例に基づいて、データベースに関連する情報に応じて、一部のプロパティは「ボーカリスト」、「ジャズ」、または「プラチナ販売アーティスト」になる可能性があります。
• エッジ：グラフまたは関係とも呼ばれるエッジは、2つのノードがどのように関連しているかを表すものであり、キーです。 RDBMSやドキュメントストアと区別するグラフデータベースの概念。 エッジは、有向または無向にすることができます。
  • 無向：無向グラフでは、ノード間の接続を示すためだけにノード間のエッジが存在します。 この場合、エッジは「双方向」の関係と考えることができます。つまり、一方のノードがもう一方のノードにどのように関係しているかに暗黙の違いはありません。
  • 有向：有向グラフでは、関係の元の方向に基づいて、エッジの意味が異なる場合があります。 この場合、エッジは「一方向」の関係です。 たとえば、有向グラフデータベースは、サミーから海藻への関係を指定し、サミーがグループのアルバムを作成したことを示している場合がありますが、海藻からサミーへの同等の関係を示していない場合があります。

特定の操作は、関連する情報をリンクおよびグループ化する方法があるため、グラフデータベースを使用して実行する方がはるかに簡単です。 これらのデータベースは、データポイント間の関係から洞察を得ることが重要な場合や、ソーシャルネットワークのように、エンドユーザーが利用できる情報が他のユーザーとの接続によって決定されるアプリケーションで一般的に使用されます。 彼らは、不正検出、推奨エンジン、IDおよびアクセス管理アプリケーションで定期的に使用されています。

人気のあるオープンソースのグラフデータベースは次のとおりです。

結論

このチュートリアルでは、現在使用されているNoSQLデータモデルのほんの一部について説明しました。 オブジェクトストアなどの一部のNoSQLモデルは、長年にわたってさまざまなレベルの使用が見られますが、一部のユースケースではリレーショナルモデルの実行可能な代替手段として残っています。 オブジェクトリレーショナルデータベースや時系列データベースのような他のものは、リレーショナルデータモデルとNoSQLデータモデルの要素をブレンドして、スペクトルの両端の間に一種の中間点を形成します。

データベースのNoSQLカテゴリは非常に幅広く、今日まで進化を続けています。 NoSQLデータベース管理システムと概念について詳しく知りたい場合は、NoSQL関連コンテンツのライブラリを確認することをお勧めします。