Cuando los Mundos Chocan: Frontend vs Base de Datos

Excelente, muchas gracias por unirse hoy. Mi nombre es Tyler Hannon, y me encargo de community, soporte y éxito del cliente en Fauna. Mi experiencia está en sistemas distribuidos y bases de datos, por lo que un evento como JS Nation no es donde me siento más cómodo, pero de manera similar, mi experiencia es quizás donde tú no te sientes más cómodo. Y por eso titulé esta charla Cuando los Mundos Chocan.

Estamos en un cambio sociológico en el mundo Fullstack, donde un servidor web estaba adyacente a la database, a este nuevo mundo con clientes y APIs globales, donde la latencia y la consistencia en el borde son críticas. Pero desafortunadamente, todos estamos siendo bombardeados con publicidad. Así que cuando piensas en tu aplicación, la realidad es que solo queremos almacenar data en algún lugar, y queremos leer data de algún lugar. Y te garantizo que ya sea en un diagrama propio o en algún lugar dentro de la empresa para la que trabajas, hay una imagen de clip art que parece de los años 80 que representa una database con las notas, inserta el logo aquí. Y de eso quiero hablar hoy. ¿Qué es importante considerar al elegir qué logo insertar en ese diagrama de database?

Sabemos que la database a menudo es un cuello de botella, y al igual que muchos proveedores de database hablan ahora, también sabemos que las transacciones distribuidas son la solución, pero ¿distribuido, qué incluso es eso? ¿Y qué es esta cosa, ACID, de la que los proveedores de database siguen hablando? No está relacionado con lo que puedes encontrar aquí en la ciudad de la que soy, Ámsterdam. Es algo completamente diferente. De hecho, es un acrónimo y los acrónimos son extraños. Así que pensé que tomaría un poco de tiempo para explicar este acrónimo ACID contigo. Así que el primero es A, atómico o atomicidad. Básicamente, lo que está diciendo es que todos los cambios en los data se realizan como si fueran una sola operación. Es decir, todo sucede o no sucede. El ejemplo canónico para este tipo de flujo de trabajo son los servicios financieros. Si estoy debitando una cuenta esa operación de débito debe realizarse con éxito y la operación de crédito debe realizarse con éxito pero eso son muchas palabras. Así que me gusta pensar en la propiedad atómica como todo o nada. Hay C para consistente. Los data están en un estado consistente cuando comienza la transacción y cuando termina la transacción. Nuevamente, para usar nuestro ejemplo canónico, esto sería en una aplicación que transfiere fondos de un lugar a otro. Esta propiedad asegura que el valor total combinado esté en el mismo estado tanto antes como después de la transacción. Es válido antes, es válido después. I es para aislamiento, en el que el estado intermedio de una transacción es invisible para otros. Básicamente, las cosas suceden una a la vez o en paralelo, pero independientemente, el resultado es el mismo, y D es duradero, o durabilidad. Cuando la transacción está completa, los cambios se persisten y no se deshacen. Esto es probablemente lo que te resulta más familiar. Una vez que está completo, sobrevive a las interrupciones. Ahora, hay una amplia variedad de proveedores de database que hablan sobre transacciones distribuidas.

Hay muchos enfoques para resolver esto. Está el enfoque de Mongo y el enfoque de Dynamo, y lo que Firebase menciona, y lo que Cassandra menciona. También hablamos de esto en FAUNA. Nuestro enfoque, por lo que vale, se basa en una transacción distribuida y un protocolo de replicación de datos llamado CALVIN. Este es el título del artículo. CALVIN Fast Distributed Transactions for Partitioned Database Systems. Si tienes interés, te animo a que lo leas. Porque en última instancia, comprender cómo se cumplen tus requisitos es importante para asegurarte de que se cumplan por completo.

En resumen, es una transacción de varios documentos, y se ve un poco así. He construido una aplicación impresionante y atractiva en algún sabor de JavaScript utilizando los marcos y herramientas en los que confío, ya sea React, Next o cualquier otro. Mi aplicación tiene un fragmento de datos, y mi pequeño ayudante amigable en mi aplicación va a la base de datos y dice: `oye, aquí están los datos`. Y esos datos se registran en el registro de transacciones. Ese registro de transacciones se replica en otro sitio a nivel global. La replicación se confirma. Hay una serie de comprobaciones, cálculos y cosas confusas que entran en juego. Y luego se escriben los datos. A medida que esos datos se replican globalmente, porque están en el registro de transacciones, se devuelven a la aplicación como completos. Esto también permite algunas capacidades realmente geniales en cuanto a temporalidad, saber qué sucedió en qué momento. Y nos permite llegar a una variedad de proveedores de servicios en la nube en diversas regiones del mundo, algunas de las cuales están disponibles hoy y otras que estarán disponibles en el futuro.

Pero tu viaje apenas comienza. Te animo a que veas el CMU Database Group YouTube si te interesa cómo funcionan este tipo de cosas. A mirar jepson.io y las increíbles charlas que ha realizado Kyle Kingsbury y el trabajo que ha hecho en la mejora de las bases de datos distribuidas y en hacer que nuestra industria sea mejor. Pero en resumen, solo quieres guardar tus datos en algún lugar. Solo quieres leer lo que escribiste. Solo quieres que sea rápido en todas partes. Has descrito un sistema distribuido geográficamente redundante. Y como no quieres ser un operador, has descrito una base de datos diseñada para ser sin servidor. Solo quieres que funcione. Queremos que lo pruebes. Es gratis, hay un nivel gratuito. Es genial. También no dudes en contactarme. Estoy en Tyler Hannon. También nos puedes encontrar en fauna. Te estoy haciendo marketing. Siempre te están haciendo marketing. Ten en cuenta que tu viaje de comprensión sobre los fundamentos de las bases de datos distribuidas comienza por saber qué te importa. Muchas gracias y estaré en el chat si alguien tiene preguntas. ♪♪