NoSQL（一般に "Not only SQL" と解釈される）とは、関係データベース管理システム (RDBMS) 以外のデータベース管理システムを指すおおまかな分類語である。関係データベースを杓子定規に適用してきた長い歴史を打破し、それ以外の構造のデータベースの利用・発展を促進させようとする運動の標語としての意味合いを持つ。関係モデルではないデータストアの特徴として、固定されたスキーマに縛られないこと、関係モデルの結合操作を利用しないこと、水平スケーラビリティが確保しやすい事が多いこと、高度なトランザクション処理を利用できないものが多いことなどが挙げられる。学術的な世界では、この種のデータベースのことを構造型ストレージ (structured storage) と呼ぶことが多い[1][2][3][4]。

NoSQL系データベース管理システムは、データの格納および取得が高度に最適化されているものが多い。その最適化のために機能性を最小限にしているものもある。その最たる例が、「値」およびそれを取得するための「キー」だけを格納できるKey-Value型データベースである。NoSQL系データベースは、関係データベースのような汎用性は欠くものの、その制約された条件下ではRDBMSより高いパフォーマンスを持つ。そのためビッグデータ系ソリューションでしばしば活用される。

NoSQL系データベース管理システムが有用な場面は、関係モデルを必要としないデータを扱う時や、大量のデータを扱う時である。用途は多様であり、数百万のkey-valueペアを格納したり、数10個程度の連想配列を格納したり、数百万の構造的データを格納したりと、様々に使われる。この構造は、大規模なデータを統計的に解析したり、増えつづける情報をリアルタイムに解析するのにも便利である。

産業界での有名な実装として、GoogleのBigTable、アマゾンのAmazon DynamoDBなどがある。オープンソースの実装も数多く存在し、例えばMongoDB、Redis、Apache HBase、Hypertable[5], Apache Cassandraなどがある。
歴史

NoSQLという用語は1998年、SQLインタフェースを持たない軽量な関係データベースのオープンソースソフトウェアの名前として最初に用いられた。その著者Carlo StrozziはNoSQL運動について、「関係モデル全体と一線を画すものであるから、『NoREL』などと名づけられるべきだった」と主張している[6]。この用語は、Last.fmのJohan Oskarssonの呼びかけによって2009年初頭に開催されたオープンソースの分散データベースについての会合において、Rackspace（英語版）の従業員Eric Evansによって再導入された[7]。この名前はMySQL、MS SQL、PostgreSQLなど関係データベースのシステムで広く用いられていた命名法を参照して付けられたものであり、ACID保証を提供しないような非関係型の分散データストアの勃興を表現する意図が込められていた。

NoSQL運動が普及するに従い、その名前のもつネガティブな印象（SQLは不要である、など）が問題となり議論が起こっている。Eric EvansはNoSQLをNot only SQLのバクロニムとして理解するのが好ましいとしている[8]。
アーキテクチャ

現代的な関係データベースは、小規模の高頻度なトランザクションか、巨大だが書き込みをほとんど伴わないトランザクションに最適化されて設計されているため、近年必要とされてきている大規模データに基づく (data-intensive) 応用事例では性能が劣化してしまう[9]。そのような応用の例として、検索のための文書のインデキシング、トラフィックの高いウェブサイトのサーバ、ストリーミングデータの配布などがあり、Diggのgreen badge[10]、Facebookのインボックスの検索、eBayのシステム全体などがその実例である。

NoSQLのアーキテクチャにおいては、結果整合性のみを保証するなどして一貫性の保証を弱く設計したり、トランザクションをひとつのデータアイテムに限るという制限を設けたりすることが多い。補助的なミドルウェアの層を付加することによって完全なACID保証を提供している場合もある[11]。

いくつかのNoSQLシステムは分散アーキテクチャを採用している。そのようなシステムでは、多くの場合は分散ハッシュテーブルを用いて、データを複数のサーバに冗長性を持たせながら配置する。これにより、サーバを追加するだけでシステムを容易にスケールアップさせることができ、障害への耐性も強くなる[12]。
分類

NoSQL には、主要なものとして、以下のものがある[13]。

キー・バリュー型 (Key Value Store) - キーに対してバリュー（値）という単純な構造。Basho Riak, Redis,Amazon DynamoDBなど。大半はバリューとして単純なバイナリデータ (BLOB) のみが格納できるが、Redisのようにリスト、マップ、ソート済みセットといったリッチなデータ構造をサポートするものもある。またバリューに加えて、タグやメタデータと呼ばれる追加情報が格納できるものも多い。日本発のものには okuyama, Hibari などがある。

ソート済みカラム指向 - 行キーに対してカラム（名前と値の組み合わせ）の集合を持つ。行ごとに好きな名前のカラムを好きな数だけ格納できる。カラムはカラム名によってソートされるため、例えばカラム名に時刻を使うことで1行の中に時系列のデータを格納することができる。Apache Cassandra, Apache HBaseなど。

ドキュメント指向（Document-oriented、Document store） - XMLやJSONといった、 スキーマレスでデータ構造が柔軟なもの。MongoDB、Apache CouchDB、Amazon DocumentDBなど。XMLデータベースなどのシステムでは、XQueryを利用できるものもある。

グラフ指向 - ノード（頂点）とエッジ（辺）とプロパティ（属性）の３つの要素から構成され、ノード間の関係を管理することに特化したデータベース。Neo4j、Amazon Neptuneなど。

オープンソースのプロジェクト一覧

Apache Cassandra - 分散データベース、ソート済みカラム指向型

Apache CouchDB - ドキュメント指向型

Apache HBase - 分散データベース、ソート済みカラム指向型

⇒ArangoDB - multi-model database

Basho Riak - 分散データベース、キー・バリュー型

Chordless

Db4o - オブジェクトデータベース（Javaオブジェクトなどの格納）

GT.M

Hibari - 分散データベース、キー・バリュー型（日本発）

Hypertable - 分散データベース、ソート済みカラム指向型

Memcachedb

Mnesia - 分散データベース

MongoDB - 分散データベース、ドキュメント指向型

okuyama - 分散データベース、キー・バリュー型（日本発）

Project Voldemort - 分散データベース、キー・バリュー型

Redis - インメモリ・データベース、キー・バリュー型（リスト、マップ、ソート済みセットなど）

ScyllaDB - 分散データベース、Apache CassandraをC++へと移植し高速化したもの

SimpleDB

⇒Neo4j - グラフ型

⇒DEX

BaseX

⇒eXist

⇒AllegroGraph

⇒OrientDB

⇒InfiniteGraph - グラフ型

⇒Sones GraphDB

⇒InfoGrid

⇒HyperGraphDB

実装例
ドキュメントストア

名称言語補足
BaseXJava, XQueryXMLデータベース
Cloudant（英語版）Erlang, Java, Scala, CJSONストア（オンラインサービス）
Clusterpoint（英語版）C++XML, 全文検索
Couchbase ServerErlang, C, C++JSONとバイナリドキュメント
Apache CouchDBErlangJSONデータベース
djondb[14][15][16]C++JSON, ACIDドキュメントストア
SolrJavaサーチエンジン
ElasticsearchJavaJSON, サーチエンジン