HANA: xsodata: Огромный разрыв в производительности между первым и 2-го исполнения запроса

Question

Если я разоблачить VIEW

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

через xsodata

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

и GET/MyView впервые после создания VIEW ПРЕДСТАВЛЕНИЕМ очень низкая:

Однако: После того, как ре rforming тот же запрос снова (и каждый раз после этого) производительность является то, что я хочу, чтобы это было:

Вопросы:

• Почему?

• Как избежать первого долговременного запроса?

Уже пробовал:

• Выполнение SQL Profiler-вывода (без подготовки заявления) в консоли HANA Studios SQL дает хорошую производительность всегда

• Таблица hotloading (LOAD myTable ALL;) не имело эффект

Обновление

Мы выяснили, что «почему» -part: xs-engine запускает запрос как подготовленный оператор, даже если в запросе нет параметров. При первом выполнении (в контексте пользователя) запрос получает значение, что приводит к записи в M_SQL_PLAN_CACHE (SELECT * FROM M_SQL_PLAN_CACHE WHERE USER_NAME = 'myUser'). Очистка кеша плана (ALTER SYSTEM CLEAR SQL PLAN CACHE) делает запрос OData медленным, что приводит к предположению, что разрыв в производительности заключается в повторной подготовке запроса.

Мы застряли со вторым вопросом: как этого избежать? Наш подход, чтобы отметить определенные записи кэша плана для перекомпиляции (ALTER SYSTEM RECOMPILE SQL PLAN CACHE ENTRY 123) просто аннулировал запись и не обновлять автоматически ...

Answer 1

Я не уверен, что вы можете REMOVE первого выполнения много времени, но вы можете попробуйте изменить представление на представление расчета, выполненное в SQL Engine.

HANA был оптимизирован для использования его вычислений, а кэш плана должен работать быстрее с ними, возможно, значительно сократить время первого выполнения. Кроме того, запланировать кеш Calc. Мнения должны быть разделены между пользователями (так как _SYS_REPO - это тот, кто их генерирует).

Если вы используете версию скрипта, я считаю, что вы можете повторно использовать много своего текущего SQL, но вы также можете попробовать использовать графический подход.

Сообщите нам, если вам повезло.Моделирование с помощью Big Data всегда является неожиданностью.