Cursor supera i limiti di scalabilità di Git con un nuovo approccio

Cursor ha superato i limiti di scalabilità di Git, un sistema di controllo delle versioni ampiamente utilizzato, introducendo un nuovo approccio basato su storage di oggetti. Questo cambiamento è stato reso possibile grazie a un’architettura interna chiamata Continuity, che permette di gestire migliaia di repository in modo più efficiente. Il problema principale di Git, come spiegato da Vicent Martí, principale ingegnere sistemi di Cursor, risiede nella sua capacità di gestire operazioni su larga scala, specialmente quando si tratta di sincronizzazione e accesso a repository complessi.

Scalabilità e limiti di Git

Git, creato da Linus Torvalds, è progettato come un sistema di archiviazione dati basato su hash, dove ogni oggetto è identificato univocamente. Tuttavia, quando si gestiscono repository su larga scala, come quelli di GitHub, la sincronizzazione diventa un problema. Martí ha spiegato che, per soddisfare richieste come il recupero di un packfile o l’elenco delle modifiche recenti, il server deve percorrere l’intero grafo di commit, un processo che diventa lento e inefficiente con il numero di repository che cresce.

La sincronizzazione è un problema complesso, e Git non si adatta bene all’eventualità della consistenza asincrona.

GitHub ha cercato di risolvere questa sfida introducendo il concetto di “Spokes”, ovvero tre copie sincronizzate di ogni repository su dischi NVMe. Tuttavia, questa soluzione ha limiti, soprattutto quando si considera il numero crescente di repository e la complessità introdotta dagli agenti di sviluppo.

Agenti e complessità del lavoro moderno

Gli agenti di sviluppo, come quelli utilizzati in ambienti CI/CD, hanno reso il lavoro con Git più complesso. Martí ha sottolineato che gli agenti generano un numero elevato di repository, spesso piccoli e di breve durata, che complicano la gestione. Questo fenomeno ha reso necessario un sistema più flessibile e scalabile, in grado di gestire la crescita del numero di repository e delle operazioni di sincronizzazione. Con l’aumento del numero di repository e delle operazioni, il sistema di Git ha mostrato limiti, soprattutto quando si tratta di gestire operazioni su larga scala. Questo ha portato Cursor a cercare alternative, come il sistema di storage di oggetti, che offre una soluzione più efficiente.

Un nuovo approccio con object storage

Cursor ha scelto di utilizzare il storage di oggetti, un approccio diverso rispetto a file o block storage. Questo tipo di storage assegna un identificatore univoco a ogni chunk di dati e li memorizza in un unico namespace, senza directory. L’uso di Amazon S3, un servizio di storage di oggetti popolare, ha permesso a Cursor di costruire un sistema scalabile e affidabile. Con l’architettura Continuity, Cursor ha sviluppato un servizio chiamato Origin, che utilizza un log di scrittura anticipata (WAL) per memorizzare le modifiche in modo immutabile. Questo permette di gestire le modifiche in modo più veloce e efficiente, riducendo il carico sul sistema. Inoltre, le modifiche vengono raggruppate per migliorare la velocità di trasmissione.

Il sistema di Cursor permette di sincronizzare i repository in modo più rapido, grazie alla gestione locale delle operazioni. Martí ha spiegato che, con un’unica sincronizzazione con un repository locale, il sistema riesce a ingegnare modifiche molto più velocemente rispetto a un sistema basato su replica. Se Origin riuscirà a mantenere un elevato livello di affidabilità e scalabilità, potrebbe diventare un’alternativa interessante per chi gestisce repository su larga scala. Per ora, il successo di questo approccio dipende dal fatto che non si verificheranno problemi di tipo outage, come quelli che hanno colpito GitHub in passato.