ノーSQL

NoSQL (元々は「非SQL」または「非リレーショナル」を指していた) ^[1]は、リレーショナル データベースで使用される表形式の関係以外の方法でモデル化されたデータの保存と取得のメカニズムを提供することに重点を置いたデータベース設計のアプローチです。リレーショナル データベースの一般的な表形式構造の代わりに、NoSQL データベースは 1 つのデータ構造内にデータを格納します。この非リレーショナル データベース設計はスキーマを必要としないため、大規模で通常は構造化されていないデータ セットを管理するための迅速なスケーラビリティを提供します。^[2] NoSQL システムは、SQLのようなクエリ言語をサポートしたり、多言語永続アーキテクチャで SQL データベースと並んで使用したりできることを強調するために、「SQL だけではない」と呼ばれることもあります。^{[3] [4]}

非リレーショナルデータベースは1960年代後半から存在していましたが、「NoSQL」という名前は2000年代初頭にWeb 2.0企業のニーズに刺激されて造られました。 ^{[5] [6] [ 7] NoSQLデータベースは、}ビッグデータやリアルタイムWebアプリケーションでますます使用されています。^[8]

このアプローチの動機としては、設計の単純さ、マシンのクラスタへのより単純な「水平」スケーリング（これはリレーショナルデータベースでは問題である）、^[5]可用性のより細かい制御、およびオブジェクトリレーショナルインピーダンスミスマッチの制限などが挙げられる。^[9] NoSQLデータベースで使用されるデータ構造（キーと値のペア、ワイドカラム、グラフ、またはドキュメントなど）は、リレーショナルデータベースでデフォルトで使用されるものとは異なっており、NoSQLでは一部の操作が高速化される。特定のNoSQLデータベースの特定の適合性は、解決しなければならない問題によって決まる。NoSQLデータベースで使用されるデータ構造は、リレーショナルデータベーステーブルよりも「柔軟」であると見なされることもある。^[10]

多くの NoSQL ストアは、可用性、分断耐性、速度を優先して、一貫性 ( CAP 定理の意味で) を犠牲にしています。NoSQL ストアの採用拡大を阻む障壁としては、低レベルのクエリ言語(SQL の代わりになど) の使用、テーブル間でアドホック結合を実行できないこと、標準化されたインターフェイスがないこと、既存のリレーショナル データベースへの多大な投資などが挙げられます。^[11]ほとんどの NoSQL ストアには真のACIDトランザクションがありませんが、 MongoDBなどのいくつかのデータベースでは、 ACID トランザクションを設計の中心に据えています。^[12]

代わりに、ほとんどの NoSQL データベースは「結果的一貫性」という概念を提供します。これは、データベースの変更が「最終的に」（通常は数ミリ秒以内）すべてのノードに伝播されるため、データのクエリによって更新されたデータがすぐに返されないか、正確でないデータが読み取られる可能性があり、これは古い読み取りと呼ばれる問題です。^[13]さらに、一部の NoSQL システムでは、書き込みの損失やその他の形式のデータ損失が発生する場合があります。^[14]一部の NoSQL システムでは、データ損失を回避するために、先行書き込みログなどの概念が提供されています。 ^{[15]複数のデータベースにわたる}分散トランザクション処理の場合、データの一貫性はさらに大きな課題であり、NoSQL とリレーショナル データベースの両方にとって困難です。リレーショナル データベースでは、「参照整合性制約がデータベースにまたがることはできません」。^[16]分散トランザクション処理用のACIDトランザクションとX/Open XA標準の両方を維持しているシステムはほとんどありません。^[17]インタラクティブなリレーショナル データベースは、共通機能としてコンフォメーション リレー分析手法を共有しています。^[18]インターフェース環境内の制限はセマンティック仮想化プロトコルを使用することで克服され、NoSQLサービスはほとんどのオペレーティングシステムからアクセス可能になります。^[19]

NoSQLという用語は、1998年にCarlo Strozziによって、標準の構造化照会言語（SQL）インターフェースを公開していないがリレーショナルである軽量のStrozzi NoSQLオープンソースリレーショナルデータベースに名前を付けるために使用されました。 ^[20]彼のNoSQL RDBMSは、2009年頃のNoSQLデータベースの一般的な概念とは異なります。Strozziは、現在のNoSQLの動きは「リレーショナルモデルから完全に逸脱しているため、より適切に「NoREL」と呼ばれるべきだった」と示唆しています^[21]。これは「リレーショナルではない」ことを意味します。

当時Last.fmの開発者だったヨハン・オスカーソンは、2009年初頭に「オープンソースの分散型非リレーショナルデータベース」について議論するイベントを開催した際に、NoSQLという用語を再導入しました。^{[22]この名前は、Googleの}Bigtable / MapReduceやAmazonのDynamoDBのオープンソースクローンを含む、非リレーショナル分散型データストアの増加を示すために付けられました。

NoSQLデータベースを分類する方法は様々で、カテゴリやサブカテゴリが異なり、一部は重複しています。以下はデータモデルによる非網羅的な分類と例です。^[23]

キーバリュー（KV）ストアは、連想配列（マップまたは辞書とも呼ばれる）を基本的なデータモデルとして使用します。このモデルでは、データはキーと値のペアのコレクションとして表現され、各キーはコレクション内で最大1回出現します。^{[26] [27]}

キーバリューモデルは最も単純で重要なデータモデルの一つであり、より豊富なデータモデルは多くの場合、その拡張として実装されます。キーバリューモデルは、キーを辞書式順序で維持する離散順序モデルに拡張できます。この拡張は計算的に強力であり、選択したキー範囲を効率的に取得できます。^[28]

キーバリューストアは、結果整合性からシリアル化可能性まで、一貫性モデルを使用できます。一部のデータベースはキーの順序付けをサポートしています。さまざまなハードウェア実装があり、データをメモリ (RAM) に保存するユーザーもいれば、ソリッドステートドライブ(SSD) や回転ディスク(別名ハードディスクドライブ (HDD)) に保存するユーザーもいます。

ドキュメント ストアの中心的な概念は、「ドキュメント」です。この定義の詳細はドキュメント指向データベースによって異なりますが、ドキュメントはデータ (または情報) を何らかの標準形式またはエンコーディングでカプセル化してエンコードすることを前提としています。使用されているエンコーディングには、XML、YAML、JSON、およびBSONなどのバイナリ形式があります。ドキュメントは、そのドキュメントを表す一意のキーを介してデータベース内でアドレス指定されます。ドキュメント指向データベースのもう 1 つの定義特性は、コンテンツに基づいてドキュメントを取得するための APIまたはクエリ言語です。

実装によって、ドキュメントを整理およびグループ化する方法が異なります。

• コレクション
• タグ
• 非表示のメタデータ
• ディレクトリ階層

リレーショナル データベースと比較すると、コレクションはテーブルに類似しており、ドキュメントはレコードに類似していると考えられます。ただし、これらは異なります。テーブル内のすべてのレコードは同じフィールドのシーケンスを持ちますが、コレクション内のドキュメントにはまったく異なるフィールドがある場合があります。

グラフ データベースは、有限数の関係で接続された要素で構成されるグラフとして関係が適切に表現されるデータ用に設計されています。データの例としては、社会的関係、公共交通機関のリンク、道路地図、ネットワーク トポロジなど が挙げられます。

グラフデータベースとそのクエリ言語

NoSQL データベースのパフォーマンスは通常、操作数/秒で測定されるスループットのメトリックを使用して評価されます。パフォーマンス評価では、運用構成、データベースのパラメータ、予想されるデータ量、同時ユーザーワークロードなどの適切なベンチマークに注意を払う必要があります。

ベン・スコフィールドは、NoSQLデータベースのさまざまなカテゴリを次のように評価しました。^[30]

パフォーマンスとスケーラビリティの比較は、 YCSBベンチマークを使用して最も一般的に行われます。

ほとんどの NoSQL データベースはクエリでの結合機能がないため、データベース スキーマを通常、異なる方法で設計する必要があります。NoSQL データベースでリレーショナル データを処理するには、主に 3 つの手法があります。(結合をサポートする NoSQL データベースについては、「結合と ACID サポート」の表を参照してください。)

1 つのクエリですべてのデータを取得する代わりに、必要なデータを取得するために複数のクエリを実行するのが一般的です。NoSQL クエリは従来の SQL クエリよりも高速であることが多いため、追加のクエリにかかるコストは許容範囲内です。必要となるクエリの数が多すぎる場合は、他の 2 つのアプローチのいずれかが適しています。

外部キーのみを保存するのではなく、モデルのデータと一緒に実際の外部値を保存するのが一般的です。たとえば、各ブログコメントにはユーザーIDに加えてユーザー名が含まれている場合があり、これにより別の検索を必要とせずにユーザー名に簡単にアクセスできます。ただし、ユーザー名が変更されると、データベースの多くの場所でユーザー名を変更する必要があります。したがって、このアプローチは、書き込みよりも読み取りがはるかに多い場合に適しています。^[31]

MongoDB のようなドキュメント データベースでは、より多くのデータを少数のコレクションに格納するのが一般的です。たとえば、ブログ アプリケーションでは、ブログ投稿ドキュメント内にコメントを保存して、1 回の検索ですべてのコメントを取得できるようにすることができます。したがって、このアプローチでは、特定のタスクに必要なすべてのデータが 1 つのドキュメントに含まれます。

データベースのドキュメントにその旨が記載されている場合、データベースはACIDプロパティ (原子性、一貫性、独立性、永続性) または結合操作をサポートしているとマークされます。ただし、これは必ずしもほとんどの SQL データベースと同様に機能が完全にサポートされていることを意味するわけではありません。

DynamoDB、MongoDB、Cassandra 、Couchbase、HBase、Redisなどのさまざまな NoSQL データベースは、インデックス化されていないフィールドをクエリするときにさまざまな動作を示します。多くのデータベースでは、このようなクエリに対してテーブル全体またはコレクション全体のスキャンを実行し、データを取得した後にフィルタリング操作を適用します。ただし、最新の NoSQL データベースには、クエリのパフォーマンスを最適化するための高度な機能が組み込まれていることがよくあります。たとえば、MongoDB は複合インデックスとクエリ最適化戦略をサポートし、Cassandra はセカンダリ インデックスとマテリアライズド ビューを提供し、Redis は特定のユース ケースに合わせたカスタム インデックス メカニズムを採用しています。Elasticsearch などのシステムでは、効率的なテキストベースの検索に転置インデックスを使用しますが、インデックス化されていないフィールドに対しては完全なスキャンが必要になる場合があります。この動作は、多くの NoSQL システムの設計が、任意のフィールドの最適化されたクエリではなく、スケーラビリティと効率的なキーベースの操作に重点を置いていることを反映しています。その結果、これらのデータベースは基本的なCRUD操作とキーベースの検索に優れていますが、結合や非インデックスフィルタリングを含む複雑なクエリへの適合性は、データベースの種類（ドキュメント、キー値、ワイドカラム、グラフ）と特定の実装によって異なります。^[35]

• CAP定理
• オブジェクトデータベース管理システムの比較
• 構造化ストレージソフトウェアの比較
• C++
• データベースのスケーラビリティ
• 分散キャッシュ
• ファセット検索
• マルチバリューデータベース
• マルチモデルデータベース
• スキーマに依存しないデータベース
• トリプルストア
• ベクターデータベース

• Sadalage, Pramod、Fowler, Martin (2012)。NoSQL Distilled: ポリグロット永続性の新たな世界への簡潔なガイド。Addison- Wesley。ISBN 978-0-321-82662-6。
• McCreary, Dan; Kelly, Ann (2013) 。NoSQL を理解する: マネージャーとその他のユーザーのためのガイド。Manning。ISBN 9781617291074。
• Wiese, Lena (2015). SQL、 NoSQL 、クラウド、分散データベース向けの高度なデータ管理。DeGruyter/Oldenbourg。ISBN 978-3-11-044140-6。
• Strauch, Christof (2012) 「NoSQL データベース」(PDF)。
• Moniruzzaman, AB; Hossain, SA (2013). 「NoSQL データベース: ビッグ データ分析のためのデータベースの新時代 - 分類、特性、比較」. arXiv : 1307.0191 [cs.DB].
• Orend, Kai (2013)。「NoSQL データベースの分析と分類、およびオブジェクト リレーショナル永続化レイヤーを置き換える能力の評価」。CiteSeerX 10.1.1.184.483 。
• クリシュナン、ガネーシュ。クルカルニ、サラン。ダドバワラ、ダルメシュ・キリット。 「バージョン管理された情報の共有、統合、およびレポートのための方法とシステム」。

• ストラウフ、クリストフ。 「NoSQL ホワイトペーパー」(PDF)。シュトゥットガルト: メディア大学。
• Edlich、Stefan。「NoSQL データベース リスト」。
• Neubauer, Peter (2010)。「グラフ データベース、NOSQL、Neo4j」。
• Bushik, Sergey (2012)。「ベンダーに依存しない NoSQL データベースの比較: Cassandra、HBase、MongoDB、Riak」。NetworkWorld。
• Zicari, Roberto V. (2014)。「NoSQL データ ストア - 記事、論文、プレゼンテーション」。odbms.org。