トータルの人件費を安くできる--デファクトの可能性もある「MongoDB」の勘所 - (page 2)

渡部徹太郎 (野村総合研究所)

2015-03-16 19:38

データ構造の変更が柔軟

 この特徴がメリットとなるケースは、さまざまなデータソースからデータを集約する必要があるアプリケーションを作る場合です。例えば、既存のホストやRDBMSの中に格納されたデータを集約してアプリケーションに提供する使い方や、業界にあるさまざまなベンダーの情報を集約して業界横断型の情報アプリを作るケースです。

 RDBMSでこれを実現しようとした場合、集約型アプリの場合は、データ取得元ごとにデータ構造を定義する必要があることに加えて、運用中にデータ取得元のデータ構造が変わるごとに対応が必要となり、工数がかかります。業界横断型アプリの場合は、データ構造の8割が同じだが、2割が個社ごとに違うといったことが多くあり、この2割のためにRDBMSの列を定義し、メンテナンスし続けていかなければならず、工数がかかります。


(左から)図4:業界横断情報アプリケーションの場合、図5:データ集約ハブとして活用する場合(筆者作成)
図6:ECサイトでのカタログ管理として活用する場合
図6:ECサイトでのカタログ管理として活用する場合(筆者作成)

エンジニアでなくてもデータの全貌がわかる

 この特徴がメリットとなるケースの一例として、ECサイトのカタログ管理があります。多くの場合、カタログに載せる情報は、エンジニアではなく企画担当や営業担当が決めるものですが、JSONであればエンジニアでなくてもデータをレビューできます。また項目の追加なども気軽にできるため、メンテナンスが容易であったり、商品ごとに異なった列を持たせることが難なくできます。

 その他のケースとして、アジャイル開発があります。アジャイル開発では顧客とエンジニアが少人数のチームを組み、非常に短期間で少しずつシステムを作り上げていきますが、エンジニアではない顧客がデータ構造を読めるということがデータの設計効率を高めます。MongoDBを特によく利用している米国の先進企業では「最もアジャイル開発に適したデータベース」と評価している企業もあります。

図7:JSONを活用するメリット
図7:JSONを活用するメリット(筆者作成)

ウェブサービスの標準的なデータ構造をそのまま扱える

 ウェブサービスから取れるJSON形式のデータをRDBMSで処理するのは大変です。CREATE TABLE文を何度も発行し、列名、データ型、テーブル同士の結合キーなどを定義することが必要です。また応答のJSONが毎回同じデータ構造ならばいいのですが、ウェブサービスのエンハンスなどによりJSONの形式が変更になった場合は、RDBMSでは挿入できなくなるでしょう。

 ドキュメント型NoSQLであれば、とりあえず挿入はできます。もちろんそのデータを使うアプリケーションの改修は必要ですが、「とりあえず溜めておいて、あとで使い方を変える」というケースには非常にマッチします。

ZDNET Japan 記事を毎朝メールでまとめ読み(登録無料)

ホワイトペーパー

新着

ランキング

  1. セキュリティ

    「デジタル・フォレンジック」から始まるセキュリティ災禍論--活用したいIT業界の防災マニュアル

  2. 運用管理

    「無線LANがつながらない」という問い合わせにAIで対応、トラブル解決の切り札とは

  3. 運用管理

    Oracle DatabaseのAzure移行時におけるポイント、移行前に確認しておきたい障害対策

  4. 運用管理

    Google Chrome ブラウザ がセキュリティを強化、ゼロトラスト移行で高まるブラウザの重要性

  5. ビジネスアプリケーション

    技術進化でさらに発展するデータサイエンス/アナリティクス、最新の6大トレンドを解説

ZDNET Japan クイックポール

自社にとって最大のセキュリティ脅威は何ですか

NEWSLETTERS

エンタープライズ・コンピューティングの最前線を配信

ZDNET Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]