{"id":62754,"date":"2019-11-28T08:00:32","date_gmt":"2019-11-28T07:00:32","guid":{"rendered":"http:\/\/e3mag.com\/?p=62754"},"modified":"2020-02-07T22:12:14","modified_gmt":"2020-02-07T21:12:14","slug":"hana-el-todo-es-mas-que-la-suma-de-las-partes","status":"publish","type":"post","link":"https:\/\/e3mag.com\/es\/hana-el-todo-es-mas-que-la-suma-de-las-partes\/","title":{"rendered":"Hana: El todo es m\u00e1s que la suma de las partes"},"content":{"rendered":"

Ahora se habla cada vez m\u00e1s de \"warm storage\" (almacenamiento din\u00e1mico por niveles y extensiones de almacenamiento nativo). Entonces, \u00bfva SAP por el camino inverso y acabar\u00e1 donde las bases de datos cl\u00e1sicas: con bases de datos en disco y la memoria como cach\u00e9?<\/p>\n

Filas para OLTP Columnas para OLAP<\/h3>\n

A menudo se oye decir que el almacenamiento en filas es mejor para leer frases enteras. Incluso Hasso Plattner lo insinu\u00f3 en la \u00faltima keynote de Sapphire. El argumento de siempre:<\/p>\n

Los datos de un registro se almacenan juntos en una base de datos basada en l\u00edneas. Un argumento atractivo, pero demasiado corto de miras. No se tiene en cuenta la distancia topol\u00f3gica.<\/p>\n

Este argumento procede de la \u00e9poca de los discos duros, cuando el cabezal de lectura m\u00e1s la velocidad angular del disco giratorio determinaban el tiempo de acceso y se le\u00edan sectores de 4 kB de una vez.<\/p>\n

Con los SSD ya no hay mec\u00e1nica, se env\u00eda una direcci\u00f3n y se devuelve un sector de 4 kB. Por lo tanto, el tiempo de acceso a un sector es significativamente m\u00e1s corto, pero los datos deben seguir estando cerca, en el mismo sector de 4 kB.<\/p>\n

En cambio, la memoria s\u00f3lo devuelve 16 bytes por acceso, pero por supuesto mucho m\u00e1s r\u00e1pido, y qu\u00e9 direcci\u00f3n de memoria se solicita a continuaci\u00f3n es irrelevante.<\/p>\n

En otras palabras: para leer 4 kB a m\u00e1xima velocidad, los datos deben estar en un sector en los discos duros y SSD. A la memoria, en cambio, no le importa en absoluto, se realizan 256 accesos de 16 bytes cada uno para leer 4 kB como sea.<\/p>\n

Desde esta perspectiva, el almacenamiento orientado a filas o columnas es igual de r\u00e1pido si todos los datos est\u00e1n ya en la memoria. La direcci\u00f3n de memoria es diferente, pero esto no influye en la velocidad.<\/p>\n

La afirmaci\u00f3n de que la lectura de una fila requiere un almacenamiento orientado a filas y los an\u00e1lisis OLAP requieren una orientaci\u00f3n a columnas s\u00f3lo se aplica a las operaciones de disco. Aunque he refutado as\u00ed el razonamiento en s\u00ed, la afirmaci\u00f3n \"con memoria suficiente, una base de datos normal es tambi\u00e9n una base de datos en memoria\" sigue sin respuesta.<\/p>\n

Esto se debe a la orientaci\u00f3n de las columnas: un registro de datos contiene una gran variedad de informaci\u00f3n, n\u00famero de material, texto y muchos indicadores como color, tipo, tama\u00f1o, etc.<\/p>\n

Sin duda, esta informaci\u00f3n divergente no puede comprimirse tan bien como cada columna por s\u00ed sola, con patrones m\u00e1s bien repetitivos. Un enfoque a\u00fan m\u00e1s inteligente consiste en examinar individualmente cada valor de una columna de este tipo.<\/p>\n

Por ejemplo, s\u00f3lo existen los valores M, S, L, XL para el campo Talla, por lo que se generan cuatro cadenas. La cadena para M podr\u00eda tener este aspecto: 0100-0000-0000-1000; y significa que el valor M aparece en los registros 2 y 13.<\/p>\n

Algo as\u00ed se puede comprimir muy bien con un ordenador y adem\u00e1s muy r\u00e1pido. Para otras columnas se utilizan otros m\u00e9todos, como el n\u00famero de material, que es diferente para cada material.<\/p>\n

\"Werner<\/a><\/h3>\n

Buscar y encontrar<\/h3>\n

En un sistema ERP se accede a los datos por clave primaria o mediante una b\u00fasqueda. \"mostrar pedido de cliente 1234\" o \"buscar todos los art\u00edculos de venta para el pedido de cliente 1234\".<\/p>\n

El primer proceso es el mismo para ambos tipos de base de datos. Una base de datos cl\u00e1sica utiliza el \u00edndice, encuentra all\u00ed la direcci\u00f3n de la fila y lee el registro en esta direcci\u00f3n. En Hana, se lee el \u00edndice, se encuentra all\u00ed el n\u00famero de registro y se recupera el valor en esta posici\u00f3n de cada columna.<\/p>\n

De nuevo hay diferencias en la b\u00fasqueda: con una orientaci\u00f3n por filas, es de esperar que haya un segundo \u00edndice que contenga todas las direcciones de los registros de art\u00edculos de venta que pertenecen a un pedido de cliente.<\/p>\n

De lo contrario, la base de datos no tiene ninguna posibilidad y tiene que buscar en toda la tabla. Con Hana, la indexaci\u00f3n ya viene dada por la forma en que se almacenan los datos. Una inmensa ventaja pr\u00e1ctica.<\/p>\n

Cada uno de estos puntos -orientaci\u00f3n a columnas, compresi\u00f3n, indexaci\u00f3n e in-memory- tiene sus propias ventajas y desventajas. El argumento de venta exclusivo de SAP Hana es que, a\u00fan hoy, esta base de datos sigue siendo la \u00fanica que combina inteligentemente todos estos puntos, de modo que las ventajas se unen.<\/p>\n

Puedes conservar todo en memoria si lo comprimes. Si organizas los datos en columnas, puedes comprimirlos mejor. Aparte de las claves primarias, los \u00edndices ya no son necesarios gracias a la organizaci\u00f3n en columnas y a la compresi\u00f3n.<\/p>\n

Dado que todos los datos se almacenan en la memoria, las consultas de un conjunto de tablas completo son igual de r\u00e1pidas que con el almacenamiento por filas, por lo que incluso se puede utilizar el almacenamiento por columnas para este tipo de consultas.<\/p>\n

Por otro lado, se gana mucho con Hana para los casos normales. Las consultas OLAP como \"ventas totales al a\u00f1o\" son muy r\u00e1pidas porque los datos ya est\u00e1n organizados en columnas.<\/p>\n

Las b\u00fasquedas en cualquier atributo son mucho m\u00e1s r\u00e1pidas porque cada columna representa por s\u00ed misma un \u00edndice. Las consultas que no leen el 100% de las columnas de la tabla son m\u00e1s r\u00e1pidas.<\/p>\n

Pero \u00e9ste es tambi\u00e9n el quid de la cuesti\u00f3n: Todo mi an\u00e1lisis se basaba en la premisa de que todos los datos ya est\u00e1n en la memoria y tambi\u00e9n caben en ella.<\/p>\n

\u00bfNo es un despilfarro de memoria y, por tanto, de dinero mantener siempre todo en la RAM (memoria de acceso aleatorio), independientemente de si se necesita o no?<\/p>\n

SAP ofrece aqu\u00ed al administrador opciones de optimizaci\u00f3n: El primer punto son los tipos de datos binarios (tipos de datos LOB, CLOB y NCLOB). Estos no se almacenan en memoria, sino que permanecen siempre en disco.<\/p>\n

El puntero al fichero est\u00e1 en la memoria, pero no el contenido. Buena idea, pero no sirve de mucho porque esos tipos de datos casi nunca aparecen en un ERP.<\/p>\n

Primer uso<\/h3>\n

Siguiente optimizaci\u00f3n: Las particiones s\u00f3lo se cargan en la memoria cuando se han utilizado por primera vez y no por precauci\u00f3n. As\u00ed, si una tabla consta de mil millones de registros, divididos en diez particiones para diez a\u00f1os, s\u00f3lo se cargar\u00eda en memoria la partici\u00f3n correspondiente al a\u00f1o en curso.<\/p>\n

Tambi\u00e9n es una buena idea, reduce el tiempo de arranque y el requerimiento de memoria inicial, pero con el tiempo cada partici\u00f3n habr\u00e1 sido utilizada al menos una vez por alguien. Esto significa que en alg\u00fan momento todo estar\u00e1 en la RAM y permanecer\u00e1 all\u00ed hasta el pr\u00f3ximo reinicio.<\/p>\n

Existe una funci\u00f3n para ello: el periodo de retenci\u00f3n. Con este ajuste, tales particiones se eliminan de la RAM despu\u00e9s de un tiempo determinado sin ning\u00fan acceso. Finalmente un ajuste que elimina cosas de la RAM. Atenci\u00f3n, \u00a1este interruptor est\u00e1 en Off por defecto!<\/p>\n

Esto ya est\u00e1 muy bien, pero hay dos lagunas. La primera persona que utiliza un solo conjunto de datos desencadena la carga completa de esta partici\u00f3n en la memoria.<\/p>\n

Si dicha partici\u00f3n tiene un tama\u00f1o de un gigabyte, puede tardar dos segundos. Y nada de esto ayuda si toda la base de datos requiere 1,1 terabytes de RAM, pero s\u00f3lo se dispone de 1 terabyte.<\/p>\n

Aqu\u00ed es donde la \u00faltima funci\u00f3n, la Extensi\u00f3n de Almacenamiento Nativo, viene al rescate. Esto significa que ya no se carga toda la partici\u00f3n, sino s\u00f3lo las p\u00e1ginas necesarias que contienen estos datos.<\/p>\n

Y si no hay suficiente RAM disponible, las p\u00e1ginas que no se necesitan se eliminan de nuevo. El procedimiento aqu\u00ed es realmente el mismo que con una base de datos cl\u00e1sica basada en disco y s\u00f3lo utiliza la RAM como cach\u00e9 para las tablas con esta configuraci\u00f3n.<\/p>\n

Datos multitemperatura<\/h3>\n

Pero no es as\u00ed como se pretende. Hana tambi\u00e9n es una base de datos de computaci\u00f3n en memoria, por lo que todos (!) los datos utilizados (!) deben estar disponibles en la memoria. Esta es la \u00fanica forma de que las consultas OLTP y OLAP puedan ser gestionadas por la misma base de datos, la \u00fanica forma de conseguir tiempos de respuesta cortos y predecibles.<\/p>\n

Estas funciones adicionales s\u00f3lo son adecuadas para datos multitemperatura. Para datos que se necesitan de vez en cuando. Para los que el usuario no debe ser enviado a una base de datos de archivo.<\/p>\n

Si utilizara estas caracter\u00edsticas para todas las tablas y proporcionara muy poca RAM, entonces las desventajas del almacenamiento orientado a columnas empezar\u00edan a hacerse evidentes. Ya no tendr\u00eda todas las ventajas sin los inconvenientes.<\/p>\n

En su lugar, Hana representa el punto de entrada central para los datos de diferente naturaleza y oculta las diferencias f\u00edsicas: el usuario emite sus \u00f3rdenes, algunos datos proceden del almac\u00e9n en memoria, otros del disco, otros se visualizan a trav\u00e9s de la funci\u00f3n Hana Smart Data Access desde un sistema externo (\"Federated\"). El usuario no nota nada de esto, aparte de unos tiempos de respuesta m\u00e1s largos. Hana se convierte en un tejido de datos.<\/p>\n

La f\u00edsica est\u00e1 oculta, pero sigue ah\u00ed. La lectura de estructuras de datos Hana desde la memoria es m\u00e1s r\u00e1pida que desde el disco con la Extensi\u00f3n de Almacenamiento Nativo.<\/p>\n

La diferencia con la asignaci\u00f3n din\u00e1mica de niveles con una base de datos SAP IQ en segundo plano es a\u00fan mayor porque aqu\u00ed ya no se utilizan estructuras de datos Hana. Por tanto, la interfaz se limita a SQL.<\/p>\n

Y si el usuario accede a un sistema externo a trav\u00e9s de Smart Data Access, la respuesta s\u00f3lo puede ser tan r\u00e1pida como lo permita el sistema externo.<\/p>","protected":false},"excerpt":{"rendered":"

Reportaje: Una breve historia sobre el largo camino - computaci\u00f3n en memoria con la base de datos Hana:<\/p>\n

Cuando se introdujeron por primera vez los conceptos de Hana en SAP, pens\u00e9 que cualquier base de datos con suficiente memoria es una base de datos de computaci\u00f3n en memoria y, por tanto, r\u00e1pida. Pero al menos yo no era el \u00fanico.<\/p>","protected":false},"author":1891,"featured_media":62755,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"pmpro_default_level":"","footnotes":""},"categories":[5,36593],"tags":[65,428],"coauthors":[36006],"class_list":["post-62754","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-it-management","category-mag-1910","tag-hana","tag-olap","pmpro-has-access"],"acf":[],"featured_image_urls_v2":{"full":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"thumbnail":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-150x150.jpg",150,150,true],"medium":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",400,180,false],"medium_large":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-768x346.jpg",768,346,true],"large":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"image-100":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-100x45.jpg",100,45,true],"image-480":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-480x216.jpg",480,216,true],"image-640":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-640x288.jpg",640,288,true],"image-720":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-720x324.jpg",720,324,true],"image-960":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-960x432.jpg",960,432,true],"image-1168":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"image-1440":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"image-1920":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"1536x1536":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"2048x2048":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"trp-custom-language-flag":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",18,8,false],"bricks_large_16x9":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"bricks_large":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"bricks_large_square":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"bricks_medium":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",600,270,false],"bricks_medium_square":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",600,270,false],"profile_24":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-24x24.jpg",24,24,true],"profile_48":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-48x48.jpg",48,48,true],"profile_96":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-96x96.jpg",96,96,true],"profile_150":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-150x150.jpg",150,150,true],"profile_300":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-300x300.jpg",300,300,true]},"post_excerpt_stackable_v2":"

Reportage: Eine kurze Geschichte zum langen Weg \u2013 In-memory Computing mit der Hana-Datenbank:<\/p>\n

Als die Konzepte von Hana das erste Mal innerhalb von SAP vorgestellt wurden, dachte ich, jede Datenbank mit gen\u00fcgend Memory ist doch eine In-memory-Computing-Datenbank und entsprechend schnell. Aber wenigstens war ich nicht der Einzige.<\/p>\n","category_list_v2":"IT-Management<\/a>, MAG 19-10<\/a>","author_info_v2":{"name":"Werner D\u00e4hn, rtdi.io","url":"https:\/\/e3mag.com\/es\/author\/werner-daehn\/"},"comments_num_v2":"0 comentarios","_links":{"self":[{"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/posts\/62754","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\/1891"}],"replies":[{"embeddable":true,"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/comments?post=62754"}],"version-history":[{"count":0,"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/posts\/62754\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/media\/62755"}],"wp:attachment":[{"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/media?parent=62754"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/categories?post=62754"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/tags?post=62754"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/e3mag.com\/es\/wp-json\/wp\/v2\/coauthors?post=62754"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}