［次世代DB編］DWHアプライアンスでOLTPを動かしてはいけない

　データウエアハウス（DWH）分野では、アプライアンス型の製品が続々と登場している。DWH環境が高性能・高機能になったことで、分析対象には日次バッチの結果だけでなく、より頻度の高い更新データも扱えるようになった。

　ところが、よく耳にするのが「DWHアプライアンスで業務系システムのOLTP（オンライントランザクション処理）を動かしたい」という要望である。確かに、リアルタイム更新が可能であれば、OLTPを実現できると考えがちだ。景気停滞の中で、業務系と情報系のサーバーを一つに統合できれば、コスト削減にもつながる。

　とはいえ、最新のDWHアプライアンスをもってしても、そのアーキテクチャーはあくまでDWH向けである。原則として、DWHアプライアンスでOLTPを動かしてはいけない。DWHとOLTPには、プラットフォームだけでは乗り越えられない違いがある。

性能が全く出ないケースも

　DWHアプライアンス上でOLTPを動かすと何が起こるのか。代表的なものに以下のような問題がある。

・OLTPの性能が出ない
・情報系処理がOLTPを妨害する
・データの正確性を確保できない

　DWHアプライアンスでOLTPを動かすと、最初に直面するのが性能の問題だ。以前、DWHアプライアンス上に業務系システムを構築したが、性能が出ずに結局OLTP用のサーバーを別に構築し直した経験がある。

　なぜ性能が出ないのか。これは、OLTPとDWHにおけるデータ処理の性質に違いがあるからだ。DWH専用のアーキテクチャーを持つアプライアンスでは、その違いを解消できない。

　表1は、業務系システムのOLTPと、情報系システムのDWHのデータ処理の性質を整理したものである。業務系システムの場合、データを瞬時に更新する処理が多いので、処理（OLTP）を可能な限り高速なメモリー空間上で行う。

　これに対して情報系システムのDWHでは、大規模データを高速に検索することに主眼が置かれている。このため常にディスクへデータを読み取りに行くことを前提としたアーキテクチャーになっている。更新処理の速度はOLTPに比べてどうしても遅くなり、更新処理が集中すると、期待した性能を全く得られない可能性がある。

大量クエリーがOLTPに悪影響

　情報系システムの処理がOLTPを妨害するケースも珍しくない。そもそもDWHが誕生した背景には「情報系の処理が業務系の処理に影響を与える危険性を避ける」という目的があった。

　例えば、大量のクエリーがデータベースに投げられると、サーバーのリソースを占有しかねない。これをコントロールする仕組みがないと、同じシステム上にある業務系システムに多大な影響を与える危険性が高い。業務系システムは、SLA（Service Level Agreement）の保証、負荷分散、災害時対応などを高いレベルで行う必要がある。DWHアプライアンスでは、こうした要求に応えるのが難しい。

真水と泥水を一緒にするようなもの

　「DWHは、OLTPで発生したデータのコピー」という原則がある。DWHのデータは、OLTPで確定したデータを分析に適した形に変換し、DWH側に移動する。このためDWH自体は直接的にはデータを更新しない。つまり、OLTPのデータは“真水”、DWHのデータは“泥水”という言い方ができる（もちろん価値を生むDWHのデータは宝の水ともいえる）。

　この真水と泥水を混ぜてはいけない。DWHアプライアンスに業務系システムを実装すれば、おそらくデータベースの一部は共有するはずだ。ディスク容量の節約のために、いくつかのテーブル、特に容量の大部分を占める実績テーブルを共有するだろう。

　DWHは誰かが勝手にデータを変更できない仕組みだからこそ、データの信頼性が保たれている。もしDWHとOLTPが混在すると、この原則を守るのが難しくなる。こうなると、もはや運用側の努力に頼るしかない。その複雑さゆえに、現場は疲弊し、結果的にOLTPにとっても、DWHにとっても不幸な道をたどる。