Bases de datos en memoria: Oracle TimesTen vs. Sybase ASE

Esta es la primera entrega de una serie de dos partes en la que se comparan las tecnologías de bases de datos en memoria de Oracle TimesTen y de Sybase Adaptive Server Enterprise (ASE). Esta parte examina en profundidad TimesTen. La segunda parte analiza cómo esSybase ASE en comparación con TimesTen.

Una base de datos en memoria, o IMDB, puede ser un sistema de gestión de bases de datos independiente (DBMS) como Oracle TimesTen, o una base de datos específica que forma parte de un DBMS, como es el caso de Sybase Adaptive Server Enterprise (ASE).

El objetivo de una IMDB es maximizar el rendimiento y minimizar la latencia, apoyándose en la memoria del ordenador para almacenar datos. Esto es así, a diferencia de los sistemas tradicionales de gestión de bases de datos que dependen del almacenamiento en disco. Las bases de datos en memoria son más rápidas que las que funcionan optimizadas desde disco, dado que los algoritmos internos de optimización son más simples y ejecutan menos instrucciones de CPU. El acceso a los datos en la memoria posibilita una respuesta más rápida. En aplicaciones en las cuales el tiempo de respuesta resulta crítico, como es el caso de ciertos sistemas de comercialización, telecomunicaciones y defensa, las IMDB son de uso frecuente. Debido a la naturaleza de las IMDB, estas bases de datos tienden a utilizar más memoria que sus homólogas residentes en discos.

Oracle TimesTen y Sybase ASE IMDB son ejemplos de bases de datos fuera del proceso en memoria principal. Implementan SQL completo, probablemente con algunos dialectos, seguridad y gestión de base de datos. Ambos proveen acceso a los datos a través de SQL. Emulan la funcionalidad de sus hermanas mayores residentes en disco. Eso hace que sea más fácil usar estos productos para el almacenamiento en caché de peticiones SQL a un back-end de SQL que mantiene bases de datos persistentes.

TimesTen, ASE IMDB y casi todas las IMDB comerciales actuales se basan en lo que llamo una implementación de almacenamiento del modelo relacional basada en filas. Estos productos son eficaces para las aplicaciones de procesamiento de transacciones en línea (OLTP).

¿Qué es la base de datos en memoria Oracle TimesTen?

Oracle TimesTen fue diseñada desde el principio como una base de datos en memoria. Almacena datos utilizando el modelo relacional basado en filas (tablas, columnas, tipos de datos, índices, etc.), y utiliza SQL como lenguaje de acceso. Proporciona muchas API y soporta ampliamente Oracle PL/SQL. Las aplicaciones trabajan en ella de la misma manera en la que lo harían sobre cualquier base de datos relacional. La diferencia principal es que el rendimiento ofrecido por TimesTen es mucho mejor en comparación con una base de datos clásica. Aunque TimesTen opera completamente en la memoria, conservará una copia de la base de datos en el disco, solamente con fines de reinicio y recuperación. Esta copia se mantiene actualizada a través de puntos de control y registro de transacciones, lo que permite la recuperación después de una falla. TimesTen también tiene un mecanismo de replicación que se utiliza generalmente para la alta disponibilidad. Su funcionalidad de Conexión Caché le permite actuar como una memoria caché de alto rendimiento para un subconjunto de datos en una base de datos back-end de Oracle. Cuando se utiliza de esta manera es conocida como la opción de Caché de Base de Datos en Memoria para las bases de datos Oracle.

En el modo cliente/servidor, la biblioteca de Clientes API suele utilizar TCP/IP (pero también puede utilizar un socket de dominio UNIX o una conexión local de memoria compartida) para intercambiar solicitudes y respuestas con un proceso de servidor TimesTen que realiza la conexión real a la base de datos. Este es el modo frecuentemente utilizado cuando la aplicación se ejecuta en un host diferente al de la base de datos TimesTen. Además de latencia generada por la ida y vuelta en la red, el código adicional, los cambios de contexto, etc. que se involucran en cada acceso a la base de datos y también generan un impacto sobre el rendimiento.

El modo directo solo se puede utilizar cuando la aplicación y TimesTen se ejecutan en el mismo host. En este modo, la biblioteca de gestión de datos API es también en esencia el motor de la base de datos TimesTen. Las llamadas API son llamadas de funciones de proceso, y la base de datos TimesTen (segmento de memoria compartida) será asignada al espacio de direcciones de la aplicación. Esto elimina los cambios de contextos de las rutas de acceso de la base de datos y ofrece el rendimiento más alto y una menor latencia con resultados consistentes.

Es común disponer de un acceso mixto en el cual una base de datos TimesTen es al mismo tiempo accedida en modo directo y de cliente/servidor, por parte de diferentes procesos/hilos de la aplicación. Una sola base de datos puede manejar hasta 2000 conexiones de usuarios. Cuando TimesTen tiene una instancia (al gestionar múltiples bases de datos TimesTen), entonces por lo general hay un límite de 25 000 conexiones de usuarios.

Hay una diferencia funcional escasa o nula a nivel de API entre los dos modos, por lo que en general el código de aplicación no tiene por qué saber ni tampoco le importa el modo en que se está utilizando –es ante todo una opción de configuración en el momento de construcción o ejecución–.

El modo directo es una de las funcionalidades únicas de TimesTen. La mayor parte de los despliegues de producción TimesTen ha sido por lo general únicamente o en gran parte en modo directo. Sin embargo hay escenarios en los que también se ha utilizado el modo cliente/servidor.

Una caché TimesTen es transparente ya que se pueden visualizar los datos almacenados en caché utilizando cualquier herramienta relacional. Si la aplicación tiene una visión de sus datos centrada en la base de datos –es decir que accede a sus datos utilizando SQL y JDBC– entonces TimesTen puede ser la mejor opción. Sin embargo, TimesTen no tiene incorporada ninguna interoperabilidad con bases de datos que no sean Oracle, por lo que el código de la aplicación tendría que gestionar cualquier movimiento de datos entre TimesTen y Sybase u otros.

Estructura de memoria de TimesTen

Las construcciones de memoria de TimesTen son mucho más simples que las de la base de datos Oracle. A diferencia de Oracle, TimesTen no tiene los conceptos de base de datos de caché de búfer, pileta de contención o pileta de reciclaje. Los sistemas convencionales de bases de datos se han diseñado utilizando una estrategia de minimización del I/O del disco (lectura/escritura). Esta estrategia de diseño se debe al reconocimiento del I/O como un factor muy importante en el rendimiento de las bases de datos. A diferencia de ello, los sistemas de base de datos en memoria eliminan el I/O del disco desde el principio. Su objetivo primordial de optimización es la reducción de las demandas de memoria y CPU.

TimesTen actualmente soporta dos tipos de indexados: los índices de hash y los índices de Árbol T. Los índices de hash se limitan a búsquedas de claves únicas con plena igualdad, pero para ello son muy rápidos, y las llevan a cabo independientemente de la cardinalidad de la tabla subyacente (siempre y cuando sean del tamaño correcto e ignorando los efectos de caché L1/L2/L3 en el hardware para las tablas pequeñas). Estos índices escalan bien para lecturas y escrituras y ofrecen una buena simultaneidad. Los índices de Árbol T también son buenos para las lecturas, pero no tanto como los índices de hash. Son más flexibles dado que son compatibles con las búsquedas de rango. Pero una de las áreas en las que resultan un tanto débiles es en la concurrencia con pesadas cargas de trabajo de escritura, ya que cada modificación del índice tiene que enclavar el índice completo. Sin embargo, el rendimiento de escritura de los Árboles T resulta muy bueno en condiciones bajas de concurrencia.

Aplicación de TimesTen

TimesTen trata principalmente de los tiempos de respuesta, con el rendimiento y la alta disponibilidad como valores secundarios. Típicamente TimesTen ofrece un valor alto para cargas de trabajo de estilo OLTP, en las que hay una necesidad muy baja y consistente en los tiempos de respuesta. También es importante la redundancia. Normalmente usted tendrá diversos servidores de aplicaciones para un único servidor de base de datos. El uso de TimesTen en estos servidores de aplicaciones reduce la necesidad de ir a la base de datos, eliminando de este modo la latencia de la red y la I/O del disco.

Por ejemplo, algunos sistemas de comercio proporcionan información sobre tarifas en una web. Sin el uso de TimesTen, el servidor de aplicaciones tendría que comprobar la base de datos residente en el disco cada vez que ingresa una consulta de tarifas. Con un máximo de 100 000 consultas por segundo, terminaría por paralizar la base de datos. TimesTen está diseñada para trabajar cercana a la capa de aplicación, mientras que un DBMS clásico tiene un propósito mucho más amplio. Para respuestas en tiempo real y volúmenes moderados, hay una abrumadora ventaja en el uso de TimesTen frente a cualquier DBMS clásico. 

En áreas como el comercio de programas y datos del mercado, en las cuales los datos subyacentes cambian con rapidez, TimesTen será muy práctico, ya que los datos son en tiempo real y los cálculos deben hacerse casi en tiempo real, con pocas complicaciones desde el motor de ejecución. Otras áreas de interés son las telecomunicaciones, la defensa y la inteligencia.

Mich Talebzadeh es un consultor y arquitecto técnico que ha trabajado con sistemas de gestión de bases de datos desde sus días de estudiante en el Imperial College, Universidad de Londres, donde obtuvo su doctorado en Física Experimental de Partículas. Se especializa en el uso estratégico de Oracle y Sybase y es autor de varios libros y artículos sobre bases de datos.