PureDataが3つのラインナップで登場した理由は、IBMが長い歴史から学んできた思想にある。

1台ですべてを賄おうとすればどうしてもチューニングなどの
手間やコストが発生してしまう

　IBMが2012年4月に発表した、ハードウェアとソフトウェアを融合させた垂直統合型のソリューション「IBM PureSystems」。その時点で発表された「PureFlex System」と「PureApplication System」は、先行して発表されていたOracleのDatabase Machine「Exadata」と直接競合する製品ではなかった。汎用性が高く、データベースだけでなくさまざまな用途に利用できるプラットフォームだったのだ。より目的に特化し、さらにチューニングされ、最適化された仕組みの提供はないのか？ それに応えるように登場したのが、2012年10月、第3のPureSystemsとして発表された「PureData」だった。このPureDataこそが、ある意味Exadataのライバルとして位置づけられるものだ。

　ところで、IBMはPureDataという1製品だけを提供はしなかった。「PureData System for Transactions」、「PureData System for Analytics」、「PureData System for Operational Analytics」という3つを用意したのだ。なぜ、3つも必要だったのか。それは「One fit all (すべて一台)ではうまくいかない」ことが、IBMの長い歴史の中で明らかになっていたからだ。

　OLTP系のシステムに対し、アナリストが行うようなアドホック検索を行おうとしても、十分な性能が得られないことが多い。OLTP系のシステムでは、小さなデータの更新処理の効率化に重きを置く。なので、ランダムな読み取り、ランダムな更新に長けた仕組みが必要だ。一方で、分析を目的としたデータウェアハウスのようなシステムでは、大きなサイズのデータを一度に読み込み処理する必要がある。こちらは、順次読み取り、順次データロードの性能が高くなければならない。これらはまさに、相反するものなのだ。

　最近のようにハードウェア・スペックが向上した状況であれば、これら2つのシステムを物理的に1台のマシンに同居させることはできる。とはいえ、そもそもOLTPとアナリティクスという異なるデータワークロードを単一のアーキテクチャー上に同居させた上で、両方の目的を最大限の性能で達成するのはかなり難しい。結果的に、インデックスを多数張ったり、それぞれの目的を満足させるような高度なチューニングを施したりする必要がある。つまりは、同居させ双方の要件を満足させるには、かなりの手間とコストがかかるのだ。これでは、シンプルさに欠けてしまう。そうなれば、迅速なシステム展開と運用管理の手間の削減は、達成できなくなる。

　そこで、IBMはトランザクション処理に特化したデータベースマシンであるfor Transactions、大規模データの分析に特化したfor Analytics、そしてさらにオペレーショナル分析に特化したfor Operational Analyticsという3つの性格の異なる製品を用意したのだ。

ミッションクリティカルなOLTP系システムで求められるのは
高いトランザクション処理と可用性の両立

　OLTP系システムの処理特性は、小中規模のデータベースサイズでランダムI/O。つまりは、細かい単位の数多くの処理を、同時実行する。そのため、1トランザクションはなるべくシステムリソースを消費せず、他のトランザクションに影響を与えないほうがいい。そして、求められる処理がさらに増える場合は、それに耐えうる拡張性も重要。もちろん、ミッションクリティカルなシステムが多いので、これらを実現しつつ高可用性も確保しなければならない。

　これらすべてを実現するデータベースアーキテクチャとしては、シェアードディスク型が向いている。ディスクを共有したほうが高い可用性を確保しやすく、ノード追加で処理性能を向上しやすいのだ。ノードが1台から2台になれば2倍に、3台になれば3倍にと、リニアに向上するのが理想だ。

　for Transactionsでこれを実現しているのが、DB2 pureScale機能だ。UNIXやLinuxなどのDB2では、従来はシェードナッシング（ディスクを共有しない）型のアーキテクチャが採用されていた。このままでは、高可用性と拡張性を両立するのが難しい。そこで、メインフレームのDB2では実績のあったシェアードディスク型を、オープン系のDB2にも新たに追加したのがpureScaleだ。pureScaleでは、共有ディスクのボトルネックとなる、同時実行処理時におけるノード間の排他制御処理のオーバーヘッドを、独自の仕組みで解消している。そのため、ノード追加に応じた高い拡張性を提供している。

　for Transactionsでは、このpureScaleの機能を最大限に活用し、高い拡張性と可用性の両立を果たしている。とはいえ、このpureScaleを使いこなすには、それなりの知識と経験が必要。それをPureDataでは、IBMの専門技術者があらかじめ最適化した上で顧客に提供する。IBMで培ってきたノウハウや「知見」が、トポロジー・パターン、データベース・パターンという2つの形で用意され、前者がpureScaleを活用するためのインフラ部分の定義、後者はその上で動くデータベースの定義となっている。ユーザーは必要なノード数などを選ぶだけでpureScaleを活用するインフラ構成がすぐにでき、ERP用など各種データベース・パターンも用意されているので、それを適用すれば用途に特化したデータベース設定が自動的に行われる。

　さらに、for Transactionsでは、メモリの使い方も工夫されている。メモリをより多く搭載し、トランザクション処理の際に必要なデータを極力メモリ上で読み書きできるようにしている。さらにストレージには高速なSSDも用意され、頻度の高いデータはSSDに置くことで、さらなるトランザクション性能の向上も図られている。このようにトランザクション処理だけに特化したシステムが、PureData System for Transactionsだ。

PureData System for Analyticsは定評あるNetezzaテクノロジーを踏襲

　PureData for Analyticsは、データウェアハウス・アプライアンスとして実績の高いNetezzaがベースだ。こちらは、データウェアハウスなどの大量データ分析に向く、シェアードナッシング型アーキテクチャをとっている。とはいえfor Analyticsは、単純なシェアードナッシング型ではない。ある意味、シェアードナッシングとシェアードディスクの良いところを組み合わせた構造となっている。

　各ディスクには、直結する形でサーバーが配置される。これはMPP（超並列処理）層と呼ばれ、シェアードナッシングの構造だ。for Analyticsでは、この上にMPP層を束ねるSMP層が配置される。MPP層のCPUとメモリ、FPGA、そしてディスクという組み合わせを1つのインテリジェントなディスクと捉えれば、SMP層はディスクを共有する構造となる。このシェアードディスクとシェアードナッシングを組み合わせることで、高速な処理と管理の容易さを両立している。

　さらにfor Analyticsの高速処理で肝となるのが、各ノードに配置されているFPGAだ。FPGAはField Programmable Gate Arrayの略。平たく言えば、プログラムの書き換えが可能な、高速なLSI（半導体集積回路）だ。CPUはプログラムを読み込んで汎用的な処理を行う が、FPGAでは特定の処理を行う。For Analyticsでいう特定の処理とはデータベース処理である。FPGAではディスクからのデータ読み取り速度で、ストリーミング－読出しデータをディスクやメモリーに滞留させることなく－、データベース処理できるのだ。

　FPGAがストリーミングで行う処理は、圧縮データの解凍、データの絞り込み、カラムの絞り込み、関数、SQLロジック、JOINなどのデータベース処理だ。そのため、ディスクからメモリへとデータが渡されるまでのほんの短い間に、これらの処理が済んでしまう。CPUは渡された結果だけを用い、残りのデータベース処理をすればいい。これに対し汎用的なデータベースでは、ディスクからメモリに必要データをすべて読み込み、その上で圧縮の解凍、データやカラムの絞り込みなどの処理をCPUで行わなければならない。このFPGAによる事前のストリーミング処理による性能差は、かなり大きなものとなる。

　さらにfor Analyticsでは、検索処理だけでなく分析ロジックも取り込んでいる。通常の分析環境では、データウェアハウスとは別に分析用サーバーを用意し、その上で高度な統計処理などを行う。そうなれば、分析用のサーバーに必要なデータを抽出し渡す必要がある。これでは、ビッグデータそのものを分析対象にはできず、集計データやサンプル抽出したデータしか使えない。つまりは、真のビッグデータ分析とはならないのだ。

　for Analyticsでは、最近注目されているR言語分析、IBM SPSSのデータマイニングや予測分析、空間・地図分析などの分析ロジックをあらかじめ内包している。なので、高速なアプライアンスサーバーの中で、ビッグデータに対しこれらの分析を行える。分析ロジックは、あらかじめ用意したものだけでなくユーザーなどが独自開発したものも取り込める。

　FPGAによるストリーミング処理や分析ロジックそのものを取り込んでいることにより、チューニングやインデックス作成などの面倒な作業は必要ない。このように、大量データの分析に特化しているのが、PureData System for Analyticsなのだ。

トランザクションでデータを蓄積しながらリアルタイムに分析するニーズに応える

　PureDataの中でも、ある意味汎用的な目的に利用できるのがfor Operational Analyticsだ。トランザクション処理と分析をミックスした特性を持つからだ。ベースとなっているのは、IBM Smart Analytics Systemの技術だ。

　アプリケーションによっては、発生したデータを蓄積しながら適時に判断したい場合もある。つまり、トランザクションデータをリアルタイムに反映し、照会や分析が要求されるケース。たとえば、クレジットカード会社が、リアルタイムに不正利用を検出したいといった用途がそれだ。このような場合には、同じ分析を目的としていてもfor Analyticsとは異なる構造が必要だ。for Operational Analyticsでは、ランダムな順次読み取りとデータロード、そして継続的なデータ収集ができるように最適化されている。アーキテクチャはシェアードナッシングで、パーティショニングを用い、適宜狭い範囲で効率的に演算処理ができるようになっている。

　利用されているデータベースは、DB2だ。DB2に搭載されている表、ページという2段階で圧縮が行えるアダプティブ圧縮、履歴データのトレンドを分析し将来の予測を可能にするタイムトラベル照会などの機能を活用することで、リアルタイムに蓄積されるデータを瞬時に分析し新たなアクションに結び付けることが可能だ。

　オペレーショナルデータのリアルタイム分析の際には、個人データなどセキュアに扱うべきものが対象となることも多い。そういった際にも役立つ、行、列というレベルでの細かいアクセス制御機能もあり、強固な制御も可能。また、ワークロード・マネージャーにより、優先して行うべき処理も細かいレベルで設定でき、サーバー資源を有効活用できる。さらに、32コア256GBメモリというXSサイズから、96コア768GBメモリのLサイズ、さらにはその上のXLサイズまで用意されており、必要な処理容量に合わせ柔軟な選択ができるのも大きな特長だ。

　市場にはトランザクション処理を行いながら、そのデータを適時分析したいというニーズがあることをIBMは分かっているからこそ、for Operational AnalyticsをPureDataのラインナップに加えられた。このようにIBMでは、ハードウェアとソフトウェアを組み合わせ、自らの手で最適化したデータベースマシンを用意するに止まらず、そこにIBMの長い歴史の中で育まれてきたアプリケーションに対するノウハウや知見も加えることを選択した。だから、トランザクション用、分析用といったより細かな目的ごとに別々のシステムを提供することになったのだ。

　つまりは、1つの汎用的な高性能データベースマシンではなく、ユーザーニーズに直結しそれに特化したシステムを提供する。ハードウェアとソフトウェアをベンダーの手で最適化したものがエンジニアド・システムズだとすれば、それにさらなる知見を加えより少ないコストで最高、最適なパフォーマンスをユーザーニーズに合わせて提供しようとしているのが、IBMの目指す「Expert Integrated System」ということ。IBMでは、今後さらにユーザーニーズに特化した新たなPureDataも提供する可能性があるとのことだ。