NoSQLデータベースの決定的なガイド

Webアプリケーションがデータを処理する方法が過去10年間で大幅に変化したことは間違いありません。 より多くのデータが収集され、これまで以上に多くのユーザーがこのデータに同時にアクセスしています。 これは、スキーマベースのリレーショナルデータベースではスケーラビリティとパフォーマンスがこれまで以上に課題になっているため、拡張が困難になる可能性があることを意味します。

NoSQLの進化

SQLのスケーラビリティの問題は、Google、Amazon、Facebookなど、データとインフラストラクチャのニーズが増大しているWeb2.0企業によって認識されていました。 彼らは、BigTable、DynamoDB、Cassandraなどのテクノロジーという問題に対する独自の解決策を考え出しました。

この関心の高まりにより、パフォーマンス、信頼性、および一貫性に重点を置いた多数のNoSQLデータベース管理システム（DBMS）が生まれました。 検索と読み取りのパフォーマンスを向上させる目的で、既存のインデックス構造の多くが再利用され、改善されました。

まず、最初のNoSQLシステムであると考えられているGoogleのBigTableやAmazonのDynamoDBなど、特定のニーズを満たすために大企業によって開発された独自の（クローズドソース）タイプのNoSQLデータベースがありました。

これらの独自のシステムの成功により、同様のオープンソースおよび独自のデータベースシステムの開発が開始されました。最も人気のあるシステムは、Hypertable、Cassandra、MongoDB、DynamoDB、HBase、およびRedisです。

NoSQLの違いは何ですか？

NoSQLデータベースと従来のリレーショナルデータベースの主な違いの1つは、NoSQLが非構造化ストレージの形式であるという事実です。

これは、NoSQLデータベースには、リレーショナルデータベースに見られるような固定のテーブル構造がないことを意味します。

NoSQLデータベースの長所と短所

利点

NoSQLデータベースには、従来のリレーショナルデータベースと比較して多くの利点があります。

根本的な違いの1つは、NoSQLデータベースの構造が単純で柔軟であることです。 それらはスキーマフリーです。

リレーショナルデータベースとは異なり、NoSQLデータベースはキーと値のペアに基づいています。

NoSQLデータベースの一部のストアタイプには、列ストア、ドキュメントストア、キー値ストア、グラフストア、オブジェクトストア、XMLストア、およびその他のデータストアモードが含まれます。

通常、データベースの各値にはキーがあります。 一部のNoSQLデータベースストアでは、開発者は単純な文字列値だけでなく、シリアル化されたオブジェクトをデータベースに格納することもできます。

オープンソースのNoSQLデータベースは、高額なライセンス料を必要とせず、安価なハードウェアで実行できるため、導入の費用対効果が高くなります。

また、オープンソースであろうとプロプライエタリであろうと、NoSQLデータベースを操作する場合、拡張はリレーショナルデータベースを操作する場合よりも簡単で安価です。 これは、メインホストをより強力なものに置き換えるリレーショナルデータベースシステムで通常行われるタイプの垂直スケーリングではなく、水平方向にスケーリングしてすべてのノードに負荷を分散することによって行われるためです。

短所

もちろん、NoSQLデータベースは完璧ではなく、常に正しい選択であるとは限りません。

一つには、ほとんどのNoSQLデータベースは、リレーショナルデータベースシステムによってネイティブにサポートされている信頼性機能をサポートしていません。 これらの信頼性機能は、アトミック性、一貫性、分離性、および耐久性としてまとめることができます。 これは、これらの機能をサポートしないNoSQLデータベースが、パフォーマンスとスケーラビリティと一貫性を交換することも意味します。

信頼性と一貫性の機能をサポートするために、開発者は独自のコードを実装する必要があります。これにより、システムがさらに複雑になります。

これにより、銀行システムのように、安全で信頼性の高いトランザクションをNoSQLデータベースに依存できるアプリケーションの数が制限される可能性があります。

ほとんどのNoSQLデータベースに見られる他の形式の複雑さには、SQLクエリとの非互換性が含まれます。 これは、手動または独自のクエリ言語が必要であり、さらに時間と複雑さが増すことを意味します。

NoSQLとリレーショナルデータベース

この表は、NoSQLとリレーショナルデータベースの機能の簡単な比較を示しています。

この表は、両方のモデルを実装するさまざまなデータベース管理システムではなく、データベースレベルでの比較を示していることに注意してください。 これらのシステムは、両方のシステムの問題と欠点のいくつかを克服するための独自の技術を提供し、場合によっては、パフォーマンスと信頼性を大幅に向上させます。

NoSQLデータストアタイプ

キーバリューストア

Key Valueストアタイプでは、一意のキーがアイテムを指すハッシュテーブルが使用されます。

キーは、キーの論理グループに編成できます。キーは、独自のグループ内で一意である必要があります。 これにより、異なる論理グループで同一のキーを使用できます。 次の表は、キーが都市の名前であり、値がその都市のアルスター大学の住所であるKey-Valueストアの例を示しています。

Key Value Storeの一部の実装は、パフォーマンスを大幅に向上させるキャッシュメカニズムを提供します。

データベースに保存されているアイテムを処理するために必要なのは、キーだけです。 データは、文字列、JSON、またはBLOB（Binary Large OBject）の形式で保存されます。

この形式のデータベースの最大の欠陥の1つは、データベースレベルでの一貫性の欠如です。 これは、開発者が独自のコードを使用して追加できますが、前述のように、これにより、より多くの労力、複雑さ、および時間が追加されます。

キーバリューストア上に構築されている最も有名なNoSQLデータベースは、AmazonのDynamoDBです。

ドキュメントストア

ドキュメントストアは、スキーマがなく、Key-Valueモデルに基づいているという点で、Key-Valueストアに似ています。 したがって、どちらも同じ長所と短所の多くを共有しています。 どちらもデータベースレベルでの一貫性に欠けているため、アプリケーションはより信頼性と一貫性のある機能を提供できます。

ただし、この2つには重要な違いがあります。

ドキュメントストアでは、値（ドキュメント）は保存されたデータのエンコーディングを提供します。 これらのエンコーディングは、XML、JSON、またはBSON（バイナリエンコードされたJSON）にすることができます。

また、データに基づくクエリも実行できます。

ドキュメントストアに依存する最も人気のあるデータベースアプリケーションはMongoDBです。

列ストア

列ストアデータベースでは、ほとんどのリレーショナルデータベース管理システムで行われるように行に格納されるのではなく、データは列に格納されます。

列ストアは、データベース内の特定の列を論理的にグループ化する1つ以上の列ファミリーで構成されます。 キーは、データベース内のいくつかの列を識別して指すために使用され、このキーのスコープを定義するキースペース属性があります。 各列には、名前と値のタプルが含まれ、順序付けられ、コンマで区切られています。

列ストアは、保存されたデータに高速で読み取り/書き込みアクセスできます。 列ストアでは、単一の列に対応する行が単一のディスクエントリとして格納されます。 これにより、読み取り/書き込み操作中のアクセスが高速化されます。

列ストアを使用する最も人気のあるデータベースには、GoogleのBigTable、HBase、およびCassandraが含まれます。

グラフベース

グラフベースのNoSQLデータベースでは、データを表すために有向グラフ構造が使用されます。 グラフはエッジとノードで構成されています。

正式には、グラフはオブジェクトのセットの表現であり、オブジェクトのいくつかのペアがリンクによって接続されています。 相互接続されたオブジェクトは、頂点と呼ばれる数学的抽象化によって表され、頂点のいくつかのペアを接続するリンクはエッジと呼ばれます。 頂点とそれらを接続するエッジのセットは、グラフと呼ばれます。

これは、エッジとノードを使用してデータを表現および格納するグラフベースデータベースの構造を示しています。 これらのノードは、ノード間のエッジで表される相互の関係によって編成されます。 ノードとリレーションシップの両方に、いくつかの定義済みのプロパティがあります。

グラフデータベースは、ソーシャルネットワーキングアプリケーションで最も一般的に使用されます。 グラフデータベースを使用すると、開発者はオブジェクト自体ではなく、オブジェクト間の関係に焦点を当てることができます。 このコンテキストでは、実際にスケーラブルで使いやすい環境が可能になります。

現在、InfoGridとInfiniteGraphは最も人気のあるグラフデータベースです。

NoSQLデータベース管理システム

データベースの簡単な比較のために、次の表に、さまざまなNoSQLデータベース管理システム間の簡単な比較を示します。

MongoDBには柔軟なスキーマストレージがあります。つまり、保存されたオブジェクトは必ずしも同じ構造またはフィールドである必要はありません。 MongoDBには、データコレクションを分散するいくつかの最適化機能もあり、全体的なパフォーマンスの向上とよりバランスの取れたシステムを実現します。

Apache CouchDBなどの他のNoSQLデータベースシステムもドキュメントストアタイプのデータベースであり、RESTful APIを使用してデータベースにアクセスできることを除いて、MongoDBと多くの機能を共有しています。

RESTは、World Wide Web内のコンポーネント、コネクタ、およびデータ要素に適用される一連の調整されたアーキテクチャ制約で構成されるアーキテクチャスタイルです。 これは、ステートレス、クライアントサーバー、キャッシュ可能な通信プロトコル（HTTPプロトコルなど）に依存しています。

RESTfulアプリケーションは、HTTPリクエストを使用して、データの投稿、読み取り、削除を行います。

列ベースのデータベースに関しては、HypertableはC ++で記述されたNoSQLデータベースであり、GoogleのBigTableに基づいています。

Hypertableは、MongoDBやCouchDBと同様に、ノード間でのデータストアの分散をサポートしてスケーラビリティを最大化します。

最も広く使用されているNoSQLデータベースの1つは、Facebookによって開発されたCassandraです。

Cassandraは、信頼性とフォールトトレランスを目的とした多くの機能を含む列ストアデータベースです。

次のサブセクションでは、各NoSQL DBMSの詳細を説明するのではなく、最も広く使用されているNoSQLデータベース管理システムの2つであるCassandraとMongoDBについて説明します。

カサンドラ

Cassandraは、Facebookによって開発されたデータベース管理システムです。

Cassandraの背後にある目標は、単一障害点がなく、最大の可用性を提供するDBMSを作成することでした。

Cassandraは主に列ストアデータベースです。 一部の研究では、Cassandraを、列ストアデータベースであるGoogleのBigTableとキーバリューデータベースであるAmazonのDynamoDBに触発されたハイブリッドシステムと呼んでいます。

これは、キー値システムを提供することで実現されますが、Cassandraのキーは、GoogleのBigTable分散ファイルシステムとDynamoの可用性機能（分散ハッシュテーブル）に依存する一連の列ファミリーを指します。

Cassandraは、さまざまなノードに分散された大量のデータを保存するように設計されています。 Cassandraは、Facebookのような大規模なサービスに不可欠な、単一障害点のない高可用性サービスを提供しながら、大量のデータを処理し、多くのサーバーに分散するように設計されたDBMSです。

Cassandraの主な機能は次のとおりです。

• 単一障害点はありません。 これを実現するには、Cassandraを単一のマシンではなく、ノードのクラスターで実行する必要があります。 これは、各クラスターのデータが同じであることを意味するわけではありませんが、管理ソフトウェアは同じです。 いずれかのノードで障害が発生すると、そのノードのデータにアクセスできなくなります。 ただし、他のノード（およびデータ）には引き続きアクセスできます。
• 分散ハッシュは、1つのスロットを追加または削除しても、キーからスロットへのマッピングが大幅に変更されないように、ハッシュテーブル機能を提供するスキームです。 これにより、容量に応じてサーバーまたはノードに負荷を分散し、ダウンタイムを最小限に抑えることができます。
• 比較的使いやすいクライアントインターフェイス。 Cassandraは、クライアントインターフェイスにApacheThriftを使用しています。 Apache ThriftはクロスランゲージRPCクライアントを提供しますが、ほとんどの開発者は、HectorなどのAppleThrift上に構築されたオープンソースの代替手段を好みます。
• その他の可用性機能。 Cassandraの機能の1つは、データ複製です。 基本的に、クラスター内の他のノードにデータをミラーリングします。 レプリケーションはランダムにすることも、別のデータセンターのノードに配置することでデータ保護を最大化するために特定することもできます。 Cassandraにあるもう1つの機能は、パーティショニングポリシーです。 パーティショニングポリシーは、キーを配置するノードの場所を決定します。 これは、ランダムまたは順番に行うこともできます。 両方のタイプのパーティショニングポリシーを使用する場合、Cassandraは負荷分散とクエリパフォーマンスの最適化のバランスをとることができます。
• 一貫性。 レプリケーションなどの機能により、一貫性が困難になります。 これは、すべてのノードが常に最新の値で最新である必要があるため、または読み取り操作がトリガーされた時点であるためです。 ただし、最終的には、Cassandraは、開発者にこのカスタマイズ性を提供することにより、レプリケーションアクションと読み取り/書き込みアクションのバランスを維持しようとします。
• 読み取り/書き込みアクション。 クライアントは、単一のCassandraノードにリクエストを送信します。 ノードは、レプリケーションポリシーに従って、データをクラスターに格納します。 各ノードは、最初にコミットログでデータの変更を実行し、次に変更でテーブル構造を更新します。どちらも同期的に実行されます。 読み取り操作も非常によく似ており、読み取り要求は単一のノードに送信されます。その単一のノードは、パーティション化/配置ポリシーに従って、データを保持するノードを決定するノードです。

MongoDB

MongoDBは、C++で記述されたスキーマフリーのドキュメント指向データベースです。 データベースはドキュメントストアベースです。つまり、エンコードされたデータの形式で値（ドキュメントと呼ばれます）を格納します。

MongoDBでエンコードされた形式の選択はJSONです。 データがJSONドキュメント内にネストされている場合でも、クエリとインデックス作成が可能なため、これは強力です。

以下のサブセクションでは、MongoDBで利用可能な主要な機能のいくつかについて説明します。

破片

シャーディングとは、複数のマシン（ノード）間でデータを分割および分散することです。 ノードが対称的に分散されているCassandraとは対照的に、シャードはMongoDBノードのコレクションです。 シャードを使用するということは、複数のノードにまたがって水平方向にスケーリングできることも意味します。 単一のデータベースサーバーを使用するアプリケーションがある場合、シャーディングはMongoDBによって行われるため、元のアプリケーションコードにほとんど変更を加えることなく、シャードクラスターに変換できます。 多くの場合、クライアント側に公開されているパブリックAPIからほぼ完全に切り離されています。

Mongoクエリ言語

前に説明したように、MongoDBはRESTfulAPIを使用します。 dbコレクションから特定のドキュメントを取得するには、目的のドキュメントが一致する必要のあるフィールドを含むクエリドキュメントを作成します。

行動

MongoDBには、ルーターと呼ばれるサーバーのグループがあります。 それぞれが1つ以上のクライアントのサーバーとして機能します。 同様に、クラスターには構成サーバーと呼ばれるサーバーのグループが含まれています。 それぞれが、どのシャードにどのデータが含まれているかを示すメタデータのコピーを保持しています。 読み取りまたは書き込みアクションは、クライアントからクラスター内のルーターサーバーの1つに送信され、構成サーバーの助けを借りて、そのサーバーによってデータを含む適切なシャードに自動的にルーティングされます。

Cassandraと同様に、MongoDBのシャードには、まったく同じデータを保持する各シャードのレプリカセットを作成するデータレプリケーションスキームがあります。 MongoDBには、マスタースレーブレプリケーションとレプリカセットレプリケーションの2種類のレプリカスキームがあります。 レプリカセットは、より多くの自動化と障害のより良い処理を提供しますが、マスタースレーブは時々管理者の介入を必要とします。 レプリケーションスキームに関係なく、レプリカセット内の任意の時点で、1つのシャードのみがプライマリシャードとして機能し、他のすべてのレプリカシャードはセカンダリシャードとして機能します。 すべての書き込みおよび読み取り操作はプライマリシャードに送られ、（必要に応じて）セット内の他のセカンダリシャードに均等に分散されます。

下の図では、上で説明したMongoDBアーキテクチャが表示され、ルーターサーバーが緑色、構成サーバーが青色、MongoDBノードを含むシャードが示されています。

MongoDBでのシャーディング（またはシャード間でのデータの共有）は完全に自動化されているため、失敗率が低下し、MongoDBは非常にスケーラブルなデータベース管理システムになります。

NoSQLデータベースのインデックス構造

インデックス作成は、キーをDBMS内の対応するデータレコードの場所に関連付けるプロセスです。 NoSQLデータベースで使用される多くのインデックスデータ構造があります。 次のセクションでは、より一般的な方法のいくつかについて簡単に説明します。 つまり、Bツリーインデックス、Tツリーインデックス、およびO2ツリーインデックスです。

Bツリーインデックス

Bツリーは、DBMSで最も一般的なインデックス構造の1つです。

Bツリーでは、内部ノードは、事前定義された範囲内で可変数の子ノードを持つことができます。

AVLなどの他のツリー構造との大きな違いの1つは、Bツリーを使用するとノードが可変数の子ノードを持つことができることです。つまり、ツリーのバランスが少なくなり、無駄なスペースが増えます。

B +-Treeは、B-Treeの最も人気のあるバリアントの1つです。 B +-Treeは、すべてのキーがリーフに存在する必要があるB-Treeを改良したものです。

Tツリーインデックス

Tツリーのデータ構造は、AVLツリーとBツリーの機能を組み合わせて設計されました。

AVLツリーは一種の自己平衡二分探索木ですが、Bツリーは不平衡であり、各ノードは異なる数の子を持つことができます。

Tツリーでは、構造はAVLツリーとBツリーに非常に似ています。

各ノードは、複数の{key-value、pointer}タプルを格納します。 また、バイナリ検索を複数タプルノードと組み合わせて使用​​して、ストレージとパフォーマンスを向上させます。

Tツリーには3つのタイプのノードがあります。右と左の子を持つTノード、子のないリーフノード、および子が1つしかないハーフリーフノードです。

TツリーはAVLツリーよりも全体的なパフォーマンスが優れていると考えられています。

O2-ツリーのインデックス作成

O2-Treeは基本的に、リーフノードに{key value、pointer}タプルが含まれている二分探索木の形式である赤黒木を改良したものです。

O2-Treeは、現在のインデックス作成方法のパフォーマンスを向上させるために提案されました。 次数m（m≥2）のO2-ツリー（mはツリーの最小次数）は、次のプロパティを満たします。

• すべてのノードは赤または黒のいずれかです。 根は黒です。
• すべてのリーフノードは黒で表示され、「キー値、レコードポインタ」のペアを保持するブロックまたはページで構成されます。
• ノードが赤の場合、その子は両方とも黒です。
• 内部ノードごとに、ノードから子孫リーフノードへのすべての単純なパスに同じ数の黒いノードが含まれます。 各内部ノードは単一のキー値を保持します。
• リーフノードは、⌈m/2⌉とm個の「キー値とレコードポインタ」のペアを持つブロックです。
• ツリーに単一のノードがある場合、それはツリーのルートであるリーフである必要があり、1〜m個の主要なデータ項目を持つことができます。
• リーフノードは、順方向と逆方向に二重にリンクされています。

ここでは、O2-Tree、T-Tree、B +-Tree、AVL-Tree、およびRed-BlackTreeのパフォーマンスを簡単に比較できます。

使用されたTツリー、B +ツリー、およびO2ツリーの順序はm=512でした。

検索、挿入、および削除の操作の時間が記録され、更新率は5,000万レコードのインデックスに対して0％〜100％の間で変化し、操作によってさらに5,000万レコードがインデックスに追加されます。

更新率が0〜10％の場合、BツリーとTツリーのパフォーマンスがO2ツリーよりも優れていることは明らかです。 ただし、更新率が高くなると、O2-Treeインデックスは他のほとんどのデータ構造よりも大幅にパフォーマンスが向上し、B-TreeおよびRed-BlackTree構造が最も影響を受けます。

NoSQLの場合？

NoSQLデータベースの簡単な紹介では、従来のリレーショナルデータベースでは不十分な主要な領域に焦点を当て、最初のポイントを紹介します。

リレーショナルデータベースは一貫性を提供しますが、大量のデータが頻繁に保存および処理されるアプリケーションでの高性能には最適化されていません。

NoSQLデータベースは、高いパフォーマンス、高いスケーラビリティ、およびアクセスのしやすさにより、多くの人気を博しました。 ただし、一貫性と信頼性を提供する機能はまだありません。

幸い、多くのNoSQL DBMSは、スケーラビリティと信頼性を強化する新機能を提供することで、これらの課題に対処しています。

すべてのNoSQLデータベースシステムがリレーショナルデータベースよりも優れたパフォーマンスを発揮するわけではありません。

MongoDBとCassandraは、書き込みおよび削除操作において、リレーショナルデータベースよりもパフォーマンスが類似しており、ほとんどの場合、パフォーマンスが優れています。

ストアタイプとNoSQLDBMSのパフォーマンスの間に直接的な相関関係はありません。 NoSQLの実装は変更されるため、パフォーマンスが異なる場合があります。

したがって、さまざまな調査のデータベースタイプ全体のパフォーマンス測定値は、これらの数値を正確にするために、常に最新バージョンのデータベースソフトウェアで更新する必要があります。

パフォーマンスについて明確な判断を下すことはできませんが、次の点に注意してください。

• 従来のBツリーおよびTツリーのインデックスは、従来のデータベースで一般的に使用されています。
• ある研究では、複数のインデックス構造の特性を組み合わせてO2ツリーを作成することにより、改善と機能強化を提供しました。
• O2-Treeは、特に巨大なデータセットと高い更新率で、ほとんどのテストで他の構造を上回りました。
• Bツリー構造は、この記事で取り上げたすべてのインデックス構造の中で最悪のパフォーマンスを実現しました。

NoSQL DBMSの整合性を強化するために、さらに作業を行うことができます。 NoSQLとリレーショナルデータベースの両方のシステムの統合は、さらに調査する領域です。

最後に、NoSQLは既存のデータベース標準への優れた追加ですが、いくつかの重要な注意点があることに注意することが重要です。 NoSQLは、信頼性と一貫性の機能を完全なパフォーマンスとスケーラビリティと交換します。 NoSQLデータベースに依存できるアプリケーションの数は限られているため、これにより特殊なソリューションになります。

良い面は？ 専門化は柔軟性の点であまり提供されないかもしれませんが、専門的な仕事をできるだけ迅速かつ効率的にやりたい場合は、スイスアーミーナイフは必要ありません。 NoSQLが必要です。