1

VIEW を公開すると

CREATE VIEW myView AS
SELECT ...
FROM ...

xsodata経由

service namespace "oData" {
    entity "mySchema"."myView" as "myView";
}

および GET /myView を VIEW 作成後に初めて実行すると、パフォーマンスが非常に低くなります。

ここに画像の説明を入力

ただし：同じリクエストを再度実行した後（およびその後は毎回）、パフォーマンスは私が望むものです：

ここに画像の説明を入力

質問:

  • なんで？

  • 最初の長時間実行されるリクエストを回避するには?

すでに試しました：

  • HANA Studios SQL コンソールで (ステートメントの準備なしで) SQL プロファイラー出力を実行すると、常に優れたパフォーマンスが得られます

  • テーブルのホットロード ( LOAD myTable ALL;) は効果がありませんでした

アップデート

「Why」の部分: xs-engine は、リクエストにパラメーターがなくても、クエリを準備済みステートメントとして実行していることがわかりました。(ユーザーのコンテキスト内で) 最初の実行時にクエリが実行され、M_SQL_PLAN_CACHE( SELECT * FROM M_SQL_PLAN_CACHE WHERE USER_NAME = 'myUser') 内のエントリが生成されます。プラン キャッシュ ( ALTER SYSTEM CLEAR SQL PLAN CACHE) をクリアすると、oData 要求が再び遅くなり、パフォーマンス ギャップがクエリの再準備にあるという仮定につながります。

現在、2 番目の質問に行き詰まっています。それを回避するにはどうすればよいでしょうか。特定のプラン キャッシュ エントリを再コンパイル ( ALTER SYSTEM RECOMPILE SQL PLAN CACHE ENTRY 123) にマークするという私たちのアプローチでは、エントリが無効になり、自動的に更新されませんでした...

4

1 に答える 1

1

最初の実行を長い間削除できるかどうかはわかりませんが、ビューを で実行される計算ビューに変更してみてくださいSQL Engine。

HANAは計算ビューを使用するために非常に最適化されており、プラン キャッシュは計算ビューを使用するとより高速に実行され、最初の実行時間が大幅に短縮される可能性があります。また、Calcのプランキャッシュ。ビューはユーザー間で共有する必要があります (ユーザーがビュー_SYS_REPOを生成するため)。

スクリプト バージョンを使用すると、現在の SQL の多くを再利用できると思いますが、グラフィカルなアプローチを使用することもできます。

運が良かったら教えてください。ビッグデータを使用したモデリングは常に驚きです。

于 2016-09-05T19:32:50.667 に答える