NoSQLデータベースの長所と短所：NoSQLベストプラクティス（3）（1/2 ページ）

本連載では、「NoSQLデータベースの今」を正しく理解し、ビジネス躍進の実現に向けて対策していくための「ベストプラクティス」を掲示していきます。今回は「NoSQLの特性と、種類別の長所と短所」を説明します。

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

連載バックナンバー

目次

• NoSQLは機能をトレードオフして誕生した
• 「データの一貫性」を犠牲にすると何が起きるのか
• NoSQLの種類それぞれの長所と短所
  • キーバリューストア型
  • ドキュメントストア型
  • HadoopのMap Reduceバッチ処理型
  • カラムストア型
  • エンタープライズNoSQL

　前回は、「リレーショナルデータベース（以下、RDB）ではうまくいかなくなってきている背景とその理由」を解説しました。今回はNoSQLの長所と短所を、「キーバリューストア」「ドキュメントストア」などの種類別に説明していきます。

NoSQLは機能をトレードオフして誕生した

　リレーショナルデータベースでは対処が困難、非効率的、現実的に不可能である、幾つかのデータ問題への認識が高まったことが「NoSQLムーブメント」の発生した要因です。

　NoSQLとひとくくりに言っても、NoSQL製品の中には「従来型のデータベースと同等に語れないもの」が多数あります。具体的には、リレーショナルデータベースでは当たり前の性能である「データの一貫性」「（政府レベルでも利用できる）セキュリティ」「高可用性」といったエンタープライズ機能を標準機能として提供していないものもあります。

　NoSQLは、RDBMSに存在する特定の制約（特定タスクの実現の妨げになるもの）に対処するために誕生したことから、こうした標準機能の搭載をトレードオフしています。例えばNoSQLは、「行レベル競合（「hot row」）」「水平拡張」「疎データによるパフォーマンス問題」「唯一のスキーマによる融通の利かなさ」といった特定の問題に対処するために、RDBMSよりも機能を特化して作られています。

　つまりNoSQLの多くは、それ単体でエンタープライズのプラットフォームの要件（ACIDトランザクションやリアルタイムアプリケーションなどを備えるもの）を満たすものとしてデザインされているわけではない、ということです。例外は「エンタープライズNoSQL」と呼ばれるタイプです。これは、他のNoSQLと同様の柔軟性やスケールアウトのパフォーマンスを実現しながらも、RDBMSが当たり前の機能として持つエンタープライズ機能も備えています。

「データの一貫性」を犠牲にすると何が起きるのか

　NoSQLがトレードオフした機能で一番大きいのは「データの一貫性」です。これを犠牲にすることで、柔軟な水平拡張を実現しています。

　ただし、これによってどんな影響が発生するのでしょうか。また、その理由についても理解しておく方がいいでしょう。キャッシュベースのNoSQL（memcachedなど）ではデータの一貫性に問題があることは明白なので、ここでは永続化ストアの問題に限って説明します。

　永続化ストアでは、「永続性をパフォーマンスのために犠牲にする」というコンセプトが単純明快です。コモディティサーバで構成されるクラスタ内で、データを最大限均等にパーティショニング（分配）するというものです。この際に、今後データベースに対してどんな問い合わせをするか（クエリを利用するか）を事前に理解しておく必要があります。そうしないと、全ての結果がクラスタ内の一カ所に偏ってしまう恐れがあるからです。

　同一データの複数のコピーを持つことでパフォーマンスを改善できます。並列処理されるスレッドの数が増え、またロック競合による「ホットスポット」を軽減できるためです。しかしこれによって、一貫性のある更新ができなくなります。またNoSQLの中には結合（JOIN）ができないものもあります。この場合、データの正規化ができないことから、ここでもデータのコピーが複数必要です。

　幾つかのNoSQLが提供する「デフォルトの一貫性ハッシュアルゴリズム」を使う方法もあります。しかしこれもコンテンツを考慮しないために完全な最適化はできません。クエリが変更された場合には、パフォーマンスの維持のために再パーティショニングが必要となります。

　このように、いずれの場合にもデータの一貫性に問題があることが分かります。更新の際、ある時間内においてクラスタ内の幾つかのノードに古いデータが発生する可能性があります。更新は「常に」可能なので、古いデータを読み取ってしまうことで矛盾が発生する可能性があるので、この問題はアプリケーション開発者側で解決しなくてはなりません。RDBによる厳密な一貫性に対して、「最終的な段階まで待って、そこで合っていればいい」という考え方になります。この「結果整合性（Eventual Consistency）」の概念は「Amazon Dynamo」で採用され、この他のNoSQLの多くが採用しています。