ABAP/4 : Buenas prácticas en HANNA

4. Buenas Prácticas

El poder de la base de datos SAP HANA reside un en rendimiento sin precedentes y su fácil administración.

Los usuarios de las funciones analíticas de la base de datos SAP HANA podrán apreciar las cortas respuestas que . Los tiempos de respuesta cortos permiten a los usuarios consultar la base de datos de una manera altamente interactiva sin la necesidad de informes predefinidos. Las mejores prácticas tanto todos nos esforzamos para minimizar los tiempos de respuesta.

La base de datos SAP HANA destaca en operaciones a alta velocidad. En particular, esto es evidente por los cortos tiempos de respuesta disponibles al utilizar las funciones de análisis de la base de datos. Al tener la capacidad de entregar resultados rápidamente SAP HANA puede ser consultada en una manera muy interactiva sin necesidad de informes predefinidos o sin la necesidad de tablas de agregación intermedias.

Con todo esto, el rendimiento de SAP HANA es muy dependiente de cómo se utiliza. En esta sección se centrará en las mejores prácticas. Las mejores prácticas en este contexto de actuación, tienen que ver con la minimización de la transferencia de datos dentro de la base de datos y lograr tiempos de respuesta rápidos.

4.1 Características del motor de almacenamiento de columna

Tanto el motor de almacenamiento de la fila y como de la columna tienen una capacidad de consulta incorporada optimizada para el método de almacenamiento respectivo. En consecuencia, todos los motores de almacenamiento tiene sus puntos fuertes para cada una de las diferentes tareas.

El motor fila soporta todas las características proporcionadas por SAP HANA SQL.

El motor de columna, sin embargo, ha sido optimizado para el análisis y soporta un conjunto más restringido de características de SQL. Estas características son mucho más rápidas que las funciones correspondientes a los motores de almacenamiento de la fila. Como no todas las características proporcionadas por SAP HANA SQL están soportados de forma nativa por el motor de almacenamiento de la columna, el optimizador de consultas crea a veces en el plan de ejecución que involucra ambos motores de almacenamiento, incluso si los datos residen totalmente en el almacén de la columna. Por el contrario, a veces es deseable transferir los resultados intermedios de la fila al almacen de la columna porque los pasos posteriores de cálculo se pueden procesar mucho más rápido por este motor. Como regla general se recomienda utilizar el "Explain Plan" característica del estudio de SAP HANA para explorar la ejecución de sentencias SQL críticas y optimizar el modelo de datos y las instrucciones SQL que vamos a necesitar. Los resultados de esta se pueden utilizar para optimizar el modelo de datos y las instrucciones SQL.

En la lista siguiente se explican las características del motor de columna de la consulta. El motor de columna de forma nativa puede ejecutar consultas que son lógicamente equivalentes a las consultas que se pueden expresar de la siguiente forma.

SELECT <column engine expressions separated by comma>
FROM <column engine FROM specifications separated by comma>
[ WHERE <column engine filter condition> ]
[ GROUP BY <column engine expressions separated by comma> ]
[ HAVING <column engine filter condition> ]
[ ORDER BY <column engine expressions with optional

ASC | DESC separated by comma>]

[ LIMIT <any expression> [OFFSET <any expression> ] ]

El motor de columna FROM puede ser usado de la siguientes formas:

<table reference>

( SELECT * FROM <table reference> WHERE <column engine filter condition> )

<column engine FROM specification> INNER JOIN <column engine FROM specification> ON <column engine join condition>

<column engine FROM specification> LEFT OUTER JOIN <column engine FROM specification> ON <column engine join condition>

<column engine FROM specification> RIGHT OUTER JOIN <column engine FROM specification> ON <column engine join condition>

<column engine FROM specification> FULL OUTER JOIN <column engine FROM specification> ON <column engine join condition>

El motor de columna admite las siguientes condiciones de unión.

<column reference from one side> = <column reference from the other side>

Los tipos de datos de dos columnas debe ser el mismo. Decimales con diferentes precisiones o escalas también son tratados como tipos de datos diferentes.

AND operations between column engine join conditions

Los outer joins, cyclical joining. Por ejemplo, Ta y Tb = Sa = Rb no se admite si ya existe una condición de unión entre S y R.

El motor de columna soporta las siguientes condiciones.

Binary comparison (=, <>, <, >, <= and >=) between column engine expressions

LIKE, IS NULL and IN predicate on a column engine expression

AND, OR, NOT operations over column engine filter conditions

El motor columna soporta las siguientes expresiones.

Constant values

Binary arithmetic operation (+, -, * and /) between column engine expressions

<column engine expression>

String concatenation (||) between column engine expressions

CASE <column engine expression> WHEN <column engine expression> THEN <column engine expression> ... [ELSE <column engine expression> ] END

CASE WHEN <column engine filter condition> THEN <column engine expression> ... [ELSE <column engine expression> ] END

Las funciones especificadas a continuación tienen como argumento.

Funciones sin argumentos son evaluados por el analizador de SQL. Los resultados evaluados se pasa al motor de columna como valores constantes.

o CURRENT_CONNECTION, CURRENT_SCHEMA, CURRENT_USER, SYSUUID, CURRENT_DATE/ CURRENT_TIME/ CURRENT_TIMESTAMP and CURRENT_UTCDATE/ CURRENT_UTCTIME/ CURRENT_UTCTIMESTAMP

Expresiones equivalentes a una de las listadas anteriormente.

El motor columna soporta los siguientes expresiones de agregación.

o MIN | MAX | COUNT | SUM | AVG ([DISTINCT] <column engine expression>)

Desde SQL proporciona varias maneras posibles para formular una consulta, una consulta SQL que no está en el formato anterior se pueden procesar de forma nativa por el motor de columna si la consulta es equivalente a una consulta que se puede representar en el formato correcto. A continuación se presentan ejemplos de tal equivalencia. La equivalencia se denota como ↔.

SELECT * FROM T, S WHERE T.a = S.a ↔ .SELECT * FROM T INNER JOIN S ON T.a = S.a

SELECT DISTINCT a, b, c FROM T ↔ .SELECT a, b, c FROM T GROUP BY a, b, c

SELECT * FROM T WHERE EXISTS (SELECT * FROM S WHERE T.a = S.a) ↔ .SELECT DISTINCT T.* FROM T INNER JOIN S ON T.a = S.a

Equivalente solo si la tabla T tiene clave primaría.

SELECT * FROM T WHERE NOT EXISTS (SELECT * FROM S WHERE T.a = S.a)
↔.SELECT T.* FROM T LEFT OUTER JOIN S ON T.a = S.a WHERE S.a IS NULL

4.2 Estimación de las consultas SQL's.

El optimizador de SQL es un mecanismo para la ejecución de consultas utilizando para formular una estimacion de los costos. Las siguientes tablas muestran un listado de coeficientes que se pueden utilizar para calcular los tiempos de ejecución relativos para las operaciones de búsqueda soportados por los dos motores de almacenamiento. Hay que tener en cuenta que este cuadro no se puede utilizar para calcular los tiempos reales de ejecución, ya que dependen de los parámetros de hardware implicados como el número de núcleos de CPU y la velocidad del reloj del bus. Sin embargo, las tablas se pueden usar para la comparación relativa entre los métodos alternativos para calcular una estrategia de búsqueda óptima o modelo de datos óptimo.

4.2.1 Modelo del costo en rendimiento de las busquedas por filas.

4.2.2 Modelo del costo en rendimieno de las búsquedas por Columnas.

4.3 SQL Query Tuning para motores de almacenamienos en columnas.

El motor de almacenaemiento en columna de SAP HANA ha sido optimizado para el patrón más frecuente de las consultas OLAP en forma de un solo bloque SPJG (seleccionar, proyectar, JOIN y GROUP BY). En esta sección se enumeran las características para obtener el mejor rendimiento de la columna del motor.

Tenga en cuenta que el uso de técnicas de alto rendimiento no causará problemas si usamos tablas pequeñas o trabajamos con un número relativamente pequeño de datos de resultados intermedios extraídos de tablas grandes. Sin embargo, hay que prestar especial atención cuando las operaciones se ejecutan en tablas grandes o grandes conjuntos de resultados intermedios. Las soluciones sugeridas aquí son sólo ejemplos y soluciones posibles.

Muchos de los consejos aquí sugieren evitar las operaciones que no son compatibles de forma nativa por el motor de la columna. En el capítulo anterior se puede comprobar las operaciones que se admiten de forma nativa.

Todas las tablas utilizadas por los ejemplos de este capítulo son tablas basadas en columnas.

4.3.1 Expresiones.

Cálculo. Si un cálculo que se utiliza no esta soportado por motor de la columna, la operación de cálculo se ejecutará por el motor de la fila que puede conducir a la transferencia de grandes conjuntos de resultados intermedios de la columna para el motor del motor fila.

Por ejemplo, la función TO_DATE sólo es compatible con el motor sin columna una cadena de formato La función TO_DATE puede analizar cadenas en forma de «AAAAMMDD" y "AAAA-MM-DD 'por defecto. Si un usuario sabe que las cadenas de origen puede ser analizada por la función TO_DATE, es mejor utilizar la función TO_DATE sin una cadena de formato. De lo contrario la llamada de función y sus parámetros tienen que ser transferidos al motor fila para ser procesado. En el ejemplo siguiente, DATE_STRING es una columna VARCHAR.

Usando cálculos que son admitidos de forma nativa por el motor de la columna es más rápido que usar no usar cálculos nativos. Sin embargo, las operaciones con los cálculos son más lentas que las operaciones sin cálculos y es mejor evitar cálculos si es posible. A continuación se muestra un ejemplo de cómo evitar cálculos.

Si un cálculo no se puede evitar cambiando la instrucción SELECT, puede ser posible evitar un cálculo de silencio durante el procesamiento de consultas. Esto se puede conseguir mediante la adición a la columna calculada automáticamente como se muestra en el siguiente ejemplo. Adición de una columna generada automáticamente mejora el rendimiento de las consultas sin el coste en tiempos y recursos de la inserción y la actualización.

Tenga en cuenta que la especificación de columnas que se necesita para las inserciones de datos después de la adición de la columna generada. Esto es necesario para evitar la creación de valor para la columna generada, como se muestra en el siguiente ejemplo.

Casting Implicito.

SAP HANA puede realizar un casting implícitamente incluso si el usuario no ha especificado una operación explícita de encasillado. Por ejemplo, si hay una comparación entre un valor VARCHAR y un valor de fecha, el sistema de base de datos los realiza. El casting de tipos implícita la operación para convertir el valor en un valor DATE VARCHAR. La conversión de tipos implícita se hace desde los de baja preferencia a los tipos de mayor preferencia. Se puede encontrar el tipo de reglas de prioridad en el SAP HANA SQL Reference.

El casting implícito es un tipo de cálculo y tiene el mismo efecto en el rendimiento como otros cálculos. Por esta razón, es mejor evitar el casting implicito si es posible. Si dos columnas se compara con frecuencia por las consultas, es mejor crear dos columnas con el mismo tipo de datos. Una forma de evitar el coste de los casting implícitos es utilizar castings explícitos. Si una columna VARCHAR es para ser comparado con un valor de fecha y el desarrollador sabe que el valor de fecha de fundición en un valor VARCHAR produce el resultado deseado. Es mejor para ahorrar el costo de cambiar el tipo de la columna cambiando el tipo de valor. Por ejemplo, si la columna VARCHAR sólo contiene valores de fecha en forma de «AAAAMMDD», podría ser comparado con una cadena generada a partir de un valor de fecha en forma de «AAAAMMDD».

En el ejemplo siguiente, DATE_STRING es una columna VARCHAR. Tenga en cuenta que la comparación entre cadenas se produce un resultado diferente que entre las fechas en general. Ellos son idénticas sólo en algunos casos específicos.

Si encasillamiento implícito no puede ser directamente evitarse, añadiendo una columna generada a expensas del aumento de inserción y el costo de actualización puede ofrecer una solución más eficiente. Por ejemplo, un usuario puede encontrar '1 ', '1 .0' y '1 .00 'almacenan en una columna VARCHAR con las siguientes consultas.
En el siguiente ejemplo, 's' es una columna VARCHAR.

4.3.2 Ingreso

Non-Equijoin predicado.

El motor de columna no admite de forma nativa los predicados de unión distintas de la condición de igualdad. En otras palabras, el motor de columna sólo admite combinaciones de igualdad de forma nativa.

Predicados de unión conectadas por OR, productos cartesianos, comparaciones, y se une sin un predicado de unión no son compatibles de forma nativa. En estos casos, el motor fila será invocado y el intermedio de datos se transfiere a ese motor. Si sólo no equijoin predicados se utiliza el motor ejecutará la operaciones de filas join usando un algoritmo de bucle anidado. Usando el algoritmo de bucle anidado, así como cambio de formato de los datos intermedios, puede ser costoso si el conjunto de resultados intermedios es grande.

Para las combinaciones externas, si Equijoin predicados están conectados por y con organizaciones no equijoin predicados, se procesan de la misma manera como no equijoin predicados. Para interior se une, si equijoin predicados están conectados por y con organizaciones no equijoin predicados, sólo los predicados equijoin se utilizan para unir, y no equijoin predicados se aplican como predicados de filtro después de unirse. En este caso, incluso si los predicados de unión en su conjunto son suficientemente selectivo, únase a la cirugía puede tomar un tiempo considerable si el equijoin predicados mismos no son suficientemente selectivo.

Un ejemplo de reescritura de un predicado no equijoin en predicado en equijoin se muestra a continuación. En el ejemplo, M es una tabla que contiene fechas del primer y último mes de interés.

Los predicados sobre columnas calculadas. Equijoin predicados sobre columnas calculadas no son compatibles de forma nativa por el motor de la columna. Si el cálculo se soporta de forma nativa por el motor de la columna, el resultado intermedio de niño que contenga el cálculo operacional se formatea y consumida por el motor de la columna de nuevo. Si el cálculo no está soportado nativamente por el motor de la columna, los resultados intermedios de ambas operaciones niño se cambian y consumida por el motor fila. En cualquier caso, no puede haber un impacto en el rendimiento si la cantidad de datos intermedios es grande. Una manera posible de evitar los cálculos se investigó mediante el uso de columnas generadas.

A continuación se muestra un ejemplo de evitar columnas de combinación calculados utilizando columnas generadas.

El motor de columna no admite de forma nativa los predicados de filtro en el interior de combinación externa predicados. Predicados de filtro sobre la parte derecha de una combinación externa izquierda predicados y el filtro sobre el lado izquierdo de una combinación externa derecha son excepciones porque el desplazamiento de los predicados de las selecciones invocados por la operación de combinación produce los mismos resultados.

Si predicados de filtro se utilizan en el interior de combinación externa predicados y no puede ser desplazado por debajo de la operación de unión, el motor fila ejecuta la operación de combinación después de formatear los resultados intermedios de las selecciones de ambos niño. Un ejemplo de reescritura de tales predicados de filtro en predicados equijoin utilizando una columna generada se muestra a continuación.

Cyclic Join.

El motor de columna no admite de forma nativa unirse árboles que tienen ciclos en los bordes si se unen una combinación externa está involucrada en el ciclo. Si existe un ciclo que involucra una combinación externa, el resultado de un hijo de la combinación que completa el ciclo se materializa (reordenada) para romper el ciclo. Cíclica combinaciones internas son compatibles de forma nativa por el motor de la columna, pero es mejor evitarlas, ya que su rendimiento es inferior a acíclico combinaciones internas. Una manera de romper estos ciclos es mover algunas de las columnas que participan en la unión a diferentes mesas, cambiando el esquema. A continuación se muestra un ejemplo. En el ejemplo, la columna NACION de la tabla de proveedores se mueve a la tabla LINE_ITEM.

Filter Predicates Below Outer Join Accessing Multiple Tables

Predicados de filtro sobre varias mesas no son compatibles de forma nativa por el motor de columna si aparecen en una combinación externa. Si existe tal predicado de filtro, el resultado del niño, incluyendo el predicado se materializó antes de ejecutar la combinación. Predicados de filtro sobre el hijo izquierdo de una combinación externa izquierda y predicados de filtro sobre el menor derecho de una combinación externa derecha son excepciones porque mover los predicados hacia arriba a la combinación externa produce los mismos resultados. Tal movimiento se realiza automáticamente por SQL optimizador.
A continuación se muestra un ejemplo de un predicado de filtro que desencadena materialización de los resultados intermedios. Una forma de evitar tal materialización en el ejemplo sería mantener una columna de prioridad en la tabla LINE_ITEM en lugar de en la tabla PEDIDOS