Em busca de um SQLite mais rápido

• O SQLite já é um sistema de banco de dados rápido, mas pesquisadores estão buscando formas de torná-lo ainda mais rápido
• Pesquisadores da Universidade de Helsinque e de Cambridge publicaram o artigo "co-design de runtime serverless/banco de dados por meio de I/O assíncrona", mostrando que é possível reduzir a latência de cauda em até 100 vezes. Esse artigo serve de base para o Limbo, uma reescrita do SQLite em Rust.

io_uring

• Explicação do io_uring: o subsistema io_uring do kernel Linux fornece uma interface para I/O assíncrona. Ele reduz a sobrecarga de cópia de buffer por meio de um ring buffer entre o espaço do usuário e o espaço do kernel. A aplicação pode enviar requisições de I/O e executar outras tarefas até receber do sistema operacional a notificação de conclusão da operação.

• Execução de consultas no SQLite: o SQLite usa arquivos para armazenar dados, abre o banco com a função sqlite3_open() e converte instruções SQL em bytecode com a função sqlite3_prepare(). A função sqlite3_step() executa as instruções de bytecode para processar a consulta.

Premissa

• Ascensão da computação serverless: em ambientes serverless, a latência do banco de dados pode se tornar um problema. Embutir o banco de dados diretamente no runtime de edge elimina essa latência, e o SQLite é adequado para esse tipo de ambiente.

• Problemas do SQLite: por usar I/O síncrona, o uso de recursos não é otimizado, o que causa problemas de concorrência e multitenancy.

• Migração para io_uring: substituir chamadas de I/O POSIX por io_uring não é algo simples; é necessário reprojetar o SQLite para se adequar a um modelo de I/O assíncrona.

Limbo

• Suporte a I/O assíncrona: os componentes VM e BTree foram modificados para oferecer suporte a I/O assíncrona, substituindo instruções síncronas de bytecode por instruções assíncronas. A I/O assíncrona elimina bloqueios e melhora a concorrência.

• Separação entre motor de consultas e motor de armazenamento: é proposta a separação entre o mecanismo de consultas e o mecanismo de armazenamento para maximizar o uso de recursos.

Avaliação e resultados

• Benchmarking: foi simulado um runtime serverless multitenant em que cada tenant possui seu próprio banco de dados embutido. Ao comparar a latência de consultas entre SQLite e Limbo, o Limbo reduziu a latência de cauda em 100 vezes no p999.

• Trabalhos futuros: estão planejados benchmarks adicionais com vários leitores e escritores, e a vantagem de desempenho se destaca principalmente apenas após o p999.

• Código open source: o código do Limbo está disponível como open source: Limbo GitHub

[GN⁺]

Comentários do Hacker News

• Há uma discussão sobre como certos casos de uso de computação serverless, como AWS Lambda e bancos de dados centrais, nem sempre combinam bem com apps estruturados de forma serverless

  • Houve uma experiência de trabalho, há 6–7 anos, para resolver um problema em que era necessário processar arquivos hierárquicos complexos e extrair informações específicas
  • FaaS era caro para tarefas computacionalmente pesadas, e carregar e fazer parse de arquivos XML grandes toda vez era ineficiente
  • Como solução, foi usada uma função central com timer para ler e fazer parse dos arquivos, carregá-los em um banco de dados SQLite, indexá-los e depois armazenar o arquivo no S3
  • As funções Lambda baixavam o arquivo do S3 e faziam consultas quando ele estava mais atualizado que a cópia local ou em caso de cold start
  • Descobriu-se que o Lambda tem um diretório local /tmp e que o runtime Python inclui SQLite, então não era necessário enviar nenhum código além da própria função
  • Há interesse no trabalho em andamento sobre como esse tipo de solução pode ficar mais rápido

• Pode valer a pena deixar explícito que um dos dois pesquisadores é chefe do autor

  • Houve a impressão equivocada de que o autor e os pesquisadores não tinham relação

• Há concordância com a afirmação de que "o ganho só é perceptível acima de p999, e em p90 e p99 o desempenho é quase idêntico ao do SQLite"

  • Gosta-se de SQLite e de otimizações, mas isso é fato

• O SQLite tem uma suíte de testes extensa, então é testado de forma bastante rigorosa

  • Fica a dúvida se uma reescrita receberá um nível semelhante de testes, especialmente ao usar recursos rápidos, porém difíceis de implementar e potencialmente sujeitos a bugs, como io_uring

• Para benchmarking, foi simulado um runtime serverless multi-tenant em que cada tenant tem seu próprio banco de dados embutido

  • O SQLite tem sua própria thread por tenant, e a medição é feita executando consultas em cada thread
  • Fica a dúvida se uma configuração serverless com SQLite usaria um processo SQLite por requisição

• Houve anteriormente uma tentativa de introduzir async io no Postgres, mas ela foi descontinuada

  • A proposta mais recente é permitir a substituição customizada do storage manager sem precisar fazer fork da codebase
  • Há muito interesse na nova proposta, e ela se relaciona com o movimento de separar storage e computação

• Há uma pergunta sobre a ideia de fazer outro trabalho enquanto o async io está em andamento

  • Fica a dúvida se, ao realizar trabalho de banco de dados, ainda é necessário esperar a transação ser concluída

• Como autor da postagem no blog, não se esperava que este texto chegasse à página principal

  • Trabalha na Turso, o artigo foi publicado em abril de 2024 e desde então muitas melhorias foram feitas

• SQLite é open source, mas o test harness importante não é

  • Há uma pergunta sobre como alternativas garantiriam compatibilidade

• Houve uma tentativa de encontrar um caminho simples para criar um formato parecido com JSON como subconjunto estrito do formato de arquivo do SQLite, mas sem sucesso

  • Há muita arbitrariedade no formato de arquivo, então o interesse foi perdido, embora outra pessoa talvez possa ter sucesso