Loading article…
NoSQL （「 SQLだけではない」または「非リレーショナル」を意味する口語的な名称が正式な名称になった） [ 1 ]は、リレーショナルデータベースの従来のテーブルベースの構造とは異なる方法でデータを格納および取得するデータベース設計の一種を指します。スプレッドシートのようにデータを行と列に整理するリレーショナルデータベースとは異なり、NoSQLデータベースは、キーと値のペア、ワイド列、グラフ、ドキュメントなどの単一のデータ構造を使用して情報を保持します。この非リレーショナル設計は固定スキーマを必要としないため、大規模で多くの場合非構造化されたデータセットの管理に容易に拡張できます。[ 2 ] NoSQLシステムは、 SQLライクなクエリ言語をサポートしたり、複数のデータベースタイプが組み合わされたポリグロット永続設定でSQLデータベースと連携して動作したりできるため、 「SQLだけではない」と呼ばれることもあります。[ 3 ] [ 4 ]非リレーショナルデータベースは1960年代後半に遡りますが、「NoSQL」という用語は、ソーシャルメディアプラットフォームなどのWeb 2.0企業のニーズに後押しされて2000年代初頭に登場しました。[ 5 ] [ 6 ]
NoSQL データベースは、シンプルな設計、マシンのクラスタ全体にわたるスケーリング機能(水平スケーリングと呼ばれる)、およびデータ可用性の精密な制御により、ビッグデータやリアルタイム Webアプリケーションで人気があります。[ 7 ] [ 8 ]これらの構造は特定のタスクを高速化でき、固定データベース テーブルよりも適応性が高いとみなされることがよくあります。[ 9 ]しかし、多くの NoSQL システムでは、厳密な一貫性 ( CAP 定理による) よりも速度と可用性を優先し、結果的一貫性を使用しています。これは、更新が最終的にすべてのノードに到達し、通常はミリ秒以内ですが、最新のデータへのアクセスにわずかな遅延 (古い読み取りとして知られています) を引き起こす可能性があります。[ 10 ]ほとんどのシステムでは完全なACIDトランザクション サポートがありませんが、MongoDBのように、それを主要な機能として含めているものもあります。[ 11 ]
NoSQL の普及を阻む障壁としては、SQL の代わりに低レベルのクエリ言語を使用していること、テーブル間でアドホックな結合を実行できないこと、標準化されたインターフェースがないこと、リレーショナル データベースに既に多額の投資が行われていることが挙げられます。[ 12 ]一部の NoSQL システムでは、書き込みの失敗やその他の方法でデータが失われるリスクがありますが、書き込み先読みロギング(変更を適用する前に記録する方法) などの機能によってこれを防ぐことができます。[ 13 ] [ 14 ]複数のデータベースにまたがる分散トランザクション処理では、リレーショナル データベースは別々のデータベースをリンクするルールを強制できないため、データの一貫性を維持することは NoSQL システムとリレーショナル システムの両方にとって課題です。また、分散更新を管理するためのACIDトランザクションとX/Open XA標準の両方をサポートするシステムはほとんどありません。 [ 15 ] [ 16 ]インターフェース環境内の制限は、セマンティック仮想化プロトコルを使用することで克服され、NoSQL サービスはほとんどのオペレーティングシステムからアクセス可能になります。[ 17 ]
NoSQLという用語は、1998年にカルロ・ストロッツィが、標準の構造化クエリ言語（SQL）インターフェースを公開しないものの、リレーショナルな軽量オープンソースリレーショナルデータベースであるStrozzi NoSQLに命名するために使用しました。 [ 18 ]彼のNoSQL RDBMSは、2009年頃の一般的なNoSQLデータベースの概念とは異なります。ストロッツィは、現在のNoSQLムーブメントは「リレーショナルモデルから完全に逸脱しているため、より適切には「NoREL」と呼ばれるべきだったと示唆しています。 [ 19 ]これは「リレーショナルではない」という意味です。
当時Last.fmの開発者だったヨハン・オスカールソンは、2009年初頭に「オープンソースの分散型非リレーショナルデータベース」について議論するイベントを企画した際に、NoSQLという用語を再び導入した。 [ 20 ]この名称は、GoogleのBigtable / MapReduceやAmazonのDynamoDBのオープンソースクローンなど、非リレーショナルな分散型データストアの出現をラベル付けしようとしたものである。
NoSQLデータベースを分類する方法は様々で、異なるカテゴリとサブカテゴリがあり、一部は重複しています。以下は、データモデルによる分類の例を網羅的ではない形で示したものです。[ 21 ]
キーバリュー (KV) ストアは、連想配列(マップまたは辞書とも呼ばれる) を基本的なデータ モデルとして使用します。このモデルでは、データはキーと値のペアのコレクションとして表現され、各キーはコレクション内に最大で 1 回出現します。[ 24 ] [ 25 ]
キーバリューモデルは、最も単純な非自明なデータモデルの1つであり、よりリッチなデータモデルはしばしばその拡張として実装されます。キーバリューモデルは、キーを辞書式順序で保持する離散順序モデルに拡張できます。この拡張は、選択的なキー範囲を効率的に取得できるため、計算能力に優れています。[ 26 ]
キーバリューストアは、結果整合性から直列化可能性まで、さまざまな整合性モデルを使用できます。一部のデータベースはキーの順序付けをサポートしています。ハードウェア実装も多様で、データをメモリ（RAM）に保存するユーザーもいれば、ソリッドステートドライブ（SSD）や回転ディスク（ハードディスクドライブ（HDD）とも呼ばれる）に保存するユーザーもいます。
ドキュメントストアの中心概念は「ドキュメント」です。ドキュメント指向データベースによって定義の詳細は異なりますが、いずれもドキュメントが何らかの標準フォーマットまたはエンコーディングでデータ（または情報）をカプセル化してエンコードすることを前提としています。使用されているエンコーディングには、XML、YAML、JSON、およびBSONのようなバイナリ形式があります。ドキュメントは、そのドキュメントを表す一意のキーによってデータベース内でアクセスされます。ドキュメント指向データベースのもう1つの特徴は、ドキュメントの内容に基づいてドキュメントを取得するためのAPIまたはクエリ言語です。
実装方法によって、文書の整理やグループ化の方法が異なります。
リレーショナルデータベースと比較すると、コレクションはテーブルに、ドキュメントはレコードに相当すると考えることができます。しかし、両者には違いがあります。テーブル内のすべてのレコードは同じフィールドの順序を持ちますが、コレクション内のドキュメントは完全に異なるフィールドを持つ可能性があります。
グラフデータベースは、有限個の関係で結ばれた要素からなるグラフとして、その関係が適切に表現できるデータ向けに設計されています。データの例としては、社会的関係、公共交通機関の路線図、道路地図、ネットワークトポロジーなどが挙げられます。
NoSQLデータベースのパフォーマンスは通常、 1秒あたりの操作数で測定されるスループットという指標を用いて評価されます。パフォーマンス評価においては、本番環境の構成、データベースのパラメータ、想定されるデータ量、同時ユーザーワークロードなど、適切なベンチマークに注意を払う必要があります。
ベン・スコフィールドは、NoSQLデータベースのさまざまなカテゴリを次のように評価しました。[ 28 ]
パフォーマンスと拡張性の比較は、 YCSBベンチマークを使用して行われるのが一般的です。
ほとんどのNoSQLデータベースはクエリにおける結合機能を持たないため、データベーススキーマの設計方法は通常異なります。NoSQLデータベースでリレーショナルデータを扱うには、主に3つの手法があります。（結合をサポートするNoSQLデータベースについては、テーブル結合とACIDサポートを参照してください。）
1回のクエリで全てのデータを取得するのではなく、複数のクエリを実行して目的のデータを取得するのが一般的です。NoSQLクエリは従来のSQLクエリよりも高速な場合が多いため、追加のクエリによるコストは許容範囲内となる可能性があります。ただし、クエリ数が過剰になる場合は、他の2つのアプローチのいずれかがより適切です。
外部キーのみを保存するのではなく、モデルのデータとともに実際の外部値を保存するのが一般的です。たとえば、各ブログコメントにはユーザーIDに加えてユーザー名が含まれる場合があり、これにより別の検索を必要とせずにユーザー名に簡単にアクセスできます。ただし、ユーザー名が変更されると、データベース内の多くの場所で変更する必要が生じます。したがって、このアプローチは、書き込みよりも読み取りがはるかに多い場合に効果的です。[ 29 ]
MongoDBのようなドキュメントデータベースでは、少数のコレクションに多くのデータを格納するのが一般的です。例えば、ブログアプリケーションでは、コメントをブログ記事のドキュメント内に保存することで、一度の取得で全てのコメントを取得できます。このように、このアプローチでは、単一のドキュメントに特定のタスクに必要なすべてのデータが含まれます。
データベースのドキュメントにACID特性（原子性、一貫性、分離性、永続性）または結合操作をサポートしていると記載されている場合、そのデータベースはACID特性をサポートしているとみなされます。ただし、これは必ずしも、ほとんどのSQLデータベースと同様の方法でその機能が完全にサポートされていることを意味するものではありません。
DynamoDB、MongoDB、Cassandra、Couchbase 、HBase、RedisなどのさまざまなNoSQLデータベースは、インデックスのないフィールドをクエリする際に異なる動作を示します。多くの場合、このようなクエリに対してテーブル全体またはコレクション全体をスキャンし、データ取得後にフィルタリング操作を適用します。しかし、最新のNoSQLデータベースは、クエリのパフォーマンスを最適化するための高度な機能を備えていることがよくあります。たとえば、MongoDBは複合インデックスとクエリ最適化戦略をサポートし、Cassandraはセカンダリインデックスとマテリアライズドビューを提供し、Redisは特定のユースケースに合わせてカスタマイズされたインデックスメカニズムを採用しています。Elasticsearchのようなシステムは、効率的なテキストベースの検索のために転置インデックスを使用しますが、インデックスのないフィールドに対しては依然としてフルスキャンが必要になる場合があります。このような動作は、多くのNoSQLシステムが、任意のフィールドに対する最適化されたクエリよりも、スケーラビリティと効率的なキーベースの操作に重点を置いて設計されていることを反映しています。したがって、これらのデータベースは基本的なCRUD操作やキーベースの検索には優れているものの、結合やインデックスなしのフィルタリングを含む複雑なクエリへの適合性は、データベースの種類（ドキュメント、キーバリュー、ワイドカラム、グラフ）や具体的な実装によって異なります。[ 33 ]
NoSQLデータベースは、Not Only SQLとも呼ばれます。
の多くの支持者は、NoSQLはSQLを「否定」するものではなく、「SQLだけではない」という意味だと述べている。
キーバリュー ストアを使用すると、アプリケーション開発者はスキーマレス データを格納できます。このデータは通常、キーを表す文字列と、「キーと値」の関係で値とみなされる実際のデータで構成されます。データ自体は通常、プログラミング言語の何らかのプリミティブ (文字列、整数、または配列) またはプログラミング言語のキーバリュー ストアへのバインディングによってマーシャリングされるオブジェクトです。この構造により、固定データ モデルの必要性がなくなり、適切なフォーマットが可能になります。
キーバリューストアは、データの保存とアクセスに関して、リレーショナルデータベースシステムに代わる高性能な選択肢を提供します。この論文では、現在利用可能なキーバリューストアのいくつか、およびそれらのRubyプログラミング言語とのインターフェースについて簡単に概説します。