当時もう1つ言われていたのが、Sybaseのモバイル系ソリューションが欲しかったということ。SybaseにはSQL Anywhereというモバイルに特化した実績あるデータベースがあった。それを中核とし、モバイル環境をエンタープライズで活用するノウハウの蓄積もある。SAPがモバイル市場への対応に注力している現状を見ても、やはり当時欲しかったのはSybaseのモバイルソリューションだったのではと思えてくる。
ところで、Sybaseのポートフォリオの中で、忘れてはならないのがSybase IQだろう。カラム型の検索、分析用途に特化したデータベース。買収話が出ていたころに市場でSybaseの名前を耳にしたのは、Adaptive Serverよりも圧倒的にこのSybase IQのほうだった。ところが当時は、Sybase IQについての話題はあまり聞こえてこなかった。SAPがすでに手に入れていた、BIツールのBusinessObjetsと組み合わせて活用する話もあったが、それほど積極的にアピールはされなかったのだ。
カラム型データベースとしての実績は伊達ではない
テクノロジーエンジニアリング部
シニアディレクター 原 利明氏
Sybase IQは1996年に、早くも世に出ていた製品だ。一般に企業のITシステムの中には、業務システムのOLTPデータと、データウェアハウスなどで利用する蓄積された分析用途のデータがある。OLTP処理には、1行にさまざまな情報が詰まっているローベースのデータが適切な構造だ。
一方、分析の用途では、行の中の属性データ、つまりはカラムに着目してアクセスする。ローベースの物理構造のまま、この処理がうまくできるのか。「当時、カラムベースで処理することを考えたデータベースはありませんでした」と言うのは、SAPジャパン ソリューション本部 テクノロジーエンジニアリング部 シニアディレクターの原 利明氏だ。
1990年代後半、行構造のままで検索処理を高速化する方法が各種考えられていた。たとえば、テーブル構造をスタースキーマにし、それを効率的に処理するビットマップ・インデックスなどと組み合わせる方法などがそれだ。
「当時は数10GB程度が普通で、数100GBもあればかなり大きいデータウェアハウスと言われていた時代です。なので、ローベースでもインデックスを工夫するとかで、なんとかできたのです。しかしこれが、どんどんデータが増えてくる、あるいはレポートではなくアドホックな分析が行いたい、となると十分な性能が出なくなります」（原氏）
2005、2006年くらいから、データウェアハウスの処理で性能が十分に出ない状況が顕著化する。このころは、ハードウェアの進化も激しく、最初はこの課題をハードウェアの増強で解決しようとした。つまりは、強力で高価なアプライアンスが注目されることに。とはいえ、このままローベースではうまくいきそうにない。目的とするアプリケーションごとに、データベースのアーキテクチャを変えるべきだと考え始めるベンダーも出てくる。結果、いまでは多くのカラム型データベースが登場しているわけだ。
しかしながら、Sybase IQはそれらが登場する10年も前からあった。
「Sybase IQがカラム型の元祖だと言うつもりはありませんが、10数年以上、カラム型データベースを磨いてきた自信はあります。結果的に、この分野での特許も多数取得しています」（原氏）
SAP HANAも、データの格納方式はカラム型だ。「Sybaseがカラム型に関するさまざまな特許を持っていたことにも、SAPは注目していたようです」と原氏。SAPはAdaptive Serverよりもむしろ、Sybase IQを欲していたのではということだ。
このSybase IQの特長の1つが、9種類のインデックスだ。インデックスがいらないのが、多くのカラム型データベースの特長であり、Sybase IQはそれとは違うことに。とはいえ、この場合のインデックスは、通常のリレーショナル・データベースのように、蓄積されたデータに後から張るようなものではない。これは、9種類のインデックス型で、データを格納するものなのだ。
「データごとに、さまざまなデータの持ち方ができます。データの持ち方が、そのデータに合わせた最適な形になっている、と考えてもらえばいいでしょう。これが、アドホック性能が高いことへの、答えの1つでもあります」（原氏）
Sybase IQのインデックスは、初期設定段階でどの方式にするかを選ぶ。データが更新されたらインデックスを張り直すといった手間は必要ない。
