データ構造の変更が柔軟
この特徴がメリットとなるケースは、さまざまなデータソースからデータを集約する必要があるアプリケーションを作る場合です。例えば、既存のホストやRDBMSの中に格納されたデータを集約してアプリケーションに提供する使い方や、業界にあるさまざまなベンダーの情報を集約して業界横断型の情報アプリを作るケースです。
RDBMSでこれを実現しようとした場合、集約型アプリの場合は、データ取得元ごとにデータ構造を定義する必要があることに加えて、運用中にデータ取得元のデータ構造が変わるごとに対応が必要となり、工数がかかります。業界横断型アプリの場合は、データ構造の8割が同じだが、2割が個社ごとに違うといったことが多くあり、この2割のためにRDBMSの列を定義し、メンテナンスし続けていかなければならず、工数がかかります。
(左から)図4:業界横断情報アプリケーションの場合、図5:データ集約ハブとして活用する場合(筆者作成)
図6:ECサイトでのカタログ管理として活用する場合(筆者作成)
エンジニアでなくてもデータの全貌がわかる
この特徴がメリットとなるケースの一例として、ECサイトのカタログ管理があります。多くの場合、カタログに載せる情報は、エンジニアではなく企画担当や営業担当が決めるものですが、JSONであればエンジニアでなくてもデータをレビューできます。また項目の追加なども気軽にできるため、メンテナンスが容易であったり、商品ごとに異なった列を持たせることが難なくできます。
その他のケースとして、アジャイル開発があります。アジャイル開発では顧客とエンジニアが少人数のチームを組み、非常に短期間で少しずつシステムを作り上げていきますが、エンジニアではない顧客がデータ構造を読めるということがデータの設計効率を高めます。MongoDBを特によく利用している米国の先進企業では「最もアジャイル開発に適したデータベース」と評価している企業もあります。
図7:JSONを活用するメリット(筆者作成)
ウェブサービスの標準的なデータ構造をそのまま扱える
ウェブサービスから取れるJSON形式のデータをRDBMSで処理するのは大変です。CREATE TABLE文を何度も発行し、列名、データ型、テーブル同士の結合キーなどを定義することが必要です。また応答のJSONが毎回同じデータ構造ならばいいのですが、ウェブサービスのエンハンスなどによりJSONの形式が変更になった場合は、RDBMSでは挿入できなくなるでしょう。
ドキュメント型NoSQLであれば、とりあえず挿入はできます。もちろんそのデータを使うアプリケーションの改修は必要ですが、「とりあえず溜めておいて、あとで使い方を変える」というケースには非常にマッチします。