RDBではうまくいかなくなってきた理由：NoSQLベストプラクティス（2）（1/2 ページ）

本連載では、「NoSQLデータベースの今」を正しく理解し、ビジネス躍進の実現に向けて対策していくための「ベストプラクティス」を掲示していきます。今回は「RDBではうまくいかなくなってきた理由」の基礎と背景を解説します。

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

連載バックナンバー

目次

• RDBではうまくいかなくなってきた理由
• （1）RDBは多種多様なデータに対応するように設計されていない
• （2）RDBは弾力的な拡張性を実現するように設計されていない
• （3）リレーショナルデータベースは現代的アプリケーション開発には合わない
• 現代のデータ問題に、従来の技術だけを使い続けて解決するのは無理がある

　前回は、「リレーショナルデータベース（以下、RDB）ではうまくいかなくなってきている背景と、その1つ目の理由」を解説しました。今回は、それ以外の「RDBではうまくいかなくなってきた理由」を解説します。

RDBは多種多様なデータに対応するように設計されていない

　近年、構造化データと非構造化データを混ぜて扱えずに困る状況がますます増えています。以前ならば、重要なトランザクショナルデータや2、3の顧客基本情報だけを格納するだけで済みました。しかし2017年現在では一部の重要データを扱うだけでは許されず、基本的に全てのデータを格納する必要が出てきています。

　RDBにとって、構造化データが増えることは問題です。データソースの構造がそれぞれ違うからです。新規データソースを扱うための変更は、工程が面倒なだけでなく、スキーマがさらに複雑になるのが大きな課題といえます。

　また、非構造化データの量が増えることも問題です。RDBは行や列で定義された値を格納していくには理想的ですが、ほとんどの情報は単なる値ではないからです。

　電子カルテを例にしましょう。これには、値（名前、誕生日など）、関係性（他の家族や病院の関係性、症状、投薬状況など）、地理情報データ（住所）、メタデータ（出自、セキュリティ属性）、画像（CTスキャンデータなど）、自由文（医者の診断や記録）などが含まれます。例えば、これら全てのデータをMicrosoft Excelへ入力して管理していくことを想像してみてください。かなりの工夫と難しい判断が必要なのは想像に難くありません。これらのデータをリレーショナルモデルで扱えるようにかなりの工程を、時には妥協しながら実施したとしても、そもそもこれが多種多様なデータを扱うのには適していない事実は変わりません。

　一方のNoSQLデータベースは、このような多種多様なデータの管理においても、RDBより柔軟なデータモデルを提供できるように設計されています。

RDBは弾力的な拡張性を実現するように設計されていない

　クラウドの普及によって、多くの企業や組織はアプリケーションの一部をクラウド、あるいはデータセンター内の仮想環境で実行するように変化してきています。ここでは、データやユーザーの増加に応じて容量を追加・拡張する「スケーラビリティ」や、ユーザーの需要がなくなった場合に縮退する「エラスティシティー」の考慮が必要になってきます。

　残念ながら、RDBの拡張は困難です。RDBは原則として1台のサーバで実行するように設計されているからです。システムを拡張する必要がある場合には、より巨大・複雑で高価なプロプライエタリ（独占的）なハードウェアを購入しなくてはならないといった事態も起こり得ます。

　この問題に対処するために、RDBベンダーはいろいろなものを各種取りそろえて改善しようとしています。しかしながら、RDBを強化するには、コストがかなり発生する上に、トレードオフも多くなってしまいます。例えばデータを分散管理したいならば、パフォーマンスを維持するために事前定義されたクエリを利用するのが一般的です。しかしこのケースではパフォーマンスのために柔軟性が犠牲になり、また、縮退ができる弾力性もありません。データがいったん分散され、追加スペースが割り当てられたならば、データを再分散することも不可能です。

　一方、NoSQLデータベースはこれをコモディティハードウェア上で実行できます。同時に、水平拡張と縮退ができるように柔軟性と弾力性も持ち合わせています。