Издание Wired обратило внимание на выступление сотрудницы Google Рейчел Потвин «The Motivation for a Monolithic Codebase», которое состоялось в рамках конференции в Кремниевой долине. В своём докладе она оценила число строк кода, который отвечает за работу всех интернет-сервисов Google: выяснилось, что число равно примерно 2 миллиардам. Если провести некорректное сравнение и учесть, что Windows содержит примерно 50 миллионов строк кода, то получается, что с 1998 года в Google успели написать 40 операционных систем от Microsoft, которая разрабатывается с 1985 года. Мало того, весь этот «Google-код» находится в едином репозитории, которым ежедневно пользуются 25 000 сотрудников поискового гиганта.
Рейчел заметила, что такой принцип хранения исходников позволяет разработчикам Google "… чувствовать необычную свободу в использовании и комбинировании кода других проектов". Единственное существующее ограничение — это доступ к коду, реализующему алгоритмы ранжирования Google’s PageRank, которые являются основой бизнеса, критичного для поискового гиганта. К этим файлам имеют доступ только специально выделенные сотрудники. В целом для управления кодом в Google используется собственная VCS, которая называется Piper и которая в свою очередь опирается на серьёзную инфраструктуру, состоящую из 10 дата-центров.
Любопытна статистика, приведённая Рейчел. По её словам, Piper управляет 85 терабайтами данных «Google-кода», в который ежедневно 25 000 разработчиков делают примерно 40 000 коммитов. Таким образом за каждую неделю модифицируются 250 000 файлов и 15 миллионов строк кода. В сравнении с Linux, которая вся насчитывает примерно 40 000 файлов, работа программистов Google выглядит фантастической.Также Рейчел отметила, что сейчас Google и Facebook вместе работают над новой open source VCS, которую можно будет использовать на проектах любого масштаба, сравнимого даже с самой Google. Интересно, что основой будущей VCS является не модная среди разработчиков git, а Mercurial, которую пытаются масштабировать до уровня, с которым приходится иметь дело обоим интернет-гигантам.
Комментарии (30)
RPG
17.09.2015 08:27+3На примере Хромиума: каталог third_party содержит несколько гигабайт кода (это его состояние несколько 6 лет назад, сейчас там творится просто кошмар), надёрганного их OpenSource проектов, что превышает объём кода самого Хромиума. С такими методами разработки проект растёт очень быстро.
orcy
17.09.2015 12:15+2Судя по видео там кроме исходного кода еще и конфигурация, документация, код который генерируется, итд. Из 40к коммитов ежедневно, только 15к это человек, остальное это роботы. Так что сказать «работа программистов Google выглядит фантастической» вряд ли можно по количеству исходного кода у этом репозитории.
Duche3d
17.09.2015 10:47+11«Google используется собственная VCS, которая называется Piper» — хм… странно я думал она должна называться Pied Piper :)
AxisPod
17.09.2015 11:00+7Только вот проблема в том, что счастье не в строчках. И для кода так или иначе нужные иные метрики.
Разговор о большом кол-ве строк для меня является наоборот отрицательным показателем.
Rasifiel
17.09.2015 13:18+1Чем не нравятся метрики по количеству строчек не в обсуждении продуктивности разработчиков, а в обсуждении эффективности VCS?
camelos
17.09.2015 11:30+2не модная среди разработчиков git, а Mercurial
Разбирающиеся в теме, поясните, пожалуйста, разницу. Я был убеждён, что это почти одно и то же.
Athari
17.09.2015 14:46-3Mercurial — это примерно как Git, только нормальный и непопулярный.
camelos
17.09.2015 14:47+4Александр, можете чуть подробнее про «нормальный». В git-е есть вещи, которые мне не нравятся. Может быть Меркуриал для меня.
Rasifiel
17.09.2015 16:13+2Меркуриал гораздо более «классический». Во всяком случае переход на него с свна был совершенно безболезненный — к классическим концепциям добавляется слой обеспечивающий собственно букву D. Классические бранчи (но без свновых недостатков) особенно радовали. Git для меня был болезнен и требовал постоянно дергать документацию и искать как что-то сделать.
Metus
17.09.2015 16:18+2На работе используем mercurial.
Возможно я ошибаюсь, но без плагинов нет чего-то вроде rebase и прочего.
Нет разделения веток на локальные и внешние — есть просто ветки. pull и push затягивает и толкает все ветки разом.
Более того, ветка именно ветка, она выходит из одной, она существует отдельно от других, её можно смержить с другой.
Не знаю, нормально это или нет?
Rasifiel
17.09.2015 13:22Странно, что все обсуждают размер репозитория, а не концепцию «один репозиторий для всего»
vlreshet
17.09.2015 13:54А что обсуждать? Если это успешно работает в таком гиганте как Google — значит это вполне нормальная практика.
Rasifiel
17.09.2015 14:32Ну там много чего можно добиться только с ресурсами порядка Гугла. Куча собственной самописной инфраструктуры и своих решений. Если Гугл с ФБ сделают коробочное решение для решения таких проблем, то будет хорошо.
batyrmastyr
17.09.2015 14:21Странно говорить что репозиторий один, если для его работы гробятся ресурсы 10 ЦОДов. Сдаётся мне речь не об аналоге git-репозитория речь идёт, а об одном логическом хранилище из которого делают piper clone piper.google.TLD:/<конкретный репозиторий>.
Rasifiel
17.09.2015 14:28Нет. Вы неправильно представляете)
google-engtools.blogspot.ch/2011/06/build-in-cloud-accessing-source-code.html
И откуда вы взяли, что «гробятся ресурсы 10 ЦОДов» только на хранилище кода?)batyrmastyr
17.09.2015 16:05Да, представлял неправильно. )
А про «только» — вроде как логично было предположить, что в гугле не кладут все яйца в одну корзину. Хотя вы правы — они столько ЦОДов развернули скорее для уменьшения задержек реакции внутренних сервисов, а не из-за большой прожорливости хранилища.Rasifiel
17.09.2015 16:16У Гугла и так куча ДЦ по всему миру и VCS в результате просто распределили по ним, чтобы иметь адекватную задержку и скорость работы с ним.
ArtRoman
19.09.2015 12:31Возможно, по аналогии с репозиторием Андроида – там своя тулза управления репозиторием "repo", но внутри просто сотни обычных git-репозиториев (с разделением по устройствам, по приложениям, по компонентам системы, и те огромное количество тех самых third-party библиотек). Причём их метаданные (.git) отделены от реальных данных через символьные ссылки. При обновлении сначала обновляются метаданные, потом все изменения разом накатываются на файловую систему.
Тоже можно сказать, что весь код в одном репозитории, хотя на самом деле это не совсем так.
BelBES
17.09.2015 13:25Мало того, весь этот «Google-код» находится в едином репозитории, которым ежедневно пользуются 25 000 сотрудников поискового гиганта.
Рейчел заметила, что такой принцип хранения исходников позволяет разработчикам Google "… чувствовать необычную свободу в использовании и комбинировании кода других проектов".
По её словам, Piper управляет 85 терабайтами данных «Google-кода», в который ежедневно 25 000 разработчиков делают примерно 40 000 коммитов. Таким образом за каждую неделю модифицируются 250 000 файлов и 15 миллионов строк кода.
Интересно, а среди сотрудников компании много героев, которые клонировали себе весь репозиторий, а не только рабочую ветку?)
Ну и бедные новобранцы, который с дуру решают скачать весь код)Metus
17.09.2015 13:31+2Предполагаю, что у них piper управляет не одним репозиторем, а может их быть хоть 10 тысяч. Тут как-то не раскрыта данная тема.
Rasifiel
17.09.2015 14:00Там не надо ничего клонировать. Есть FUSE модуль который делает магию — подхватывает read only версию нужного файла, а при изменениях создает рабочую копию у пользователя. Собственно статья по теме: google-engtools.blogspot.ch/2011/06/build-in-cloud-accessing-source-code.html
pehat
Кажется, что код алгоритма не такая уж и ценность – вся его сила в наборе факторов, которые, по сути, набор коэффициентов. Может быть, речь шла о самой формуле ранжирования?
vlreshet
Но ведь с кода можна вывести саму формулу, поэтому логично что доступ к нему ограничен.
pehat
Формула релевантности = код алгоритма + обучающая выборка в миллиард документов.
Знание алгоритма RSA никаким образом не поможет взломать приватный ключ отдельно взятого владельца. Если у вас нету датацентра-другого, который сможет обойти весь интернет (ну за пару лет хотя бы, пока всё окончательно не стухнет), построить индекс, сохранить его на диске, а затем уже применить всем известный алгоритм (вот, первая попавшаяся ссылка по запросу https://github.com/louridas/pagerank) – грош цена упертому коду.
joann
Думаю там не тока сам pagerank а все алгоритмы ранжирования, за которые сеошники большие денги дали бы
Yoschi
У конкурента вполне может быть датацентр-другой.