中長期的にはバッチをなくすアイデアも検討を

　IT投資意欲の旺盛な大手エンタープライズ企業の多くでは既にデータベースシステムへのフラッシュストレージ導入が進んでおり、さらなる「性能」アップを目指して、あらゆるデータを本当の意味で「リアルタイム」に共有・分析・予測したいという要求に応えようとする動きがあるという。

　既存のリレーショナルデータベースはストレージとしてHDレベルのI/Oを想定し、さまざまな高速化のための工夫をしてきた。例えば、素早くデータを分析するために、集計用のビューをいくつも用意したり、個別にバッチプログラムを用意したりといった、今まで当たり前としてきた手続きは、いずれもHDI/Oを含むシステムパフォーマンス上の制約に対応するために生まれた手法だ。

　データウェアハウス向けにデータベースの情報を出力する必要があるのは、システム負荷が高すぎてデータウェアハウス処理をデータベースシステム上で動作させられないからだった。

　もしこれが全てフラッシュストレージ上、もしくはメモリ上で処理できるようになると、これまでとは異なるアプローチでデータベースエンジンを作ることができる。

　データウェアハウスなどの処理においては、列指向の格納方法（カラムストア型、カラム型）を取ることにより、並列化がしやすく高速化が実現できる。縦方向に同じタイプのデータが並ぶことから、データ圧縮がしやすくなるというメリットもある。解析系のシステムでは、列指向で並列が可能なデータベースを基幹系とは別に構築することで、データベース処理の高速化を実現する手法は当たり前になってきた。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

図3　カラムストア型データベース（出典：日本ヒューレット・パッカード）

　そして、カラムストアをさらに高速にするために登場したのが「インメモリデータベース」だ。これはデータベースのデータをメモリ内で処理することにより、高速化を実現するというものだ。インメモリデータベースは、SAP HANAの登場で注目を集めたが、今ではSQL ServerやOracle Databaseなどでも実装されている。

バッチ処理のない基幹業務システムは実現するか？

　カラムストアとインメモリデータベースが登場し、超高速なトランザクションと集計処理が同時に実施できるようになってきたことで、基幹業務システムのデータベースには新たな可能性が見えてきた。バッチ処理なしでのデータベース運用の可能性だ。

　例えば「基幹システム向けパッケージ」を例に考えてみよう。

　通常、会計処理における単純なデータモデルは「ヘッダテーブル」と「明細テーブル」が必要だ。このシステムをリレーショナルデータベースで実現しようとすると、処理速度の問題で月別サマリーテーブルや品目別サマリーテーブルなど、明細からさまざまなテーブルをパフォーマンスの理由で作らなければならない場合が多い。これにはインデックス生成のコストや、サマリーテーブル生成のためのプログラムの保守コスト、何よりそれらを生成するための「バッチ処理時間」が必要になる。システムの改修によりバッチ処理時間が増大し、突き抜けが起きてしまう要因だ。

　インメモリデータベースをフル活用すると、ヘッダテーブルと明細テーブルを「高速に処理」できるため、これらのサマリーテーブルを作る必要が無くなる。そのため、サマリーテーブル作成のためのプログラムも、バッチ処理もすることなく「リアルタイム」で集計できるのだ。SAPが提供する基幹システムソリューションである「S/4HANA」では、このようなアーキテクチャ変更によりソースコードの4割を削減したという。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

図4　SAPの「S/4HANA」ではデータベースエンジンを「HANA」に一本化　HANAの機能を最大限に活用することで、これまでのデータモデルとロジックをシンプルにした（出典：SAPジャパン）