Unidad 2: Programación ABAP HANA Avanzada.
Lección 5: Recomendaciones para desarrollar aplicaciones ABAP en SAP HANA.
Audio tip 1: Existen motivos para utilizar todavía el almacenamiento por filas en una tabla, por ejemplo, si se accede a una tabla predominantemente mediante declaraciones en lenguaje de manipulación de datos DML en el tiempo por ejemplo mediante update, insert o delete. Esta no puede ser una tabla de aplicaciones en la que posteriormente deseamos realizar análisis por lo tanto principalmente las tablas técnicas de SAP son elegibles para el almacenamiento por filas. Los ejemplos incluyen tablas para el procesamiento de actualizaciones correspondientes al paquete STSK o para el procesamiento de llamadas a funciones remotas RFC correspondientes al paquete SRFC. Normalmente se accede a estas tablas con un select simple
Audio tip 2: Al diseñar la aplicación debemos considerar las siguientes preguntas.
¿Existen sistemas con un sistema de base de datos diferente en nuestro entorno de trabajo o en el entorno del cliente ?
¿Cuan fundamentales son las funciones específicas de la base de datos para nuestra aplicación ?
¿Esta involucrada la calidad central de la aplicación?
¿El desarrollo en SAP HANA se llamará únicamente a través de aplicaciones basadas en ABAP o también a través de otros canales?
Audio tip 3: Pueden ocurrir problemas cuando asumimos que un ordenamiento determinado es llevado a cabo en la secuencia de un programa ABAP. este es el caso por ejemplo de cuando trabajamos con tablas internas y ejecutamos Binary search la cual tiene como requisito que la tabla interna se encuentre previamente ordenada por el campo o campos a partir de la cual se realizará la búsqueda binaria. Podemos encontrarnos con sorpresas en la lista de salida de datos si derrepente no aparecen en el orden de clasificación deseado. En conclusión no debemos confiar en los ordenamientos implícitos si necesitamos una clasificación específica de los datos cuando accedemos a una base de datos debemos utilizar la adición Order by explicitamente.
Audio tip 4: Aunque la adición Into corresponding fields of selecciona solo las columnas que también están en la tabla interna de destino cuando se especifica * se requiere de un esfuerzo adicional para comparar nombres en la interface de la base de datos por lo tanto esta adición solo debe usarse con moderación y para conjunto de datos de resultados más grandes por que el esfuerzo involucrado en la comparación de nombres puede ser relativamente alto para declaraciones select muy rápidas.
Audio tip 5: Para formular las cláusulas WHERE estas son nuestras principales recomendaciones.
El operador = , el operador EQ y los enlaces & siempre son compatibles de manera eficiente en el índice, es decir, el optimizador para reducir el esfuerzo de entrada salida siempre que sea técnicamente posible. Una lista de IN también cae en esta categoría por que representa en principio un múltiple igual para la columna, por lo tanto debemos utilizar las condiciones EQ e IN siempre que siempre que sea posible. Debemos evitar las condiciones negativas como distinto, NO EQ o NO porque no se pueden admitir de manera eficiente en el índice, si es posible debemos reescribir tales condiciones como condiciones positivas, si esto no es posible aún igual debemos especificar las condiciones en la condición WHERE y no omitirlas por completo. Esta es la única forma en que se seleccionaran los registros de datos requeridos de lo contrario leeremos registros innecesarios que luego deberemos eliminar del programa ABAP lo que contradice la primera regla de oro. si no especificamos todos los campos en el índice debemos asegurarnos de incluir la sección inicial del índice en la condición WHERE de lo contrario el uso de un índice no es posible en muchos casos.
Video " El almacenamiento y compresión de datos en SAP HANA"
En este video vamos a analizar los tipos de almacenamiento disponibles y como se realiza la compresión de los datos en la base de datos de SAP HANA.
En cada Base de datos relacional las entradas de una tabla base de datos deben almacenarse en un determinado diseño de dato independientemente de que si esta representación se realiza en la memoria principal por ejemplo en SAP HANA o siguiendo el enfoque tradicional con un medio físico. Hay dos opciones completamente disponibles para esto.
Disposición de los datos en la memoria principal:
- Almacenamiento de datos basado en filas.
- Almacenamiento de datos basado en columnas.
SAP HANA soporta ambos enfoques. Con SAP HANA podemos especificar el enfoque de almacenamiento que se utilizara para cada tabla base de datos ya sea que la creemos en el diccionario de datos o en SAP HANA studio. Para ello, por ejemplo desde el diccionario de datos accedemos a las opciones técnicas (Technical Settings) y visualizamos las propiedades específicas de las base de datos (DB-Specific Properties) Aquí podremos ver el tipo de almacenamiento de cada tabla. Vamos a a analizar un poco los dos enfoques de almacenamiento.
En el almacenamiento de datos basado en filas de SAP HANA todos los datos pertenecientes a una fila se colocan uno al lado de otro, lo que facilita el acceso a todas las filas, sin embargo, acceder a todos los valores de una columna es un poco mas complejo ya que estos valores no se pueden transferir desde la memoria principal a la CPU de manera tan eficiente como el almacenamiento de datos basado en columnas. La compresión de los datos, es decir, como se comprimen igual a los datos en la memoria que explicaremos a continuación también es menos eficiente con este enfoque de almacenamiento.
El almacenamiento de datos basado en columnas no es nada realmente nuevo más bien este tipo de almacenamiento ya se usaba en aplicaciones de almacenamiento de datos y escenarios de análisis en el pasado, sin embargo, en los escenarios transaccionales hasta el momento solo se había utilizado el almacenamiento basado en filas, los contenidos de una columna se colocan uno junto al otro en la memoria principal esto significa que todas las operaciones que accedan a una columna encontraran la información requerida cerca lo que tiene efectos favorables en ele transporte de datos entre la memoria principal y la CPU, sin embargo, si necesitamos una gran cantidad de datos o todos los datos de una fila este enfoque es desventajoso porque esos datos no estan cerca. El almacenamiento de datos basado en columnas también facilita la compresión eficiente y la agregación de datos basados en una columna.
Conclusiones:
- Como podemos ver ambos enfoques tienen ventajas y desventajas.
- Los datos comerciales casi siempre se colocan en el almacenamiento basado en columnas. Esto se aplica particularmente si necesitamos analizar grandes cantidades de datos
- Sin embargo, algunas tablas requieren almacenamiento de datos basado en filas. Estas son principalmente tablas muy pequeñas o muy volátiles, donde el tiempo requerido para los accesos de escritura es más importante que el tiempo requerido para los accesos de lectura. O en tablas donde los accesos de un solo registro ( a través del comando SELECT SINGLE ) son el patrón de acceso principal.
Compresión de los datos.
La Base de datos de SAP HANA proporciona una serie de técnicas de compresión que pueden usarse para los datos en almacenamiento por columnas tanto en la memoria principal como en el almacenamiento persistente. La alta compresión de datos tiene un impacto positivo en el tiempo de ejecución porque reduce la cantidad de datos que deben transferirse desde la memoria principal a la CPU.
Las técnicas de compresión de SAP HANA son muy eficientes con respecto al tiempo de ejecución y pueden proporcionar un factor de compresión promedio de 5 a 10 en comparación con los datos que no se han comprimido. Las técnicas de compresión se basan en la codificación del diccionario donde los contenidos de la columna se almacenas como enteros codificados en el llamado vector de atributos. En este contexto codificación significa traducir el contenido de un campo en un valor entero.
Para almacenar el contenido de una columna en el almacenamiento por columnas, la base de datos de SAP HANA crea un mínimo de dos estructuras de datos:
- Vector de diccionario
- Vector de atributo
El vector de diccionario almacena cada valor de una columna solo una vez. Esto significa que la columna género solo contiene los valores "M" y "F" en el vector de diccionario. Para la columna ubicación hay tres valores posibles: Chicago, san francisco y dallas. Los contenidos del vector de diccionario se almacenan como datos ordenados. La posición en el vector de diccionario asigna cada valor a un entero en nuestro ejemplo esto es 1 para el género "F" y 2 para el género "M". En el vector de diccionario para la ubicación el entero 5 significa Chicago el entero 6 Dallas y el entero 7 para San Francisco. Debido a que este valor se puede derivar implícitamente de su posición primer valor, segundo valor, etc. No se requiere almacenamiento adicional.
Los vectores del diccionario se muestran en la mitad superior de la imagen, solo los datos sombreados en gris se almacenas explícitamente en memoria. El vector de atributos ahora solo almacena los valores enteros, la posición en el diccionario, al igual que las bases de datos tradicionales el orden de los registros no esta definido. Por ejemplo el apellido Smith se colocó en el vector de diccionario para los apellidos desde su posición en este vector un valor puede derivarse implícitamente, el valor 9 en nuestro ejemplo, este valor una vez mas ahora siempre se almacena en la posición para el apellido Smith en el vector de atributos para el apellido en nuestro ejemplo este es el séptimo registro de nuestros datos de muestra de la tabla.
Otro ejemplo es la ubicación, San Francisco por ejemplo, que se almacena en la posición 7 del vector de diccionario para la ubicación y aparece para la fila 4 y 6 en el vector de atributo para la ubicación. Los vectores de atributo se muestran en la parte inferior de la figura. En esta figura los tres vectores de atributos se muestran consecutivamente para mostrar que todos los datos también los vectores de diccionario, se almacenan en un flujo de datos en la memoria principal y se direccionan a través de las referencias y compensaciones de la memoria. Aquí solo las secciones sombreadas en gris de la figura se almacenan realmente en la memoria principal: Los números de fila que se muestran debajo de estas secciones no necesitan ningún espacio de almacenamiento y nuevamente se derivan implícitamente de su posición en el vector de atributo, se corresponden con la posición en nuestro ejemplo de la tabla, es decir, el primer registro, el segundo registro, etc.