solidDB y los secretos de la velocidad

Impacto de la base de datos dentro de la memoria IBM en el alto rendimiento

Una mirada a los secretos técnicos de IBM solidDB

Antoni Wolski, Chief Researcher for solidDB product family, IBM

Antoni Wolski es chief researcher de solidDB. Con más de 20 años de experiencia en tecnología de base de datos, ha colaborado con soluciones, productos, investigación, patentes y literatura en este campo.



Sally Hartnell, IBM solidDB Product Marketing Leader, IBM

Sally Hartnell se unió a IBM a partir de la adquisición de Solid Information Technology y sigue a cargo de marketing internacional de IBM solidDB.



01-04-2010

Lo invitamos a leer este artículo en nuestro formato de edición digital interactiva

La base de datos relacional dentro de la memoria IBM solidDB se usa en todo el mundo por su capacidad de brindar una velocidad y una disponibilidad extremas. Como su nombre lo indica, una base de datos dentro de la memoria reside totalmente en la memoria principal y no en disco, haciendo del acceso a datos una orden de magnitud más rápida que con las bases de datos convencionales basadas en disco. Parte de este salto se debe al hecho de que la memoria RAM simplemente ofrece acceso a datos más rápido que las unidades de disco duro.

Pero solidDB también tiene estructuras de datos y métodos de acceso específicamente diseñados para almacenar, buscar y procesar datos en la memoria principal, superando así a las bases de datos comunes basadas en disco, aún cuando estas últimas tienen los datos totalmente guardados en caché en la memoria. Algunas bases de dato brindan latencia baja pero no pueden administrar grandes cantidades de transacciones o sesiones simultáneas. IBM solidDB suministra una capacidad de procesamiento medida en el rango de diez a miles de miles de transacciones por segundo y a su vez alcanza eficazmente tiempos de respuesta (o latencia) medidos en microsegundos. Este artículo explora las diferencias estructurales que existen entre las bases de datos dentro de la memoria y las bases de datos basadas en disco y cómo funciona solidDB para brindar velocidad extrema.

Algo de historia sobre RDBMS

Cuando surgieron los primeros sistemas de administración de datos en los años ’60, las unidades de disco eran el único lugar que existía para almacenar y acceder a grandes cantidades de datos en un tiempo razonable. Los diseñadores de RDBMS se concentraron en optimizar la E/S y trataron de alinear los patrones de acceso a datos con la estructura de bloques impuesta por las unidades de disco. La estrategia de diseño frecuentemente se centraba en un pool de buffer compartido en donde se conservaban los bloques de datos para su reutilización, en tanto que los avances logrados en los métodos de acceso produjeron soluciones como la tan conocida árbol B+ que es un índice optimizado por bloques.

Mientras tanto, las tácticas de optimización de consultas se focalizaban en minimizar lo más posible las capturas de páginas. En la dura batalla por el rendimiento, la E/S del disco a menudo era el más temido de los enemigos, y se sacrificaba la eficacia de procesamiento para evitar el acceso a disco. Por ejemplo, con típicos tamaños de página de 8 KB o 16 KB, el procesamiento dentro de la página es indefectiblemente secuencial y menos eficaz para el uso de CPU que el acceso de datos aleatorio. Sin embargo, sigue siendo una práctica muy usada para reducir el acceso a disco.

Cuando llegó la era de la memoria abundante, muchos DBA aumentaron sus pools de buffer hasta ser lo suficientemente grandes como para contener toda una base de datos creando así el concepto de una base de datos totalmente guardada en caché, pero dentro de los pools de buffer RAM, los DBMS seguían albergando todas las ineficacias estructurales de la estrategia de E/S orientada a bloques que se había creado para administrar las unidades de disco duro.


Un paso más allá de los bloques

Una de las diferencias más destacadas de un sistema de base de datos dentro de la memoria es la ausencia de grandes estructuras de bloques de datos. IBM solidDB las elimina. Las filas de tabla y los nodos de índice se almacenan independientemente en memoria, de manera que se puedan agregar datos sin reorganizar grandes estructuras de bloques. Las bases de datos dentro de la memoria también prescinden del uso de índices de grandes bloques, a veces llamados árboles tupidos, en pos de estructuras más simples en donde la cantidad de niveles de índice se aumente y se mantenga el tamaño del nodo de índice al mínimo para evitar el costoso procesamiento dentro de nodos. La estrategia más común de índice de base de datos dentro de la memoria se llama T-tree (Árbol T). IBM solidDB en cambio usa un índice llamado trie (o prefijo “tree” [árbol]) que se creó originariamente para la búsqueda de texto, pero luego resultó ser perfecto para indexación dentro de la memoria. Un trie (el nombre deriva de la palabra “retrieval” [recuperación]) está compuesto por una serie de nodos en donde los descendientes de un determinado nodo tienen el mismo prefijo de la cadena asociada a ese nodo. Por ejemplo, si la palabra "dog" (perro) se almacenó en un trie como nodo, descenderá del nodo que contenga "do" que descenderá del nodo que contenga "d".

Los índices aumentan el rendimiento al reducir la necesidad de comparar valores clave y prácticamente eliminan el procesamiento dentro de nodos. El índice contiene un nodo que es un pequeño array de punteros que señalan al nivel inferior. En lugar de usar todo el valor clave para recorrer el árbol mediante comparaciones, el valor clave se divide en varios fragmentos de unos pocos bits. Cada fragmento es un índice directo al array de punteros del nivel correspondiente: el primer fragmento del lado izquierdo apunta a los nodos del primer nivel, el segundo fragmento de los nodos al segundo nivel, etc. Así toda la búsqueda se puede efectuar con unas pocas recuperaciones de elementos array. Además, cada nodo de índice es un pequeño bloque de datos (aproximadamente 256 bytes en solidDB), lo cual es beneficioso porque los bloques se adaptan exactamente a las cachés de procesadores modernos, aumentando la eficacia del procesamiento al promover el uso eficaz de caché. Los arrays de datos pequeños como estos constituyen la estructura de datos más eficaz en los procesadores modernos y solidDB los usa frecuentemente para maximizar el rendimiento.


Puntos de control y duración: elementos que conducen a la velocidad

IBM solidDB usa varias técnicas adicionales para acelerar el procesamiento de bases de datos, comenzando con un método de punto de control patentado que produce un punto de control con copia instantánea consistente sin bloquear el procesamiento normal de transacciones. Un punto de control con copia instantánea consistente le permite a la base de datos reiniciar solamente desde un punto de control. Otros productos de bases de datos normalmente no permiten que los archivos de registro de transacciones se usen obligatoriamente para recalcular el estado de consistencia o concordancia (solidDB permite que se apague el inicio de sesión, si se lo desea). La solución solidDB existe gracias a la capacidad de asignar imágenes de filas e imágenes paralelas de filas (diferentes versiones de la misma fila) sin usar estructuras de bloque ineficaces. Sólo aquellas imágenes que coinciden con la correspondiente copia instantánea consistente se escriben en el archivo de punto de control, y las imágenes paralelas de filas permiten que las transacciones que se están ejecutando actualmente se ejecuten sin limitaciones durante la aplicación de puntos de control.

Además, el optimizador de consultas solidDB reconoce la naturaleza diferente de las tablas dentro de la memoria, estimando los costos de ejecución de una manera nueva. La optimización de consultas se focaliza en las rutas de ejecución ligadas a CPU, en tanto que una base de datos totalmente guardada en caché seguirá preocupándose por las capturas de páginas de optimización para almacenar masivamente que ya no constituyen un problema.

Otra técnica que usa IBM solidDB es la flexibilidad de la duración de transacciones. En el pasado, las bases de datos siempre soportaban duración total, garantizando que los datos escritos persistieran al momento en que se realizaba la transacción. El problema es que la duración total exige escrituras sincrónicas de registro y por lo tanto consume recursos y reduce los tiempos de respuesta. En muchas situaciones, aceptar una duración menor para algunas tareas en pos de tiempos de respuesta más rápidos es una compensación perfectamente aceptable. Con solidDB, la duración de las transacciones se puede flexibilizar en tiempo de ejecución para una determinada sesión de base de datos o incluso para una transacción individual.

IBM solidDB también aumenta el rendimiento de las bases de datos, ayudando a que los desarrolladores eviten cambios de contexto de procesos en interacciones cliente/servidor. Al usar el driver de acceso a base de datos suministrado por solidDB, el cual contiene todo el código de ejecución de consultas, el desarrollador puede vincular eficazmente la aplicación con el código DBMS y usar la memoria compartida para compartir los datos entre las aplicaciones.

Cuando se aplican todas estas medidas y la carga de aplicaciones es de un tipo que exige una E/S significativa en una base de datos tradicional, la capacidad de procesamiento mejorada que usa solidDB puede ser una orden de magnitud superior. Además, las mejoras en el tiempo de respuesta son aún más profundas: las latencias para las transacciones de consulta oscilan normalmente entre 10 y 20 microsegundos y las latencias para las transacciones de actualización son generalmente inferiores a 100 microsegundos. En una tradicional base de datos basada en disco, los tiempos correspondientes se miden habitualmente en milisegundos.


Velocidad y potencia de solidDB

Además de estas ventajas de rendimiento, solidDB también ofrece varios beneficios adicionales. Combina una base de datos totalmente transaccional en la memoria y una poderosa base de datos basada en disco en una sola solución compacta con la capacidad de alojar de manera transparente parte de la misma base de datos en memoria y parte en disco. IBM solidDB es el único producto del mercado que puede implementarse como caché de alta velocidad frente a casi cualquier otra base de datos relacional basada en disco (véase la Figura 1). Por último, solidDB ofrece disponibilidad extrema, trascendiendo el tiempo activo de los típicos cinco nueves a 99,9999%. En otras palabras, si está buscando velocidad extrema, aquí la encontrará, pero esto es tan solo el comienzo para IBM solidDB.

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Information mgmt
ArticleID=479813
ArticleTitle=solidDB y los secretos de la velocidad
publish-date=04012010