ある特定の品物を購入した顧客のモバイル端末にクーポンをプッシュしたいというユースケースを想定してほしい。これは顧客を対象にしたシステムオブエンゲージメント(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発の記事を朝日インタラクティブが日本向けに編集したものです。