Tags populares：
Virtualização segurança DNS verificação formal análise de alcance IA erros do compilador conflito de macro extensão web framework de desenvolvimento Gráficos de Bitmap Todos os tags

Os bancos de dados podem substituir completamente os caches?

2025-08-31

Esta publicação explora a possibilidade de bancos de dados substituírem completamente os caches. Embora os bancos de dados ofereçam alguns recursos de cache, como pools de buffer e réplicas de leitura, os caches se destacam no acesso a dados de baixa latência, especialmente para subconjuntos de dados específicos e dados pré-computados. Para substituir os caches, os bancos de dados precisam resolver vários desafios: lidar eficientemente com inúmeras réplicas de leitura, habilitar réplicas de leitura parciais, priorizar dados específicos e implementar um mecanismo de manutenção de visualização incremental (IVM) eficiente. O autor sugere que a combinação de IVM com réplicas de leitura parciais pode eventualmente permitir que os bancos de dados substituam parcialmente os caches, mas ainda existe uma lacuna.

Leia mais
(avi.im)
Desenvolvimento réplicas de leitura

Modo WAL do SQLite: Compensação entre Durabilidade e Desempenho

2025-08-24

O modo WAL (Write-Ahead Log) do SQLite, frequentemente usado para maior taxa de transferência de gravação, compromete a durabilidade dos dados em comparação com o modo de diário padrão. O pragma `synchronous` controla a frequência com que o fsync é chamado; o padrão é NORMAL. No modo NORMAL, os arquivos WAL são sincronizados antes de cada ponto de verificação e o arquivo de banco de dados depois, mas a maioria das transações não possui operações de sincronização. Para aplicativos onde a durabilidade não é crítica, NORMAL é suficiente. Para durabilidade garantida em caso de perda de energia, `synchronous=FULL` adiciona uma sincronização de arquivo WAL após cada confirmação de transação, aumentando a durabilidade ao custo de velocidade de gravação. Esta explicação, motivada por preocupações sobre o SurrealDB possivelmente sacrificando a durabilidade para o desempenho de benchmark, esclarece a abordagem do SQLite.

Leia mais
(avi.im)
Desenvolvimento modo WAL durabilidade de dados

Problema de Soma de Verificação no Modo WAL do SQLite: Perda Silenciosa de Dados

2025-07-25

Esta publicação investiga uma falha no mecanismo de soma de verificação do SQLite no modo de registro antecipado de gravação (WAL). Quando ocorre uma discrepância na soma de verificação em um frame WAL, o SQLite descarta silenciosamente o frame com defeito e todos os frames subsequentes, mesmo que eles não estejam corrompidos. Esse design, embora intencional, leva à perda potencial de dados. O autor analisa as razões subjacentes e propõe que o SQLite deve lançar um erro ao detectar a corrupção, em vez de descartar silenciosamente os dados, melhorando assim a integridade dos dados. A discussão também aborda o contexto do uso do SQLite em sistemas embarcados e dispositivos móveis, onde a corrupção é mais prevalente.

Leia mais
(avi.im)
Desenvolvimento Integridade de dados

SQLite: Uma Lenda Inacreditável de Banco de Dados

2024-12-30

O SQLite, o banco de dados mais amplamente implantado do mundo, é mantido por uma equipe de três pessoas, rejeitando contribuições externas, mas conquistando o mundo com seu desempenho excepcional e estabilidade. Nascido em um navio de guerra dos EUA para resolver problemas de inatividade do servidor, tornou-se a pedra angular de trilhões de bancos de dados. O SQLite não é de código aberto, mas sim um software de domínio público, com menos restrições do que qualquer licença de código aberto. Seu rigoroso processo de teste, simulando até mesmo situações extremas como travamentos do sistema operacional, garante sua confiabilidade incrivelmente alta. No entanto, seu modelo de negócios único — gerando receita por meio de suporte pago e associações — também é digno de nota. A lenda do SQLite reside não apenas em sua proeza técnica, mas também na persistência e inovação por trás dele.

Leia mais
(avi.im)
Desenvolvimento lenda

Filtros de Bloom: O Segredo para Deixar o SQLite 10 Vezes Mais Rápido

2024-12-22

Pesquisadores usaram filtros de Bloom de forma inteligente para tornar as consultas analíticas do SQLite 10 vezes mais rápidas. Eles descobriram que as junções de loop aninhado do SQLite eram ineficientes, com muito tempo gasto em sondagens de árvore B. Ao usar um filtro de Bloom antes da operação de junção para filtrar rapidamente as linhas que provavelmente não correspondem e, em seguida, realizar sondagens de árvore B apenas em correspondências potenciais, o número de sondagens foi significativamente reduzido. Os filtros de Bloom têm uma sobrecarga de memória mínima e foram fáceis de integrar no mecanismo de consulta existente do SQLite, resultando em um aumento significativo de desempenho. Essa melhoria foi integrada ao SQLite v3.38.0.

Leia mais
(avi.im)
Desenvolvimento Filtros de Bloom Otimização de banco de dados

Reescrita do SQLite em Rust atinge redução de 100x na latência de cauda

2024-12-16

Pesquisadores da Universidade de Helsinque e Cambridge reescreveram o SQLite em Rust, criando o Limbo, um projeto que utiliza E/S assíncrona e io_uring para melhorar drasticamente o desempenho. Ao utilizar E/S assíncrona e desagregação de armazenamento, o Limbo consegue uma redução de até 100x na latência de cauda, particularmente benéfico em ambientes serverless multilocatários. A melhoria principal vem da substituição de instruções de bytecode síncronas por equivalentes assíncronos, eliminando bloqueios e melhorando a concorrência. As melhorias são mais notáveis em percentis altos, tornando o Limbo ideal para aplicações que exigem alta confiabilidade.

Leia mais
(avi.im)
Desenvolvimento E/S Assíncrona