Registrador y grabador de datos

En memoriaTecnología requiere modelos de programación fundamentalmente nuevos que no pueden realizarse adaptando el software existente, sino que exigen planteamientos radicalmente nuevos. Esto significa que es inminente un cambio de paradigma no sólo en el hardware, sino también en la tecnología del software.

A medida que la tecnología ha ido avanzando, la velocidad de acceso de los sistemas de almacenamiento no ha seguido el ritmo de aumento de la velocidad de los procesadores. A velocidades de reloj de la CPU de 3 GHz, que corresponden a tiempos de ciclo de 0,3 nanosegundos, los pasos de procesamiento en el procesador duran del orden de nanosegundos (ns), mientras que los accesos al almacenamiento externo se sitúan en el rango de los milisegundos (ms). Es decir, ¡una desproporción de 1 a 1.000.000!

Como consecuencia, las CPU de las aplicaciones de procesamiento de la información pasan la mayor parte del tiempo esperando la IO. Ahora no basta con hacer más rápido el almacenamiento, por ejemplo con sistemas ultrarrápidos. Flash-ya que la luz y, por tanto, los datos sólo pueden recorrer una distancia muy limitada en el rango de los ns (< 30 cm en 1 ns).

Así, el acceso rápido a los datos sólo puede lograrse, en última instancia, manteniendo también los datos cerca del procesador: en el RAMo mejor aún en la caché.

Código a datos

Se puede conseguir una mayor aceleración de la velocidad de procesamiento ejecutando el código de la aplicación directamente en la base de datos, evitando así latencias comparativamente altas en la comunicación entre la aplicación y la base de datos.

Mientras que antes los datos se canalizaban a través de la base de datos hasta la aplicación, en el futuro el código de la aplicación llegará hasta los datos. Esta es la mejor forma de describir el cambio de paradigma: en lugar de "datos a código", en el futuro será "código a datos".

La corriente es RAM Sin embargo, los datos siguen siendo volátiles, por lo que las operaciones de escritura en la memoria principal deben estar protegidas por una capa de persistencia, es decir, en última instancia, de nuevo almacenamiento. Para el acceso de lectura, incluso a cantidades muy grandes de datos, se requiere lo siguiente RAM Hoy en día, los ordenadores ya están bien equipados para hacer frente a la cada vez mayor densidad de empaquetamiento de los elementos de memoria y a la simultánea caída de los precios. RAM-capacidades (hasta varios TB) están disponibles a precios razonables.

Desde la lectura del RAM SAP Hana y otras soluciones in-memory se centran en el desarrollo de nuevasTecnologías se centran en la lectura de aplicaciones como la elaboración de informes y la inteligencia empresarial (Procesamiento analítico en línea, OLAP).

Para sistemas transaccionales (OnLine Transaction Processing, OLTP), pueden obtenerse ventajas del hecho de que, por un lado, la elaboración de informes en línea sobre los datos transaccionales es posible sin pérdidas de rendimiento en el procesamiento de transacciones, o que las líneas de código con un alto volumen de comunicación entre la base de datos y la aplicación ya se benefician de un cambio a la base de datos.

Pero si OLAP o OLTPLa base de datos en memoria (IMDB) requiere un Persistenciaporque, a más tardar, cuando se apaga el ordenador, los datos del RAM desapareció.

Capa de persistencia y rendimiento

Dado que en una IMDB los accesos a los datos tienen lugar predominantemente en el RAM cabe esperar que el almacenamiento como capa de persistencia desempeñe un papel menor en términos de rendimiento y sirva principalmente como salvaguarda para garantizar que no se pierda ningún dato. Los requisitos de la SAP al rendimiento de la Persistencia eran y son, sin embargo, en parte superiores a las de las bases de datos clásicas. En general, se pueden identificar dos mecanismos de escritura para las bases de datos: logwriter y datawriter. El logwriter documenta cada cambio individual (inserción, actualización, eliminación) realizado en la base de datos en un área separada en tiempo real (sincrónicamente). El datawriter actualiza cada cierto tiempo (de forma asíncrona) los cambios en las tablas almacenadas y garantiza una imagen coherente, aunque normalmente no actualizada (porque es asíncrona), de la base de datos. El logwriter es crítico para el procesamiento de transacciones y para la recuperación de la base de datos, si alguna vez fuera necesario. Una transacción sólo se considera completada cuando el logwriter la ha reportado como documentada. Sólo entonces puede continuar el procesamiento. Esto garantiza que, tras una finalización imprevista de la base de datos, se pueda restaurar el último estado válido actualizando la última imagen de datos coherente con las entradas de registro que aún no se hayan registrado en ella (roll forward).

Registrador y grabador de datos

En las primeras revisiones de Hana el logwriter se diseñó para escribir todos los cambios en bloques de pequeño tamaño en el área de registro. Cuando se realizaban cambios extensos en la base de datos, se producía un número significativo de operaciones IO. Por lo tanto, en ese momento el requisito de SAPque el Persistencia tenía que ser capaz de escribir al menos 100.000 IOps (operaciones IO por segundo).

Esto puede lograrse con un esfuerzo razonable sólo con Flash-(basados en PCI). Esta es la razón por la que la mayoría de las instalaciones de nodo único de Hana tenían y siguen teniendo dispositivos basados en PCIe. Flash-dispositivos. Más tarde Hana se amplió con una arquitectura ScaleOut para el caso de que la expansión máxima posible de la memoria principal de un ordenador ya no fuera suficiente para almacenar completamente una base de datos más grande.

Hana puede distribuirse a varios nodos de ordenador con esta opción. Los ordenadores pueden diseñarse de forma que no todos estén activos, sino que uno o varios nodos puedan utilizarse también como Conmutación por error en caso de que falle un nodo activo. Sin embargo, esto requiere un Persistencia que pueda ser leído por todos los ordenadores, porque de lo contrario un Conmutación por error-Los datos de un ordenador averiado no pueden ser leídos por el nodo.

Esto significaba que el concepto de escribir datos de registro muy rápidamente en un dispositivo local ya no era defendible. En consecuencia, el logwriter se optimizó para que pudiera escribir bloques de tamaño variable. Esto significaba que las altas tasas de IO ya no eran necesarias. En un escenario scale-out, algo menos de 20.000 IOps por nodo informático eran suficientes. No obstante, SAP mantuvo los 100.000 IOps para nodos individuales hasta hace poco.

Además del logwriter, existe, como ya se ha mencionado, el datawriter. Al principio, uno podría pensar que esto no sería crítico en términos de rendimiento, ya que escribe de forma asíncrona. Sin embargo Hana a intervalos configurables -por defecto, cinco minutos-, los llamados puntos de salvaguarda. El rendimiento del almacenamiento debe diseñarse de forma que el volumen modificado entre dos puntos de guardado pueda escribirse en el intervalo de tiempo disponible, al menos en términos de rendimiento.

Dado que el grabador de datos funciona según el principio de copia en escritura, la carga de escritura tiende a ser secuencial, ya que se cambia Bloquea no se sobrescriben, sino que los cambios se incorporan a las nuevas asignaciones Bloquea ser presentada. Esto simplifica los requisitos para la Persistenciaporque la IO secuencial puede realizarse de forma mucho más eficiente que la IO aleatoria.

Dado que la arquitectura interna basada en columnas de Hana es comparable a las bases de datos indexadas al cien por cien. Hana más a menudo reorganizaciones internas, que luego afectan también a la Persistencia ser mapeado.

Esto aumenta el requisito de rendimiento de escritura del escritor de datos. Por el contrario, cabe esperar que los requisitos de rendimiento de E/S para la lectura de datos sean bastante bajos, ya que Hana Datos realmente en el RAM debe decir.

Esto puede ser cierto para el funcionamiento normal, pero no lo es para el caso de que Hana se inicia. Suponiendo que haya que leer 1 TB de datos en la memoria principal, esto aún tarda 20 minutos a un rendimiento de 1 GB/s. Esto no sería un problema si los reinicios de la base de datos fueran la excepción. Esto no sería un problema si los reinicios de la base de datos fueran la excepción.

Allí Hana está actualmente en constante desarrollo con el objetivo de llegar algún día a hacer un uso óptimo de la NVRAM, hay que instalar actualizaciones a intervalos regulares, que a menudo van acompañadas de un reinicio de la base de datos. Esto explica la necesidad de SAPEl Persistencia también estar equipados con altas tasas de rendimiento para la lectura en el área de datos.

OLAP frente a OLTP

Aunque, como ya se ha mencionado, el principal ámbito de aplicación de las IMDB tiende a estar en la OLAP mentiras, va SAP ya de paso, también OLTP-aplicaciones en Hana para propagarse (Suite on Hana). Técnicamente, es posible que OLTP-sistemas para utilizar tanto nodos únicos como arquitecturas scale-out.

Sin embargo, desde el punto de vista del rendimiento, hay una diferencia significativa. Como ya se ha explicado, para OLTP-aplicaciones una ventaja de rendimiento en el Hana Esto puede lograrse cuando las secciones de código se trasladan a la base de datos para evitar una comunicación entre la aplicación y la base de datos que consume mucho tiempo.

Si Hana sino que se distribuye por varios nodos informáticos en un entorno ScaleOut, resulta muy difícil distribuir el código y las tablas de datos entre los nodos de forma que las líneas de código también encuentren sus tablas en el mismo ordenador en el que se están ejecutando en ese momento. Esto se debe a que si el código tiene que obtener los datos de un nodo vecino, se produce de nuevo un esfuerzo de comunicación entre los nodos, que ocurre con una latencia comparativamente alta, como si el código hubiera permanecido en el servidor de aplicaciones.

Por esta razón, una implementación de un solo nodo de Hana para OLTP definitivamente preferible a una arquitectura scale-out.

Al mismo tiempo SAP hasta ahora para Hana como nodo único en la necesidad de dispositivos de registro rápidos (internos). Sin embargo, los dispositivos de registro internos son esenciales para las empresas críticas. Aplicaciones OLTP inaceptable, ya que la pérdida del ordenador o del dispositivo de registro también va acompañada de una pérdida de datos.

Los datos críticos para el negocio, especialmente los datos de registro, siempre deben escribirse (reflejarse) en una segunda ubicación para que, en caso de emergencia, la base de datos pueda recuperarse desde una segunda fuente hasta la última transacción completada.

Fujitsu no tardó en reconocer la Hana-arquitectura de un solo nodo integrada en el concepto operativo FlexFrame y los datos de registro colocados en unidades de almacenamiento externas y replicables. Aunque los 100.000 IOps requeridos anteriormente no están disponibles allí, desde un punto de vista técnico no han sido necesarios durante mucho tiempo. Sin embargo, esto significa que para Hana el funcionamiento seguro y flexible conocido de FlexFrame está garantizado para las aplicaciones críticas para la empresa con los elevados SLA típicos de este tipo de aplicaciones.

Mientras tanto, el SAP de los elevados requisitos de E/S del grabador de registros, con el fin de Hana prepararse para una integración flexible en el funcionamiento del centro de datos.

Concepto de funcionamiento eficaz y bases de datos en la sombra

La demanda de un almacenamiento de datos seguro y un concepto operativo eficiente se satisface con la integración de Hana en FlexFrame. Con el almacenamiento compartido en espejo, la alta disponibilidad está garantizada tanto a nivel local como en todo el centro de datos.

Un punto pendiente sigue siendo el problema de los tiempos de reinicio. Dependiendo del tamaño de la base de datos, un reinicio completo puede llevar un tiempo excesivamente largo incluso con canales IO de alto rendimiento.

En el curso del desarrollo ulterior de Hana funciona SAP sobre el concepto de base de datos en la sombra, que idealmente minimizaría los tiempos de conmutación, ya que las bases de datos en la sombra suelen ejecutarse casi sincrónicamente con los datos primarios.

Tras el fallo de la base de datos primaria, la activación y recuperación completa de la base de datos en la sombra sólo llevaría unos minutos hasta que se pudieran reanudar las operaciones.

Las bases de datos en la sombra están en Hana aún no está disponible en la actualidad, pero como precursora de estas ofertas Hana la opción de replicación del sistema, que garantiza que los datos de registro se repliquen de forma sincrónica a una segunda instancia y que, a intervalos regulares, el almacén de columnas (la estructura de columnas) de Hana se precarga en la memoria principal y se actualiza.

Esto significa que no es necesario Conmutación por error la recarga completa del almacén de columnas, puesto que la mayor parte ya está precargada. Esto reduce a un nivel razonable los tiempos de reinicio en entornos críticos.

La recomendación para las aplicaciones que sólo permiten un tiempo de inactividad mínimo sería utilizar local a la productiva Hana-instancia con replicación del sistema y utilizar el sistema productivo en caso de desastre. Persistencia en una segunda RZ.

Dado que la instancia con replicación de sistemas sólo utiliza una pequeña parte de los recursos del ordenador, otros sistemas no productivos podrían ejecutarse en paralelo en el nodo del ordenador.

ScaleOut

Lo que queda por debatir es cómo debe evaluarse una arquitectura scale-out en comparación con un nodo único. Básicamente, lo siguiente se aplica a ambas OLTP así como para OLAPque con el mismo tamaño de base de datos, el Nodo Único, proporcionado por el RAM-capacidades posibles, es la alternativa preferida.

Hay dos razones principales para ello. La primera ya se mencionó durante el debate en relación con OLTP discutido. La comunicación entre los nodos de la base de datos cuesta comparativamente mucho tiempo y tiene un impacto negativo en el rendimiento.

Especialmente para Aplicaciones OLAP el problema de asignar inteligentemente líneas de código a los datos no es tan relevante como con OLTPporque, por lo general, las consultas pueden procesarse de forma bien distribuida debido a su estructura matemática. No obstante, persiste el problema de la latencia, ya que los resultados parciales de una consulta deben reunirse finalmente en un nodo y consolidarse en un resultado final.

Un segundo problema surge, por ejemplo, con las uniones que pasan por tablas distribuidas en varios nodos. Antes de poder ejecutar la unión, los datos de las tablas implicadas deben transferirse al nodo en el que se ejecuta la unión y almacenarse temporalmente. Esto cuesta tiempo, por un lado, y memoria principal adicional, por otro.

Con un único nodo, no hay necesidad de transferencia de datos ni de almacenamiento intermedio, ya que todos los datos son locales. De ahí la recomendación de que las aplicaciones se sirvan con una única instancia de nodo durante el mayor tiempo posible.

Los avances actuales en tecnología de hardware dan cabida a este planteamiento. Con el hardware disponible oficialmente en febrero de 2014, será posible utilizar hasta 12 TB RAM instalarse en una máquina.

SAP mientras tanto deja saber que con el nuevo hardware para aplicaciones OLTP soportará hasta 6 TB en una máquina para sistemas productivos y para OLAP hasta 2 TB con ocho zócalos cargados, frente a 1 TB en el pasado.

Esto parece plausible, ya que el rendimiento de la CPU de la nueva generación de procesadores se ha duplicado aproximadamente. Sin embargo, el rendimiento del Hana–Tecnología se ha mejorado constante y significativamente en los últimos años, de modo que, desde un punto de vista técnico, incluso se han conseguido mayores RAM-Puedo imaginar una expansión más potente que 2 TB para un nodo en una arquitectura ScaleOut.