Todas las aplicaciones dependen de los datos, pero a los desarrolladores de aplicaciones no les gusta pensar en bases de datos. Aprender los aspectos internos y el lenguaje de consulta de una base de datos en particular agrega carga cognitiva y requiere un cambio de contexto que resta productividad. Aún así, las aplicaciones exitosas deben ser receptivas, resistentes y escalables, todas características que estarán determinadas por la elección de la base de datos.
Entonces, ¿cómo debería un desarrollador de aplicaciones equilibrar estas consideraciones? ¿Qué pasaría si pudiéramos cambiar el equilibrio, brindando un servicio de datos en lenguajes amigables para los desarrolladores, en lugar de esperar que los desarrolladores aprendan lenguajes específicos de la base de datos?
En el proyecto Stargate, la puerta de enlace de datos de la API de código abierto diseñada para trabajar con , estamos emocionados de comenzar a hablar públicamente sobre nuestra próxima que se adapta a los desarrolladores orientados a JSON en sus términos. Esta no solo es una gran noticia para los desarrolladores orientados a JSON, sino que la técnica que hemos seguido constituye un nuevo patrón de diseño para aprovechar las API de datos y el modelado de datos avanzado para producir servicios de datos.
En este artículo, hablaré sobre cómo proporcionar modismos amigables para los desarrolladores usando Cassandra junto con Stargate, y cómo estamos trabajando para hacer precisamente eso para JSON .
Modelos de datos: interoperabilidad frente a idioma
En los primeros días, a veces se describía a Cassandra como “una máquina para hacer índices”. Este fue un testimonio de la resistencia y flexibilidad inherentes de Cassandra, una arcilla a partir de la cual se podían moldear estructuras más robustas. Cassandra hoy es una arcilla más rica y con mayores posibilidades. No solo es una gran base de datos, sino que también es una gran máquina para crear bases de datos. Aquí en el proyecto Stargate, estamos usando la API de JSON para probar esto como el primer ejemplo de un nuevo paradigma en el desarrollo de bases de datos.
No es inusual que una base de datos se construya a partir de otra. Incluso MongoDB está construido sobre , si profundizas lo suficiente. AWS es conocido por su amplio uso de MySQL entre bastidores, incluido . Por lo tanto, la idea de usar Cassandra, con su escalabilidad y rendimiento inherentes, como componente básico para otros sistemas de datos tiene sentido.
Sin embargo, los desarrolladores de aplicaciones no interactúan realmente con las bases de datos. Incluso si su organización administra su propia infraestructura de base de datos y crea aplicaciones en esa infraestructura, el primer paso generalmente es definir e implementar los modelos de datos que requieren sus aplicaciones.
Esos modelos de datos median entre la aplicación y la base de datos. En cierto sentido, el modelado de datos limita una base de datos; toma arcilla sin forma, y por lo tanto de uso general, y la moldea en algo especialmente diseñado para un idioma de aplicación particular. Sacrificamos la interoperabilidad por algo idiomático.
¿Es una buena idea cambiar por algo idiomático y renunciar a algo interoperable? Si quiere superar los promedios, entonces la respuesta es un rotundo "sí". No pensamos mucho de esta manera cuando elegimos bases de datos, pero lo hemos pensado durante mucho tiempo al elegir lenguajes de programación.
Esta idea fue hace décadas cuando explicó cómo Viaweb ganó la carrera inicial de las puntocom para crear la primera plataforma de comercio electrónico basada en la web de gran éxito. Viaweb no era necesariamente la plataforma de comercio electrónico más rápida o escalable. En palabras de Graham, fue “razonablemente eficiente”. En cambio, Graham argumenta que, para los lenguajes de programación, en una escala de lectura mecánica a lectura humana, los lenguajes más legibles por humanos (y por lo tanto de mayor nivel) son más poderosos porque mejoran la productividad del desarrollador. Y en el momento de Viaweb, Graham pensó que el lenguaje más poderoso era . El quid del argumento de Graham es este:
“Nuestra hipótesis era que si escribíamos nuestro software en Lisp, podríamos ejecutar funciones más rápido que nuestros competidores, y también hacer cosas en nuestro software que ellos no podían hacer. Y debido a que Lisp era de un nivel tan alto, no necesitaríamos un gran equipo de desarrollo, por lo que nuestros costos serían más bajos. Si esto fuera así, podríamos ofrecer un mejor producto por menos dinero y seguir obteniendo ganancias. Terminaríamos obteniendo todos los usuarios, y nuestros competidores no obtendrían ninguno y eventualmente quebrarían”.
Desbloqueo de la productividad del desarrollador
Graham escribió esas palabras hace 20 años, y la productividad de los desarrolladores sigue siendo la estrella polar que guía gran parte de la innovación en tecnología. Cuando Graham habla sobre el poder de los lenguajes de alto nivel, expresamos el mismo concepto de proporcionar a los desarrolladores herramientas que son más idiomáticas para su experiencia de desarrollo de software.
Graham elogia a Lisp (con razón), y desde la época de las puntocom, hemos visto una proliferación de nuevos lenguajes de alto nivel: Ruby y Rust, por nombrar algunos. También hemos visto el nacimiento y la proliferación de marcos y lenguajes para desarrolladores de dispositivos móviles, como Swift, Flutter y Dart.
Entonces, ¿por qué los lenguajes como C y C++ siguen siendo importantes? El viejo chiste sobre C contiene una verdad importante: "Combinar el poder del lenguaje ensamblador con la facilidad de uso del lenguaje ensamblador". Si desea escribir un compilador, debe acercarse al idioma del lenguaje de máquina y alejarse del idioma del lenguaje natural.
En otras palabras, entre otras virtudes, C y C++ son máquinas para construir nuevos lenguajes. Lo que es fácil pasar por alto en el elogio de Graham a Lisp es que Lisp también tiene algo de esta característica de "máquina para construir lenguajes".
Lisp fue el primer lenguaje de uso generalizado en introducir el concepto de macros, y a menudo es el concepto de macros lo que hace tropezar a los nuevos en Lisp. Una vez que comprenda las macros, comprenderá que Lisp es más un metalenguaje que un lenguaje y que las macros se pueden usar para crear un lenguaje especialmente diseñado para un dominio de problema específico.
Diseñar y crear un conjunto inicial de macros es un trabajo duro e intelectualmente desafiante. Pero una vez que Graham y el equipo de Viaweb hicieron eso, de hecho tenían un lenguaje de programación de comercio electrónico con el que trabajar, y eso desbloqueó la productividad del desarrollador que les permitió superar a la competencia.
Veinte años después, todo esto parece bastante claro en el contexto de los lenguajes de programación. Entonces, ¿qué ha sucedido en el mundo de las bases de datos? La respuesta corta es que las bases de datos han evolucionado más lentamente.
La revolución de la API de datos
Si los datos tabulares son el lenguaje ensamblador del mundo de las bases de datos, entonces SQL es el C/C++ de los lenguajes de consulta. Desarrollamos estructuras de datos tabulares y el concepto de normalización de datos en una era en la que la informática y el almacenamiento eran costosos y para casos de uso que estaban bien definidos con cambios de esquema relativamente poco frecuentes. En ese contexto, para operar de manera eficiente a cualquier tipo de escala, las bases de datos necesitaban imitar de cerca la forma en que las computadoras almacenaban y accedían a la información.
El mundo de hoy es todo lo contrario, lo que hace que el tiempo anterior parezca arcaico en comparación: los costos de cómputo y almacenamiento están altamente mercantilizados, pero en un mundo de datos en tiempo real combinados con aprendizaje automático e inteligencia artificial, los casos de uso son abiertos y los cambios de esquema son frecuente.
La revolución más reciente en la tecnología de bases de datos fue la revolución NoSQL, una respuesta directa al canon de datos tabulares y normalizados establecido por los sumos sacerdotes del mundo de las bases de datos relacionales. Cuando decimos “revolución NoSQL”, nos referimos al período que va desde 2004, cuando Google publicó su , hasta 2007, cuando Amazon publicó su .
Lo que surgió de este período fue una familia de bases de datos que logró una velocidad, escalabilidad y resiliencia sin precedentes al eliminar dos principios relacionales preciados: las bases de datos NoSQL favorecieron los datos desnormalizados sobre la normalización de datos y favorecieron la consistencia final sobre la consistencia transaccional. Cassandra, lanzado por primera vez en 2008, surgió de esta revolución.
Las API de datos serán la próxima gran revolución en la tecnología de bases de datos, una revolución que recién comienza. Los cambios en el mundo de las bases de datos tienden a ir a la zaga de los cambios en los lenguajes de programación y el desarrollo de aplicaciones. Entonces, si bien las API RESTful han existido por un tiempo y han ayudado a marcar el comienzo de la arquitectura para aplicaciones orientadas a servicios distribuidos, apenas estamos comenzando a ver que las API de datos se manifiestan como una parte clave de la infraestructura de la aplicación.
Para comprender la importancia de esta revolución y cómo, 20 años después de la proclamación de Paul Graham, el mundo de las bases de datos finalmente está logrando productividad para los desarrolladores, echemos un vistazo a la propia historia de Stargate. Comienza volviendo al tema de interoperable versus idiomático.
Stargate: una experiencia de desarrollador idiomática de alta fidelidad
Cuando decidimos que el ecosistema de Cassandra necesitaba una puerta de enlace de datos, construimos el conjunto original de API de Stargate con un sentido de urgencia. Eso significaba una arquitectura monolítica; Los monolitos son más rápidos de construir, pero no siempre mejores. Lanzamos con una API Cassandra Query Language (CQL), una API REST y una API RESTful Document. Rápidamente agregamos GraphQL como una API adicional. Hasta la fecha, Stargate ha sido interoperable; Todo, desde Stargate, se almacena utilizando un modelo de datos CQL nativo, por lo que, en principio, podría consultar cualquier tabla desde cualquier API.
Hemos aprendido que en la práctica, nadie realmente hace esto. Los desarrolladores se apegan a su lenguaje particular. Al favorecer la interoperabilidad, incorporamos Cassandra-ismos en la experiencia del desarrollador, lo que impidió la productividad del desarrollador. Debido a que la versión original de Stargate requería que los desarrolladores entendieran las estructuras de datos tabulares de columna ancha de Cassandra, para entender los espacios de teclas y las particiones, nos hemos anclado demasiado cerca del idioma de la máquina y demasiado lejos del idioma humano.
La trampa de la interoperabilidad es favorecer el propósito general sobre el pensamiento de diseño integrado. Hemos pasado a pensar en términos de construcción específica, lo que cambia alguna capacidad general por un modo de expresión más específico, acercándonos al idioma humano y alejándonos del idioma de la máquina. Entonces, comenzamos a pensar: ¿podríamos ofrecer una experiencia de desarrollador idiomática de alta fidelidad mientras conservamos las virtudes de los fundamentos NoSQL de Cassandra (escala, disponibilidad y rendimiento)?
La clave está en el modelado de datos. Para convertir a Cassandra en el "Lisp de las bases de datos", necesitábamos un modelo de datos que pudiera cumplir un propósito análogo a las macros de Lisp, junto con una API de Stargate que permitiera a los desarrolladores interactuar idiomáticamente con ese modelo de datos. Comenzamos con JSON, el mayor denominador común de las estructuras de datos entre los desarrolladores de aplicaciones, y así comenzamos a construir la API de JSON para Stargate. Luego tuvimos que descubrir la mejor manera de modelar JSON en Cassandra.
Stargate ya tiene una API de documentos, pero en la API de documentos original de Stargate, usamos un modelo de datos " para representar un documento JSON como una tabla de Cassandra. Este modelo asigna un documento a varias filas en una sola tabla de Cassandra y conserva la interoperabilidad. Si usa CQL para consultar la tabla resultante, obtendrá resultados significativos.
Este modelo original de trituración de datos tiene desventajas. No conserva los metadatos sobre un documento. Por ejemplo, para cualquier documento que contenga matrices, una vez que se escribe el documento, no sabemos nada sobre el tamaño de la matriz sin inspeccionar completamente el documento. Más importante aún, nos hemos apartado de las expectativas de Cassandra sobre la indexación. Cassandra indexa en filas, pero ahora hemos distribuido nuestro documento en varias filas, lo que hace imposible un índice nativo de documentos de Cassandra.
Para hacer de Cassandra un motor de almacenamiento adecuado para JSON, íbamos a necesitar un nuevo modelo de datos, algo superior a la trituración. Lo llamamos "supertrituración". Puede obtener más información sobre la supertrituración en de Aaron Morton en diciembre, pero aquí hay un adelanto: aprovechamos la naturaleza de columna ancha de Cassandra para almacenar un documento por fila, sabiendo que una fila de Cassandra puede manejar incluso documentos muy grandes. documentos.
También tenemos un conjunto de columnas en esa fila que son explícitamente para almacenar características de metadatos estándar de un documento JSON. Ahora tenemos algo indexable más fácilmente, así como un medio para conservar y recuperar metadatos.
Contribuyendo a Cassandra
Sí, para que todo esto funcione a escala, necesitaremos algunos cambios subyacentes en Cassandra. Accord, que Apple está contribuyendo a Cassandra 5, nos ayudará a manejar los cambios de datos de una manera más transaccional. La indexación adjunta al almacenamiento (SAI) y la clasificación global, que , nos ayudarán a manejar las consultas de rango en documentos JSON de una manera más eficiente.
Cassandra no es una pieza estática de software; es un proyecto de código abierto vibrante y en evolución. Por lo tanto, también continuamos con la larga tradición de Cassandra de usar requisitos que surgen del lado del cliente para fomentar cambios en el lado de la base de datos. Las necesidades de los usuarios han impulsado las propuestas de Accord, SAI y Global Sort. Esto no solo mejorará la API JSON de Stargate, sino que también mejorará a Cassandra. Este es un gran recordatorio de que los ingenieros de datos y los desarrolladores de aplicaciones no son dos comunidades diferentes, sino cohortes complementarias de la comunidad extendida de Cassandra.
Y JSON es solo el primer paso. Esencialmente, habremos creado una base de datos de documentos con la que interactúa a través de una API JSON a partir de Cassandra, Stargate y un modelo de datos de Cassandra razonablemente eficiente. Super trituración es nuestra macro. Este enfoque convierte a Cassandra en una máquina para crear bases de datos.
¿Podría este enfoque ser seguido por otra base de datos además de Cassandra? No es fácil, y he aquí por qué. Hay una especie de base de datos análoga a la segunda ley de la termodinámica que funciona a favor de Cassandra. Comenzamos con algo que es rápido, escalable y resistente, pero no muy idiomático para los desarrolladores. Dentro de las limitaciones de una eficiencia razonable, cambiamos parte de esa velocidad, escala y resiliencia por una interfaz más idiomática para presentar a los desarrolladores. Lo que no se puede hacer fácilmente es ir en la dirección contraria. Comenzar con algo que es muy idiomático y luego tratar de descubrir cómo hacerlo rápido, escalable y resistente es una tarea abrumadora que quizás ni siquiera sea posible.
Ese principio termodinámico es la razón por la que las API de datos son la nueva revolución de las bases de datos y por la que Cassandra es la base de datos que impulsará esta revolución.
También publicado
