Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
Sawa_Ito
Product and Topic Expert
Product and Topic Expert
0 Kudos
309

このブログは、2013 年 6 月 17 日に SAP ジャパン公式ブログに掲載されたものを SAP ジャパン公式ブログ閉鎖に伴い転載したものです。

 




 

こんにちは、SAP ジャパンの naotosakai です。先日 6 月 12 日に行われたプレスリリースで SAP IQ 16 が発表されました。このブログではプレスリリースの中で紹介した SAP IQ 16 の新機能のいくつかを詳細に解説したいと思います。

速さの根幹:データ格納方法の変更による圧縮効率の改善


ビッグデータを解析するデータウェアハウスのパフォーマンスを向上させるには、大量のデータのスキャン時に発生するディスク I/O をいかに減らすかが重要です。SAP IQ ではこれまでデータを圧縮して保管することでディスク I/O の削減を行い、パフォーマンス向上に繋げてきました。SAP  IQ はディスクベースの列指向データベースです。データはカラム単位にディスク上に格納されています。この際にそのまま格納せず「FP(Fast Projection)インデックス」という形式で格納しています。以下が FP インデックスを概念化した図となります。


FP インデックスは内部的にカラムの値をユニーク化したものが格納される「ルックアップテーブル」とそれへのポインタが格納される「論理配列」の2 つで構成されます。

 

SAP IQ 15.4 までは論理配列のデータ長は3種類あり、ルックアップテーブルのエントリー数、カラムのカーディナリティ(カラムに格納される値の種類の数)により 1 byte、2 byte、3 byte と変換されてディスク上に格納します。運用を開始してカーディナリティが増加し、1 byte に収まりきらなくなった場合は変換が発生し、ルックアップテーブルと論理配列のポインタ部分のデータ長を2 byte や 3 byteに拡張します。(注:3 byte を超えると Flat FP インデックスという別形式になります。)

この構造によりデータは圧縮されて格納されることになり、更にカラムをスキャンする際はポインタとなる論理配列へのスキャンが主となり、結果ディスク I/O が削減され超高速パフォーマンスを実現しています。他社 RDBMS(Relational Database Management System)で使用していたスキーマ構成のまま SAP IQ へ移行しただけでディスクの使用量が 1/5 になった、締めのレポート作成や夜間バッチの速 度が 100 倍以上速くなったという数々の事例はこのようなちょっと地味なデータ格納構造がベースとなり実現されています。

さて SAP IQ 16 ではこの FP インデックスが「n-Bit FPインデックス」という新しい FP インデックスに置き換えられました。論理配列の管理単位が byte 単位ではなく bit 単位となります。


 

上記までの説明でお気づきの方もいらっしゃるのではないでしょうか?

実は SAP IQ 15.4(まで)ではデータ型、データ長と挿入されるデータのカーディナリティにおいてデータの圧縮率の低下、あるいはデータの圧縮自体が構造上行われないというパターンが存在しました。一番簡単な例は 1 byte のカラムです。CHAR(1) や VARCHAR(1) はデータのカーディナリティなどにかかわらずデータ圧縮ができないのです。これは、FPインデックスの論理配列の最小が 1 byte で、データも 1 byte ですので同じサイズとなり、FPインデックスの形式をとることで逆に大きくなってしまうということが原因です。(注:この場合でも SAP  IQ は列指向アーキテクチャにより他の RDBMS を圧倒するパフォーマンスを提供することができます。)

SAP  IQ 16 からは、論理配列の管理単位がbitとなりこのようなパターンへの対処、並びに圧縮率が改善されています。また、これまでカーディナリティが現在の FP インデックスの byte 数を超えた場合、例えば 1 byte から 2 byte へ切り替わる際には、既存の FP インデックスの変換(自動で行われます)が必要でしたが、これは不要となりました。n-Bit FPインデックスは 31 bit まで対応しているため FP インデックス形式で対応できるカーディナリティ数が大幅に増加したことも特長の1つです。SAP IQ 15.4と比較し SAP  IQ 16 はデータの圧縮率、パフォーマンス共に向上し、ペタバイトクラスのデータウェアハウスを考慮した改良がされています。

ロードパフォーマンス向上:デルタマージ

 


 

SAP  IQ 16 ではデータロード時の動作が変更されています。HG インデックスが付与された既存のテーブルにデータを追加ロードする場合はロードしたデータから小型のインデックスを作成し、その後バックグラウンドで既存のインデックスとマージするという動作になりました。大きなテーブルにデータを追加した場合、テーブルへのデータ追加処理ではなくインデックスへのデータ追加処理に時間がかかるという現象があります。RDBMS に対しての作業で

    • 同じデータ量なのにロード時間が違う

 

    • 日次バッチ等で毎日ほぼ同じデータ量をロードしているにも関わらず、だんだんとロード時間が長くなっていく



という現象などが該当します。SAP  IQ 16 ではこのような現象を改善し、データ量に比例したデータロード時間でロードが完了するようになりました。ロード完了直後は 1 つのテーブルに同一のインデックスが 2 つ存在するイミングタイミングが存在するということになりますが、オプティマイザーはそれをきちんと考慮しますのでご安心ください。インデックスのマージも小型のインデックスになった時点で追加分のデータは内部的にソートされていることになりますのでロードしながらのインデックスの追加と比較し高速に行うことができます。

この機能を何処かで聞いたことがある方もいらっしゃるのではないでしょうか?そうです、これはSAP HANA が採用している「デルタマージ」という機能です。

SAP  IQ 16 は ”SAP”として提供する SAP  IQ の最初のメジャーリリースとなります。SAP とSybase の統合により SAP と Sybase の開発者の連携・交流も進んでいます。SAP  IQ 16 にはこのように SAP HANA に由来するテクノロジーが搭載されました。(余談ですが Sybase データベースから SAP HANA に提供したテクノロジーもあったりしますよ。)

次回は OLTP 系の処理にも対応させることが出来るインメモリーローレベルストアとマルチプレックスによるスケールアウト構成での機能拡張を解説する予定です。