GitHub baut Git-Speicher um: 7.200 Pushes pro Sekunde auf ein einziges Repository
GitHub's new Git storage architecture
GitHub hat mit „Project Rubicon“ eine neue Git-Speicherarchitektur vorgestellt, die Tausende gleichzeitige Schreibzugriffe auf ein Repository ermöglicht. Im internen Test hielten 5.000 Agenten gleichzeitig ein Repository bespielt und schickten 7.200 Pushes pro Sekunde, bei konstant niedriger Lese-Latenz. Der Kern: Git-Objekte liegen unveränderlich in Azure Blob Storage, während nur die winzigen Referenz-Updates über den neuen Dienst Ref-CAS koordiniert werden – so skalieren Speicher, Anfragen und Wartung unabhängig voneinander.
Git-Objekte sind unveränderlich und nach ihrem Inhalt benannt, das heißt, zwei Schreiber können sie gleichzeitig ablegen, ohne sich auf irgendetwas einigen zu müssen.
- dwm
Das sieht Cursors Continuity sehr ähnlich, wobei GitHub allerdings einen um eine Größenordnung höheren Schreibdurchsatz meldet.
- yakkomajuri
Wenn ich das richtig lese, ist das (sehr solide) Zukunftsplanung, die aber bei den aktuellen Ausfällen nicht hilft?
Das hätte ich aus der Überschrift + dem einleitenden Inhalt geschlossen, aber dann sagen sie, dass die horizontalen Skalierungstechniken im Grunde aus der bestehenden Architektur übernommen werden (wo offenbar das Problem liegt?) und es hier hauptsächlich darum geht, bei dem zu helfen, was sie "vertikale Skalierung" nennen (Skalierbarkeit innerhalb eines Repos). Sie geben direkt danach auch zu, dass die heute aktivsten Repos kurze Schübe von höchstens ein paar Dutzend Writes bekommen.
Das wirkt also wie wirklich nützliche Planung für eine nahe Zukunft, die wahrscheinlich hilft, weitere Probleme zu vermeiden, aber nicht wirklich dazu gedacht ist, bei aktuellen Problemen zu helfen. Lese ich das richtig?
Natürlich sind solche Verbesserungen so oder so immer nützlich. Ich will hier überhaupt nicht stänkern.
- pksunkara
Das meiste davon ähnelt dem, was https://enroute.sh bereits bei der Skalierung von Git gemacht hat. https://enroute.sh/blog/everyone-is-doing-git-on-s3-wrong
- bob1029
Ich denke, Perforce könnte das bessere VCS sein, wenn man vorhat, eine Menge autonomer Agenten über einen großen gemeinsamen Haufen zusammenarbeiten zu lassen.
Mehrere Terabyte sind out of the box kein Problem. Man bekommt exklusives Locking von Dateien. Man kann problemlos partielle Checkouts des Monolithen machen. Zentralisierung ist in diesem speziellen Kontext ein Feature. Git funktioniert großartig, wenn der Koordinationsbedarf moderat ist. Wenn man aber Tausende automatisierte Entwickler hat, die alle ihre Finger im Keksglas haben, werden exklusive Locks plötzlich ziemlich überzeugend. Perforce ist mit einem stark verteilten Team mies, aber im Fall eines KI-Agenten-Schwarms haben wir vermutlich die Möglichkeit, den Checkout eines Agenten bei Bedarf sofort zu vernichten. Ich muss den Agenten nicht kontaktieren und warten, bis er aus dem Bett kommt.
- jxramos
Agent-Skalierung ist definitiv in der ganzen Branche im Kopf; ich frage mich, was die Leute bei GitHub auf https://www.anthropic.com/research/redesigning-source-contro... antworten würden. Es ist eine interessante Lektüre, um einen Schritt zurückzutreten und Source Control von den Grundprinzipien her zu betrachten und die Tradeoffs neu auszubalancieren, welche Eigenschaften in diesem neuen Regime zählen.