Пост канала
- ссылка
GitHub перестраивает систему хранения данных — операции записи стали быстрее в 35 раз Когда клиенты GitHub переключили внимание на использование ИИ-агентов в разработке, активность на платформе резко возросла. В период с сентября 2025 года по август 2026 года трафик GitHub удвоился, увеличившись с 218,2 млрд до 473,3 млрд событий в месяц. Только в сентябре количество коммитов достигло 7,38 млрд, что в пять раз превышает показатель сентября 2025 года. Столь резкий рост трафика создает серьезную нагрузку на систему. Согласно отчету GitHub о доступности сервиса, только в апреле произошло 10 инцидентов, приведших к снижению производительности. В мае случилось еще девять сбоев, каждый из которых вызывал все больший общественный резонанс. В ответ на беспрецедентный спрос со стороны ИИ-агентов GitHub с нуля перестраивает архитектуру хранения данных Git. Предварительные внутренние тесты новой архитектуры демонстрируют многообещающий результат: скорость записи выросла в 35 раз. План предусматривает разделение операций записи и чтения, перенос задач по обслуживанию на другие компоненты и использование объектного хранилища для обеспечения избыточности данных Текущая архитектура хранения данных GitHub, известная под названием Spokes, использует протокол трехфазной фиксации (three-phase commit): полные копии репозиториев размещаются на нескольких локальных дисках, а для подтверждения каждой операции записи требуется кворум реплик. Хотя такой подход обеспечивает высокую надежность, он ограничивает скорость записи, поскольку выполнение каждой операции push (отправки изменений) лимитируется скоростью работы самой медленной реплики, входящей в кворум. Новая архитектура предполагает запись коммита лишь однажды — в Azure Blob Storage. Это объектное хранилище самостоятельно управляет репликацией (и, следовательно, избыточностью данных), устраняя тем самым «узкое место», связанное с необходимостью кворума. GitHub также повышает производительность за счет выделения запросов на чтение в отдельный канал, который обслуживается легковесными вычислительными процессами (воркерами). Единственным элементом координации между операциями чтения и записи остается управление указателями на ветки (reference pointers). Задачи по обслуживанию системы — такие как уплотнение данных (compaction) и сборка мусора (garbage collection) — перенесены из основного пути обработки запросов в фоновый режим, что дополнительно снижает задержки в работе системы. https://github.blog/engineering/architecture-optimization/building-git-infrastructure-for-agent-scale-development/
Открыть в MAX- Просмотры
- 219
- ER
- 1,4%
- Реакции
- 3