GitHub rediseña el almacenamiento de Git para que miles de agentes escriban a la vez en un mismo repositorio
GitHub's new Git storage architecture
GitHub presenta Rubicon, su nueva arquitectura de almacenamiento de Git, capaz de sostener 5.000 agentes concurrentes sobre un solo repositorio y 7.200 pushes por segundo, con lecturas de baja latencia. La clave: los objetos de Git son inmutables y solo las referencias necesitan coordinación, así que el almacenamiento vive en Azure Blob Storage y el estado de las referencias en un servicio replicado llamado Ref-CAS. Así, almacenamiento, cómputo y mantenimiento escalan por separado sin cambiar la experiencia de los desarrolladores.
Git objects are immutable and named by their contents, meaning two writers can store them at the same time without agreeing on anything.
- dwm
Esto se parece mucho al Continuity de Cursor, aunque GitHub reporta un rendimiento de escritura un orden de magnitud mayor.
- yakkomajuri
Si lo estoy leyendo bien, ¿esto es una planificación (realmente sólida) a futuro pero no ayudará con las caídas actuales?
Lo habría pensado por el titular + el contenido inicial, pero luego dicen que las técnicas de escalado horizontal básicamente se trasladan de la arquitectura existente (¿donde parece estar el problema?) y que esto es principalmente para ayudar con lo que llaman "escalado vertical" (escalabilidad intra-repositorio). También admiten justo después que los repositorios más activos hoy recibirán ráfagas cortas de como máximo docenas de escrituras.
Así que esto parece una planificación realmente útil para un futuro cercano que probablemente ayuda a prevenir más problemas, pero que no está realmente pensada para ayudar con los problemas actuales. ¿Lo estoy leyendo bien?
Por supuesto, mejoras como esta siempre son útiles de todos modos. No estoy criticando en absoluto.
- pksunkara
La mayor parte de esto es similar a lo que https://enroute.sh ya hizo escalando Git. https://enroute.sh/blog/everyone-is-doing-git-on-s3-wrong
- bob1029
Creo que Perforce podría ser el VCS mejor si pretendes tener un montón de agentes autónomos intentando colaborar sobre un gran montón.
Múltiples terabytes no son problema desde el principio. Obtienes bloqueo exclusivo de archivos. Puedes hacer fácilmente checkouts parciales del monolito. La centralización es una característica en este contexto particular. Git funciona genial si la necesidad de coordinación es moderada. Si tienes miles de desarrolladores automatizados con las manos en el tarro de las galletas, los bloqueos exclusivos empiezan a parecer realmente atractivos. Perforce apesta con un equipo altamente distribuido, pero en el caso de un enjambre de agentes de IA presumiblemente tenemos la capacidad de aniquilar instantáneamente el checkout de un agente si es necesario. No tengo que contactar al agente y esperar a que se levante de la cama.
- jxramos
La escala de agentes definitivamente está en la mente de la industria, me pregunto qué diría la gente de GitHub en respuesta a https://www.anthropic.com/research/redesigning-source-contro.... Es una lectura interesante para dar un paso atrás y considerar el control de versiones desde los primeros principios y reequilibrar las compensaciones sobre qué cualidades importan en este nuevo régimen.