HANAについてはそれまで「インメモリ・カラムストア型データベース」という漠然とした認識しかありませんでした。
- すべてのデータをインメモリで処理する。
- カラムストアでOLTPとOLAPの両方に対応する。
という２つがHANAの最も特徴的なものですが、特に後者は一般的なRDBMSを扱ってきたデータベース技術者にとって、とっつきづらい点を持つところなのではないかと考えます。
「カラムストアはOLTP特に更新系処理に対して不向きである」ことは多くのエンジニアの共通認識なのではないかと思いますが、HANAがなぜこのような特徴を持つに至ったのかということが個人的に最も興味を持った点でした。
HANAを理解するには、今までの経験が役に立つこともありましたが、いくつかは自分の中の常識を覆すことであり、知的好奇心を大いに掻き立てられるものでした。
本連載では「Oracle技術者から見たSAP HANA」というコンセプトで、このユニークなデータベースを紹介していきたいと思います。
第1回は、技術的な解説よりもSAP社の基本理念からSAP HANAが誕生した背景を簡単に紹介します。
OLAPとはリアルタイム処理である
業務処理(OLTP:OnLine Transaction Processing)によって蓄積されたデータを同じデータベース上で分析するという形態は、初期の分析系としては一般的なものでした。（図1）
データベースが大規模になるにつれて、パーティショニングやパラレル処理等、Oracleデータベースの歴史で言うと、Oracle8あたりから、様々な高速化手法が登場してきました。
しかし、分析処理(OLAP：OnLine Analytical Processing)が複雑化することによって、コンピュータリソースが大量に必要になるため、データベース自体を「業務用」「分析用」に分け、ミッション・クリティカルな業務処理に影響を与えない形態が主流になりました。（図2）
この形態ではOLAPは「業務用」データベースで発生したデータを、ETL(Extract, Transform and Load)ツールによって「分析用」データベースに取り込んでから始まります。
２つのシステム間でデータを転送する構成だと、データの発生から分析までにタイムラグが発生し、「リアルタイムに分析結果をレポートしたい」というニーズに対しては、応えるのがなかなか厳しい状況となります。
そもそもOLAPの「Online」とは「リアルタイム」をイメージさせるため、「分析用データが揃え（さえすれ）ばリアルタイムに結果を出せます。」というIT側の事情は、経営層には単なる言い訳にしか聞こえないかもしれません。
つまり、データ発生と同時にリアルタイム分析を行うことができるというのが究極のビジネスニーズなのです。
