Histórico de estrelas do GitHub: paginar o trabalho é melhor que paginar o resultado

O GitHub apresentou uma API de histórico de estrelas que devolve contagens diárias de até 30 semanas por requisição, sem retornar as identidades de quem favoritou o repositório.[13] No exemplo de react/react, com cerca de 251 mil estrelas, a coleta cai de aproximadamente 2.511 para 24 requisições.[13] O ganho mais interessante, porém, está abaixo do JSON: limitar quanto o banco precisa trabalhar.

O que muda para quem desenvolve

A alternativa inicial agregava todas as estrelas e só depois paginava o resultado, repetindo a leitura em cada página e chegando a aproximadamente 6 milhões de linhas examinadas naquele exemplo.[13] O desenho final transforma a paginação em faixas indexadas de tempo antes de agrupar.[13]

Minha leitura é que esse caso separa duas otimizações que parecem iguais na interface. Reduzir o tamanho da resposta economiza transporte. Restringir o conjunto lido antes da agregação muda o custo do processamento. Uma API pode melhorar no primeiro aspecto e continuar cara no segundo.

O desenho também atende melhor à necessidade real do consumidor. Ferramentas de tendência usavam listas de usuários para aproveitar os timestamps, e essas listas também alimentavam coleta de identidades para spam e phishing.[13] Entregar o agregado pode resolver o relatório sem distribuir dados pessoais desnecessários.

Como aplicar

Escolha um relatório paginado do seu sistema. Observe se a consulta restringe a faixa de dados antes de agrupar ou se recalcula o conjunto inteiro para cada página. Compare os planos de execução e o total de linhas examinadas para obter todas as páginas, não apenas a latência da primeira.

Verifique também as contagens auxiliares. A investigação do GitHub encontrou recálculo do total de estrelas em cada página, com quase 37 mil consultas lentas na semana observada, média próxima de três segundos e mais de mil interrupções por proteção do banco.[13] O trabalho levou ao uso da contagem em cache em páginas que não precisavam recalculá-la.[13]

Como experimento, proponha um contrato agregado que entregue apenas as dimensões necessárias ao consumidor. Compare custo, resolução temporal e exposição de dados com a API detalhada. Inclua intervalos vazios, fronteiras de página e uma concentração intensa de eventos em um único período. Não conclua que uma faixa curta é barata sem medir sua densidade.

Cuidados e limites

Uma semana muito movimentada ainda pode ser cara, porque limitar o tempo não limita quantas estrelas existem naquele intervalo.[13] Além disso, o modelo representa as estrelas atuais: remover uma estrela elimina seu registro, portanto a curva não é um diário imutável de todos os eventos.[13]

Use esse histórico como sinal aproximado de interesse, não como contabilidade permanente de popularidade.[13] Em sistemas próprios, deixe essa semântica explícita no contrato. Uma API eficiente continua errada para o consumidor se ele atribuir aos dados uma precisão histórica que eles não oferecem.

Fonte

[13] Fonte: GitHub Blog