OLTPの最適化をすればビッグデータには最適化されない
ビッグデータ＆データマネジメント製品営業部 統括部長
森 英人氏
ビッグデータに関わるあらゆるテクノロジーを持っているIBM。それぞれを、目的に応じ使い分けることが重要だと森氏は言う。
「1つのテクノロジーで、顧客の課題すべてを解決できるわけではありません。OLTPの最適化をすれば、ビッグデータには最適化されません」（森氏）
たとえば、検索系の処理か更新系の処理かでも解決するためのテクノロジーは異なる。さらに昨日のデータを見たいのかリアルタイムに見たいのか、あるいは1ヶ月分のデータすべて溜めてから見たいのかでも使うべき技術は当然異なる。さらに同じリアルタイムでも、後で帳尻が合う程度のデータの正確さがあればいいのか、あるいはリアルタイムでもデータの高い正確性を求められるかで求められる技術は違ってくる。
ある銀行では、業務要件の違いからデータ処理パターンの洗い出しをした。結果的には29のパターンにまで絞り込むことができたとか。この銀行では、処理パターンごとに最適な技術を選択し組み合わせていくことになる。
とはいえ、この銀行のようにすべての業務処理を洗い出す作業に取り組める体力があればいいが、多くの企業はそんなことを行う余裕はない。多くの場合は、深く考えずにベンダーの薦めるままにテクノロジーを選択することだろう。
そこで顧客がなるべく間違いのないビッグデータ技術の選択ができるよう、IBMではビッグデータに関わる処理をデータベースの視点からシンプルに分類しモデル化している。扱うデータが構造化か非構造化か、さらにはその中間とも言える構造化データではあるがスキーマモデルではないものにまずは分類する。さらに処理がOLTPなのかデータウェアハウスのようなオペレーショナル・アナリティクスなのか、あるいはより高度で深い分析を行うディープ・アナリティクスなのかで分けるのが基本の形だ。
これらの条件で分類すると、それぞれで重なる部分はあるものの図のように大きくは3つのパターンに分けられる。リレーショナルデータベースで対処すべきOLTPの領域、これはたとえば銀行のATMの処理など勘定系の処理であり、大量の同時アクセスがあってもトランザクションが滞留しないようする。「この場合はスループット重視となり、その上でデータが間違ってはいけません」と森氏。求められるのはシーケンシャル性、値の精度、そして可用性でありいわゆるミッションクリティカルな世界だ。
この領域のビッグデータを最適に処理するには、シェアードディスク型の可用性を重視したアーキテクチャ「IBM DB2 pureScale」のテクノロジーがいい。これはメインフレームのSystem 390時代から受け継がれている技術であり、高い可用性を確保すると同時に「ほとんどリニアな拡張性を持っています」と森氏。
このシェアードディスク型のアーキテクチャは、DB2以外にはOracle DatabaseのReal Application Clustersだけだ。
「当時のOracleはオープンなデータベースを誰でも使えるようにしました。その中で高い可用性を実現するには、性能を犠牲にしたところがあります。これは、歴史的な宿命。リニアな拡張性はpureScaleに優位性があります」（森氏）
pureScaleでは、ロック制御の仕組みを専用のマシンで行う。これでクラスターの処理で発生するロック情報のやり取りというボトルネックをなくしている。これがOLTP領域のビッグデータ処理におけるIBMの優位性というわけだ。
