PSY 1 × 0 DBA do YouTube

Uma vez, muito tempo atrás na época em que eu era CSA de uma startup, desenvolvíamos uma aplicação para rodar em PDAs com PalmOS, ou seja, ambiente extremamente restrito, tanto em recursos quanto em performance. Eu bolei um modelo de dados onde teríamos 5 flags essenciais do usuário armazenadas nos bits de um único byte.

Assim o bit 1 indicaria se o sujeito estava logado ou não, o bit 2 indicaria se era cliente ou fornecedor, o bit 3 se a conta estava ativa ou não… um simples byte, em binário 11111111 teria um monte de informações, ocuparia… um byte em memória, consumiria menos recursos no banco e nos PDAs. Modificar o valor era pura questão de matemática binária, qualquer programador decente escreveria em algumas horas funções pra isso.

Eu tinha um estagiário. Quando fui ver, ele implementou meu esquema criando no banco de dados o campo flag, CHAR(8). com valor default “00000000”. O filho de uma chocadeira disse que era complicado demais do meu jeito.

Com uma simples alteração ele aumentou em 7x o consumo de memória daquele campo.

Otimizar recursos não era popular na época e é menos ainda hoje em dia, onde na dúvida compra-se mais CPUs no Azure e pronto. E como toda boa ação tem sempre uma punição, quando alguém otimiza algo, toma no roscofe. Foi o que aconteceu com o YouTube.

Por questão de performance e bom-senso o contador de views dos vídeos era armazenado em banco como um campo INT, de 32 bits. Isso significa que o número de views poderia ir até inimagináveis 2.147.483.647 visualizações. Isso ocupando 4 bytes (4 * 8 = 32, dã).

Eis que chega o japa* — fenômeno com aquela bobagem do Gangnam Style, e as visitas não cansam de subir. Uma hora a quantidade ultrapassou os dois bilhões, e o que aconteceu depende da imaginação de cada um, não tenho idéia do controle de erros do banco do YouTube.

Só sei que os caras publicaram um post comentando o incidente, e avisando que mudaram o campo no banco para um BIGINT, então vai levar algum tempo até o PSY conseguir 9.223.372.036.854.775.807 views. Alguns (eu inclusive) estranharam o YouTube não usar um UNSIGNED INT.

Explicando: o campo INT normal armazena em um de seus 32 bits a informação se o número é negativo ou positivo. Assim um INT vai de -2.147.483.648 a 2.147.483.647.

Um campo UNSIGNED INT só armazena valores positivos, então os 32 bits estão disponíveis. Nosso Gangnam Style só daria problema com 4.294.967.295 views.

Ao mudar de INT para BIGINT o Google DOBROU o tamanho do campo, em todos os seus vídeos. de 4 bytes agora ele ocupa 8 bytes. Acha pouco? Quantos vídeos o YouTube tem?

Não faria mais sentido mudar para UNSIGNED INT ou então ir logo pro UNSIGNED BIGINT, com 18.446.744.073.709.551.615 views?

Faria mas as normas de codificação do Google proíbem. A argumentação é até válida, e HD é barato.

Fonte: TC.

* eu sei