Particionado de Tablas en SAP HANA (y III) – Buenas Prácticas


A continuación señalamos algunas buenas prácticas (best practices) al definir particiones en SAP HANA Database. Cabe señalar que para los objetos BW on SAP HANA, la técnica de particionamiento es distinta (ver entradas anteriores: aquí y aquí):

  • Sólo aplicar el particionado de tablas cuando sea necesario y se observa un beneficio claro de esta técnica. Una alta cantidad de particiones innecesarias ocasionaría una sobrecarga en el sistema al ejecutar consultas, al tener que acceder a múltiples particiones para encontrar los datos solicitados.
  • Si se particiona por el límite de tamaño de tabla de los dos mil millones de registros, es aceptable si el tamaño de las particiones contienen hasta los 500 millones de registros.
  • Si el criterio de partición es por fecha, se debe evitar utilizar criterios granulares tales como día o semana, dado que generaría un gran número de particiones.
  • Si se utiliza el tipo de partición RANGE sobre una columna cuyo contenido no se distribuye uniformemente, se deben verificar la distribución de sus valores reales para definir los límites de los rangos en consecuencia
  •  Utilizar el menor número de columnas para definir el criterio de particionamiento. En el caso del tipo de partición HASH, a menudo es útil emplear sólo la columna clave más selectiva, para que las solicitudes de datos que incluye esta columna sólo accedan a una partición.
  •  Las buenas prácticas de los documentos de referencia, señalan que las particiones de una misma tabla estén contenidas en el mismo host si es que se cuenta con una estrategia scale-out (despliegue/escalabilidad horizontal)
  • Si se va a reparticionar una tabla, para lograr mayor eficiencia, elija un número múltiplo o divisor del número de particiones con respecto al actual.
  • Evitar la definición de particiones con restricciones únicas adicionales, por ejemplo índices secundarios, dado que las verificaciones posteriores significarían una sobrecarga importante.

Particionado de Tablas en SAP HANA (II) – Tipos de Partición

Seguimos señalando las características básicas sobre el particionamiento de los datos en SAP HANA Database (ver entrada anterior)
Tipos de particionamiento


Seguimos señalando las características básicas sobre el particionamiento de los datos en SAP HANA Database (ver entrada anterior)

Tipos de particionamiento

HASH. Los registros son asignados a particiones basados en un algoritmo hash, por lo que no se requiere un conocimiento profundo del contenido de la tabla (no hay una separación lógica de los datos). En la configuración de esta tipo de partición se debe indicar las columnas cuyos valores se utilizarán para determinar el valor hash. Si las tablas tienen columnas índices, estas deben ser utilizadas en este proceso. De fácil configuración, no requieren mantenimiento. Durante las consultas todas las particiones deben ser exploradas a menos que se indique explícitamente las particiones a consultar (parámetros “=” o “IN” de la cláusula “WHERE”).

ROUND-ROBIN. Se utiliza para lograr una distribución uniforme de los datos en las particiones, a diferencia del caso anterior, no es necesario especificar columnas para definir el criterio de este proceso. Los nuevos registros de van asignando rotativamente. Las tablas no deben tener claves primarias. Son de fáciles configuración, no requieren mantenimiento. En consultas, todas las particiones deben ser exploradas. No hay separación lógica de los datos.

RANGE. Los registros son asignados a particiones utilizando los rangos de particiones definidos. Es la única que define la asignación de particiones bajo un criterio lógico, en consecuencia, es la mejor vía para optimizar el acceso a los datos. Para una adecuada configuración, es necesario conocer los datos y sus aplicaciones. Es necesario un regular mantenimiento (p.e. para definir nuevas particiones o eliminar otras cuyos datos han sido archivados). Es necesario el uso de una clave principal. Sólo es aplicable para tipos de datos (cadenas, enteros y fechas).

Particionamiento multinivel en SAP HANA Database

Cualquier definición de partición utilizando uno de los métodos anteriores, dará lugar a un particionamiento simple (single-level partioning). Si cada partición es particionada nuevamente por otros criterios, estaríamos hablando un particionamiento multinivel (multi-level partitioning).

Particionado de Tablas en SAP HANA (I) – Definiciones

En ocasiones, los problemas de rendimiento de muchos sistemas de información pasan por una falta de particionamiento de los datos o una mala adopción de esta técnica, SAP HANA no es una excepción, a pesar de los grandes recursos disponibles que puede tener la plataforma in-memory de SAP, está medida en ocasiones es necesaria.


En ocasiones, los problemas de rendimiento de muchos sistemas de información pasan por una falta de particionamiento de los datos o una mala adopción de esta técnica, SAP HANA no es una excepción, a pesar de los grandes recursos disponibles que puede tener la plataforma in-memory de SAP, está medida en ocasiones es necesaria.

A continuación, una breve relación de respuestas a preguntas frecuentes sobre este tema en SAP HANA:

Que es el Particionado de tablas de datos

  • El particionamiento significa que las tablas son divididas en sub-tablas denominadas particiones según un criterio específico.
  • Sólo es aplicable en tablas con almacenamiento columnar (column store), en tablas con almacenamiento en filas (row store) no soportan particionamiento.
  • El particionamiento es transparente para que las aplicaciones funcionen correctamente. Sin embargo la partición puede tener un impacto en el rendimiento, positivo o negativo, que pueden percibir los usuarios en la carga de los sistemas, depende de la estrategia implementada.

Cuando Particionar las tablas de datos

  • Por lo general, el particionado es muy útil en tablas de gran tamaño, por otro lado, debe tener presente que las tablas columnares no pueden superar los dos mil millones de registros.
  • Además del procesamiento paralelo, en un despliegue scale-out (escalabilidad horizontal, uso de más de un host), en consultas complejas, accediendo a particiones distribuidas en distintos nodos, se obtendría un alto rendimiento, más no en consultas simples.
  • Si las tablas tienes conjuntos de datos de uso frecuente, y otros conjuntos de menos uso, deberían ser particionados según este criterio (partition prune).
  • Si una región de datos sólo es actualizada y la otra no, los procesos de actualización serán más eficientes.

SAP da sus primeros pasos en «Internet of Things» con SAP HANA

Internet of Things (IoT), es un término acuñado en 1999 que está siendo cada vez más utilizado en los últimos meses, especialmente impulsado por la tecnología que rodea al mundo Mobile y Big Data. Para IoT podemos encontrar variadas definiciones, de las vistas, podemos destacar la siguiente:


Internet of Things (IoT), es un término acuñado en 1999 que está siendo cada vez más utilizado en los últimos meses, especialmente impulsado por la tecnología que rodea al mundo Mobile y Big Data. Para IoT podemos encontrar variadas definiciones, de las vistas, podemos destacar la siguiente:

Imagina un mundo en el que miles de millones de objetos pueden detectar, comunicar y compartir información, todos interconectados a través de redes IP (Internet Protoco) públicas o privadas. Estos objetos interconectados podrían recopilar datos con regularidad, los cuales podrían ser analizados y utilizados para tomar iniciativas, brindando más inteligencia a la planificación, a la toma de decisiones y a la gestión general de los procesos de negocio. Este es el mundo de la Internet de las Cosas (Internet of Things, IOT) -(Ref)

Definición de Internet of Things según McKinsey

Internet of Things, debe ser vista como una disciplina o tecnología, la cual engloba muchos otros elementos, tales como técnicas, estándares, buenas prácticas y otros conceptos. El término IoT en ocasiones es utilizado como sinónimo de M2M (Machine to Machine), pero debería diferenciarse que IoT es la tecnología o disciplina y M2M es la principal técnica que hace posible IoT para que los objetos puedan transmitir información.

Internet of Things (IoT), previsiones de objetos interconectados

Ante las previsiones de incremento de la demanda de soluciones IoT, SAP ha dado un primer paso es este sector para su plataforma SAP HANA, se trata de una extensión para el desarrollo de aplicaciones IoT. Esta extensión, por el momento, tiene un uso restringido para ciertos usuarios y la información disponible es limitada, a través de la nota 2008204 podremos conocer futuras novedades.

Visión de SAP de IoT

A partir de estas propuestas como la que ofrece SAP, se podrá desarrollar soluciones que respondan a necesidades concretas de negocio.

Potenciales aplicaciones para IoT

 

Selección del motor para procesar consultas en BW on HANA

En entradas anteriores comentamos sobre los motores (engines) de SAP HANA, los cuales, según el tipo de consulta o cálculo, entran en ejecución para obtener los mejores tiempos de respuesta de todo un proceso que se demande. Para el caso de consultas en un entorno BW on SAP HANA, el motor especialmente diseñado y optimizado para este fin es OLAP Engine, es el que mejores tiempos de procesamiento debería brindar el ejecutar una consulta en SAP NW BW powered by SAP HANA.


En entradas anteriores comentamos sobre los motores (engines) de SAP HANA, los cuales, según el tipo de consulta o cálculo, entran en ejecución para obtener los mejores tiempos de respuesta de todo un proceso que se demande. Para el caso de consultas en un entorno BW on SAP HANA, el motor especialmente diseñado y optimizado para este fin es OLAP Engine, es el que mejores tiempos de procesamiento debería brindar el ejecutar una consulta en SAP NW BW powered by SAP HANA.

Sin embargo, analizando la ejecución de una determinada consulta puede ser posible que se observe que mejores tiempos de respuesta nos brinde el motor JOIN Engine, si fuese así, SAP señala que se trataría de un error el cual debería ser reportado a SAP Support.

Mientras se encuentre la solución al posible error señalado en el párrafo anterior, SAP ofrece un “workaround” el cual debe ser deshabilitado una vez que el problema se resuelva. La “solución temporal” consiste en señalar el motor que debe utilizarse, el cual puede ser señalado para todo el sistema (modificando el parámetro HDB_QUERY_ENGINE_SELECTION), un infoprovider (agregando una fila a la tabla RSDRS_HDB_ENGSEL) o para una determinada consulta (vía transacción RSRT). Para más información consultar la nota 1931671.