EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

003 なぜこれまでの汎用RDBMSではビッグデータに対応できないのか

  2011/10/14 00:00

「ビッグデータ」の定義として、これまでのアーキテクチャでは処理しきれない急激なボリュームの増大を伴うデータ、ということが言われます。連載第3回目では、なぜこれまでの汎用RDBMSではビッグデータに対応できないのか、シェアードナッシングMPPアーキテクチャを採用するGreenplum DBではどのようにこの課題を解決するのか、といった部分をやや技術的な方向にフォーカスを移しつつ解説していきます。

OLTP処理にフォーカスした汎用RDBMS

 Greenplum DBはビジネスインテリジェンス(BI)や分析処理に適したシェアードナッシングMassively Parallel Processing (MPP)アーキテクチャを採用しています。一方で、こんにちの汎用リレーショナルデータベース(RDB)の大半はオンライントランザクション処理(OLTP)に最適化されています。汎用RDBはデータウェアハウスやBIアプリケーションへの対応を謳っているため、ユーザーは当たり前のこととしてこのアーキテクチャを使っています。しかしながら、BIや分析アプリケーションのワークロードはOLTPのワークロードとは根本的に異なるため、本来その処理に適したアークテクチャが用いられるべきなのです。

 OLTPトランザクションのワークロードでは、速いレスポンスと小さな単位のレコードの更新性能が求められます。このような処理は、単一もしくは少数の並列処理ユニットを使ってディスクの局所的な部分に限定してアクセスが行われるのが一般的です。処理ユニットが単一の大容量ディスクとメモリを共有するシェアードエブリシングアーキテクチャでは、このようなOLTPワークロードを非常に効率的に処理します。また、Oracle RACは共有ディスクを介して一貫性を保ちつつ、複数サーバでクエリを分割して独立に処理できるため、OLTPに対して優れた性能を発揮します。

BI/分析アプリケーションで必要とされる処理能力とは

 しかし、BIや分析アプリケーションのワークロードの大半を占める、フルテーブルスキャン、複雑なテーブルジョイン、ソート、集計などの処理を膨大なデータに対して行う場合、シェアードエブリシングアーキテクチャでは大きな困難を伴います。

 このようなワークロードでは対象データが増えるに従って指数関数的に処理量が多くなります。処理量の増加に対応するためには、高速なCPUへの置き換え、CPUコア数の増加、メモリの大容量化、高速なストレージ(SSD)の追加などのスケールアップのアプローチが必要になります。しかしながら、このような方法では投資に見合った性能の向上が得られません。

 そこで、このような課題に対応するために登場したのがシェアードナッシングMPPアーキテクチャです。このアーキテクチャにおいては、全データは完全に分割されて複数ノード上のディスクに格納され、各処理ユニットはそれぞれの部分データを所有・管理する自己完結したDBMSとして振る舞います。システムは自動的にデータを分散し、全てのハードウェアでクエリのワークロードを並列に処理するようにコントロールします。データを分割することにより全体で必要な計算量を抑えつつ、相対的にコストの小さい処理ユニットを追加することで処理量の増大にも対応することができるようになります。

 もちろんRDBMSの処理の並列化はそれほど簡単ではありません。ACID属性を保証しつつ、ボトルネックのない形でシステムをスケールアウトさせていくためには、様々な技術上の課題を解決する必要があります。例えば、効率的な並列実行を可能にするクエリ実行プランを生成するアルゴリズムが必要ですし、複数のユニット間でのデータ移動を最適化することも重要です。シェアードナッシングMPPアーキテクチャの発展の過程で、これらの課題は徐々に解決され、実用的な技術として利用できるようになりました。


著者プロフィール

バックナンバー

連載:ビッグデータのリーサルウェポン!徹底解析GreenplumDB

もっと読む

All contents copyright © 2007-2020 Shoeisha Co., Ltd. All rights reserved. ver.1.5