(Traduzido de We need tool support for keyset pagination)
Você sabia que a paginação via offset é muito problemática, mas fácil de evitar?
offset instrui os bancos de dados a pular os primeiros N resultados N de uma consulta. No entanto, o banco de dados ainda deve buscar essas linhas a partir do disco e trazê-los em ordem antes de ele pode enviar os seguintes.
Isto não é um problema de implementação, é a maneira na qual offset foi desenhado:
... As linhas são primeiro classificadas de acordo com a <cláusula order by> e, em seguida, limitada retirando-se o número de linhas especificadas na <cláusula offset> desde o início ...
— SQL:2011, Part 2, §4.15.3 Derived tables
Em outras palavras, grandes offsets impõe um grande trabalho para o banco de dados, não importa se SQL ou NoSQL.
Mas o problema com offset não pára aqui: já pensou sobre o que acontece se uma nova linha é inserida entre duas páginas buscadas?
Quando offset➌ é usado para ignorar as entradas❶ anteriores, você terá duplicações no caso de existirem novas linhas inseridas entre as duas páginas➋. Há outras anomalias possíveis também, este é apenas o caso mais comum.
Este nem é um problema de banco de dados, é a maneira como os frameworks implementam paginação: eles apenas dizem qual é o número da página a ser recuperada ou quantas linhas devem ser ignoradas. Com estas informações apenas, nenhum banco de dados pode fazer melhor.
Vida sem OFFSET
Agora imagine um mundo sem estes problemas. Como se constata, viver sem offset é bem simples: apenas utilize uma cláusula where que selecione apenas os dados que você ainda não viu.
Para isso, exploraremos o fato de que trabalhamos com um conjunto ordenado - você tem uma cláusula order by, não é? Uma vez que há uma ordenação definida, podemos usar um filtro simples para somente selecionar o que é posterior a entrada que vimos anteriormente.
SELECT ...
FROM ...
WHERE ...
AND id < ?last_seen_id
ORDER BY id DESC
FETCH FIRST 10 ROWS ONLY
Esta é a receita básica. Ele fica mais interessante quando a classificação é por várias colunas, mas a idéia é a mesma. Esta receita também é aplicável a muitos sistemas NoSQL.
Esta abordagem - chamada seek method ou keyset pagination - resolve o problema de derivação de resultados como ilustrado acima e é ainda mais rápido do que offset. Se você quer saber o que acontece dentro do banco de dados ao usar offset ou keyset pagination, dê uma olhada nestes slides (benchmarks, benchmarks!):
No slide 43 você também pode ver que keyset pagination tem algumas limitações: mais notavelmente que você não pode navegar diretamente para páginas arbitrariamente. No entanto, isto não é um problema quando se utiliza rolagem infinita. Mostrar o número de páginas para serem clicadas é uma interface de navegação pobre, na minha humilde opinião.
Se você quiser ler mais sobre como implementar corretamente keyset pagination em SQL, por favor fetch-next-page. Mesmo que você não esteja envolvido com o SQL, vale a pena ler fetch-next-page antes de começar a implementar qualquer coisa.
No entando, os frameworks
A principal razão para preferir offset a paginação por conjunto de chaves (keyset pagination) é a falta de suporte. A maioria das ferramentas de paginação são baseadas em offset, mas não oferecem nenhuma maneira conveniente para a utilização de paginação por conjunto de chaves.
Por favor, note que a paginação por conjunto de chaves afeta toda a tecnologia envolvida na execução de JavaScript do navegador que esteja fazendo a requisição AJAX para rolagem infinita: ao invés de simplesmente passar um número de página para o servidor, você deve passar o conjunto de chaves completo (geralmente múltiplas colunas) para o servidor.
O hall da fama de frameworks que suportam paginação por conjunto de chaves é ainda pequeno:
É por isto que preciso da sua ajuda. Se você estiver mantendo um framework que tem algum envolvimento com paginação, eu peço, eu imploro, que você construa um suporte nativo para navegação por conjunto de chaves também. Se você tiver quaisquer perguntas sobre detalhes, ficarei feliz em ajudar (forum, contact form, Twitter)!
Mesmo que você esteja apenas utilizando um software que deveria suportar paginação por conjunto de chaves, como um gerenciador de conteúdos ou uma loja virtual, faça os mantenedores saberem sobre isso. Você poderia fazer uma requisitação da funcionalidade (link a esta página) ou, se possível, desenvolva um patch. Novamente, ficarei feliz em ajudar a ter todos os devidos detalhes.
Tome WordPress como um exemplo.
Espalhe a palavra
O problema com a paginação de conjunto de chaves não é técnico. O problema é que é pouquíssimo conhecido no meio e não há suporte das ferramentas. Se você gosta da idéia de evitar o uso de paginação por offset, por favor, ajude a espalhar a palavra. Use o Twitter, compartilhe, envie por e-mail, você pode até reproduzir este post (CC-BY-NC-ND). Traduções são também bem-vindas, apenas faça um contato prévio - eu também incluirei o link da tradução a esta página.
Ah, e se você estiver em um blog, você também pode acrescentar um banner para que seus leitores fiquem alertas a isto. Eu preparei uma a galeria de banner NoOffset com alguns formatos comuns. Escolha o que ficar melhor.
