{"id":440,"date":"2014-02-27T14:08:39","date_gmt":"2014-02-27T13:08:39","guid":{"rendered":"http:\/\/e3mag.com\/?p=440"},"modified":"2022-02-06T14:40:24","modified_gmt":"2022-02-06T13:40:24","slug":"logwriter-datawriter","status":"publish","type":"post","link":"https:\/\/e3mag.com\/es\/logwriter-datawriter\/","title":{"rendered":"Registrador y grabador de datos"},"content":{"rendered":"

En memoriaTecnolog\u00eda<\/span> requiere modelos de programaci\u00f3n 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\u00f3lo en el hardware, sino tambi\u00e9n en la tecnolog\u00eda del software.<\/p>\n

A medida que la tecnolog\u00eda 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\u00faan en el rango de los milisegundos (ms). Es decir, \u00a1una desproporci\u00f3n de 1 a 1.000.000!<\/p>\n

Como consecuencia, las CPU de las aplicaciones de procesamiento de la informaci\u00f3n pasan la mayor parte del tiempo esperando la IO. Ahora no basta con hacer m\u00e1s r\u00e1pido el almacenamiento, por ejemplo con sistemas ultrarr\u00e1pidos. Flash<\/span>-ya que la luz y, por tanto, los datos s\u00f3lo pueden recorrer una distancia muy limitada en el rango de los ns (< 30 cm en 1 ns).<\/p>\n

As\u00ed, el acceso r\u00e1pido a los datos s\u00f3lo puede lograrse, en \u00faltima instancia, manteniendo tambi\u00e9n los datos cerca del procesador: en el RAM<\/span>o mejor a\u00fan en la cach\u00e9.<\/p>\n

C\u00f3digo a datos<\/h3>\n

Se puede conseguir una mayor aceleraci\u00f3n de la velocidad de procesamiento ejecutando el c\u00f3digo de la aplicaci\u00f3n directamente en la base de datos, evitando as\u00ed latencias comparativamente altas en la comunicaci\u00f3n entre la aplicaci\u00f3n y la base de datos.<\/p>\n

Mientras que antes los datos se canalizaban a trav\u00e9s de la base de datos hasta la aplicaci\u00f3n, en el futuro el c\u00f3digo de la aplicaci\u00f3n llegar\u00e1 hasta los datos. Esta es la mejor forma de describir el cambio de paradigma: en lugar de \"datos a c\u00f3digo\", en el futuro ser\u00e1 \"c\u00f3digo a datos\".<\/p>\n

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

Desde la lectura del RAM<\/span> SAP Hana y otras soluciones in-memory se centran en el desarrollo de nuevasTecnolog\u00edas<\/span> se centran en la lectura de aplicaciones como la elaboraci\u00f3n de informes y la inteligencia empresarial (Procesamiento anal\u00edtico en l\u00ednea, OLAP<\/span>).<\/p>\n

Para sistemas transaccionales (OnLine Transaction Processing, OLTP<\/span>), pueden obtenerse ventajas del hecho de que, por un lado, la elaboraci\u00f3n de informes en l\u00ednea sobre los datos transaccionales es posible sin p\u00e9rdidas de rendimiento en el procesamiento de transacciones, o que las l\u00edneas de c\u00f3digo con un alto volumen de comunicaci\u00f3n entre la base de datos y la aplicaci\u00f3n ya se benefician de un cambio a la base de datos.<\/p>\n

Pero si OLAP<\/span> o OLTP<\/span>La base de datos en memoria (IMDB) requiere un Persistencia<\/span>porque, a m\u00e1s tardar, cuando se apaga el ordenador, los datos del RAM<\/span> desapareci\u00f3.<\/p>\n

Capa de persistencia y rendimiento<\/h3>\n

Dado que en una IMDB los accesos a los datos tienen lugar predominantemente en el RAM<\/span> cabe esperar que el almacenamiento como capa de persistencia desempe\u00f1e un papel menor en t\u00e9rminos de rendimiento y sirva principalmente como salvaguarda para garantizar que no se pierda ning\u00fan dato. Los requisitos de la SAP<\/span> al rendimiento de la Persistencia<\/span> eran y son, sin embargo, en parte superiores a las de las bases de datos cl\u00e1sicas. En general, se pueden identificar dos mecanismos de escritura para las bases de datos: logwriter y datawriter. El logwriter documenta cada cambio individual (inserci\u00f3n, actualizaci\u00f3n, eliminaci\u00f3n) realizado en la base de datos en un \u00e1rea separada en tiempo real (sincr\u00f3nicamente). El datawriter actualiza cada cierto tiempo (de forma as\u00edncrona) los cambios en las tablas almacenadas y garantiza una imagen coherente, aunque normalmente no actualizada (porque es as\u00edncrona), de la base de datos. El logwriter es cr\u00edtico para el procesamiento de transacciones y para la recuperaci\u00f3n de la base de datos, si alguna vez fuera necesario. Una transacci\u00f3n s\u00f3lo se considera completada cuando el logwriter la ha reportado como documentada. S\u00f3lo entonces puede continuar el procesamiento. Esto garantiza que, tras una finalizaci\u00f3n imprevista de la base de datos, se pueda restaurar el \u00faltimo estado v\u00e1lido actualizando la \u00faltima imagen de datos coherente con las entradas de registro que a\u00fan no se hayan registrado en ella (roll forward).<\/p>\n

Registrador y grabador de datos<\/h3>\n

En las primeras revisiones de Hana<\/span> el logwriter se dise\u00f1\u00f3 para escribir todos los cambios en bloques de peque\u00f1o tama\u00f1o en el \u00e1rea de registro. Cuando se realizaban cambios extensos en la base de datos, se produc\u00eda un n\u00famero significativo de operaciones IO. Por lo tanto, en ese momento el requisito de SAP<\/span>que el Persistencia<\/span> ten\u00eda que ser capaz de escribir al menos 100.000 IOps (operaciones IO por segundo).<\/p>\n

Esto puede lograrse con un esfuerzo razonable s\u00f3lo con Flash<\/span>-(basados en PCI). Esta es la raz\u00f3n por la que la mayor\u00eda de las instalaciones de nodo \u00fanico de Hana ten\u00edan y siguen teniendo dispositivos basados en PCIe. Flash<\/span>-dispositivos. M\u00e1s tarde Hana<\/span> se ampli\u00f3 con una arquitectura ScaleOut para el caso de que la expansi\u00f3n m\u00e1xima posible de la memoria principal de un ordenador ya no fuera suficiente para almacenar completamente una base de datos m\u00e1s grande.<\/p>\n

Hana<\/span> puede distribuirse a varios nodos de ordenador con esta opci\u00f3n. Los ordenadores pueden dise\u00f1arse de forma que no todos est\u00e9n activos, sino que uno o varios nodos puedan utilizarse tambi\u00e9n como Conmutaci\u00f3n por error<\/span> en caso de que falle un nodo activo. Sin embargo, esto requiere un Persistencia<\/span> que pueda ser le\u00eddo por todos los ordenadores, porque de lo contrario un Conmutaci\u00f3n por error<\/span>-Los datos de un ordenador averiado no pueden ser le\u00eddos por el nodo.<\/p>\n

Esto significaba que el concepto de escribir datos de registro muy r\u00e1pidamente en un dispositivo local ya no era defendible. En consecuencia, el logwriter se optimiz\u00f3 para que pudiera escribir bloques de tama\u00f1o 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\u00e1tico eran suficientes. No obstante, SAP<\/span> mantuvo los 100.000 IOps para nodos individuales hasta hace poco.<\/p>\n

Adem\u00e1s del logwriter, existe, como ya se ha mencionado, el datawriter. Al principio, uno podr\u00eda pensar que esto no ser\u00eda cr\u00edtico en t\u00e9rminos de rendimiento, ya que escribe de forma as\u00edncrona. Sin embargo Hana<\/span> a intervalos configurables -por defecto, cinco minutos-, los llamados puntos de salvaguarda. El rendimiento del almacenamiento debe dise\u00f1arse de forma que el volumen modificado entre dos puntos de guardado pueda escribirse en el intervalo de tiempo disponible, al menos en t\u00e9rminos de rendimiento.<\/p>\n

Dado que el grabador de datos funciona seg\u00fan el principio de copia en escritura, la carga de escritura tiende a ser secuencial, ya que se cambia Bloquea<\/span> no se sobrescriben, sino que los cambios se incorporan a las nuevas asignaciones Bloquea<\/span> ser presentada. Esto simplifica los requisitos para la Persistencia<\/span>porque la IO secuencial puede realizarse de forma mucho m\u00e1s eficiente que la IO aleatoria.<\/p>\n

Dado que la arquitectura interna basada en columnas de Hana<\/span> es comparable a las bases de datos indexadas al cien por cien. Hana<\/span> m\u00e1s a menudo reorganizaciones internas, que luego afectan tambi\u00e9n a la Persistencia<\/span> ser mapeado.<\/p>\n

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<\/span> Datos realmente en el RAM<\/span> debe decir.<\/p>\n

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

All\u00ed Hana<\/span> est\u00e1 actualmente en constante desarrollo con el objetivo de llegar alg\u00fan d\u00eda a hacer un uso \u00f3ptimo de la NVRAM, hay que instalar actualizaciones a intervalos regulares, que a menudo van acompa\u00f1adas de un reinicio de la base de datos. Esto explica la necesidad de SAP<\/span>El Persistencia<\/span> tambi\u00e9n estar equipados con altas tasas de rendimiento para la lectura en el \u00e1rea de datos.<\/p>\n

OLAP<\/span> frente a OLTP<\/span><\/strong><\/h3>\n

Aunque, como ya se ha mencionado, el principal \u00e1mbito de aplicaci\u00f3n de las IMDB tiende a estar en la OLAP<\/span> mentiras, va SAP<\/span> ya de paso, tambi\u00e9n OLTP<\/span>-aplicaciones en Hana<\/span> para propagarse (Suite on Hana<\/span>). T\u00e9cnicamente, es posible que OLTP<\/span>-sistemas para utilizar tanto nodos \u00fanicos como arquitecturas scale-out.<\/p>\n

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

Si Hana<\/span> sino que se distribuye por varios nodos inform\u00e1ticos en un entorno ScaleOut, resulta muy dif\u00edcil distribuir el c\u00f3digo y las tablas de datos entre los nodos de forma que las l\u00edneas de c\u00f3digo tambi\u00e9n encuentren sus tablas en el mismo ordenador en el que se est\u00e1n ejecutando en ese momento. Esto se debe a que si el c\u00f3digo tiene que obtener los datos de un nodo vecino, se produce de nuevo un esfuerzo de comunicaci\u00f3n entre los nodos, que ocurre con una latencia comparativamente alta, como si el c\u00f3digo hubiera permanecido en el servidor de aplicaciones.<\/p>\n

Por esta raz\u00f3n, una implementaci\u00f3n de un solo nodo de Hana<\/span> para OLTP<\/span> definitivamente preferible a una arquitectura scale-out.<\/p>\n

Al mismo tiempo SAP<\/span> hasta ahora para Hana<\/span> como nodo \u00fanico en la necesidad de dispositivos de registro r\u00e1pidos (internos). Sin embargo, los dispositivos de registro internos son esenciales para las empresas cr\u00edticas. Aplicaciones OLTP<\/span> inaceptable, ya que la p\u00e9rdida del ordenador o del dispositivo de registro tambi\u00e9n va acompa\u00f1ada de una p\u00e9rdida de datos.<\/p>\n

Los datos cr\u00edticos para el negocio, especialmente los datos de registro, siempre deben escribirse (reflejarse) en una segunda ubicaci\u00f3n para que, en caso de emergencia, la base de datos pueda recuperarse desde una segunda fuente hasta la \u00faltima transacci\u00f3n completada.<\/p>\n

Fujitsu no tard\u00f3 en reconocer la Hana<\/span>-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\u00e1n disponibles all\u00ed, desde un punto de vista t\u00e9cnico no han sido necesarios durante mucho tiempo. Sin embargo, esto significa que para Hana<\/span> el funcionamiento seguro y flexible conocido de FlexFrame est\u00e1 garantizado para las aplicaciones cr\u00edticas para la empresa con los elevados SLA t\u00edpicos de este tipo de aplicaciones.<\/p>\n

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

Concepto de funcionamiento eficaz y bases de datos en la sombra<\/h3>\n

La demanda de un almacenamiento de datos seguro y un concepto operativo eficiente se satisface con la integraci\u00f3n de Hana<\/span> en FlexFrame. Con el almacenamiento compartido en espejo, la alta disponibilidad est\u00e1 garantizada tanto a nivel local como en todo el centro de datos.<\/p>\n

Un punto pendiente sigue siendo el problema de los tiempos de reinicio. Dependiendo del tama\u00f1o de la base de datos, un reinicio completo puede llevar un tiempo excesivamente largo incluso con canales IO de alto rendimiento.<\/p>\n

En el curso del desarrollo ulterior de Hana<\/span> funciona SAP<\/span> sobre el concepto de base de datos en la sombra, que idealmente minimizar\u00eda los tiempos de conmutaci\u00f3n, ya que las bases de datos en la sombra suelen ejecutarse casi sincr\u00f3nicamente con los datos primarios.<\/p>\n

Tras el fallo de la base de datos primaria, la activaci\u00f3n y recuperaci\u00f3n completa de la base de datos en la sombra s\u00f3lo llevar\u00eda unos minutos hasta que se pudieran reanudar las operaciones.<\/p>\n

Las bases de datos en la sombra est\u00e1n en Hana<\/span> a\u00fan no est\u00e1 disponible en la actualidad, pero como precursora de estas ofertas Hana<\/span> la opci\u00f3n de replicaci\u00f3n del sistema, que garantiza que los datos de registro se repliquen de forma sincr\u00f3nica a una segunda instancia y que, a intervalos regulares, el almac\u00e9n de columnas (la estructura de columnas) de Hana<\/span> se precarga en la memoria principal y se actualiza.<\/p>\n

Esto significa que no es necesario Conmutaci\u00f3n por error<\/span> la recarga completa del almac\u00e9n de columnas, puesto que la mayor parte ya est\u00e1 precargada. Esto reduce a un nivel razonable los tiempos de reinicio en entornos cr\u00edticos.<\/p>\n

La recomendaci\u00f3n para las aplicaciones que s\u00f3lo permiten un tiempo de inactividad m\u00ednimo ser\u00eda utilizar local a la productiva Hana<\/span>-instancia con replicaci\u00f3n del sistema y utilizar el sistema productivo en caso de desastre. Persistencia<\/span> en una segunda RZ.<\/p>\n

Dado que la instancia con replicaci\u00f3n de sistemas s\u00f3lo utiliza una peque\u00f1a parte de los recursos del ordenador, otros sistemas no productivos podr\u00edan ejecutarse en paralelo en el nodo del ordenador.<\/p>\n

ScaleOut<\/h3>\n

Lo que queda por debatir es c\u00f3mo debe evaluarse una arquitectura scale-out en comparaci\u00f3n con un nodo \u00fanico. B\u00e1sicamente, lo siguiente se aplica a ambas OLTP<\/span> as\u00ed como para OLAP<\/span>que con el mismo tama\u00f1o de base de datos, el Nodo \u00danico, proporcionado por el RAM<\/span>-capacidades posibles, es la alternativa preferida.<\/p>\n

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

Especialmente para Aplicaciones OLAP<\/span> el problema de asignar inteligentemente l\u00edneas de c\u00f3digo a los datos no es tan relevante como con OLTP<\/span>porque, por lo general, las consultas pueden procesarse de forma bien distribuida debido a su estructura matem\u00e1tica. 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.<\/p>\n

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

Con un \u00fanico nodo, no hay necesidad de transferencia de datos ni de almacenamiento intermedio, ya que todos los datos son locales. De ah\u00ed la recomendaci\u00f3n de que las aplicaciones se sirvan con una \u00fanica instancia de nodo durante el mayor tiempo posible.<\/p>\n

Los avances actuales en tecnolog\u00eda de hardware dan cabida a este planteamiento. Con el hardware disponible oficialmente en febrero de 2014, ser\u00e1 posible utilizar hasta 12 TB RAM<\/span> instalarse en una m\u00e1quina.<\/p>\n

SAP<\/span> mientras tanto deja saber que con el nuevo hardware para aplicaciones OLTP soportar\u00e1 hasta 6 TB en una m\u00e1quina para sistemas productivos y para OLAP<\/span> hasta 2 TB con ocho z\u00f3calos cargados, frente a 1 TB en el pasado.<\/p>\n

Esto parece plausible, ya que el rendimiento de la CPU de la nueva generaci\u00f3n de procesadores se ha duplicado aproximadamente. Sin embargo, el rendimiento del Hana<\/span>-Tecnolog\u00eda<\/span> se ha mejorado constante y significativamente en los \u00faltimos a\u00f1os, de modo que, desde un punto de vista t\u00e9cnico, incluso se han conseguido mayores RAM<\/span>-Puedo imaginar una expansi\u00f3n m\u00e1s potente que 2 TB para un nodo en una arquitectura ScaleOut.<\/p>\n

\"https:\/\/e3mag.com\/partners\/fujitsu\/\"<\/a><\/p>","protected":false},"excerpt":{"rendered":"

Con Hana, SAP lleva varios a\u00f1os desarrollando una nueva base t\u00e9cnica para sus aplicaciones. La motivaci\u00f3n para ello puede ser que es inminente un cambio de paradigma tecnol\u00f3gico con la memoria RAM no vol\u00e1til (NVRAM).<\/p>","protected":false},"author":46,"featured_media":1125,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"pmpro_default_level":"","footnotes":""},"categories":[5],"tags":[424,428,430],"coauthors":[24296],"class_list":["post-440","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-it-management","tag-in-memory-technologie","tag-olap","tag-oltp","pmpro-has-access"],"acf":[],"featured_image_urls_v2":{"full":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"thumbnail":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-150x150.jpg",150,150,true],"medium":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",400,267,false],"medium_large":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-768x512.jpg",768,512,true],"large":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"image-100":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-100x67.jpg",100,67,true],"image-480":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-480x320.jpg",480,320,true],"image-640":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-640x427.jpg",640,427,true],"image-720":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-720x480.jpg",720,480,true],"image-960":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-960x640.jpg",960,640,true],"image-1168":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"image-1440":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"image-1920":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"1536x1536":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"2048x2048":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"trp-custom-language-flag":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",18,12,false],"bricks_large_16x9":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"bricks_large":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"bricks_large_square":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"bricks_medium":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",600,400,false],"bricks_medium_square":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",600,400,false],"profile_24":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-24x24.jpg",24,24,true],"profile_48":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-48x48.jpg",48,48,true],"profile_96":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-96x96.jpg",96,96,true],"profile_150":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-150x150.jpg",150,150,true],"profile_300":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-300x300.jpg",300,300,true]},"post_excerpt_stackable_v2":"

SAP entwickelt mit Hana seit einigen Jahren eine neue technische Basis f\u00fcr ihre Anwendungen. Die Motivation daf\u00fcr mag darin begr\u00fcndet sein, dass mit nicht fl\u00fcchtigem Hauptspeicher (NVRAM \u2013 non volatile RAM) ein technologischer Paradigmenwechsel bevorsteht.<\/p>\n","category_list_v2":"IT-Management<\/a>","author_info_v2":{"name":"J\u00fcrgen Meynert, Fujitsu","url":"https:\/\/e3mag.com\/es\/author\/juergen-meynert\/"},"comments_num_v2":"0 comentarios","_links":{"self":[{"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/posts\/440","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/users\/46"}],"replies":[{"embeddable":true,"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/comments?post=440"}],"version-history":[{"count":0,"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/posts\/440\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/media\/1125"}],"wp:attachment":[{"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/media?parent=440"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/categories?post=440"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/tags?post=440"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/coauthors?post=440"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}