なぜ「NoSQLデータベース」なのか？：NoSQLベストプラクティス（1）（2/2 ページ）

NoSQLデータベースが急速に普及しています。RDBの時代は終わってしまうのでしょうか。RDBは根本的な欠陥があるのでしょうか。──それは違います。本連載では、「NoSQLデータベースの今」を正しく理解し、ビジネス躍進の実現に向けて対策していくための「ベストプラクティス」を掲示していきます。初回は「今日のデータ問題」の基礎と背景を解説します。

[三浦デニース（Denise Miura），マークロジック株式会社]

RDBだけではうまくいかない理由

　RDBは通常、特定のアプリケーションやデータタイプ用に個別設計されます。そこから取り出したデータを他のデータベースで別の目的で利用したい場合には、ETL（抽出／変換／読み込み）処理を行って、対象となるデータベースのスキーマにマッチさせる工程が必要になります。ほとんどの組織においてETLは頻繁に行われています。しかしその度に新たなデータサイロが生み出されます。サイロが増殖すればするほど、その保守や関連付けが困難になります。

　残念ながら、RDBを活用したITプロジェクトでは、期日や予算が守られず、コストが余計にかかったり、プロジェクトが失敗したりすることは珍しくありません。一般論として、予算超過で成果未達のプロジェクトに携わるチームに、組織の将来の成功に必要なイノベーションプロジェクトに取り組む時間や余裕はありません。そのような現状を変えない限り、CIO（Chief Information Officer：最高情報責任者）やIT部門は大量のレガシーシステムの保守に忙殺され続けます。つまり、リソースをイノベーションや業務変革に充てている競合他社に負けてしまいます。

　では、RDBには根本的な欠陥がある、ということなのでしょうか。それは違います。そもそもRDBは「日々生成されるあらゆるデータを扱う」ようには設計されていないということです。

RDBは「変化」に対応するように設計されていない

　RDBは、データを行と列の表形式で扱います。Microsoft Excelの表と同じです。

　このアプローチには問題が2つあります。1つ目は、データモデリングの過程に何カ月（データベースの規模によっては数年）もかかることです。リレーショナルスキーマは複雑なだけではなく、データの読み込みやアプリケーション構築の前に「モデリング」を全て終えておく必要があります。

　2つ目は、アプリケーション構築後の仕様変更には、さらに時間（平均的には、数カ月から年単位）とリソースが大量に必要となることです。リレーショナルモデルはセンシティブかつ複雑なシステムです。たった1つの小さな変更によって、致命的なダメージが発生したり、データベース全体あるいはアプリケーション全体へと影響が波及したりします。大規模なシステムでは、表内の列の追加や置き換えといったシンプルと思える変更でさえ数億円単位のコストが発生する場合もあります。変化や変更が頻繁に起こるようになった今日、この「データモデリング」は深刻な課題です。RDBで対応していくには、時間とリソースがあまりにもかかってしまうからです。

　それなのに今後もRDBだけで行くということは、データモデリングとETL処理に毎年数千億円ものコストを費やし、今後変更する必要のない「より完璧なモデルを作成（再作成）」するのと同じことといえるでしょう。将来のデータベースの「変化や変更は避けられない」にもかかわらずです。

変化が必要な理由

　本連載のテーマであるNoSQLデータベースは、「柔軟なデータモデル」によってこの問題に対応します。

　次回はこの他の個別要素についての背景を詳しく解説しましょう。

筆者紹介

三浦デニース（Denise Miura）

マークロジック株式会社日本法人代表。ソフトウェア開発ならびにwebテクノロジーに関して25年以上の経験を持ち、さまざまなエンジニアリング、コンサルティング、管理職などの要職を歴任。前職はSilicon Graphics、E*TRADE Financial、Blue Martini Software（日本法人代表取締役）など。カーネギーメロン大学卒（コンピュータサイエンス専攻）