Optimizar el rendimiento de las apps
El rendimiento de las apps se puede mejorar con un tamaño reducido de app, unos modelos de datos simplificados y la utilización estratégica del análisis de conjuntos. Esta sección le ayudará a evitar problemas de rendimiento al señalar áreas en las que el rendimiento pueda verse afectado y cómo puede evaluar y supervisar el rendimiento de la app.
Puede ver cómo está siendo el rendimiento de su app con la herramienta de evaluación del rendimiento. Para más información, vea Evaluación del rendimiento de las apps.
Complejidad de la app
Aquí se indican diferentes categorías para el diagnóstico de problemas. Las apps más complejas tienen el rendimiento más bajo.
Apps sencillas:
- No incluyen análisis de conjuntos complejos o sentencias If().
- No incluyen tablas extensas.
- Tienen un modelo de datos simple.
- Contienen cálculos simples.
- Pueden tener grandes volúmenes de datos.
Apps moderadas:
- Tienen un modelo de datos con muchas tablas, pero se respetan las mejores prácticas.
- Utilizan análisis de conjuntos y varias sentencias If().
- Tienen tablas grandes o anchas en hojas (de 15 columnas o más).
Apps complejas:
-
Tienen un modelo de datos muy complejo.
- Conectan con grandes volúmenes de datos.
- Contienen cálculos, gráficos y tablas complejos.
Grandes volúmenes de datos
Puede emplear estas estrategias de arquitectura cuando conecte con grandes volúmenes de datos.
Segmentación
Puede segmentar QVDs por dimensiones, como el periodo de tiempo, la región o la agregación. Por ejemplo, puede tener:
- Un QVD que contenga datos de los dos años más recientes.
- Un QVD que contenga datos históricos de más de dos años.
Un QVD que contenga todos los datos agregados en un nivel superior. Por ejemplo, por mes en lugar de fecha, o por país en lugar de clientes individuales.
- Un gran QVD con todos los datos, que solo lo utilice un pequeño subconjunto de usuarios.
Puede segmentar las apps de forma similar. Las apps más pequeñas abordarán las necesidades analíticas de la mayoría de los usuarios. Esto ahorra memoria.
También puede tener varias apps enfocadas en diferentes regiones. De esta manera, los usuarios no abrirán una app con datos que no les interesen o para la que no tengan derechos de acceso. Los datos a los que no se puede acceder mediante la sección de acceso afectan también a la memoria.
Generación de apps a demanda (ODAG)
Las apps a demanda de Qlik Sense proporcionan a los usuarios vistas agregadas de almacenes de macrodatos. Pueden identificar y cargar subconjuntos relevantes de datos para un análisis detallado.
Desde la perspectiva del usuario, hay dos apps:
- Un carrito de la compra con datos agregados.
- Una app de plantilla vacía que sirve para mostrar detalles.
El usuario realiza selecciones en la app del carrito de compras. Una vez que se alcanza un determinado umbral, se crea un script de carga LOAD personalizado que llena la app de plantilla con los detalles solicitados. Para más información, vea Gestionar grandes fuentes de datos big data con apps bajo demanda.
Encadenamiento de aplicaciones
El encadenamiento de aplicaciones (conocido como encadenamiento de documentos en QlikView) significa que hay una aplicación agregada que los usuarios consumen regularmente. Si un usuario necesita más detalles, se pueden pasar las selecciones de la app agregada a una app de detalles para que pueda visualizar un nivel de granularidad menor. Esto ahorra memoria, porque el usuario no carga detalles innecesarios. El encadenamiento de aplicaciones se puede realizar agregando objetos de botón a una hoja. Para más información, vea Encadenamiento de aplicaciones.
El encadenamiento de aplicaciones también es compatible a través de APIs. Por ejemplo, puede usar la API de integración de aplicaciones para crear un encadenamiento de aplicaciones personalizado. Para más información, vea API App Integration (solo en inglés).
Vistas dinámicas
Las vistas dinámicas permiten visualizaciones actualizadas para un gran volumen de datos o escenarios de datos que cambian rápidamente. Considere lo siguiente cuando trabaje con vistas dinámicas:
Cuando actualiza las vistas dinámicas, la fuente de datos se carga directamente. El rendimiento de la actualización se ve afectado por el rendimiento de la fuente de datos subyacente.
Las aplicaciones de plantillas de vista dinámica pueden ayudarle a crear gráficos dinámicos.
Para más información sobre el uso de las vistas dinámicas, vea Administrar datos con vistas dinámicas.
Direct Query
Si bien se recomiendan las aplicaciones en memoria, Direct Query le permite mantener los datos en su fuente original. Considere lo siguiente para optimizar el uso de Direct Query:
El rendimiento de Direct Query se ve muy afectado por el rendimiento de la fuente de datos subyacente.
Mantenga su modelo de datos de Direct Query lo más simple posible, ya que las consultas complejas pueden causar problemas de rendimiento.
Para más información sobre Direct Query, vea Acceso directo a bases de datos en la nube con Direct Query.
Rendimiento del modelo de datos
Estos son indicadores que pueden afectar al rendimiento del modelo de datos. Cada uno de ellos es una práctica recomendada que mejorará la facilidad de uso de las apps.
| Acción | Descripción |
|---|---|
Eliminar las claves sintéticas | Qlik Sense crea claves sintéticas cuando dos o más tablas de datos tienen dos o más campos en común. Esto puede significar que hay un error en el script o en el modelo de datos. Para diagnosticar claves sintéticas, vea Claves sintéticas. |
Eliminar las referencias circulares del modelo de datos | Las referencias circulares se producen cuando dos campos tienen más de una asociación. Qlik Sense tratará de resolverlas cambiando la conexión con una de las tablas. A pesar de esto, todas las advertencias de referencias circulares deben resolverse, vea Entender y resolver las referencias circulares. |
Granularidad apropiada de los datos | Solo debe cargar los datos que sean necesarios. Por ejemplo: un grupo de usuarios solo necesita datos divididos por semana, mes y año. Puede cargar los datos agregados o agregar los datos dentro del script de carga para ahorrar memoria. Si un usuario necesita visualizar datos con un nivel de granularidad inferior, puede usar ODAG o encadenar documentos. |
Utilizar los QVDs cuando sea posible | Un archivo QVD es un archivo que contiene una tabla de datos exportados desde Qlik Sense. Este formato de archivo está optimizado para mejorar la velocidad de lectura de datos desde un script, siendo al mismo tiempo muy compacto. Leer datos desde un archivo QVD es por lo general 10-100 veces más rápido que leer de otras fuentes de datos. Para más información, vea: Trabajar con archivos QVD. |
Archivos QVD optimizados para la carga | Los archivos QVD se puede leer en dos modos: estándar (rápido) y optimizado (más rápido). El modo que se utilice viene determinado de forma automática por el motor de script. Hay algunas limitaciones en cuanto a las cargas optimizadas. Es posible cambiar el nombre de los campos, pero cualquiera de las operaciones siguientes dará como resultado una carga estándar:
|
Aprovechar las cargas incrementales | Si su app conecta con una gran cantidad de datos procedentes de bases de datos que están continuamente actualizándose, cargar el conjunto de datos completo puede llevar mucho tiempo. Para evitar esto debe usar la carga incremental, a fin de recuperar registros nuevos o modificados de la base de datos. Para más información, vea Cargar registros nuevos y actualizados mediante la carga incremental. |
Modelo Snowflake consolidado | Si tiene un modelo de datos en copo de nieve, es posible que pueda reducir la cantidad de tablas de datos uniendo algunas de ellas mediante el prefijo Join u otra forma de asignación. Esto es especialmente importante para tablas grandes de hechos. Una buena regla general es tener solo una tabla grande. Para más información, vea Unir o no unir. |
Las tablas que tienen un número pequeño de campos no están normalizadas | Si tiene dos tablas con pocos campos, unirlas puede mejorar el rendimiento. Para obtener más información, vea Combinar tablas con Join y Keep. |
Tablas de búsqueda (hoja) no normalizadas con cargas de correspondencias | No debería usar el prefijo Join si solo necesita agregar un campo de una tabla a otra. Debe usar la función de búsqueda ApplyMap , vea No unir - usar ApplyMap. |
Eliminar o desasociar marcas de tiempo del campo de fecha | Los campos de fecha pueden ocupar demasiado espacio cuando la marca de fecha-hora está presente, ya que la representación de la cadena es más larga y el número de valores distintos es mayor. Si no necesita tanta precisión en su análisis, puede redondear la marca de fecha-hora por ej. a la hora más cercana usando Timestamp(Floor(YourTimestamp, 1/24)) o eliminar directamente el componente de hora por completo usando Date (Floor(YourTimestamp)). Si desea que aparezca la hora, puede desasociarla de la fecha. Puede usar la misma función Floor() y luego crear un nuevo campo con la hora extraída usando algo parecido a: Time(Frac(YourTimestamp)). |
Eliminar campos innecesarios del modelo de datos | Solo debería cargar los campos que sean necesarios en su modelo de datos. Evite usar Load * y SELECT. Asegúrese de mantener:
|
Evitar las tablas de enlaces cuando se trata con grandes volúmenes de datos | Debe usar tablas de enlaces cuando sea posible. No obstante, si se trata de grandes volúmenes de datos, las tablas concatenadas pueden superar en rendimiento a las tablas de enlaces. |
Dividir las dimensiones concatenadas en nuevos campos | Debe separar las dimensiones concatenadas en campos aparte. Esto reduce el número de instancias únicas en que aparecen los valores en sus campos. Esto es similar a cómo se pueden optimizar las marcas de tiempo. |
Utilizar AutoNumber cuando sea posible | Puede crear una carga optimizada cargando primero los datos desde un archivo QVD y después usando la sentencia AutoNumber para convertir los valores en claves de símbolo. Para obtener más información, vea AutoNumber. |
Evitar las islas de datos | Las islas de datos pueden ser útiles, pero por lo general afectan al rendimiento. Si está creando islas para los valores de selección, utilice variables. |
Los QVD se almacenan basándose en plazos incrementales | Debe almacenar los QVD en segmentos, por ejemplo, mensualmente. Estos QVD mensuales más pequeños pueden admitir muchas apps diferentes que podrían no necesitar todos los datos. |
Rendimiento de las hojas
Aquí tiene las prácticas recomendadas que mejorarán el rendimiento de las hojas y visualizaciones.
| Acción | Descripción |
|---|---|
La función If() se ha de evitar en la medida de lo posible | Si la función If() se usa dentro de una función de agregación, operará a nivel de registros y será evaluada muchas veces. Por ejemplo, si tiene 1000 registros en una agregación, una condición If() se evaluará 1000 veces. Esto podría aumentar en cascada rápidamente si anida sentencias. Debería usar el análisis de conjuntos en su lugar. Se aplica un filtro de análisis de conjuntos antes de la agregación, lo que ocasiona una respuesta más rápida. Estas respuestas también se pueden almacenar en la memoria caché mediante análisis de conjuntos, donde If() no puede. También podría considerar otras funciones y modificaciones al modelo de datos. |
| Los campos de diferentes tablas dentro de una tabla de agregación se evitan siempre que sea posible. | Cuando se evalúa una agregación, el cálculo se realiza en dos pasos:
La parte de un solo subproceso puede afectar considerablemente al rendimiento. Un ejemplo es si tiene varios campos dentro de la agregación, por ejemplo, Sum(Quantity*ListPrice). Si Quantity se encuentra en la tabla de hechos y ListPrice está en la tabla maestra de productos, el primer motor debe unir las dos tablas para encontrar las combinaciones antes de poder comenzar a sumar el producto. La unión es la parte de un solo hilo y la suma es de varios hilos. Si ambos campos se encuentran en la misma tabla, no es necesaria ninguna combinación y la agregación se evalúa considerablemente más rápido. |
Las funciones Aggr() y Aggr() anidadas se deben usar lo mínimo posible. | La función Aggr() afecta enormemente al rendimiento. El uso incorrecto puede dar resultados inexactos. Por ejemplo, en una tabla con dimensiones que se diferencian de las dimensiones dentro de la función Aggr(). Para más información, vea ¿Cuándo no debe usarse AGGR? |
Usar análisis de conjuntos en la medida de lo posible. | Puede utilizar el análisis de conjuntos para definir un conjunto de valores de datos que sea distinto del conjunto normal definido por las selecciones actuales. Para más información, vea Análisis de conjuntos. |
Evitar las comparaciones de cadenas en la medida de lo posible | Las comparaciones de cadenas no son tan eficientes como el análisis de conjuntos. Por ejemplo, es mejor evitar Match(), MixMatch(), WildMatch() y Pick(). Cree indicadores en el script o utilice el análisis de conjuntos en su lugar. Para más información, vea Funciones condicionales y Rendimiento de agregaciones condicionales. |
Las condiciones de cálculo se utilizan en objetos que contienen cálculos intensivos. | Puede tener visualizaciones con muchos registros cuando no haya selecciones. Como práctica recomendada, agregue condiciones de cálculo a los objetos para que solo se procesen después de haber realizado ciertas selecciones. Esto detiene la creación de hipercubos muy grandes. Por ejemplo: GetSelectedCount([Country])=1 OR GetPossibleCount([Country])=1. En este escenario, la visualización no se reproducirá a menos que el usuario seleccione un solo país o haga otras selecciones donde solo sea posible un único país. |
Calcular previamente las medidas en el script siempre que sea posible | Cualquier medida que se encuentre en el nivel más bajo de granularidad del modelo de datos debe calcularse en el script. Por ejemplo, si en el mismo registro en una tabla tiene Sales y Cost, podría obtener el margen calculando Sales - Cost AS Margin. También puede agregar otros valores por adelantado si sabe que no variarán según la selección o que están vinculados a un nivel diferente de granularidad. |
Las tablas tienen menos de 15 columnas y tienen condiciones de cálculo. | Una tabla con 15 columnas podría considerarse amplia. Si sus tablas constan de muchos registros, debe usar condiciones calculadas en el objeto de la tabla para que solo se muestre después de cumplirse determinadas selecciones o criterios. Si su tabla se extiende mucho a lo ancho, considere lo siguiente:
|
Las hojas no deben tener una cantidad excesiva de objetos. | Los objetos se calculan cuando el usuario navega a la hoja. Cada vez que un usuario realiza una selección en esa hoja, cada objeto se volverá a calcular si ese estado actual no existe en la memoria caché. Si tiene una hoja con muchos gráficos, el usuario tendrá que esperar a que se calcule cada objeto en casi todas las selecciones. Esto supone una carga significativa para el motor. Como práctica recomendada, siga el concepto Dashboard/Analysis/Reporting (DAR) para desarrollar una app limpia y mínima. Para más información, consulte la metodología DAR. |
Los indicadores numéricos se deben aprovechar en el script para su uso en el análisis de conjuntos | El análisis de conjuntos con indicadores puede ser más eficiente que usar comparaciones de cadenas o multiplicación. |
Utilizar elementos maestros o variables para las expresiones | Los elementos maestros permiten arrastrar y soltar métricas gobernadas y garantizan que las expresiones se almacenarán en la memoria caché. Por ejemplo, Sum(Sales) es diferente de SUM(Sales). Las expresiones se almacenan en la memoria caché con su ortografía y mayúsculas, y deben coincidir literalmente para ser reutilizadas. |
Rendimiento de la carga de datos
Optimizar la carga de datos es importante para una experiencia fluida y receptiva al trabajar con aplicaciones en Qlik Cloud. Esta sección destaca los factores que afectan al rendimiento y proporciona orientación sobre cómo prevenir problemas de rendimiento.
Pasarela de datos de Qlik - Direct Access
Cuando utiliza Pasarela de datos de Qlik - Direct Access para recargar datos en su aplicación, los siguientes factores afectan al rendimiento:
Velocidad de conexión y latencia entre la máquina que aloja la pasarela y la base de datos.
Velocidad de conexión y latencia entre la máquina que aloja la pasarela y su espacio empresarial inquilino de Qlik Cloud. Lo ideal es alojar la pasarela de datos en la misma región que su espacio empresarial inquilino de Qlik Cloud para mejorar el rendimiento.
Almacenamiento en base de datos
Las conexiones de almacenamiento lentas pueden aumentar los tiempos de recarga. Considere lo siguiente para bases de datos alojadas localmente o en la nube:
Locales: Si su base de datos es local y comparte un servidor con otras aplicaciones, su rendimiento podría verse afectado por las actividades de esas otras aplicaciones.
Nube Cuando tienen el tamaño correcto, las bases de datos en la nube suelen ofrecer un mejor rendimiento que las bases de datos locales. Para obtener resultados óptimos, elija una región para su almacenamiento en la nube que esté cerca de su espacio empresarial inquilino de Qlik Cloud.