Оптимизация производительности приложений
Производительность приложения может быть улучшена за счет уменьшения размера приложения, упрощения моделей данных и стратегического использования анализа множеств. Этот раздел поможет вам избежать проблем с производительностью, указывая на области, которые могут повлиять на производительность, а также на то, как вы можете оценивать и отслеживать производительность приложения.
Вы можете отслеживать производительность своего приложения с помощью инструмента оценки производительности, а также тестировать его работу на движках разного размера, вручную назначая более крупные движки. Для получения дополнительной информации см. Оценка производительности приложения и Назначение механизмов для повышения производительности приложения.
Сложность приложения
Это свободные категории, которые могут помочь в диагностике проблем. Наиболее сложные приложения имеют самую низкую производительность.
Простые приложения:
- Не содержат сложного анализа множеств или операторов If().
- Не содержат больших таблиц.
- Имеют простую модель данных.
- Содержат простые вычисления.
- Могут иметь большие объемы данных.
Умеренно сложные приложения:
- Имеют модель данных со множеством таблиц, но следуют лучшим практикам.
- Используют анализ множеств и несколько операторов If().
- Имеют большие или широкие таблицы на листах (15 или более столбцов).
Сложные приложения:
-
Имеют очень сложную модель данных.
- Подключаются к большим объемам данных.
- Содержат сложные вычисления, диаграммы и таблицы.
Большие объемы данных
Вы можете использовать эти архитектурные стратегии при подключении к большим объемам данных.
Сегментация
Вы можете сегментировать QVDs по таким измерениям, как временной диапазон, регион или уровень агрегирования. Например, у вас может быть:
- Файл QVD, содержащий данные за последние два года.
- Файл QVD, содержащий исторические данные старше двух лет.
-
Файл QVD, содержащий все данные, агрегированные на более высоком уровне. Например, по месяцам вместо дат или по странам вместо отдельных клиентов.
- Один большой файл QVD со всеми данными, который используется только небольшой подгруппой пользователей.
Вы можете аналогичным образом сегментировать приложения. Более мелкие приложения будут удовлетворять аналитические потребности большинства пользователей. Это экономит память.
Вы также можете иметь несколько приложений, ориентированных на разные регионы. Таким образом, пользователи не будут открывать приложение с данными, которые им не интересны или к которым у них нет прав доступа. Данные, недоступные через section access, все равно влияют на память.
Генерация приложений по запросу (ODAG)
Приложения по запросу 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(). Для получения дополнительной информации см. When should AGGR not be used? |
|
По возможности используется анализ множеств |
Вы можете использовать анализ множеств для определения набора значений данных, который отличается от обычного набора, определяемого текущими выборками. Для получения дополнительной информации см. Анализ множеств. |
|
По возможности избегайте сравнения строк |
Сравнения строк не так эффективны, как анализ множеств. Например, следует избегать функций Match(), MixMatch(), WildMatch() и Pick(). Вместо этого создавайте флаги в скрипте или используйте анализ множеств. Для получения дополнительной информации см. Условные функции и Performance of conditional aggregations. |
|
Условия расчета используются для объектов, содержащих ресурсоемкие вычисления |
У вас могут быть визуализации со множеством записей, когда выборки отсутствуют. В качестве лучшей практики добавляйте условия расчета к объектам, чтобы они отображались только после того, как будут сделаны определенные выборки. Это предотвращает создание очень больших гиперкубов. Например: GetSelectedCount([Country])=1 OR GetPossibleCount([Country])=1. В этом сценарии визуализация не будет отображаться, пока пользователь не выберет одну страну или не сделает другие выборки, при которых возможен выбор только одной страны. |
|
По возможности меры предварительно рассчитываются в скрипте |
Любая мера, находящаяся на самом низком уровне детализации модели данных, должна рассчитываться в скрипте. Например, если в одной и той же записи таблицы у вас есть Sales и Cost, вы можете получить маржу, рассчитав Sales - Cost AS Margin. Вы также можете заранее агрегировать другие значения, если знаете, что они не будут меняться в зависимости от выборки, или если они привязаны к другому уровню детализации. |
|
Таблицы имеют менее 15 столбцов и содержат условия расчета |
Таблица с 15 столбцами может считаться широкой. Если ваши таблицы состоят из множества записей, вам следует использовать условия расчета для объекта таблицы, чтобы она отображалась только после выполнения определенных выборок или критериев. Если ваша таблица очень широкая, рассмотрите следующие варианты:
|
|
Листы не содержат избыточного количества объектов |
Объекты вычисляются, когда пользователь переходит на лист. Каждый раз, когда пользователь делает выборку на этом листе, каждый объект будет пересчитываться, если текущее состояние отсутствует в кэше. Если на вашем листе много диаграмм, пользователю придется ждать вычисления каждого объекта практически при каждой выборке. Это создает значительную нагрузку на движок. В качестве лучшей практики следуйте концепции Dashboard/Analysis/Reporting (DAR) для разработки чистого и минималистичного приложения. Для получения дополнительной информации см. DAR methodology. |
|
Числовые флаги используются в скрипте для применения в анализе множеств |
Анализ множеств с флагами может быть более эффективным, чем использование сравнения строк или умножения. |
|
Основные элементы или переменные, используемые для выражений |
Основные элементы позволяют перетащить управляемые метрики и гарантируют кэширование выражений. Например, Sum(Sales) отличается от SUM(Sales). Выражения кэшируются с учетом написания и регистра и должны совпадать дословно для повторного использования. |
Производительность загрузки данных
Оптимизация загрузки данных важна для обеспечения бесперебойной работы и дружественного интерфейса при работе с приложениями в Qlik Cloud. В этом разделе описаны факторы, влияющие на производительность, и даны рекомендации по предотвращению проблем с производительностью.
Шлюз данных Qlik — прямой доступ
Когда вы используете Шлюз данных Qlik — прямой доступ для перезагрузки данных в свое приложение, на производительность влияют следующие факторы:
-
Скорость подключения и задержка между компьютером, на котором размещен шлюз данных (Data Gateway), и базой данных.
-
Скорость подключения и задержка между компьютером, на котором размещен шлюз данных (Data Gateway), и вашим клиентом Qlik Cloud. В идеале для повышения производительности размещайте шлюз данных в том же регионе, что и ваш клиент Qlik Cloud.
Хранилище базы данных
Медленные подключения к хранилищу могут увеличить время перезагрузки. Учитывайте следующее для баз данных, размещенных локально или в облаке:
-
Локально: если ваша база данных размещена локально и использует один сервер с другими приложениями, на ее производительность могут влиять действия этих других приложений.
-
Облако: при правильном выборе размера облачные базы данных обычно обеспечивают лучшую производительность, чем локальные базы данных. Для достижения оптимальных результатов выберите регион для своего облачного хранилища, который находится близко к вашему клиенту Qlik Cloud.