viernes, 8 de marzo de 2013

SAP HANA Database 

– Guía de desarrollo –

Como usar SQL y SQLScript para el Modelado de Datos



1 Introducción.

1.1 ¿Que es SAP HANNA?


SAP HANA es una nueva tecnología desarrollada por SAP. Esta tecnología en su núcleo usa técnicas innovadoras denominadas “in-memory” para almacenar los datos, esta especialmente diseñado para el manejo de grandes cantidades de datos en tablas o datos relacionales sin repercutir en el rendimiento.

Las Bases de datos comunes almacenan los datos de las tablas en filas, por ejemplo, todos los datos que describen una dirección se almacenan uno junto a la otro en la memoria. De forma que siempre y cuando las necesidades de acceso sea una única dirección la aplicación se ejecutará más rápidamente ya que todos los datos requeridos se almacenan de forma contigua.

Sin embargo, vamos a imaginar que la aplicación requiere un listado de cuántas de las direcciones almacenadas hay en concreto para un un país, ciudad o código postal. En este caso se tendría que buscar en toda la tabla, seleccionar cada fila, y comprobar si el país o la ciudad que se requiere, son los que se están buscando en la consulta.

Como en “Todos” los dispositivos de almacenamineto masivo, como, discos duros, cintas, suelen tener lecturas mínimas bastantes grandes en comparación con los datos de interés, como por ejemplo 512 bytes para un disco duro, por lo que tendría que leer una o varias filas solo para comprobar un par de datos, “Brasil” o “San Francisco” por ejemplo. Las tablas a menudo contienen muchos campos, que son rara vez usados, como por ejemplo datos que relacionan otras tablas o campos que determinan otros campos según sus datos.

¿Se imaginan el aumento de la eficiencia si la aplicación accediera entorno a esos campos deseados y tener acceso a la información que es la que realmente estamos buscando? Si este estilo de almacenamiento de datos se utilizara experimentaría una respuesta significativamente más rápida desde su base de datos o aplicación.

SAP HANA permite la lectura en de los datos deseados por la organización una forma mas eficiente que la lectura de tablas formada por filas usando tablas formadas sólo por columnas. Además de la forma de almacenamiento común orientada a filas ahora se dispone de una disposición de datos orientada en columnas. Esto significa que su aplicación no tiene que esperar a la base de datos para recuperar los datos, no es necesario ya que todos los datos de una columna de la tabla se almacena de una manera adyacente. Así. En nuestro ejemplo de una tabla de direcciones, la exploración por el campo o columna de la ciudad es mucho más rápido que con la distribución orientada al almacenamiento en filas.

Pero que ocurría si su sistema de base de datos almacenara en caché ya todos los datos en la memoria RAM, la memoria principal, accesible cerca de la CPU. ¿Una memoria de acceso orientada a un diseño en columnas, un acceso silencioso y alta velocidad? Las mediciones realizadas en SAP y en el Instituto Hasso Plattner en Potsdam han demostrado que la reorganización de los datos en la memoria en modo de columnas trae un aumento muy elevado de velocidad al acceder a un subconjunto de los datos en cada fila de la tabla. Como SAP HANA almacena todos los datos en la memoria, los discos duros son raramente utilizados en el sistema, sólo son necesarios para registrar los cambios en la base de datos de persistencia permanente.

SAP HANA conserva el número de cambios de nuestro conjunto de datos lo más pequeño posible para ir registrando todos los cambios del conjunto de datos original. Los datos no son modificados en  la base de datos sino que son insertados o añadidos a tabla en formadas por columnas. Esto proporciona varias ventajas, no sólo la velocidad de acceso. Como todos los datos antiguos se conservan, sus aplicaciones pueden efectivamente hacer "un viaje en el tiempo" através de los datos que proporcionan vistas de los datos, que ha sido cambiados con el tiempo.

Las aplicaciones de gestión de bases de datos , mantienen por separado dos capas en su arquitectura, una capa de aplicación y otra capa de base de datos. Esta separación obliga a hacer viajar los datos de la base de datos a la aplicación antes de que pueda ser analizada o modificada. A veces grandes cantidades de datos tienen que viajar de una capa a otra . SAP HANA evita este cuello de botella común mediante una localización de datos precisa para las aplicaciones, que están en la propia base de datos. Para activar esta incorporación de la lógica de aplicación en la base de datos SAP ha inventado una extensión al estándar SQL (Structured Query Language) llamado SQLScript. SQLScript permite la programación de operaciones de los datos de una manera mas precisa que pueden ser ejecutados en la capa de base de datos. SQLScript. Le permite ampliar las consultas SQL que contienen cálculos a alto nivel ampliando así la capacidad de procesamiento de datos de la base de datos.


En este documento se explica cómo se puede hacer un uso eficiente del SQLScript para lograr un procesamiento mas preciso y rápido de los datos de nuestra base de datos SAP HANA.


1.2 Documentación relacionada. 

 
SAP ofrece otros documentos relacionados con los que se cuentan con detalle las herramientas de las que disponemos los programadores, y los lenguajes de programación utilizados. Estos documentos incluyen:

SAP HANA Database – Administration GuideCómo utilizar el SAP HANA estudio y la forma de administrar la base de datos SAP HANA.

SAP HANA - Modeling GuideCómo utilizar el modelizador HANA para crear vistas analíticas OLAP y puntos de vista de cálculo que se basan en los programas de SQLScript.

SAP HANA Database – SQL Reference Guide - (PDF)

SAP HANA Database – SQL Reference Guide (HTML) – Referencia completa para el lenguaje de consulta utilizado en SAP HANA.

SAP HANA Database – SQLScript Guide – Un tutorial sobre cómo programar en SQLScript y utilizar métodos y procedimientos de SAP HANA, incluyendo el uso de programas ABAP.


2 SAP HANA, la base de datos. 


La base de datos SAP HANA conceptualmente trata de aumentar la velocidad, aumentando la velocidad de ejecución de consultas de bases de datos a través de la utilización del almacenamiento de datos en memoria, y por lo tanto aumentar la velocidad de las aplicaciones. Con la base de datos SAP HANA, las consultas pueden ser ejecutadas en paralelo y rápidamente. Esto significa que técnicas de codificación complejas, por ejemplo, pre-cálculo de los valores , que fueron requeridas por las bases de datos tradicionales para mantener un buen nivel de rendimiento ya no es necesario. Esto se debe a que se puede utilizar para consultar la HDB enormes conjuntos de datos en tiempo real. Cuando este desarrollo complejo se retira, las aplicaciones pueden ser creadas y modificadas de una manera sencilla y clara, permitiendo tiempos más rápidos de desarrollo.

SAP HANA también trabaja correctamente en las bases de datos más tradicionales, por ejemplo,  a tablas con una orientación en filas. Esta combinación de lo clásico y de las tecnologías innovadoras permite al desarrollador elegir la mejor tecnología para su aplicación y, en su caso, utilizar los dos en paralelo.

2.1 Conceptos Básicos. 


2.1.1 Impacto del nuevo Hardware sobre la Arquitectura del sistema de la Base de Datos.

 

 Históricamente los sistemas de bases de datos se han diseñado para funcionar bien en sistemas informáticos de RAM limitada, esto tuvo el efecto de que los discos duros tuvieses un acceso lento I / O, siendo este el principal cuello de botella en el rendimiento en el acceso a los datos. En consecuencia, la arquitectura de los sistemas fue diseñada con un enfoque para tratar de optimizar el acceso al disco, por ejemplo, minimizando el acceso del número de bloques de disco (o páginas) que se lee en la memoria principal en el tratamiento de una consulta.

Las arquitecturas de las computadoras ha cambiado en los últimos años. Ahora un multi-core CPU son bastante comun, con una comunicación entre los núcleos del procesador que permite el procesamiento en paralelo de datos. Por otro lado la memoria principal ya no es un recurso limitado, los servidores modernos pueden tener 2 TB de memoria del sistema y esto permite a bases de datos completas, ser alojadas en la memoria RAM. Actualmente los procesadores del servidor tienen hasta 64 núcleos y 128 núcleos pronto estará disponible. Con el creciente número de núcleos, las CPU son capaces de procesar mas datos en menos tiempo.

Esto cambia el cuello de botella en el rendimiento de disco E / S para la transferencia de datos entre la CPU y la memoria caché de la memoria principal (véase la figura. 1).


Las Bases de datos tradicionales para el procesamiento de transacciones en línea (OLTP) no utilizan eficientemente el hardware actual. Se ha demostrado en 1999 por Alamaki, que cuando todas las bases de datos tienen datos cargados en la memoria principal de la CPU pasa la mitad de su tiempo de ejecución en puestos de espera, es decir, esperando que los datos se cargen desde la memoria principal a la memoria caché de CPU.

Así que, ¿cuáles son las características principales de un sistema de base de datos que se ejecuta con este nuevo hardware?


En la memoria de bases de datos. Todos los datos pertinentes estan disponibles en la memoria principal. Esta característica evita la pérdida de rendimiento de disco I / O. Con todos los datos en la memoria, técnicas para reducir la E / S en disco como índices ya no son necesarios. El almacenamiento en disco se requiere para la persistencia y permanecia de los datos, por ejemplo en caso de un fallo de alimentación.

Organización de la memoria Cache-consistente. El diseño debe minimizar el número de errores de caché y evitar paradas CPU en el acceso a memoria. Un mecanismo general para lograr esto es el de maximizar la localidad espacial de los datos, es decir, que los datos a los que se deben acceder consecutivamente deben ser almacenados de forma contigua en la memoria. Por ejemplo en las operaciones de búsqueda de datos de tablas se puede acelerar mediante la organización de los datos en columnas en lugar de filas.

Apoyo a la ejecución en paralelo.
Las altas velocidades de ejecución de la CPU son hoy en día se consiguen añadiendo más núcleos a la CPU. Las mejoras anteriores dan como resultado de la aplicación  una mayor densidad de embalaje en el chip y la optimización de las rutas electrónicas actuales. Los avances de velocidad disponibles utilizando estas técnicas han sido, en su mayor parte, ya agotados. Estos avances se basan en algoritmos que se utilizarán en las bases de datos con el fin de aprovechar al máximo los recursos informáticos disponibles.

2.1.2 Almacenamiento basado en Columnas y Filas. 


Como se mencionó anteriormente la organización columnar de almacenamiento en ciertas situaciones conduce a menos fallos de caché y de CPU. Es particularmente útil cuando usamos la CPU para escanear a través de una columna completa. Por ejemplo, esto sucede cuando se ejecuta una consulta que no puede ser satisfecha por el índice de búsqueda o cuando funciones de agregado se calculan sobre la columna, por ejemplo, la suma o la media.

Filas indexadas son los medios clásicos para acelerar el acceso a tablas basadas en filas. Esto funciona bien para los almacenes de las columnas, pero los árboles tienen un índice de localización especialmente bajo y producen fallos de caché. Además de esto, los índices tienen que ser reorganizados cuando se insertan datos en una tabla. Por lo tanto, los programadores de bases de datos tienen que entender las ventajas y desventajas de ambas técnicas de almacenamiento con el fin de encontrar un equilibrio adecuado.


Conceptualmente, una tabla de base de datos es una estructura de dos dimensiones de datos con celdas organizadas en filas y columnas. La memoria de computadora sin embargo está organizada como una estructura lineal. Para almacenar una tabla en memoria lineal, existen dos opciones, como se muestra en la figura segunda. Una fila de almacenamiento orientado almacena una tabla como una secuencia de registros, cada uno de los cuales contiene los campos de una fila. A la inversa, en las entradas de una columna se almacenan en ubicaciones de memoria contiguas.
 

El concepto de de almacenamiento columnar de datos se ha utilizado durante bastante tiempo. Históricamente fue utilizado principalmente para el análisis y almacenamiento de datos donde las funciones de agregado jugaban un papel importante. Usando esta forma de almacenar los datos en columnas, las aplicaciones OLTP requieren un enfoque equilibrado de la inserción y la indexación de los datos de las columnas para minimizar errores de caché.


La base de datos SAP HANA permite al desarrollador especificar si una tabla se almacenan en modo de columnas o filas. Por tanto, es posible alterar una tabla existente basada en columnas a una basada en filas y viceversa. Ver el SAP HANA SQL Reference, para mas detalles.

Las tablas basadas ​​en columnas tienen una serie de ventajas en las siguientes circunstancias:

 - Los cálculos se ejecuta normalmente en una o sólo unas pocas columnas.
 - En la tabla se hace una busqueda basada en los valores de varias columnas.
 - La tabla tiene un gran número de columnas.
 - La tabla tiene un gran número de filas y  son requeridas operaciones con columnas como (agregado, escaneado, etc.)
 - Las altas tasas de compresión puede lograrse porque la mayoría de las columnas contienen solo unos pocos valores distintos. (en comparación con el número de filas).

Tablas basadas en filas  tienen ventajas en las siguientes circunstancias:

La aplicación sólo necesita procesar un solo registro a la vez (muchos selecciones y / o actualizaciones de los registros individuales).

- Normalmente, la aplicación necesita acceder a un completo registro (o fila).
- Las columnas contienen principalmente valores distintos además de que la tasa de compresión sería baja.
- Ni la agregación ni las búsquedas rápidas son requeridas.
- La tabla tiene un pequeño número de registros. (e. g. configuration tables).

Para habilitar las transferencias de datos on-the-fly, informes ad-hoc, y para beneficiarse de mecanismos de compresión, se recomienda que los datos de transacciónes se almacenen en una tablas basadas en columnas. La base de datos de SAP HANA  permite la unión  de tablas basadas en filas con tablas basadas en columnas. Sin embargo, es más eficiente para unir tablas que se encuentren  o en filas o en columnas. Por ejemplo, los datos maestros que frecuentemente se unen con los datos de transacciónes también deben ser almacenados en las tablas en columnas.

2.1.3 Ventajas de las Tablas columnares



Si se cumplen los criterios anteriormente mencionados  para las tablas bsadas en columnas, estas tienen varias ventajas que se explican en esta sección. No debe dar la impresión de que las tablas en columnas son siempre la mejor opción. También hay situaciones en las que las tablas basadas en filas son mas ventajosas.

Ventaja: Mayores tasas de compresión de datos
 
El objetivo de mantener todos los datos relevantes en la memoria principal se puede lograr con un costo menor si ultilizamos datos comprimidos. El almacenamiento columnar de datos permite una compresión altamente eficiente. Especialmente si se ordena una columna, normalmente habrá varios valores contiguos colocar adyacentes entre sí en la memoria. En este caso, los métodos de compresión, tales como run-length encoding, cluster coding or dictionary coding, son los que podríamos utilizar. Esto es especialmente ventajoso para aplicaciones en las que muchas de las columnas de la tabla contienen solamente unos pocos valores distintos en comparación con el número de filas. Ejemplos extremos son códigos como códigos de país o códigos postales, otros ejemplos válidos son números de cliente y cuenta, códigos de región, códigos de canal de ventas, o los códigos de estado. Muchos de estos últimos se utilizan como claves externas de otras tablas de la base de datos, e. g. tablas que contienen los datos de pedidos de los clientes y los registros contables.  


Este alto grado de redundancia dentro de una columna permite una compresión eficaz de los datos. En el almacenamiento basado en filas, posiciones sucesivas de memoria contienen datos de diferentes columnas, por lo que algunos métodos de compresión, no se pueden utilizar. En los almacenes por columnas un factor de compresión de 5 puede lograrse, en comparación con los sistemas tradicionales de almacenamiento orientadas fila.

Técnicas de compresión:
 

Run-length encoding. Si los datos de una columna se ordena hay una alta probabilidad de que dos o más elementos contengan los mismos valores. Al ejecutar Run-length encoding  cuenta el número de elementos de la columna consecutivos con los mismos valores. Para lograr esto, la columna original se reemplaza con una lista de dos columnas. La primera columna contiene los valores que aparecen en la columna de la tabla original y la segunda columna contiene las ocurrencias que tiene un determinado valor que se repite. A partir de este informción la columna original puede ser reconstruida.
 

Cluster encoding. Esta técnica de compresión funciona mediante la búsqueda de múltiples ocurrencias de la misma secuencia de valores dentro de la columna original. La columna comprimida consta de una lista de dos columna con la primera columna que contiene los elementos de una secuencia particular y la segunda columna contiene los números de fila donde la secuencia comienza en la columna original. Muchos programas populares de compresión de datos utilizan esta técnica para comprimir archivos de texto.
 

Dictionary encoding. Son columnas de la tabla que contienen sólo un número relativamente pequeño de valores distintos que pueden ser efectivamente comprimidos mediante la enumeración de los distintos valores y almacenar sólo los números. Esta técnica requiere que una tabla adicional, el diccionario, que se mantiene en la primera columna contiene los valores originales y en la segunda los números que representan los valores. Esta técnica conduce a tasas de compresión alta, es muy común, e. g. en los códigos de país o números clientes, pero pocas veces se considera como una técnica de compresión.

Ventajas: Alto rendimento en operaciones con columnas.

Con operaciones columnares de organización de datos en columnas únicas, tales como la búsqueda o agregaciones, pueden ser implementadas como bucles de más de una matriz almacenados en ubicaciones de memoria contiguas. Tal operación tiene localidad espacial alta y eficiente puede ser ejecutado en la caché de la CPU.

Con un almacenamiento basado en filas, las mismas operaciónes serían mucho más lentas porque los datos de la misma columna se distribuye a través de la memoria y la CPU se ralentiza por fallos de la caché.
 

Supongamos que se desea agregar la suma de todas las cantidades de ventas en el ejemplo de la figura 2 utilizando una tabla basada en filas. La transferencia de datos desde la memoria principal a la memoria caché CPU, pasa siempre en bloques de tamaño fijo llamadas "líneas de caché" (por ejemplo, 64 bytes). Con una organización de los datos basados en filas, puede ocurrir que cada línea de caché sólo contiene una "venta" valor (almacenado en 4 bytes), mientras que los bytes restantes se utilizan para los otros campos del registro de datos. Para cada valor necesario para la agregación  haría falta un nuevo acceso a la memoria principal. Esto demuestra que una organización basada en filas cuando se realizan operaciónes, estas son relentizadas por fallos de caché que hacen que la CPU tenga que esperar a que los datos requeridos esten disponibles. Con un almacenamiento basado en columnas, todos los valores de las ventas se almacenan en memoria contigua, así que la línea de caché que contienen 16 valores que son todos necesarios en el cálculo de la suma. Además, el hecho de que las columnas se almacenan en memoria contigua  los controladores de memoria permiten precargar los datos, que reduce aún más el número de fallos de caché.


Como se explicó anteriormente, los datos con organización columnar también permiten una compresión de datos altamente eficiente. Esto no sólo ahorra memoria, pero también aumenta la velocidad por las siguientes razones:

- Los datos comprimidos se pueden cargar en la memoria caché de la CPU más rápidamente. Esto es debido a que el factor limitante es el transporte de datos entre la memoria y la caché de la CPU, y por lo tanto la ganancia de rendimiento supera el tiempo de cálculo adicional necesario
  para la descompresión.
 

- Con la codificación de diccionario, las columnas se almacenan como secuencias de bits codificados por números enteros. Eso significa se puede ejecutar un chequeo por la igualdad entre los números enteros (por ejemplo durante las exploraciones o las operaciones de combinación). Esto es mucho más rápido que comparando, por ejemplo, valores de cadena.
 

- Compresión puede acelerar las operaciones tales como exploraciones y agregaciones si el operador es consciente de la compresión. Dada una tasa de buena compresión, el calculo de la suma de los valores codificados, comprimida en una columna será mucho más rápido si en la columna hay muchos campos con el mismo valor por lo que se podría sustituir por una sola multiplicación. Un estudio científico reciente reportó una ganancia de rendimiento del factor de 100 a 1000 cuando se comparan las operaciones sobre valores enteros codificados comprimidos con operaciones sobre los datos sin comprimir. 


Ventaja: Eliminación de índices adicionales


El almacenamiento de datos en columnas, en muchos casos, elimina la necesidad de estructuras con índices adicionales. Almacenamiento de datos de las columnas es funcionalmente similar a tener un índice integrado para cada columna. La velocidad de barrido de la columna en memoria y los mecanismos de compresión - especialmente la compresion del diccionario- permiten operaciones de lectura con un rendimiento mucho mas alto. En muchos casos no se requiere tener índices adicionales. La eliminación de índices adicionales reduce la complejidad y elimina esfuerzo para definir y mantener los metadatos.

Ventaja: Paralelización

 El sistema basado en almacenamiento en columnas también hace que sea fácil de ejecutar operaciones en paralelo usando múltiples núcleos de procesador. En un almacenaje en columnas ya están los datos verticalmente divididos. Esto significa que las operaciones en diferentes columnas pueden ser fácilmente procesadas en paralelo. Si varias columnas necesitan ser buscados o agregados, cada una de estas operaciones puede ser asignado a un núcleo de procesador diferente. Además las operaciones en una columna se pueden paralelizar por reparto de la columna en múltiples secciones que se pueden procesar por diferentes núcleos de procesador en paralelo.



Ventaja: Eliminación de los Agregados.
 
Las aplicaciones tradicionales de negocios utilizan técnicas específicas para aumentar el rendimiento de lectura de los agregados . Esto significa que los desarrolladores de aplicaciones hacen definir tablas adicionales en los que la aplicación usa y almacena redundantemente los resultados de los agregados (por ejemplo, sumas) computado en otras tablas. Los agregados se calculan y almacenan ya sea después de cada operación de escritura de los datos agregados, o en las horas programadas

 
Con una velocidad de exploración de varios gigabytes por milisegundo, las columnas alojadas en la memoria permiten calcular los agregados de grandes cantidades de datos sobre la marcha con un alto rendimiento. Se espera que esto elimine la necesidad de agregados en muchos casos.

 
En las aplicaciones financieras, los distintos tipos de totales y los saldos son datos de cantidad tipicamente persistentes. Por ejemplo, contabilidad general, cuentas por cobrar por pagar, cuentas, libro de caja, libro mayor de materiales, etc, usando un almacenamiento en forma de columnas en memoria, estas cantidades se como todos los totales y los saldos se puede calcular sobre la marcha de los elementos del documento de contabilidad con alto rendimiento.


La eliminación de los agregados tiene varias ventajas:

 
La principal es el simplificado del modelo de datos. Ya que los agregados , hace que tengamos tablas adicionales que se necesitan y por tanto hacen que el modelo de datos sea más complejo. En la aplicación SAP Business de finanzas, por ejemplo, los totales y los saldos persistentes se almacenan con un esquema en estrella (véase la sección 2.3.1).  Se han introducido objetos específicos de negocio para los totales y balances, y cada una de ellos se guardan en tablas de varias dimensiones.


De todas estas tablas se pueden quitar, si los totales y los saldos se calculan sobre la marcha. Un modelo de datos simplificado hace que el desarrollo sea más eficiente, elimina errores de programación y aumenta la mantenibilidad.

Simplifica la lógica de la aplicación.

La aplicación de cualquiera de los dos tiene que actualizar el valor agregado después de un apartado global fue añadido, eliminado o modificado. Funciones y métodos de agregación alternativa especiales necesitan ser programadas que actualizar los valores agregados a intervalos de tiempo determinados (por ejemplo una vez al día). Al eliminar los agregados persistentes, esta lógica adicional ya no es necesario.

Mayor nivel de concurrencia. 


Con los agregados después de cada operación de escritura se produce un bloqueo para actualizar los agregados. Esta concurrencia límita y puede llevar a problemas de rendimiento. Sin agregados, sólo se escriben las posiciones del documento, y esto se puede hacer al mismo tiempo sin ningún tipo de bloqueo.

Contemporaneidad de los valores agregados. Con la agregación en marcha, los valores agregados están siempre al día mientras que los agregados peremanentes se actualizan sólo a unas horas precisas.

 

 2.2 Descripción de la Arquitectura

El diagrama de bloques en la figura 4 (ver más abajo) proporciona una visión general de la arquitectura conceptual de la base de datos de SAP HANA. En la parte superior del diagrama se puede ver que hay clientes que se conectan al sistema de base de datos. Una conexión de cliente forma una sesión dentro de la base de datos, y se comunican por sentencias SQL .



En la base de datos SAP HANA, cada sentencia SQL es procesada en el contexto de una transacción. 

Las nuevas sesiones se asignan implícitamente a una nueva transacción. El administrador de transacciones es el componente que coordina las transacciones de bases de datos, los controles de aislamiento transaccional y hace un seguimiento de la ejecución y cerrado de transacciones. Cuando una transacción se confirma o se revierte, el administrador de transacciones informa a los motores de almacenamiento involucrados acerca de este evento, para que puedan llevar a cabo las acciones necesarias. El administrador de transacciones coopera con la capa persistente para lograr transacciones atómicas y duraderas.

Las peticiones de los clientes son analizadas y ejecutadas por un conjunto de componentes como procesamiento de solicitudes y de control de ejecución. La figura 4 muestra las principales funciones de esta capa: 


El analizador de la petición analiza la solicitud del cliente y lo envía al componente responsable.


Las instrucciones de definición de datos se envían al gestor de metadatos y las invocaciones de objetos se remite al almacen de objetos. Los estados de manipulación de datos se reenvían al optimizador que crea un plan de ejecución optimizado que se da a la capa de ejecución.

La base de datos SAP HANA también ha incorporado soporte para modelos específicos (por ejemplo, para la planificación financiera) y ofrece capacidades de scripting que permite cálculos específicos de la aplicación para funcionar dentro de la base de datos. La base de datos SAP HANA tiene su propio lenguaje de scripts llamado SQLScript que está diseñado para permitir optimizaciones y paralelización en el tratamiento de los datos. SQLScript se basa en funciones libres de efectos secundarios que operan sobre tablas utilizando consultas SQL para el procesamiento conjunto.


La base de datos SAP HANA también contiene un componente llamado el motor de planificación que permite a las aplicaciones de planificación financiera ejecutar operaciones básicas de planificación de la capa de base de datos. Una operación básica como es la creación de una nueva versión de un conjunto de datos como una copia de uno ya existente. Por ejemplo: los datos de planificación para un nuevo año se crea como una copia de los datos del año anterior.  


Esto requiere el filtrado por año y la actualización de la dimensión de tiempo. Otro ejemplo para una operación de planificación es la operación de desagregación que distribuye los valores objetivo de mayor a niveles de agregación inferiores basado en una función de distribución.
  
Las características de SAP HANA bases de datos como SQLScript y operaciones de planificación se implementan utilizando una infraestructura común en las funciones integradas. 
Los metadatos se pueden acceder a través del gestor de metadatos. Los metadatos de SAP HANA base de datos se compone de una variedad de objetos, como las definiciones de tablas relacionales, columnas, vistas e índices, las definiciones de las funciones y los metadatos SQLScript almacén de objetos. Los metadatos de todos estos tipos se almacenan en un catálogo común para todos los almacenes de SAP HANA base de datos (in-memory, en la memoria de almacenamiento de columna, almacén de objetos y basada en disco). Los metadatos se almacenan en tablas forma de filas. Las características de la base de datos de SAP HANA que se verán en los capítulos siguientes, como soporte de transacciones, versión multi-control de concurrencia, también se utilizan para la gestión de los metadatos.
 

Las tablas formadas por filas y las tablas columnares se pueden combinar en una instrucción SQL, los motores correspondientes deben ser capaces de utilizar los resultados intermedios creados por una y otra.  

Una diferencia importante entre los dos motores es la forma en que procesan datos: Las tablas formadas por filas usan operadores at-a-time usando iteradores. 

Las operaciones con los datos en forma de columnas  (como exploración, agregado y así sucesivamente) requieren que toda la columna está disponible en ubicaciones de memoria contiguas. Para el intercambio de resultados intermedios, la consulta fila puede proporcionar resultados a la consulta columna y los datos se transforman como filas completas en la memoria mientras que en las columnas se pueden exponer los resultados utilizando el interfaz necesaria para almacenar fila.

La capa de persistente es responsable de la durabilidad y la atomicidad de las transacciones. Se asegura de que la base de datos se restaura al estado comprometido más reciente después de un reinicio. 

Para lograr este objetivo de forma eficiente la capa persistente utiliza una combinación de escritura anticipada registros, paginación sombra y puntos de retorno. La capa persistencia ofrece interfaces para la escritura y lectura de datos. También contiene registrador de SAP HANA  que gestiona el registro de transacciones. Las entradas de registro se puede escribir implícitamente por la capa de persistencia cuando se escriben datos a través de la interfaz de persistencia o explícitamente por medio de una interfaz de registro.
 
El administrador de autorización es invocado por otros componentes de la base de datos de SAP HANA para comprobar si el usuario tiene los privilegios necesarios para ejecutar las operaciones solicitadas. SAP HANA permite la concesión de privilegios a usuarios o roles. Un privilegio otorga el derecho a realizar una operación determinada (por ejemplo, crear, actualizar, seleccionar, ejecutar, y así sucesivamente) en un objeto determinado (por ejemplo, una tabla, vista, función SQLScript, y así sucesivamente).  


La base de datos SAP HANA soporta privilegios analíticos que representan filtros o limitaciones jerarquicas de obtención de detalles para las consultas analíticas. Con los privilegios analíticos nos permiten conceder acceso a los valores con una cierta combinación de atributos de dimensión. Esto podría, por ejemplo, utilizarse para restringir el acceso a un cubo con datos de ventas a valores con atributos de dimensión de la región = 'US' y año = '2010 '. Al igual que los privilegios analíticas se definen también los valores de atributos de dimensión y no en los metadatos, y se evalúan dinámicamente durante la ejecución de la consulta.

Los usuarios se autentican ya sea por la base de datos SAP HANA a sí mismo (entrar con usuario y contraseña) o autenticación puede ser delegada a un proveedor de autenticación externos, tales como un directorio LDAP.  


2.3 Conceptos de base de datos:  Tablas, Modelos y procesamiento de la vista.

 
SAP HANA base de datos es un sistema de base de datos muy capaz, pero requiere un poco de comprensión, y para ser utilizado correctamente, para obtener un buen rendimiento. En esta sección analizaremos algunos conceptos clave de la base de datos SAP HANA. Se mostrará también un análisis de cómo se puede abordar el modelado para lograr unos buenos resultados.

2.3.1 Tablas, Vistas, y  Esquemas en forma de estrella.

 La base de datos SAP HANA permite dar forma a los datos en forma de tablas y vistas. Las tablas son estructuras de datos tabulares, cada fila de la identificación de una entidad en particular, y cada columna tiene un nombre único. Los campos de datos de una fila se llama los atributos de la entidad. La palabra "atributo" se utiliza con diferentes significados en este documento. Se puede indicar una columna de la tabla, un campo de datos particular de una fila de la tabla, o el contenido de un campo de datos. El significado respectivo será claro por el contexto.

Las vistas son combinaciones y selecciones de datos de las tablas modelados para servir a un propósito en particular. Visto siempre aparecen como tablas de lectura mecánica, es decir, operaciones de base de datos que leídas de las tablas también se puede utilizar para leer datos de vistas. Por ejemplo, puede crear vistas que sólo tiene que seleccionar algunas columnas de una tabla o vistas que seleccionan algunas columnas y algunas filas de acuerdo a un modelo de filtro.


En aplicaciones analíticas que usan los esquemas de base de datos en estrellas son un patrón general: Las tablas  son listas de las transacciones comerciales, mientras que los datos de Linked-in suelen ser datos maestros. Estas tablas Linked-in a menudo se llaman tablas de dimensiones. Una tabla rodeado rodeada de las que esta ligada, en las tablas de dimensiones a menudo se llama un esquema en estrella porque cuando se expresa gráficamente parece ver como una estrella. En SAP HANA pueden ser creados esquemas en estrellas usando tablas o vistas al rodear una visión analítica o cálculo con vistas atributos.


2.3.2 SAP HANA Modelado.

Antes de continuar a discutir la forma de modelo en SAP HANA, en primer lugar, es importante comprender cada uno de los diferentes tipos de vistas de modelado SAP HANA  y sus capacidades. 

Vistas Atributo.

Vistas atributo se utilizan para definir combinaciones entre las tablas, y explicar el sistema de forma razonable para estas uniones a realizar. También se puede utilizar para seleccionar un subconjunto de las columnas y filas de una tabla.


Una de las aplicaciones de los puntos de vista de atributos es unir varias tablas para crear una tabla de dimensión única al utilizar esquemas de estrella. La vista dimensión de atributo resultante puede entonces ser unido a una tabla de hechos a través de una vista analítica (véase a continuación) para dar sentido a sus datos. Por ejemplo vistas de atributos se pueden utilizar para unir a los empleados a unidades organizativas que podría unir a una operación de venta a través de un punto de vista analítico.


Vistas analíticas


Vistas analíticas suelen definirse en la tabla al menos uno que contiene los datos transaccionales. Con vistas analíticas que puede crear una selección de medidas (a veces conocido como figuras clave), añadir atributos y unir puntos de vista de los atributos. Puntos de vista analíticos aprovechan la potencia de computación de SAP HANA para calcular los datos agregados, e. g. el número de coches vendidos por país, o el consumo máximo de energía por día. Se definen en el vector al menos uno, i. e. una tabla que contiene e. g. una fila por cada coche vendido o una fila por lectura del medidor de potencia, o hablando más en general, alguna forma de registros de transacciones comerciales. Las tablas se pueden unir para permitir el acceso a datos más detallados utilizando una vista analítica única. Las vistas analíticas se puede definir en una sola tabla o tablas combinadas.

Las vistas analíticas pueden contener dos tipos de atributos (o columnas), las medidas de las llamadas y cifras clave. Las medidas son atributos para los cuales deben ser una agregación definidas. Si las vistas analíticas se utilizan en instrucciones SQL (ver más abajo), entonces las medidas deben enviarse agregado. g. utilizando el SUM funciones SQL (<column <nombre), MIN (<column <nombre) o MAX (<column <nombre). Estos atributos normales puede ser manejados como columnas regulares. Para ellos no hay necesidad de que sean datos agregados.


El modelo de vistas analíticas hacen uso del esquema en estrella y se puede tener acceso a las tablas de varias dimensiones. 


Las vistas analíticas se puede definir en una sola tabla o tablas combinadas (inner join).

Vistas analíticas pueden contener dos tipos de atributos (o columnas), las medidas de las llamadas y cifras clave. Las cantidades son atributos para los que la agregación se deben definir. Si las vistas analíticas se utilizan en instrucciones SQL (ver más abajo), entonces las medidas deben ser agregadas por ejemplo, utilizando la función SUMA SQL (<column <nombre), MIN (<column <nombre) o MAX (<column <nombre). Los atributos normales pueden ser manejados como columnas regulares. Para ellos no hay necesidad de crear agregados.


Vistas de cálculo


Puntos de vista de cálculo se utilizan para proporcionar compuestos de otros puntos de vista. Básicamente se basan en una combinación o unión de dos o más flujos de datos o invocar funciones genéricas de SQL.


Puntos de vista de cálculo se definen como cualquiera de las vistas gráficas o puntos de vista, pero no con el  SQLScript (con excepciones, véase más adelante). Dependiendo de la forma en que se crean. Se pueden utilizar de la misma manera como vistas analíticas. Sin embargo, en contraste con vistas analíticas que es posible unir varias tablas, en una vista de cálculo Vistas de cálculo siempre tienen al menos una medida.

Las vistas gráficas pueden ser modeladas utilizando las funciones de modelado gráfico del Modeler SAP HANA. En las vistas se crean secuencias de comandos y secuencias de instrucciones SQL.


Como se mencionó antes vistas cálculo no se crean utilizando  SQLScript
, sin embargo, existen excepciones a esta regla. El SQLScripts con las propiedades siguientes se pueden utilizar en las vistas de cálculo:

- No hay parámetros de entrada.
- Siempre de sólo lectura (no realizar cambios en la base de datos).
- Sin efectos secundarios.


2.3.3 SAP HANA Visión de los procesos.



Una explicación básica de que y como son los procesos en  SAP HANA es fundamental para asegurarnos de que la transferencia de datos en el sistema de base de datos se reduce al mínimo.
 

Una visión simplificada del sistema se ilustra en el diagrama a continuación.


Del diagrama se puede ver que SAP HANA tiene tres tipos de vistas que se utilizan sobre la base de los requisitos del modelo.

*- Vista de cálculo - se utiliza en la parte superior de vista analítico y puntos de vista de atributos para realizar cálculos complejos que no pueden ser alcanzados por el atributo o vistas analíticas sola.
  
*- Vistas analíticas - se utiliza para el cálculo y agregación ", basada en esquema en estrella" o similar



*- Vistas Atributos a utilizarse para todo tipo de combinaciones
 
Decide SQL optimizador de la mejor forma de llamar a las diferentes funciones del sistema de base de datos basado en los modelos y las consultas involucradas.

 
Este diagrama está un tanto simplificado. Por ejemplo. A una vista analítica con un atributo calculado o que incluya atributos de vista que contiene un atributo calculado, se convertirá en una vista de cálculo
.


Esto debe ser tenido en cuenta durante el modelado, ya que puede tener un gran impacto sobre el rendimiento del modelo de datos. 

 

Guía para el modelado – Minimizando la transferencia de datos.



Como se ha subrayado muchas veces ya en este documento, uno de los objetivos principales durante el modelado es reducir al mínimo la transferencia de datos. Esto es válido tanto a nivel interno, como entre las vistas de bases de datos SAP HANA, y por lo tanto entre SAP HANA y la aplicación del usuario final. Por ejemplo, el usuario final no tendrá que ver a 1 millón de filas de datos. Nunca sería capaz de entender tanta información. Esto significa que los datos, siempre que sea posible, deberán agregarse y ser filtrados a un tamaño manejable antes de salir de la capa de datos.

Al decidir sobre los registros que deben ser presentado en un informe, un enfoque de mejores prácticas es pensar en  " el conjunto a un nivel determinado o no". Un conjunto de datos se puede agregar por una región, una fecha, o algún otro grupo con el fin de minimizar la cantidad de datos que se pasan entre las vistas.




Reglas básicas del modelado a seguir - un ejemplo

 
Para este ejemplo, el requisito es que las dos tablas estén unidas por sus claves. Esto lleva a la pregunta de cómo los datos deben ser tratados.


Como se mencionó antes, siempre se habla en terminos de conjuntos de datos, no filas (o registros) de datos. La imagen de la izquierda muestra un diseño pobre, ya que se unirán a las claves de las tablas. Al hacerlo, se tiene que tocar cada registro individual durante la consulta. Esto es costoso en tiempos de ejecución debido a la utilización de unirse a los datos en la vista de cálculo.

En el caso de que ambos puntos de vistas sean analíticos generará una gran cantidad de registros, este "Join" debe ser evitada y reemplazada por otra unión . Un "Join" puede ser utilizada cuando uno de los puntos de vista analítico gen tarifas un pequeño número de registros (menos de un millón) en una vista de cálculo.


Antes de la operación, que transfiere los datos desde el punto de vista analítico a la vista de cálculo, los datos deben ser minimizados. El número de registros generados por una vista analítica se puede reducir por adición y mediante la aplicación de criterios de filtro. Estas observaciones pueden ser utilizados durante la creación de puntos de vista de cálculo para evitar problemas de actuaciones.

La imagen de la derecha muestra una manera más eficiente de la construcción de la vista. Tenga en cuenta que las dos vistas analíticas separadas inicialmente son agrupados por región y luego reunió a través de una union. Esto es más eficiente que los "joins" a nivel de fila.
 
Utilice el procesamiento masivo de datos para establecer como se mencionó en la sección anterior, utilizando un "enfoque conjunto" y no un "enfoque en filas" para el procesamiento de datos y siempre dará mejor rendimiento.

El código siguiente es un ejemplo de una consulta pobre:
 
La consulta siguiente es un ejemplo de una forma más eficaz de obtener los mismos datos. Es mucho más eficaz si está consultando en contra de conjunto de datos, en lugar de todos los datos.

Es muy importante evitar bucles al modelar ya que esto causará un rendimiento muy pobre. Esto es especialmente cierto cuando la cantidad de datos en la tabla que va a ser recorrida es muy grande (cientos de millones de entradas de datos).

 4. Buenas Prácticas

El poder de la base de datos SAP HANA reside en su 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 la operación de 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 maner muy interactivo sin necesidad de informes predefinidos o la necesidad de tablas de agregación intermedios.

 
Con todo esto dicho, 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, tiene que ver con la transferencia de datos dentro de Minimización de la base de datos y lograr tiempos de respuesta rápidos.


4.1 Características del motor de almacenamiento de columna
 
Tanto la fila y columna de cada motor de almacenamiento tiene 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 tanto a 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 puede utilizar para optimizar el modelo de datos y las instrucciones SQL en consecuencia.
 
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> ] ]

A column engine FROM specification can be one of the following:

  • <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>
 The column engine supports following join conditions.
  • <column reference from one side> = <column reference from the other side>
 Data types of two columns should be the same. Decimals with different precisions or scales are also treated as different data types.
  • AND operations between column engine join conditions
For outer joins, cyclical joining is not supported. For example, T.a = S.a AND T.b = R.b is not supported if there is already a join condition between S and R.

The column engine supports the following filter conditions

  •  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

The column engine supports the following scalar expressions.
 

  •  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
  •  Functions listed below with column engine expressions as arguments
-  TO_DECIMAL, TO_NUMBER, TO_BIGINT, TO_REAL, TO_DOUBLE, TO_CHAR,   TO_NCHAR, TO_DATE, TO_TIMESTAMP and BINTOHEX/HEXTOBIN

-  Format strings are not supported for TO_CHAR, TO_NCHAR, TO_DATE and       TO_TIMESTAMP

- LTRIM | RTRIM | TRIM, LENGTH, SUBSTR, INSTR and LOWER | UPPER 

- WEEKDAY, DAYS_BETWEEN, SECONDS_BETWEEN, ADD_DAYS, UTCTOLOCAL, LOCALTOUTC, ISOWEEK and QUARTER
- LN | LOG, EXP | POWER | SQRT, SIN | COS | TAN, ASIN | ACOS | ATAN, SINH | COSH and FLOOR | CEIL
- NULLIF, and COALESCE
- EXTRACT( YEAR | MONTH FROM <column engine expression> )

  •  Functions without arguments are evaluated by the SQL parser. The evaluated results are passed to the column engine as constant values.
o CURRENT_CONNECTION, CURRENT_SCHEMA, CURRENT_USER, SYSUUID, CURRENT_DATE/ CURRENT_TIME/ CURRENT_TIMESTAMP and CURRENT_UTCDATE/ CURRENT_UTCTIME/ CURRENT_UTCTIMESTAMP

  •  Expressions equivalent to one of the listed above (e.g. CAST function)
The column engine supports the following aggregation expressions.

o MIN | MAX | COUNT | SUM | AVG ([DISTINCT] <column engine expression>)
Since SQL provides multiple possible ways to formulate a query, an SQL query that is not in the above format can be processed natively by the column engine if the query is equivalent to a query that can be represented in the correct format. Below are examples of such equivalence. Equivalence is denoted as ↔.

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

Equivalent only if table T has a primary key.

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 SQL Query Cost Estimation

El optimizador de SQL es el mecanismo para la ejecución de consultas utilizando una fórmula de estimación de costos. Las siguientes tablas lamentablemente una lista de coeficientes se puede utilizar para calcular el tiempo de ejecución relativa para las operaciones de búsqueda soportados por los dos motores de almacenamiento. Tenga en cuenta que este cuadro no se pueden utilizar para calcular los tiempos reales de ejecución, ya que dependen de los parámetros de hardware examinados como el número de núcleos de CPU o de la CPU y la velocidad del reloj de 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 Row Search Cost Models



4.2.2 Columns Search Cost Models


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 características de alto rendimiento no causará problemas para tablas pequeñas o pequeños resultados intermedios extraídos de tablas grandes. Sin embargo, la atención especial es necesaria 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 se diferencian de una aplicación a otra.
 

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 Expressions


Cálculo. Si un cálculo que se utiliza no es soportado por la columna de motor, la cirugía basada en el cálculo se ejecuta por el motor de 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 admite de forma nativa por el motor de la columna es más rápido que usar cálculos ninguno 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 en absoluto 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 con los gastos de la inserción creciente y costos de 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 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 Conversión de tipos implícita se hace desde baja precedencia a los tipos de mayor precedencia tipos. Usted 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
 

No hay comentarios:

Publicar un comentario

Nota: solo los miembros de este blog pueden publicar comentarios.