Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
こんにちわ
QlikSenseのパフォーマンス向上の方法について質問させて下さい。
試験データから本番データに移行したら、アプリケーションが重く計算に時間がかかってしまっています。
メモリを増設する以外の方法でパフォーマンスを向上するやり方を教えて頂けますでしょうか。
調べたところ、下記やり方はあるようなので行う予定です。
・count(distinct...)ではなく、ロードスクリプトでcountフラグ'1'をつけてSumで集計するようにする。
・集計関数(Sum,Count)にifを使わず、極力SET分析に置き換える。
アプリケーションの数式は上記がほとんどなのですが、それ以外に[getobjectfield]を使ってドリルダウンによって数式を変えています。
それ以外に、DBの設計とアプリケーションの作成でやりがちな高負荷の設計方法がありましたら、改善方法を教えて頂けますでしょうか
優先順位が高い順に教えて頂けますと幸いです。
QlikView用の資料ですが、考え方はQlik Senseも基本同じなので参考にしてみてください。
記載されているように、オブジェクトやスクリプトの計算式ではCOUNT関数やIF関数の書き換え効果は大きいです。
他として、テーブル構成やファイルサイズによって効果の違いがあったり逆に低下するケースもありますが、QlikViewで効果があった内容を列記しておきます。
①ステートや変数を減らす
これは、ともに数が少ない時は気にせず利用している方が利便性のメリットの方が大きいですが、数が増えるとファイルオープンにかかる時間やリストボックスでの選択値の切替、クリアーなどにかかる時間がどんどん増加します。
QlikViewでは横思考に切り替わったV12からよりパフォーマンス低下の影響が大きくなりました。
(横思考が影響しているのかは不明ですが)
Qlik Senseもたしか横思考だったと思うので、同様のパフォーマンス低下があると思います。
ものによっては代用がきかないケースもあるかと思いますが、選択に利用する項目を、計算に利用するテーブルと連携していない別テーブルでも保持させる事で、ステートや変数をセット分析に変更する事が可能です。
ファイル内のテーブルやデータが増える事になり、ファイルサイズは大きくなりますが、対象データのテーブルに連携していないので、ファイルサイズ増加が直接パフォーマンスの低下につながることは、あまりないとおもいます。
②テーブルの正規化
基本的にQlikViewは正規化している方が処理が早いケースが多そうです。以前アーキテクチャーを読んだ際にも、そのように理解した記憶があります。ただ、ビューアーで見た際の見難さなどもあるので、1項目だけテーブルから分ける場合などは、効果と比較して総合的に判断した方が良いとおもいます。
③テキストデータの精製
前後や文中のスペースなどが不要であれば、Trim関数、PurgeChar関数などを利用して、スクリプト内で精製して取り込んだ方が良いです。また、日付情報のキーなどを数値やテキストのYYYYMMDDなどで保持する場合、AutoNumberを使わないのであればYYMMDDに変更するなど、出来るだけバイト数を少なく保持するように工夫した方がよいです。
④AutoNumber関数を使って、キー項目を書き換える
特にファイルサイズの圧縮効果は大きいです。デメリットとして、ロード時間が増加します。
計算速度が変わるかというと微妙ですが、バイト数は減るので、検索は早くなるのではないかと思います。
複数のキー項目に対して、全て単純にAutoNumber関数を使うと、変換対象となる全ての項目に対して、都度検索をかける(該当の値がAutoNumber化されているかどうか)ので、よりロード時間がかかってしまいますが、IDも合わせて記載する事で、かなり緩和されます。データ件数が多いほど追加されるデータ1件に対しての処理時間は少しずつ増加します。
(悪い例) AutoNumber(項目A) as 項目A
(良い例) AutoNumber(項目A,'idA') as 項目A
⑤圧縮率を変更する
計算処理とは別ですが、圧縮率を ' 高 ' で利用されている場合、 ' なし ' に変更すると、ファイルの保存や開閉(こちらは?)が早くなります。ファイルの保存時間はあきらかに違いが発生しますので、サイズの大きいファイルで開発、変更作業を頻繁にするのであれば、変更をおすすめします。ただ、バックアップファイルとして保存する際はサーバー領域確保のために圧縮したりと、場合によって工夫して下さい。私の場合、圧縮利用していた2G弱程度のファイルが4Gを超える事となりましたが、開発途中での保存時などのストレスがかなりなくなりました。また、以前はManagement Consoleで自動更新の際、たまに保存でのエラーが発生しておりましたが、圧縮をなくしてファイルサイズを大きくしたのにエラーはなくなりました。おそらく、圧縮を無くすことで、保存時の負荷は減っているのではないかと思います。
他にもいろいろあると思います。上記はそれぞれ概要で記載しましたが、詳しい情報が必要な場合は、また記載して下さい。
ただ、エンジンの仕様は当然わからないので、あくまでも今までの経験とそこからの憶測の範疇の話になってしまいますが....
では、チューニングがんばってください!
めんどくさい面もありますが、仮説がうまく結果に反映されると、少なくとも自己満足は出来ますので(^.^)
Kawahataさま 若松さま
いつもご回答して頂きありがとうございます。
ご教示頂いた方法を少しずつ試していきたいと思います。
地道にやっていかないといけないですね。
またガイドラインをまだ読み込めていないのですが、joinするときや、キーで他のテーブルと関連付けする際にも気をつけることはありますでしょうか。
joinした時には、もちろん不要になったテーブルは軽くするためと合成キーが出来ないようにDropしているのですが、他にも気をつけることはありますでしょうか。
テーブル構成で言うと、通常は真ん中にトランザクションがあって、そのまわりにマスタがあるような放射線状になった構成が、QlikViewの場合最も効果的といわれています。テーブルが増えてきても、この考えで部分部分が成立つようにすれば、基本的には同じです。
個人的に避けているのは、Synthetic key、Synthetic table は作らないようにしています。
これが出来ると、Synthetic tableを自動作成してしまいリロード時間が増加するだけではなく、リソース自体も消費され、動作も遅くなります。Synthetic tableが出来ないように、キー情報が複数の項目で出来上がっている場合は、それらをまとめて合成キーで連携できるようにした方が良いです。
また、テーブルが増えてくるとループが出来てしまったりといった問題も生じてくると思いますが、これを回避する意味も含め、各キー情報が網羅されたCentralLinkTableを用意して、そのまわりにトランザクション、そのさらに外側にマスタを作成するといった構成が良いと思います。注意点として、CentralLinkTableに連結している他テーブルのキー情報がCentralLinkTable内に欠損していると、当然ながらCentralLinkTable経由で他のテーブルとつながりません。ただこれさえ注意しておけば、テーブル追加の際などもあまり再構成を考えることなく、単純に追加テーブル内にキー項目を用意するだけで追加できる場合も多く、メリットとしては大きいと思います。
他では、取り込んではいるが利用していない項目を削除する事も心がけておいた方が良いです。
QlikViewだとDocumentAnalyzerというファイルがフリーで提供されていて、このファイルで調査したいファイルのパスを指定してリロードするだけで、利用していない項目の自動検索やドロップ用のスクリプト作成など、ドキュメントをさまざまな視点で調査する事が出来るのですが、QlikSenceでも同様のものが無いか一度調べてみると良いかもしれません。
DaCompareToolだと、どの動作でリソースを利用しているかといった事も調査できるので、チューニング作業の効率が飛躍的に向上します。
ともに下記から取得可能です。
若松さま
申し訳ございません、返事が大変遅くなりました。
真ん中にトランザクションがあって、周りにマスタがあるという構造は出来るだけ意識して作っていくようにしたいと思います。
また合成キーが出来てしまった場合は、必ずカラム名を変更したり、テーブル上でユニークキーを作るようにしています。
テーブルが増えてしまった場合、ループが起きてしまったり、遠回りに参照しているような構造になってしまっていることはあると思います。
QlikSenseでも効率化の調査ソフトを調べてみます。
いつもご丁寧に教えて頂きありがとうございます。