ある特定の品物を購入した顧客のモバイル端末にクーポンをプッシュしたいというユースケースを想定してほしい。これは顧客を対象にしたシステムオブエンゲージメント（SoE）であり、位置情報や購入履歴、ウォレット（財布）データなどを必要とする。これによって、モバイル顧客のリアルタイムでのエンゲージメントを図りたいはずだ。
ここで必要になるのは、構造化されていないデータを簡単に処理できる、アジリティの非常に高いシステムを実現することだ。SoEは極限まで動的なものになっていなければならない。
従来のデータベース製品は、予測しやすい構造化されたデータの取り扱いに長けている。そしてリレーショナルデータベースでは、そのデータ容量や処理能力に対する要求が大きくなるとともに、サーバ群の垂直拡張、そして場合によっては水平拡張が必要となることもある。
こういったアプローチの代替として、よりクラウドフレンドリーなNoSQLの使用がある。
負荷の増大に対しては、安価でありふれたIntelベースのサーバを多数配備し、負荷分散を図ることで容易に対応できる。NoSQLデータベースはまさに、われわれのSoEで必要となる、構造化されていない雑多で予測不能なデータを取り扱うのに打って付けのものなのだ。
NoSQLはデータベースに対するまったく新たな考え方だ。NoSQLはリレーショナルデータベースとは異なっている。そして、リレーショナルデータベースは、どのような状況に対しても最適なソリューションとなるわけではないという現実がある。NoSQLの特徴をひと言で述べると、従来のリレーショナルデータベース管理システム（RDBMS）構造にとらわれないデータベースということになる。なお、NoSQLは「Not only SQL」と呼ばれる場合もある。
NoSQLはテーブルをベースにして構築されるわけではなく、データの操作にSQLを用いるわけでもない。また、トランザクションシステムに必要となるACID（Atomicity：不可分性、Consistency：一貫性、Isolation：独立性、Durability：永続性）を完全に保証しない場合もあるものの、分散アーキテクチャや耐障害性アーキテクチャを有している。
NoSQLの分類としては、Key-Valueストアやドキュメントストア、BigTable、グラフ型データベースなどがある。
例えばMongoDBはドキュメントモデルを使用しており、これはRDBMS中の行になぞらえることができる。ドキュメント、すなわち一連のフィールド（Key-Valueペア）はプログラミング言語のデータ型にうまく当てはまる。MongoDBデータベースでは、一連のドキュメントがコレクションとして保持される。また、埋め込みドキュメントや配列を用いることで、結合処理（パフォーマンスや速度の向上に大きな影響を与える）の必要性を低減している。
なぜNoSQLを選ぶのか？その理由は、高い可用性と高いパフォーマンスが実現できるとともに、リッチなクエリ言語が提供され、高いスケーラビリティが容易に確保できるためだ。
この記事は海外CBS Interactive発の記事を朝日インタラクティブが日本向けに編集したものです。
