筆者は過去約20年間、主にOracleデータベースに携わってきたエンジニアです。最初はアプリケーション開発者としてキャリアをスタートし、DBAとして多くのデータベースを管理することや、SQLチューニング、障害対応などを行ってきました。扱ってきたバージョンはOracle7から12cまで、HA構成からRAC、Data Guard、Exadataと、Oracle製品の進化とともに経験を積んできました。本連載では、そんな筆者が、Oracle技術者の立場からSAP HANAについて様々な視点から考えていきたいと思います。
HANAについてはそれまで「インメモリ・カラムストア型データベース」という漠然とした認識しかありませんでした。
- すべてのデータをインメモリで処理する。
- カラムストアでOLTPとOLAPの両方に対応する。
という2つが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)ツールによって「分析用」データベースに取り込んでから始まります。
2つのシステム間でデータを転送する構成だと、データの発生から分析までにタイムラグが発生し、「リアルタイムに分析結果をレポートしたい」というニーズに対しては、応えるのがなかなか厳しい状況となります。
そもそもOLAPの「Online」とは「リアルタイム」をイメージさせるため、「分析用データが揃え(さえすれ)ばリアルタイムに結果を出せます。」というIT側の事情は、経営層には単なる言い訳にしか聞こえないかもしれません。
つまり、データ発生と同時にリアルタイム分析を行うことができるというのが究極のビジネスニーズなのです。
この記事は参考になりましたか?
- Oracle技術者から見た、SAP HANA連載記事一覧
- この記事の著者
-
三原健一(ミハラケンイチ)
ベンチュリーコンサルティング株式会社 技術顧問 現在、大手SIerの性能問題対応チームに従事。主にOracleデータベースの性能問題解決や負荷テストの計画・実施・分析・評価等を担当。前職のインサイトテクノロジーではメルマガやブログの執筆に関わる。 ・ブログ「サイクル&オラクル」
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか?
この記事をシェア