Innovador de SQL viaja al futuro de las bases de datos

Una leyenda de las bases de datos, autor de aspectos centrales de la base de datos relacional tradicional, ahora está mirando hacia el futuro de las bases de datos, más allá de SQL, para mejorar la forma en que las bases de datos obtienen datos para los sitios web.

Jim Starkey fundó recientemente una startup, con la cual afirma haber resuelto el espinoso problema de funcionamiento de una base de datos distribuida bajo una interfaz transaccional familiar. Ahora, él tiene otro proyecto, denominado Amorphous, que se ejecuta en un tipo único de laboratorio casero.

SearchDataCenter, publicación hermana de SearchDataCenter en Español, se reunió con Starkey para preguntar acerca de esta última frontera en la tecnología de base de datos, cómo podría cambiar el desarrollo de aplicaciones Web y qué tiene que ver con Edward Snowden.

¿Hay nuevos proyectos de bases de datos en los que está trabajando?

Jim Starkey: Estoy haciendo un proyecto privado, donde voy al extremo opuesto. Lo que estoy viendo es algo que se adapta incluso a un grado mayor que NuoDB [la startup de Starkey], pero no utiliza el modelo de datos SQL –aun así, todavía le da el control de concurrencia ACID sobre una gran cantidad de datos no estándares, por lo que puede manejar documentos igual de bien de lo que maneja una tabla. Y creo que esa es la dirección en la que el mundo tiene que ir.

¿Qué problema está tratando de resolver allí?

Starkey: Está empujando lo que considero la vanguardia en por lo menos tres dimensiones diferentes. Una de ellas es que no es relacional –no tiene tablas; sólo tiene registros. Cada registro se auto-describe, por lo que se pueden verter datos en él, y aun así será capaz de hacer consultas y actualizaciones regulares transaccionales.

Dos, no es un lenguaje SQL en absoluto. Tomemos, por ejemplo, una página web de Amazon. Si eso se hiciera sobre una base de datos SQL, casi todos los enlaces requerirían varias consultas SQL –es probable que hablemos de cuatro o cinco docenas de consultas SQL por página. Incluso suponiendo que el sistema de base de datos puede responder a todas las consultas en tiempo cero, la cantidad de latencia entre la máquina virtual que está generando la página través de la red y el servidor de base de datos y de regreso, tomaría cuatro o cinco docenas de consultas, haciéndolo completamente insostenible.

El lenguaje de acceso y la API [están] diseñados de tal manera que se podría conseguir un conjunto arbitrario de datos –todo lo necesario para generar esa página en una ida y vuelta al servidor de base de datos. Usted obtendrá una jerarquía de resultados, todo en un solo trozo, lo que tendría un efecto enorme en cómo se diseñan los sitios web. En este momento, usted tiene una gran cantidad de almacenamiento en caché localmente, lo que es ineficiente.

La tercera dimensión es difícil –esta es la parte más difícil de la misma. NuoDB tiene dos tipos de nodos de computación: motores de transacción, que bombean transacciones SQL; y nodos de almacenamiento, que almacenan copias persistentes de átomos. Como todos los motores transaccionales tendrán un montón de átomos en la memoria para replicar a todos aquellos que quieran una copia, si necesitan un átomo para ejecutar una transacción, van a tratar de encontrar un nodo que lo tenga en la memoria. Si ellos no lo tienen en la memoria, continuarán y pedirán al gestor de almacenamiento para extraerlo de su disco. Este modelo implica básicamente poner los datos en la transacción.

Jim Starkey

Para el tipo de datos para los que NuoDB está diseñado, funciona muy bien. Cuando vaya más allá de SQL y diga, ‘Vamos a poner documentos de Word, hojas de cálculo, cualquier tipo de datos que se puedan imaginar –todo va a ser indexado, con la semántica del tipo de motor de búsqueda, pero todo transaccional.’ Ahora está hablando de potenciales petabytes y exabytes de datos, y la idea de llevar todo a un sitio para ejecutar una transacción simplemente no es suficiente.

Por lo tanto, lo que Amorphous tiene que hacer es llevar un registro de todos los datos, y en lugar de solicitar que ese nodo envíe [datos], dirá: ‘Aquí hay parte de una exposición más grande; hagan lo que puedan, envíenlo al siguiente chico y luego regrésenmelo.’ Es un problema muy difícil, y yo estoy en el medio, en donde tengo cosas funcionando, pero ese es el problema que estoy abordando.

¿Dónde están trabajando en esto –en  un laboratorio casero?

Starkey: Aquí está lo interesante: Yo decidí que no podía realmente sufragar la compra de otro estante lleno de servidores de caja de pizza en mis instalaciones... por lo que el entorno de desarrollo es Raspberry Pis. Es muy lindo. No hay refrigeración, no hay ventiladores, no se necesita nada, más que los cables hacia las fuentes de alimentación y ya estamos en el negocio. [Se ríe.]

Entonces, ¿cómo llevan las transacciones a los datos?

Starkey: Esa es una pregunta muy complicada. Ese fue el primer problema que tenía que resolver. Me avergüenza un poco decir que cuando salió la noticia sobre [Edward] Snowden, y él empezó a dar cuenta de todo lo que la [Agencia Nacional de Seguridad] estaba recopilando, mi primera reacción fue: ‘Eso es una cantidad infinita de datos, ¿cómo pueden dar sentido a tantos datos?’ Cavilé sobre ese problema por un tiempo, y luego pensé, ‘Oh, así es cómo se hace.’ De ahí viene Amorphous. Básicamente, uno tiene que exportar el entorno de transacciones con la consulta, de forma que otra persona puede conocer las reglas que se aplicarían si se ejecuta localmente. Se exporta una parte seleccionada muy cuidadosamente del estado de la transacción a los otros nodos, sobre cómo interpretar los datos en esta máquina en el contexto de una transacción que se ejecuta en otro nodo. Algún día, espero incluir esta tecnología en NuoDB –pero primero espero que funcione.

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