Оптимизация производительности приложения
Производительность приложения можно улучшить, уменьшив его размер, упростив модели данных, а также с помощью стратегического использования анализа множеств. В этом разделе будут рассмотрены факторы, влияющие на производительность, что поможет избежать проблем с производительностью, и способы оценки и мониторинга производительности приложения.
Посмотреть, как работает приложение, можно с помощью инструмента оценки производительности. Для получения дополнительной информации см. Оценка производительности приложения.
Сложность приложения
Существуют широкие категории, с помощью которых можно диагностировать проблемы. Наиболее сложные приложения обладают самой низкой производительностью.
Простые приложения:
- не включают сложный анализ множеств или операторов If();
- не включают большие таблицы;
- используют простую модель данных;
- содержат простые вычисления;
- могут иметь большие объемы данных.
Приложения средней сложности:
- имеют модель данных со многими таблицами, но следуют рекомендациям;
- используют анализ множеств и несколько операторов If();
- имеют большие или широкие таблицы на листах (15 столбцов или больше).
Сложные приложения:
-
имеют очень сложную модель данных;
- подключаются к большим объемам данных;
- содержат сложные вычисления, диаграммы и таблицы.
Большие объемы данных
При подключении к большим объемам данных можно использовать следующие стратегии архитектуры.
Сегментация
QVDs можно сегментировать по измерениям, таким как период времени, регион или уровень агрегирования. Например:
- В одном файле QVD могут содержаться данные за два последние года.
- В другом файле QVD могут содержаться исторические данные старше двух лет.
В третьем файле QVD могут содержаться все данные, агрегированные на более высоком уровне. Например, данные за месяц вместо даты или данные по стране вместо отдельных клиентов.
- Один большой файл QVD может включать в себя все данные, которые используются только лишь небольшим подмножеством пользователей.
Приложения можно сегментировать похожим способом. Небольшие приложения отвечает аналитическим потребностям большинства пользователей. Это позволяет экономить память.
Можно также создать несколько приложений, каждое из которых будет охватывать тот или иной регион. Таким образом, пользователи не откроют приложение с данными, которые не представляют для них интереса или к которым у них нет доступа. Данные, которые нельзя получить через Section Access, по-прежнему влияют на память.
Создание приложения On-demand (ODAG)
Приложения On-demand Qlik Sense дают пользователям агрегированные представления больших объемов данных. Они могут определять и загружать необходимые подмножества данных для подробного анализа.
С точки зрения пользователя есть два приложения:
- корзина интернет-магазина с агрегированными данными;
- пустое шаблонное приложение для отображения подробных данных.
Пользователь создает выборки в приложении корзины интернет-магазина. По достижении определенного порога создается пользовательский скрипт LOAD, который заполняет шаблонное приложение требуемыми подробными данными. Для получения дополнительной информации см. Управление большими данными с помощью приложений On-demand.
Цепочка приложений
Цепочка приложений (она называется цепочкой документов в QlikView) означает, что есть агрегированное приложение, с которым пользователи регулярно работают. Если пользователю нужно больше подробных данных, его выборка может быть передана из агрегированного приложения в подробное приложение, чтобы можно было просмотреть данные с меньшим уровнем детализации. Это позволяет экономить память, потому что пользователи не загружают ненужные подробные данные. Для формирования цепочки приложений можно добавить на лист объекты кнопок. Для получения дополнительной информации см. Цепочка приложений.
Цепочки приложений также поддерживаются посредством APIs. Например, можно использовать API интеграции приложений, чтобы создать пользовательскую цепочку приложений. Для получения дополнительной информации см. раздел API интеграции приложений (только английский язык).
динамических видах;
Динамические виды предоставляют актуальные визуализации, построенные на основе больших объемов данных или сценариев с быстро меняющимися данными. При работе с динамическими видами необходимо учитывать следующее:
При обновлении динамических видов осуществляется непосредственная загрузка источника данных. Производительность обновления зависит от производительности базового источника данных.
Шаблонные приложения на основе динамических видов позволяют создавать динамические диаграммы.
Для получения дополнительной информации о динамических видах см. раздел Управление данными с помощью динамических видов.
Direct Query
Хотя рекомендуется использовать приложения, загружаемые в память, Direct Query позволяет оставлять данные в первоначальном источнике. Для оптимизации использования Direct Query необходимо учитывать следующее:
Производительность Direct Query очень зависит от производительности базового источника данных.
Необходимо обеспечить максимально возможную простоту модели данных Direct Query, так как сложные запросы могут вызывать проблемы с производительностью.
Для получения дополнительной информации о Direct Query см. раздел Обращение к облачным базам данных непосредственно из Direct Query.
Производительность модели данных
Ниже приводятся индикаторы, которые могут повлиять на производительность модели данных. Каждый из них представляет собой рекомендацию, которая позволит повысить удобство использования приложения.
| Действие | Описание |
|---|---|
Удалите синтетические ключи | Qlik Sense создает синтетические ключи, если в нескольких таблицах данных есть два общих поля или более. Это может означать, что в скрипте или модели данных есть ошибка. Для диагностики синтетических ключей см. Синтетические ключи. |
Удалите циклические ссылки из модели данных | Циклические ссылки возникают, когда у двух полей есть несколько связей. Qlik Sense попытается устранить эту проблему, изменив подключение к одной из таблиц. Однако необходимо устранить все предупреждения о циклической ссылке, см. Представление о циклических ссылках и их исправление. |
Используйте соответствующую детализацию данных | Следует загружать только необходимые данные. Например: группе пользователей нужны лишь данные, разделенные по неделям, месяцам и годам. Можно загрузить агрегированные данные или агрегировать данные в скрипте загрузки, чтобы сэкономить память. Если пользователю действительно нужно визуализировать данные на более низком уровне детализации, можно использовать ODAG или цепочку документов. |
Используйте QVDs, если возможно | QVD — это файл, в котором содержится таблица данных, экспортируемых из программы Qlik Sense. Этот формат файла оптимизирован для скорости при чтении данных из скрипта, но в то же время не занимает много места. Чтение данных из файла QVD обычно в 10–100 раз быстрее, чем чтение из других источников данных. Для получения дополнительной информации см. Работа с файлами QVD. |
Файлы QVD оптимизируются при загрузке | Файлы QVD можно читать в двух режимах: стандартном (быстром) и оптимизированном (сверхбыстром). Выбор режима выполняется обработчиком скриптов автоматически. В отношении оптимизированных загрузок существуют некоторые ограничения. Поля можно переименовывать, однако при наличии какого-либо из этих операторов запустится стандартная загрузка:
|
Используйте инкрементальную загрузку | Если приложение подключается к большому объему данных из постоянно обновляющихся баз данных, перезагрузка набора данных полностью может занять много времени. Вместо этого следует использовать инкрементальную загрузку для получения новых или измененных записей из базы данных. Для получения дополнительной информации см. Загрузка новых и обновленных записей с помощью инкрементальной загрузки. |
Используйте консолидированную модель Snowflake | При использовании модели данных Snowflake («снежинка») можно сократить количество таблиц данных, объединяя их при помощи префикса Join или другого сопоставления. Это особенно важно для больших таблиц фактов. Согласно общему правилу рекомендуется иметь только одну большую таблицу. Для получения дополнительной информации см. Объединять или не объединять. |
Используйте денормализованные таблицы, в которых немного полей | Если имеются две таблицы с немногими полями, их можно объединить для повышения производительности. Для получения дополнительной информации см. Объединение таблиц с помощью операторов Join и Keep. |
Используйте денормализованные таблицы поиска (листа) с сопоставлением загрузок | Не следует использовать префикс Join , если необходимо только добавить одно поле из одной таблицы в другую. Рекомендуется использовать функцию поиска ApplyMap, см. Не объединяйте — используйте вместо этого функцию ApplyMap. |
Удалите или отделите метки времени от поля даты | При наличии метки времени поля даты могут занимать пространство, так как строковое представление больше и количество уникальных значений больше. Если точность для анализа не нужна, можно округлить метку времени, например, до ближайшего часа с помощью Timestamp(Floor(YourTimestamp,1/24)) или удалить компонент времени полностью с помощью Date(Floor(YourTimestamp)). Если метка времени нужна, ее можно отделить от даты. Можно использовать ту же функцию Floor() и затем создать новое поле с извлеченным временем при помощи, например, следующей команды: Time(Frac(YourTimestamp)). |
Удалите ненужные поля из модели данных | В модели данных следует загружать только необходимые поля. Избегайте использования Load * и SELECT. Убедитесь, что сохранены:
|
Избегайте использования таблиц-связей, если объем данных большой | По возможности следует использовать таблицы-связи. Однако при больших объемах данных производительность объединенных таблиц может быть выше, чем у таблиц-связей. |
Разбивайте объединенные измерения на новые поля | Рекомендуется разбивать объединенные измерения на отдельные поля. Это уменьшает количество уникальных вхождений значений в полях. Это подобно тому, как можно оптимизировать метки времени. |
Используйте оператор AutoNumber, если возможно | Для создания оптимизированной загрузки можно сначала загрузить данные из файла QVD, а затем преобразовать значения в ключи символов с помощью оператора AutoNumber.Для получения дополнительной информации см. AutoNumber. |
Избегайте использования островков данных | Островки данных могут быть полезны, но они обычно влияют на производительность. При создании островков для значений выборки используйте переменные. |
Сохраняйте файлы QVD согласно инкрементальным периодам времени | Рекомендуется сохранять файлы QVD согласно сегментам, таким как один месяц. Эти меньшие по размеру файлы QVD за месяц можно затем использовать во многих различных приложениях, которым, возможно, не потребуются все данные. |
Производительность листа
Ниже приводятся рекомендации, позволяющие повысить производительность листов и визуализаций.
| Действие | Описание |
|---|---|
Избегайте использования функции If(), если возможно | Если функция If() будет использоваться в функции агрегирования, она будет работать на уровне записи и будет вычисляться много раз. Например, если в агрегировании 1000 записей, то условие If() будет вычислено 1000 раз. Это может лавинообразно нарастать при вложении операторов. Вместо этого рекомендуется использовать анализ множеств. Фильтр анализа множеств применяется перед агрегированием, что приводит к сокращению времени ответа. Также эти ответы можно кэшировать с помощью анализа множеств, а If() — нет. Кроме того, можно рассмотреть другие функции и изменения в модели данных. |
| Полей из различных таблиц в таблице агрегирования следует по возможности избегать. | Вычисление агрегирования выполняется за два шага:
Однопоточная часть может значительно снизить производительность. Один пример: если в агрегировании, например Sum(Quantity*ListPrice), есть несколько полей. Если Quantity находится в таблице фактов, а ListPrice — в основной таблице продуктов, подсистема сначала должна соединить эти две таблицы для нахождения комбинаций, а потом она сможет начать суммировать продукт. Соединение — однопоточная часть, а суммирование — многопоточная. Если оба поля находятся в одной таблице, соединение не требуется и агрегирование вычисляется значительно быстрее. |
Сократите до минимума использование функции Aggr() и вложенной функции Aggr() | Функция Aggr() существенно влияет на производительность. Неправильное использование может стать причиной неточных результатов. Например, в таблице с измерениями, которые отличаются от измерений в функции Aggr(). Для получения дополнительной информации см. Когда не следует использовать AGGR? |
Используйте анализ множеств, если возможно | Можно использовать анализ множеств для определения множества значений данных, отличных от обычного множества, определяемого текущими выборками. Для получения дополнительной информации см. Анализ множеств. |
Избегайте сравнения строк, если возможно | Сравнение строк не так эффективно, как анализ множеств. Например, следует избегать Match(), MixMatch(), WildMatch() и Pick(). Вместо этого создайте флаги в скрипте или используйте анализ множеств. Для получения дополнительной информации см. Условные функции и Производительность условный агрегирований. |
Используйте условия вычисления для объектов, содержащих интенсивные вычисления | Например, рассмотрим визуализацию со многими записями и отсутствием выборок. Рекомендуется добавить условия вычисления к объектам, чтобы они визуализировались только после того, как сделаны определенные выборки. Это предотвращает создание очень больших гиперкубов. Например, элемент GetSelectedCount([Country])=1 OR GetPossibleCount([Country])=1. В этом сценарии визуализация не будет выполнена, если пользователь не выберет одну страну или не сделает другую выборку, в которой возможна только одна страна. |
Вычисляйте меры предварительно в скрипте, если возможно | Любую меру, которая находится на самом низком уровне детализации модели данных, следует вычислять в скрипте. Например, если в одной и той же записи в таблице есть Sales и Cost, можно получить маржу путем вычисления Sales - Cost AS Margin. Можно также заранее агрегировать другие значения, если известно, что они не изменятся в зависимости от выборки или они привязаны к другому уровню детализации. |
Используйте таблицы, которые имеют меньше 15 столбцов и условия вычисления | Таблицу с 15 столбцами можно считать широкой. Если таблицы состоят из многих записей, рекомендуется использовать условия вычисления для объекта таблицы, чтобы он визуализировался только после того, как сделаны определенные выборки или выполнены критерии. Если таблица очень широкая, следует:
|
Не создавайте слишком много объектов на листе | Объекты вычисляются при переходе пользователя на лист. При выполнении любой выборки на листе каждый объект будет вычислен повторно, если то текущее состояние отсутствует в кэше. Если на листе много диаграмм, пользователь почти при каждой выборке должен ждать, пока каждый объект не будет вычислен. Это создает значительную нагрузку на подсистему. Поэтому рекомендуется следовать концепции Dashboard/Analysis/Reporting (DAR) для разработки чистого и минималистичного приложения. Для получения дополнительной информации см. Методология DAR. |
Применяйте числовые флаги в скрипте для использования в анализе множеств | Анализ множеств с флагами может быть эффективнее, чем использование сравнений строк или умножения. |
| Основные элементы позволяют перетаскивать управляемые показатели и гарантируют кэширование выражений. Например, Sum(Sales) отличается от SUM(Sales). Выражения кэшируются с учетом написания и регистра и должны соответствовать дословно, чтобы их можно было использовать повторно. |
Производительность загрузки данных
Оптимизация загрузки данных важна для обеспечения беспроблемной и эффективной работы с приложениями в Qlik Cloud. В этом разделе рассматриваются факторы, оказывающие влияние на производительность, и даются рекомендации по предотвращению проблем с производительностью.
Qlik Data Gateway — Direct Access
Когда Qlik Data Gateway — Direct Access применяется для перезагрузки данных в приложение, на производительность влияют следующие факторы:
Скорость и задержка отклика подключения между хостом шлюза данных и базой данных.
Скорость и задержка отклика подключения между хостом шлюза данных и клиентом Qlik Cloud. В идеале для улучшения производительности хост шлюза данных должен быть размещен в том же регионе, что клиент Qlik Cloud.
Хранилище базы данных
Медленное подключение к хранилищу приводит к увеличению времени на перезагрузку. Учитывайте следующее при работе с базами данных, размещенными локально или в облаке:
Локально: Если база данных размещена локально и использует один сервер с другими приложениями, на ее производительность могут влиять операции таких приложений.
Облако: При правильной настройке размера облачные базы данных обычно обеспечивают более высокую производительность по сравнению с локальными базами данных. Чтобы обеспечить оптимальные результаты, выберите для облачного хранилища регион, расположенный близко к клиенту Qlik Cloud.