Оптимизация производительности приложения

Производительность приложения можно улучшить за счет уменьшения размера приложения, упрощения моделей данных и стратегического использования анализа множеств. Этот раздел поможет вам избежать проблем с производительностью, указывая на области, где производительность может снижаться, и объясняя, как можно оценивать и отслеживать производительность приложения.

Вы можете отслеживать производительность вашего приложения с помощью инструмента оценки производительности, а также тестировать его работу на механизмах разного размера, вручную назначая более крупные механизмы. Для получения дополнительных сведений см. Оценка производительности приложения и Назначение механизмов для повышения производительности приложения.

Сложность приложения

Это общие категории, которые могут помочь в диагностике проблем. Самые сложные приложения имеют самую низкую производительность.

Простые приложения:

Не включают сложный анализ множеств или операторы If().
Не включают большие таблицы.
Имеют простую модель данных.
Содержат простые вычисления.
Могут иметь большие объемы данных.

Приложения средней сложности:

Имеют модель данных с множеством таблиц, но следуют передовым практикам.
Используют анализ множеств и несколько операторов If().
Имеют большие или широкие таблицы на листах (15 столбцов и более).

Сложные приложения:

Имеют очень сложную модель данных.
Подключаются к большим объемам данных.
Содержат сложные вычисления, диаграммы и таблицы.

Большие объемы данных

Вы можете применять эти архитектурные стратегии при подключении к большим объемам данных.

Сегментация

Вы можете сегментировать QVDs по измерениям, таким как временной интервал, регион или уровень агрегирования. Например, у вас может быть:

QVD, который содержит данные за два последних года.
QVD, который содержит исторические данные старше двух лет.
QVD, который содержит все данные, агрегированные на более высоком уровне. Например, по месяцам вместо дат или по странам вместо отдельных клиентов.
Один большой QVD со всеми данными, который используется только небольшой группой пользователей.

Вы можете сегментировать приложения аналогичным образом. Небольшие приложения удовлетворят аналитические потребности большинства пользователей. Это экономит память.

У вас также может быть несколько приложений, ориентированных на разные регионы. Таким образом, пользователи не будут открывать приложение с данными, которые им не интересны или к которым у них нет прав доступа. Данные, недоступные через доступ к разделу, по-прежнему влияют на память.

Генерация приложений по запросу (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 можно читать в двух режимах: стандартном (быстром) и оптимизированном (сверхбыстром). Выбор режима выполняется обработчиком скриптов автоматически. В отношении оптимизированных загрузок существуют некоторые ограничения. Поля можно переименовывать, однако при наличии какого-либо из этих операторов запустится стандартная загрузка: Любые преобразования загружаемых полей. Использование предложения where, запускающего распаковку записей в Qlik Sense. Применение команды Map к загружаемому полю.
Используйте инкрементальную загрузку	Если ваше приложение подключается к большому объему данных из постоянно обновляющихся баз данных, перезагрузка всего набора данных может занять много времени. Вместо этого следует использовать инкрементальную загрузку для получения новых или измененных записей из базы данных. Для получения дополнительной информации см. Загрузка новых и обновленных записей с помощью инкрементальной загрузки.
Используйте консолидированную модель 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 — прямой доступ

При использовании Шлюз данных Qlik — прямой доступ для перезагрузки данных в ваше приложение на производительность влияют следующие факторы:

Скорость подключения и задержка между машиной, на которой размещен Data Gateway, и базой данных.
Скорость подключения и задержка между машиной, на которой размещен Data Gateway, и вашим клиентом Qlik Cloud. В идеале размещайте Data Gateway в том же регионе, что и ваш клиент Qlik Cloud, для повышения производительности.

Хранилище базы данных

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

Локально: Если ваша база данных находится локально и использует общий сервер с другими приложениями, на ее производительность могут влиять действия этих других приложений.
Облако: При правильном выборе размера облачные базы данных обычно обеспечивают лучшую производительность, чем локальные базы данных. Для достижения оптимальных результатов выберите регион для вашего облачного хранилища, который находится близко к вашему клиенту Qlik Cloud.

Помогла ли вам эта страница?

Если вы обнаружили какую-либо проблему на этой странице или с ее содержанием — будь то опечатка, пропущенный шаг или техническая ошибка, сообщите нам об этом!

Оставьте свой отзыв здесь