GitHub научил один репозиторий принимать 7 200 пушей в секунду от тысяч агентов

GitHub's new Git storage architecture

GitHub научил один репозиторий принимать 7 200 пушей в секунду от тысяч агентов

GitHub представил новую архитектуру хранения Git — проект Rubicon, созданный под нагрузку от параллельно работающих AI-агентов. Внутренние тесты показали 5 000 одновременных агентов на одном репозитории и 7 200 пушей в секунду при стабильно низкой задержке чтения. Ключевая идея: упорядочивать нужно только обновления ссылок, а неизменяемые объекты Git можно писать параллельно. Данные хранятся в Azure Blob Storage, ссылки — в отдельном сервисе Ref-CAS, а виртуальные реплики держат лишь кэш.

Git-объекты неизменяемы и именуются по своему содержимому, а значит, два автора могут сохранять их одновременно, ни о чём не договариваясь.
  1. dwm

    Это очень похоже на Continuity от Cursor, хотя GitHub сообщает о пропускной способности записи на порядок больше.

    https://cursor.com/blog/git-at-any-scale

  2. yakkomajuri

    Если я правильно понимаю, это (действительно основательное) планирование на будущее, но оно не поможет с текущими сбоями?

    Я бы так и подумал из заголовка и начального текста, но потом они говорят, что методы горизонтального масштабирования в основном переносятся из существующей архитектуры (где, похоже, и кроется проблема?), а это в основном для того, что они называют «вертикальным масштабированием» (масштабируемость внутри репозитория). Сразу после этого они признают, что самые активные репозитории сегодня получают короткие всплески максимум в несколько десятков записей.

    Так что это выглядит как действительно полезное планирование на ближайшее будущее, которое, вероятно, поможет предотвратить новые проблемы, но не предназначено для решения текущих. Я правильно читаю?

    Конечно, подобные улучшения в любом случае всегда полезны. Вовсе не хочу принизить.

  3. pksunkara

    Большая часть этого похожа на то, что https://enroute.sh уже сделал для масштабирования Git. https://enroute.sh/blog/everyone-is-doing-git-on-s3-wrong

  4. bob1029

    Думаю, Perforce может быть лучшей VCS, если вы собираетесь заставить кучу автономных агентов пытаться сотрудничать над одной большой кучей.

    Несколько терабайт — не проблема из коробки. Вы получаете эксклюзивную блокировку файлов. Вы можете легко делать частичные чекауты монолита. Централизация в этом конкретном контексте — это фича. Git отлично работает, если потребность в координации умеренная. Если у вас тысячи автоматизированных разработчиков, запустивших руки в банку с печеньем, эксклюзивные блокировки начинают выглядеть очень заманчиво. Perforce отстой при сильно распределённой команде, но в случае роя ИИ-агентов у нас, предположительно, есть возможность мгновенно прибить чекаут агента, если понадобится. Мне не нужно связываться с агентом и ждать, пока он встанет с постели.

  5. jxramos

    Масштаб агентов определённо занимает умы в индустрии, интересно, что сказали бы ребята из GitHub в ответ на https://www.anthropic.com/research/redesigning-source-contro.... Это интересное чтиво, чтобы отступить на шаг назад и рассмотреть контроль версий с первых принципов и перебалансировать компромиссы в отношении того, какие качества важны в этом новом режиме.

Ещё за этот день

2026-11-07