トランザクション系

　トランザクション系のシステムでは、インメモリまたはフラッシュストレージを組み合わせた応答速度の高速化や、最新OSやデータベースソフトウェアで利用できるメモリサイズを生かした構成を検討するのはもちろんだが、データベースへの書き込みや読み込みのキャッシュにも高速なストレージを持っておくとよいだろう。

　 Oracleのように既存との互換性を重視する、SQL Serverのように高速化したいデータを明示的に指定する、SAP HANAのように全てをメモリ上に置くなど、各社インメモリ処理の方法論が異なるが、全てをメモリ上に置く手法がとれない場合、書き込みスピードが異なるHDD、フラッシュストレージ、NVDIMMなどにデータをどう振り分けるかなどの「データ管理」の設計がポイントとなる。

バッチ処理

　極論を言うと、処理が高速であれば「バッチ処理を廃し、全てをリアルタイム処理する」という手法も選択肢にできるだろう。前編でも言及した「バッチのないシステム」だ。

　システム性能の制約に対処するために集計処理を別にしていたのだとしたら、システム性能に制約がなければ、バッチで処理する必要がそもそもなくなる。

　実際、SAP HANAを前提に設計されている「S／4HANA」では、インメモリを前提としてビジネスロジックや中間サマリーテーブルを大幅に削減できているという。

　とはいえ、多くの企業は業務フロー自体をバッチ処理がある前提で構築しているはずだ。関連企業との連携を含めると、こうしたプロセスに影響が大きな変更はすぐには選択できない場合もあるだろう。

　データウェアハウスやIoTデータ分析のように、大量のデータを解析する処理においてはバッチ処理を避けられないが、大量のデータを「前処理」するために、Hadoopを使う事例も増えてきている。単純なソーティングやマッチングでは既存のリレーショナルデータベースのような複雑な処理は不要であるため、まずはHadoopでサマリー処理を行い、その後に基幹系システムで処理、解析を行う方法が望ましい。

アプリケーション認定やサポートの体制

　ここまでは、データベース製品そのものを見てきたが、今後の選定で大きな制約となりそうなのが「アプリケーションとの組み合わせ」「サポート体制」「ライセンス費用」「クラウド化への対応」といった要素だ。

　 Oracle DatabaseなどとSAP ERP R／3を組み合わせて利用してきたユーザーにとって大きな問題となるのが、SAP ERPの後継である「S/4HANA」の対応データベースがSAP HANAのみであることだ。

　つまり、基幹業務システムを丸ごとSAP ERPから他に置き換えるか、ERPをアップグレードして利用する一方で、データベースを置き換えるか、あるいは全く別の選択肢に移行するかを、この数年で判断していく必要がある。

　S/4HANAは、従来の独自開発言語ABAPだけでなく、HTML5などのWeb標準やAPIを使える現代的な実装になっているし、HANAがメモリに乗せられるデータ量は最大24TBにものぼる。AWSに加え、Microsoft Azure上でも動作する。

　一方、オラクルはERP製品として「Oracle E-Business Suite」を持っており、自社のクラウドサービス「Oracle Cloud」では全く同じアプリケーションをサービスとして利用できるようになっている。データベースも同様だ。

　これとは別に、マイクロソフトはOracleからSQL Serverへの移行に対する優遇キャンペーンを実施している（本稿執筆時点）。

　もちろんデータベース移行には既存アプリケーションの改修や移行テストなどの工数が掛かるが、長期的に見てライセンス費用などのコスト削減効果が期待できるケースも考えられるだろう。場合によっては周辺システムを含む基幹業務システム全体に影響する選択となるだけに、乗換えや移行プロジェクトにはある程度の時間が必要となるだろう。いま検討を始めても早すぎることはないと考えられる。