Almacenamiento SQLite de latencia cero en cada Durable Object

 (simonwillison.net)
2 puntos por GN⁺ 2024-10-15 | 1 comentarios | Compartir por WhatsApp

  • Zero-latency SQLite storage in every Durable Object

    • Kenton Varda presenta la siguiente versión de la plataforma Durable Object de Cloudflare. Esta plataforma fue actualizada recientemente de un almacén clave/valor a un sistema relacional completo basado en SQLite
    • Para información de contexto útil sobre la primera versión de Durable Objects, se puede consultar Cloudflare’s durable multiplayer moat de Paul Butler. Es popular para construir aplicaciones de colaboración en tiempo real basadas en WebSocket
    • Los nuevos Durable Objects basados en SQLite son un elemento atractivo de diseño de sistemas distribuidos que propone una forma interesante de diseñar aplicaciones a gran escala

  • Idea central de Durable Objects

    • Un Durable Object coloca la lógica de la aplicación en el mismo host físico que los datos, ofreciendo un rendimiento de lectura y escritura muy rápido
    • Un solo objeto se ejecuta en un único hilo de una sola máquina, por lo que su rendimiento está limitado. Para manejar más tráfico, se crean más objetos. Esto es más sencillo cuando cada unidad de estado tiene un nivel de tráfico lo bastante bajo como para que un solo objeto pueda manejarla

  • Ejemplo de sistema de reservas de vuelos

    • Cada vuelo puede mapearse a un Durable Object dedicado con su propia base de datos SQLite. Se crean miles de nuevas bases de datos por día para cada aerolínea
    • Cada DO tiene un nombre único, y la red de Cloudflare enruta las solicitudes al objeto sin importar en qué parte del mundo se encuentre

  • Detalles técnicos

    • Inspirado en Litestream, cada DO transmite continuamente una secuencia de entradas WAL hacia un almacenamiento de objetos. Esto se agrupa cada 16 MB o cada 10 segundos
    • Para garantizar la durabilidad dentro de la ventana de 10 segundos, las escrituras se envían a cinco réplicas en centros de datos cercanos tan pronto como se confirman, y la escritura se reconoce cuando tres de ellas la validan

  • Diseño de la API de JavaScript

    • Está diseñada para ser bloqueante, no asíncrona. Esto busca ofrecer operaciones de persistencia rápidas en un solo hilo
    • Incluye ejemplos que muestran intencionalmente el patrón de consultas N+1, que SQLite puede manejar bien

  • Storage Relay Service

    • Es el sistema subyacente de Durable Objects y ha estado respaldando el sistema SQLite D1 existente de Cloudflare durante más de un año

  • Dónde se crean los Durable Objects

    • Los Durable Objects no cambian de ubicación después de ser creados. Por defecto, se instancian en el centro de datos donde se realiza la solicitud inicial get()
    • Para crear manualmente Durable Objects en otra ubicación, se proporciona el parámetro opcional locationHint a get()

  • Sitio where.durableobjects.live

    • Es un sitio que rastrea dónde se crean los DO dentro de la red de Cloudflare

Resumen de GN⁺

  • Los Durable Objects de Cloudflare, basados en SQLite, abren nuevas posibilidades para diseñar aplicaciones a gran escala. Esto ofrece un rendimiento rápido al colocar los datos y la lógica de la aplicación en el mismo host físico
  • Este sistema es especialmente útil para aplicaciones de colaboración en tiempo real y ofrece flexibilidad para manejar diversas unidades de estado
  • Durable Objects crea réplicas en múltiples centros de datos para garantizar la durabilidad de los datos, lo que mejora la estabilidad y la confiabilidad
  • Esta tecnología puede resultar interesante para desarrolladores interesados en el diseño de sistemas distribuidos a gran escala. Sistemas con capacidades similares incluyen DynamoDB de Amazon y Firestore de Google

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-10-15
Opiniones en Hacker News

  • La API de escritura es sincrónica, pero tiene una capacidad oculta de espera asíncrona. Si una escritura falla, el runtime reemplaza la respuesta con un error HTTP, lo que permite agrupar automáticamente las escrituras y asumir que tuvieron éxito

    • No hay transacciones de lectura, por lo que es difícil obtener un snapshot de un momento específico
    • Cada instancia del runtime está limitada a 128 MB de RAM
    • Los WebSockets pueden hibernar y, en ese estado, no generan costo. Esto permite que el cliente mantenga la conexión incluso cuando el DO está dormido
    • Hay una función automática de RPC que permite comunicarse con otros DO o workers como si fueran llamadas normales de JS. El runtime se encarga de la serialización y el parsing

  • Cada DO transmite una secuencia de entradas WAL al object storage, y esto se agrupa cada 16 MB o cada 10 segundos

    • A nivel global, una escritura puede tardar hasta 10 segundos en reflejarse en una lectura
    • Es difícil reemplazar clústeres de bases de datos desplegados regionalmente

  • Me gusta el diseño de Durable Objects. Es fácil entender cómo funciona internamente

    • Los DO son buenos para construir experiencias en tiempo real rápidas y de bajo costo, pero dificultan el análisis y la generación de vistas generales
    • Si pones los datos en SQLite, tienes que consultar muchas instancias pequeñas de SQLite y luego combinar los resultados

  • Es difícil entender dónde están ubicados físicamente los Durable Objects

    • Me pregunto si están en la región donde ocurre la llamada API
    • Me pregunto si un DO puede moverse automáticamente a otra ubicación

  • Es difícil entender las nuevas tecnologías cloud

    • Tengo más de 15 años de experiencia en desarrollo web, pero siento que estas tecnologías no son para mí

  • Me pregunto cómo manejar las migraciones de esquema

    • Si la base de datos existe por tenant, aplicar cambios de esquema a cada DO parece complicado

  • El diseño de DO me parece interesante, pero creo que solo sirve para sistemas de alta carga o proyectos de juguete

    • En trabajo real se necesitan sistemas probados, y DO todavía no ha madurado

  • El diseño de DO me impresionó. Creo que su forma de manejar tareas complejas a baja escala se parece a la estructura de un producto real

  • Me llama la atención que CF esté recomendando a los desarrolladores usar DO

    • Las conexiones WebSocket de Workers expiran después de 30 segundos, y se recomienda usar DO

  • Me pregunto si DO corresponde al "modelo" en una arquitectura MVC

    • Me pregunto cómo usar DO por tenant y cómo consultar o hacer joins entre todos los DO