はじめに

NoSQLというキーワードが登場してから、長い年月が経ちました。

ここでは、Couchbaseという、一つの（比較的後発の）NoSQLデータベースに注目しながら、NoSQLという技術の現在について考えてみたいと思います。

まずは、現在の情報技術を取り巻く環境について、振り返ることから始めます。

DXとSoE

DX (Digital Transformation)

デジタルトランスフォーメーション、DXについて、経済産業省資料『「DX 推進指標」とそのガイダンス』では、以下のように定義されています。

企業がビジネス環境の激しい変化に対応しデータとデジタル技術を活用して、
顧客や社会のニーズを基に製品やサービス、ビジネスモデルを変革するとともに
業務そのものや組織、プロセス、企業文化・風土を変革し競争上の優位性を確立すること

ここで、トランスフォーメーション、つまり変革の対象とされているものは二つあります。一つは、企業が生み出し、顧客に提供する製品やサービス、そしてもう一つは、企業内部の業務プロセスです。
そして、この変革は、「顧客や社会のニーズを基に」したものであるとされています。

極めて、当たり前のことが語られているようにみえます。一方で、こう考えることもできるのではないでしょうか、つまり、これまでも確かに情報技術によって変革が行われてきた、ただしそれは(十分に)「顧客や社会のニーズ」に基づくものではなかった、と。

SoE (System of Engagement)

SoE、エンゲージメント（のため）のシステム。つまりユーザーとの「つながり」を掲げたシステム。この「SoE」が語られる文脈では、旧来からあるシステムは、SoR（システムオブレコード）、「記録」（のため）のシステム、と呼ばれることになります。

「そもそも、データを記録しないシステムなどありえるのか」という素朴な疑問（SoEと言われるシステムであっても、当然データを記録します）を持つことは、おかしなことでしょうか？そもそも、「データを記録すること」は、「システム」の定義そのものとさえ言えるのではないか、という気さえします。
新しい言葉の誕生に立ち会う時、私たちは、その概念が登場する前の風景がどういったものだったか、に思いを巡らすことになります。いかに、今までの（私たちが当たり前と思っていた）システムが（その時点の技術で）できること、システムにとって得意なことから発想されており、ユーザとのエンゲージメントから発想されたものでなかった（そのために十分にテクノロジーが発展していなかった）と、そのように考えることも出来そうです。

データベースを分類

データベースの分類といった時、（NoSQL登場以前には）RDBとDWH（データウェアハウス）という区分が、最も定番といえるものでした。そして、それは、基盤系と情報系というシステムの分類に直結していました。また、OLTP（OnLine Transaction Processing）とOLAP（OnLine Analytical Processing）というペアも、ここで思い起こしても良いでしょう。
NoSQL（NOまたは、Not Only SQL）という言葉の登場により、データベースの分類に、混乱が招き入れられました。実際「従来のものと異なる」という意味でしかない言葉を使って、具体的な（システムの目的たるビジネス上意味のある）コミュニケーションは、成り立つはずがなく、純粋なバズワードとして機能したのみでした。乱暴に言えば、NoSQLは、ビッグデータという言葉との組み合わせによる類推から、広い意味で「情報系」というカテゴリーに投げ入れられることになりました。それは結局、「Nice To Have」であり、DWHよりも、いたずらに複雑なものでしかない、ことを意味しました（極端な内容を断言しているようですが、そういう見方もある、と受け止めていただければ、と思います）。

エンゲージメントのためのデータベース

ここで、DX（という言葉）の隆盛を鑑みつつ、SoEのひそみにならって、エンゲージメントのためのデータベース、というものを考えてみたいと思います。

エンゲージメントのためのシステムにふさわしいデータプラットフォームとはどのようなものでしょうか？
SoEとSoRの境界を考えてみる時、例えば、（インターネット上での）ユーザの行動という視点から次のようにイメージすることができます。

SoRの範囲：ネットショッピングで、買い物をする瞬間
SoEの範囲：（インターネットに触れている）それ以外の全ての時間

SoEとSoRの違い

このような適用範囲の違いを踏まえて、SoEとSoRの間のシステムの性格の違いとして、以下の３点を挙げたいと思います。

ユーザーの規模感

システムを利用するユーザーの規模は、SoRの非ではない。さらに、システムは、増え続けるユーザー数増加・利用量増加対に応していく必要がある

サービスの柔軟性

新しいサービスを素早くリリースすることが重要。また、サービスは常に環境、つまりユーザーとの関係の変化に応じて更新されなければならない

要求される応答速度

サービスの多様化に合わせて、システムは複雑になり続ける。それに応じて、システムの各構成要素、例えば、データプラットフォームの応答速度として許容される時間は短くなる

対応する技術要素

そして、これらは（「NoSQL」と呼ばれた）新しいデータベースの以下の技術要素にそれぞれ対応している、ということが言えます。

分散アーキテクチャー

「分散アーキテクチャー」という特徴は、多くのNoSQL（およびNewSQL）データベースに共通しています（ただし、そのスケールに対する柔軟性については、大きな違いがあります）。

スキーマレス

「スキーマレス」という特徴も、多くのNoSQLに共通しています。任意のキーを用いてデータを格納するキーバリューストア（例えば、Redis）と、列指向データベース（例えばHBase、Cassandra）、JSONというツリー構造のデータ記述フォーマットを用いるドキュメント指向データベース(例えば、MongoDB)は、全てNoSQLに分類されますが、スキーマレスという共通の特徴を持ちます。データ構造の柔軟性については、ツリー構造を表現でき、アプリケーションのデータ（ビジネスドメインオブジェクト）をそのまま格納することのできる、ドキュメント指向データベースに軍配が上がると言えるでしょう。

インメモリ

最後の「インメモリ」については、オープンソースのNoSQLとしては、Redisが代表的と言えます。一般には、インメモリの特徴を持つデータベースは、（単体でアプリケーションのキャッシュとして用いるのでなければ）永続化層を担う他のデータベースと組み合わせて利用することによって、高い応答性能という特性を持つデータプラットフォームを実現することができます。

結論：エンゲージメントのためのデータベースとしてのCouchbase

Couchbase Serverは、上に挙げた全ての特徴を持ちます。

NoSQLにカテゴライズされるデータベースには、それぞれ、ビッグデータの集計処理や、リアルタイムかつ大量データの投入等のように、異なった典型的なユースケースがあります。
Couchbase Serverは、データに対して、リード/ライトの両方のアクセスを、低遅延で実現する必要のある（つまり、インタラクティブな）アプリケーションのバックエンドとして用いられるために設計（最適化）されています。
そして、上で述べてきた、３つの技術的要素を（シングルプラットフォームで）実現したことにより、エンゲージメントのためのデータベースとして、相応しい特徴を兼ね備えている、と言えます。

ここで紹介した、それぞれの要素についての詳細は、稿を改めて詳述します。下記の関連情報から、適宜参照ください。

関連情報

NoSQL/JSONデータベースCouchbase理解・活用へのロードマップ