ミッションクリティカルな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だ。
