{"id":61200,"date":"2015-12-03T11:10:37","date_gmt":"2015-12-03T10:10:37","guid":{"rendered":"http:\/\/e3mag.com\/?p=61200"},"modified":"2019-07-18T09:21:46","modified_gmt":"2019-07-18T07:21:46","slug":"in-memory-is-not-enough","status":"publish","type":"post","link":"https:\/\/e3mag.com\/es\/in-memory-ist-nicht-genug\/","title":{"rendered":"En memoria no es suficiente"},"content":{"rendered":"

Incluso SAP se ha dado cuenta ahora de que la idea original de mantener todos los datos permanentemente en la memoria, que parec\u00eda tan ingeniosamente sencilla, es en parte inviable y en parte insuficiente.<\/p>\n

No es viable, por ejemplo, si una base de datos contiene una gran cantidad de datos hist\u00f3ricos, cuya carga en memoria provocar\u00eda una explosi\u00f3n del coste de la memoria necesaria.<\/p>\n

Adem\u00e1s, no basta con mantener los datos permanentemente en la memoria, ya que toda base de datos debe garantizar la persistencia de los datos almacenados en ella.<\/p>\n

Por lo tanto, es necesario utilizar medios de almacenamiento persistentes y tiene sentido pensar en c\u00f3mo utilizar este almacenamiento de la forma m\u00e1s eficiente posible. En la base de datos Oracle, existen desde hace muchas versiones dos tecnolog\u00edas que sirven para este uso eficiente:<\/p>\n

Particionamiento y compresi\u00f3n. Y hay dos tecnolog\u00edas porque la palabra \"eficiente\" puede tener dos significados distintos.<\/p>\n

Lo que va junto: Partici\u00f3n<\/h3>\n

\"Uso eficiente del espacio de memoria\" - esto puede significar inicialmente: los datos deben almacenarse de tal forma que tengan que producirse el menor n\u00famero posible de procesos de E\/S al acceder a informaci\u00f3n que a\u00fan no est\u00e1 en la memoria.<\/p>\n

\"Optimizaci\u00f3n del almacenamiento de datos\" significa entonces que los datos no se almacenan en orden aleatorio (como se hace por defecto), sino teniendo en cuenta qu\u00e9 grupos de datos volver\u00e1n a necesitarse juntos m\u00e1s adelante.<\/p>\n

Particionar una tabla significa dividirla en tales subgrupos. Una partici\u00f3n contiene, por ejemplo, todos los datos que se han insertado en un mes determinado o que est\u00e1n asignados a una rama determinada.<\/p>\n

Para los clientes de SAP-on-Oracle, el particionamiento est\u00e1 activado por defecto para SAP BW, por lo que se benefician de \u00e9l inmediatamente. Sin embargo, Oracle Partitioning est\u00e1 liberado y soportado para todas las aplicaciones SAP NetWeaver. Por tanto, tambi\u00e9n puede utilizarse en sistemas que no sean BW. El motor de particionamiento de SAP, por ejemplo, est\u00e1 entonces disponible para su implementaci\u00f3n.<\/p>\n

Compresi\u00f3n<\/h3>\n

Pero \"uso eficiente del espacio de almacenamiento\" tambi\u00e9n puede significar: los datos deben almacenarse de forma que ocupen el menor espacio posible y se pueda frenar el crecimiento gigantesco de las bases de datos.<\/p>\n

Considerado a lo largo de varias versiones del software de base de datos, esto significa que la eficiencia del almacenamiento de datos debe aumentar permanentemente para que el mismo stock de datos requiera cada vez menos espacio de almacenamiento de una versi\u00f3n a otra.<\/p>\n

Y un requisito adicional es que todo esto ocurra sin que el cliente tenga que pagar el precio de una degradaci\u00f3n del rendimiento.<\/p>\n

Oracle Database 11g ya se basaba en el concepto de no escribir valores que aparecen m\u00e1s de una vez. Esto se aplica tanto a tablas como a \u00edndices. La tasa de compresi\u00f3n que puede alcanzarse depende de las caracter\u00edsticas de los datos y de la aplicaci\u00f3n.<\/p>\n

Normalmente, los datos de SAP BW (BI) pueden comprimirse m\u00e1s que los de SAP ERP (ECC), y SAP CRM permite un ahorro a\u00fan mayor. Por t\u00e9rmino medio, una base de datos totalmente comprimida con Oracle Database 11g requiere un 55% menos de espacio de almacenamiento en el entorno SAP que la correspondiente base de datos sin comprimir.<\/p>\n

Depende de la temperatura<\/h3>\n

Una pregunta frecuente es: \u00bfpor qu\u00e9 no se ha normalizado el almacenamiento comprimido de datos?<\/p>\n

Parte de la respuesta se obtiene observando las tablas de SAP BW que se utilizan para cargar nuevos datos. A uno le gustar\u00eda comprimir esas tablas, pero eso retrasar\u00eda considerablemente el proceso de carga.<\/p>\n

Aqu\u00ed es donde entra en juego Oracle Database 12c, con la introducci\u00f3n de un nuevo par\u00e1metro. En la versi\u00f3n 11g, el usuario puede responder a la pregunta con respecto a cada tabla e \u00edndice si este objeto debe comprimirse.<\/p>\n

Las respuestas posibles son \"S\u00ed\" o \"No\". En la versi\u00f3n 12c, tambi\u00e9n se pregunta cu\u00e1ndo deben comprimirse los datos nuevos o modificados. Ahora son posibles respuestas del tipo: \"S\u00ed, pero s\u00f3lo dentro de una semana\".<\/p>\n

S\u00f3lo con este nuevo par\u00e1metro pueden incluirse en la compresi\u00f3n las tablas necesarias para cargar los datos: Primero se cargan los datos sin comprimir (no se ampl\u00eda el tiempo de ejecuci\u00f3n), que s\u00f3lo se comprimen despu\u00e9s, es decir, en un momento adecuado (compresi\u00f3n diferida).<\/p>\n

Esta soluci\u00f3n se ha dise\u00f1ado de forma tan general en Oracle Database 12c que puede utilizarse para implantar una gesti\u00f3n completa del ciclo de vida de la informaci\u00f3n (ILM). Se basa en dos nuevas caracter\u00edsticas:<\/p>\n