BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Facebook faz Mercurial ser mais rápido que o Git

Facebook faz Mercurial ser mais rápido que o Git

No início deste ano, o Facebook publicou em seu blog de engenharia um texto intitulado Escalando o Mercurial no Facebook, explicando com eles estão escalando o Mercurial como seu repositório.

O Facebook armazena todos os seus códigos em um único repositório que há dois anos foi baseado no subversion. Em vez de ter repositórios separados para diferentes projetos (e compartilha-los utilizando um repositório binário), toda a base de códigos fica em um enorme repositório.

Infelizmente para o Facebook, nem o git e nem o mercurial foram projetados para suportar em um único e enorme repositório diversos projetos. Uma vez que o propósito de um sistema de controle de versão distribuído é o de armazenar todo o histórico de atualizações, e se todos os projetos de uma empresa são armazenados em um único repositório, o tamanho do repositório junto com o histórico das atualizações pode se tornar proibitivo com o decorrer do tempo. Em comparação, os controladores de versões centralizados CVS e o subversion são capazes de controlar em um único repositório múltiplos projetos, porque os clientes podem checar a versão mais recente ou um subconjunto de um repositório.

Embora o time do Facebook tenha considerado modificar o Git para suportar suas necessidades, a conclusão foi que as API's do Mercurial são mais apropriadas para dar suporte aos seus requerimentos. (O Git tem uma bem definida estrutura de objetos podendo ser manipulados por ferramentas, em oposição ao Mercurial que possui API's que podem ser utilizadas por outros programas). Muitas mudanças foram feitas contribuindo com a evolução do projeto Mercurial, incluindo novos algoritmos de gráficos e reescrita de código utilizando C.

Duas específicas alterações habilitaram a utilização do Mercurial pelo Facebook para suportar o tamanho do seu repositório; modificando a situação das atualizações dos arquivos para verificar se ocorreram alterações específicas, ao contrário da mudança de conteúdo (através da ligação com a lista de alterações de arquivos do sistema operacional) e modificando a forma do chekout deixando-o mais leve sem ter que registar um histórico mais completo.

Normalmente, um sistema distribuído de controle de versão gera um hash com base no conteúdo dos seus dados, em vez das informações de data e hora. Como resultado, para verificar se um repositório possui alterações, uma computação será executada percorrendo-se arquivo por arquivo, calculando-se o hash de cada arquivo para determinar se seu conteúdo possui alterações. Pela limitação de um conjunto de arquivos que devem ser verificados, o sistema operacional é informado sobre as alterações desde a última checagem, sendo que o tempo desta operação será proporcional ao número de arquivos que sofreram alterações em suas datas e horas, em vez de se percorrer toda a área de trabalho atual. O Git tenta reduzir este problema através da execução do lstat para obter informações específicas sobre os arquivos, mas ainda percorre todos os arquivos do repositório para determinar se foram alterados ou não. Pode-se optimizar o repositório para permitir que o sistema operacional, se solicitado, informe somente os arquivos que foram alterados.

Outro problema que o Facebook tentou resolver foi o de minimizar a quantidade de dados necessários relacionados com as operações de acréscimo de novos arquivos ou duplicações. O armazenamento de todos os projetos em um mesmo repositório faz com que seu tamanho fique proporcional ao volume de entradas dos históricos que com o passar do tempo poderá gerar problemas de escalabilidade. Uma vez que o repositório não é particionado eficazmente a solução foi o da leitura e carga da versão mais atual dos arquivos através do registro.

Isso permitiu aos desenvolvedores uma rápida obtenção de um conjunto de arquivos (da mesma forma e desempenho do subversion e CVS) também podendo ocorrer uma interação através do registro das alterações. Entretanto se versões mais antigas do repositório (ou revisões de arquivos) forem necessárias, a cópia local não vai possuir estas informações. (O Git fornece uma limitada opção de cópia que permite obter uma revisão do repositório mas sem acessar registros anteriores através de histórico).

Pela extensão das APIs do Mercurial, objetos atualizados que foram esquecidos podem gerar uma falha e serem baixados através de um servidor remoto quando solicitados. Obviamente se o servidor estiver por algum motivo indisponível, os desenvolvedores não poderão solicitar versões antigas dos códigos; mas uma vez que os registros de atualizações estejam disponíveis novas atualizações podem ser criadas e enviadas para o servidor. (Em comparação, o git mantem uma copia limitada das atualizações servindo apenas para fins de leitura).

Estas melhorias, juntamente com uma camada de memória de armazenamento e compartilhamento, têm acelerado o uso do Mercurial pelo Facebook superando o Git tanto em acréscimos de arquivos quanto em duplicações em um fator estimado de 5 vezes. Ambas as avaliações estão disponíveis nos repositórios mercurial do Facebook através de remotefilelog e hgwatchman. Embora estas configurações e abordagens sejam especificas e em muitos casos não adequados a todos os usuários do Mercurial, fornece aos DVCS um inicio de estudo comparativo em um mundo de código aberto cada vez mais dominado pelo Git.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT