La infraestructura de bases de datos debe ser compatible con las aplicaciones modernas

Una leyenda de base de datos volverá a la mesa de dibujo para diseñar nuevas formas de soportar las modernas aplicaciones de escalabilidad horizontal.

Jim Starkey se graduó de la universidad al diseñar un computador de datos para ARPANET, diseñó algunas de las primeras bases de datos relacionales en Digital Equipment Corp. y desarrolló el motor de almacenamiento de base de datos de Falcon para MySQL.

En una entrevista con nuestra publicación hermana, SearchDataCenter, Starkey explicó por qué las bases de datos transaccionales tradicionales y los nuevos diseños NoSQL no están a la altura de soportar aplicaciones modernas –y cómo su nueva empresa, NuoDB, tiene como objetivo cambiar la infraestructura de base de datos.

¿Cómo están cambiando las aplicaciones? ¿Qué hace que un nuevo tipo de base de datos sea necesaria?

Jim Starkey: El problema con las aplicaciones es que –especialmente con las aplicaciones móviles– los desarrolladores tienen el problema de pasar de dos o tres docenas de sujetos de prueba a liberar la app y de repente enfrentar la posibilidad de que, la siguiente semana, podrían tener 10 millones de usuarios. Ser capaz de hacer frente a la escalabilidad es bastante complicado. Mientras que usted pueda escalar hasta lo que puede manejar un sistema de base de datos existente diseñado para ejecutarse en una sola máquina, estará bien. Pero una vez que pasa ese punto, el sistema de base de datos no le ayudará mucho. El problema de escalabilidad entonces regresa a los desarrolladores de aplicaciones, y eso no es algo que ellos hagan muy bien. Y cuando de repente se dan cuenta de que tienen un problema de rendimiento –o, en realidad, un problema de escalabilidad– viene en un mal momento. De repente, ellos tienen una barrera artificial para llegar a todos los clientes que les fueron tan difíciles de adquirir.

Lo que hemos intentado hacer con NuoDB es construir un sistema de base de datos relacional que es completamente familiar, compatible con estándares, utilizando una interfaz estándar alrededor de la cual alguien puede construir una aplicación, liberarla y obtener una mayor capacidad mediante la conexión de varios equipos. Los desarrolladores de aplicaciones no tienen que preocuparse por el problema de escalabilidad; ellos no tienen que volver y redefinir la app para que pueda particionarse o cambiar el lugar de la inteligencia mediante el sharding (partición horizontal de datos en una base de datos o motor de búsqueda). Ellos sólo pueden concentrarse en las cosas que son importantes para su éxito en los negocios, y la base de datos se hará cargo de sí misma.

También hay bases de datos NoSQL. ¿Qué hace que sean inadecuadas?

Starkey: Cuando nos fijamos en la combinación de un programa de aplicación y un sistema de base de datos, la pregunta es, ‘¿Dónde se ubica la inteligencia?’ ¿Está en el programa de aplicación o en el sistema de base de datos? ¿Deja que la base de datos se preocupe por dónde están las cosas, y qué índices existen y lo que todo el mundo quiere, y usted solamente recupera lo que necesita? ¿O tiene que construir todo eso en su aplicación?

Jim Starkey

Los sistemas típicos de bases de datos son sistemas de alto nivel: Si le asigna una consulta SQL, encontrará la manera de hacerlo y le devolverá los resultados, y gestionará la interacción con otros usuarios en el sistema, de modo que usted no tenga que preocuparse por ello. Las bases de datos NoSQL son muy tontas. Son un almacén de valores clave, donde, en esencia, usted tiene una clave principal, si le da la clave principal obtendrá un gran objeto binario, o blob –y su trabajo será averiguar qué es ese blob, en lugar de que lo haga la base de datos. La base de datos no puede hacer mucho por usted. Es una muy buena solución para una app de carrito de compras, [pero] no es una solución muy buena para otras cosas.

¿De qué manera el enfoque de NuoDB para las aplicaciones modernas difiere de las bases de datos tradicionales?

Starkey: Como solución estándar SQL, la manera en que se crea una aplicación no es significativamente diferente de la forma de construir un sistema frente a otros sistemas de gestión de bases de datos relacionales. La diferencia es que escala. Si está ejecutando Oracle en una sola máquina, y alcanza la capacidad de una máquina de SQL, puede cambiar a Oracle RAC, y ello le dará un poco más de rendimiento. Pero cuando eso se agota, es todo. Con NuoDB, se puede tomar un diseño de aplicaciones de base de datos intuitiva, y en lugar de cambiar la aplicación para manejar más escalabilidad, sólo tiene que conectar más computadores.

¿Cómo se maneja la coherencia en ese modelo?

Starkey: La forma en que el MVCC [control de concurrencia multiversión] funciona es que cuando la base de datos almacena un registro, se pone un número de transacción en ese disco. Si alguien modifica el registro, se mantiene el antiguo registro existente [y] almacena un registro nuevo en el mismo lugar, con una nueva ID de transacción que apunta a la antigua. Cuando se inicia una transacción, se realiza un seguimiento del estado de todas las otras transacciones que suceden al mismo tiempo, así que cuando nos fijamos en un registro, se puede decir si ese registro se cometió cuando empezó. Si no se cometió al inicio, entonces irá a una versión anterior y aplicará la prueba hasta que encuentre una versión del registro que sea consistente con el inicio. No mantiene el bloqueo de registro en absoluto. Los lectores no bloquean los escritores; los escritores no bloquean los lectores.

Entonces, ¿cómo NuoDB utiliza MVCC de una nueva forma?

Starkey: La diferencia entre NuoDB y todos los otros sistemas de bases de datos relacionales es que todos los otros sistemas de bases de datos se basan en las páginas de disco y los archivos de disco. NuoDB no. El motor de SQL se acomoda en lo que llamamos átomos, que son objetos distribuidos, y puede haber muchos casos de un átomo dentro de un grupo. Todos ellos se conocen entre sí y todos ellos se responden entre sí –son objetos distribuidos. Dentro del objeto de datos están los registros, y se realiza un seguimiento de las versiones antiguas y las nuevas versiones. Cuando se accede a un átomo a través de una transacción, éste se da cuenta de qué versión era la actual cuando se inició, y cuál es la que se ve.

Lo que es realmente interesante de esto es que en los sistemas de bases de datos que están diseñados alrededor de los archivos del disco, el archivo de disco sólo existe en un solo lugar. Cuando se realiza un cambio en un solo lugar, no se aplica automáticamente a cualquier otro sitio. Pero con los objetos distribuidos, cada objeto es coherente y saben acerca de la replicación de otros objetos.

Cuando se conecta un nuevo nodo a un clúster NuoDB, se hace un cripto-apretón de manos con alguien más y dice: ‘Aquí está el catálogo maestro, empiece por ahí.’ Dentro del catálogo, todo el mundo conoce cada átomo, quién lo tiene y dónde encontrar una copia del mismo. Todo el mundo hace un ping entre sí de vez en cuando, y saben quién responde. No importa si la máquina está sobrecargada y es lenta, o si está al otro extremo del mundo, sólo se sabe que se necesita más tiempo para obtener un ping de regreso. Por lo tanto, cuando un nodo necesita tener acceso a un átomo, sabe quiénes lo tienen [y] elige al que responda mejor –que probablemente sea otro nodo en el mismo rack– y dice: ‘Dame una copia de este; a todos los demás, ya lo tengo.’ Es una idea bastante simple, pero funciona como un encanto.

Sobre el autor: Beth Pariseau es redactor de noticias senior para los grupos de Centros de Datos y Virtualización de TechTarget.