SQLite é 138x mais lento que ISSO?! (Testando o Stoolap)

BBetter Stack
컴퓨터/소프트웨어AI/미래기술

Transcript

00:00:00Quando você está iniciando um novo projeto e precisa de um banco de dados, qual a primeira opção que
00:00:03vem à mente? SQLite? Provavelmente é o SQLite, certo? Digo, ele é ótimo e confiável,
00:00:09não exige configuração e é um padrão da indústria. Mas, conforme nossos dados locais pesam e nossas consultas
00:00:14ficam mais complexas, começamos a atingir o limite do que um motor de bloqueio de arquivo de thread única
00:00:20consegue fazer. Mas agora há um novo competidor na área tentando resolver esses problemas.
00:00:25Chama-se Stulab, é um motor de banco de dados escrito inteiramente em Rust e acabou de lançar
00:00:31um driver nativo para Node.js que, honestamente, está apresentando um desempenho muito forte. O
00:00:36banco de dados é 138 vezes mais rápido que o SQLite. Então, neste vídeo, vamos analisar os bastidores
00:00:43do Stulab, ver como funciona e rodar um teste de benchmark ao vivo para ver se ele é tão poderoso
00:00:50quanto afirma ser. Vai ser bem divertido, então vamos lá. O que exatamente é o Stulab?
00:01:00Bom, em essência, o Stulab é um banco de dados OLAP (Processamento Analítico Online) embarcado. Se
00:01:06você está acostumado com bancos padrão como SQLite ou Postgres, eles são tipicamente OLTP (Processamento
00:01:14de Transações Online), que, como o nome sugere, são otimizados para transações. Mas
00:01:20o Stulab é diferente. Ele foi projetado para cargas de trabalho analíticas e construído do zero em Rust,
00:01:27focando no processamento de dados em alta velocidade. Pense nele como tendo a portabilidade de um arquivo SQLite,
00:01:33mas com o poder analítico bruto de algo como o DuckDB ou BigQuery. Mas o mais legal
00:01:39é que agora você pode usá-lo com Node.js graças ao seu driver nativo. E quando digo
00:01:45que é um driver nativo, não estou falando de um wrapper comum. Geralmente, quando um banco de dados é
00:01:49escrito em outra linguagem como Rust ou C++, seu app Node.js precisa se comunicar através de uma ponte.
00:01:56Frequentemente isso significa converter seus dados para JSON ou outro formato, enviá-los por um socket de rede local
00:02:02e depois convertê-los de volta do outro lado. Isso se chama sobrecarga de serialização e
00:02:08acaba totalmente com a performance. Mas o Stulab Node faz diferente. Ele utiliza o NAPI-RS,
00:02:15um framework que permite que o motor em Rust seja compilado em um binário nativo que carrega
00:02:21diretamente no seu processo Node.js. Ou seja, não há ponte nem tradutor no meio. Quando você envia
00:02:27uma consulta, o Node.js e o Rust essencialmente compartilham o mesmo espaço de memória. E há três grandes
00:02:33razões para o Stulab ser incrivelmente rápido. Primeiro, ele usa MVCC (Controle de Concorrência Multiversão).
00:02:40Diferente do SQLite, onde um único escritor pode travar o banco todo, o Stulab permite que múltiplos leitores
00:02:47e escritores trabalhem simultaneamente. Segundo, ele usa execução paralela. O Stulab utiliza um escalonador
00:02:53chamado Rayon. Com o Rayon, ao rodar uma consulta massiva, em vez de usar apenas um núcleo da CPU, ele divide
00:03:00a consulta e utiliza cada núcleo que sua máquina possui. E terceiro, ele usa um otimizador
00:03:06baseado em custo. Ele não executa seu SQL às cegas; ele analisa seus dados, estima
00:03:13o custo de diferentes caminhos e escolhe a forma mais rápida de chegar aos resultados. É isso que supostamente
00:03:19torna o Stulab uma opção muito mais rápida que o SQLite. Mas vamos testar para ver se é verdade.
00:03:25Para este teste, usaremos um projeto simples em Node.js e instalaremos tanto o Stulab quanto
00:03:30o SQLite como dependências. Uma das maiores vantagens onde o Stulab realmente brilha é no uso de “count distinct”.
00:03:37Estou curioso para saber se é esse o caso. Montei este script simples onde iniciamos
00:03:43uma versão em memória de cada banco e criamos uma tabela de vendas simples. Depois, populamos essa tabela
00:03:49com 10.000 linhas de dados aleatórios, onde cada linha representa uma venda de um usuário com ID entre
00:03:560 e 1.000, pertencente a uma categoria específica. Vamos inserir os dados em lote em
00:04:03ambos os bancos e rodar o benchmark, selecionando a contagem distinta de vendas feitas por um
00:04:10usuário específico em uma categoria e calcular a performance de cada um. Agora, preciso
00:04:16notar que é um pouco frustrante o fato de que, por enquanto, a instalação do pacote não funciona. Se rodarmos o
00:04:22teste de benchmark agora, vemos um erro sobre falta de vinculação nativa. O autor do projeto
00:04:28claramente esqueceu de adicionar os binários ou vincular os corretos ao pacote. Então, o que tive
00:04:34que fazer foi compilar a partir do código-fonte. Clonei o repositório, rodei o build interno, voltei
00:04:39para o meu projeto de benchmark e vinculei o diretório de origem como dependência. Isso é um pouco
00:04:44chato no momento, então espero que os autores corrijam isso no futuro. Mas,
00:04:49apesar disso, agora finalmente conseguimos rodar o benchmark. Vamos fazer isso agora.
00:04:54Como podem ver, a operação “count distinct” é de fato muito mais rápida no Stulab, embora não
00:05:01tanto quanto o anunciado. É apenas quatro vezes mais rápido. E se adicionarmos outro zero à quantidade
00:05:07de dados e rodarmos o teste novamente com 1.000.000 de linhas? Vamos tentar agora.
00:05:12Mesmo com um milhão de linhas, o Stulab é apenas seis vezes mais rápido, não 138 vezes. Mas,
00:05:20ainda assim, é um ótimo resultado. Esse foi o teste de “count distinct”. Decidi fazer outro
00:05:26benchmark para testar a operação “distinct + order by”. Neste segundo teste, configurei a
00:05:33ingestão de logs aleatórios com diferentes IPs e códigos de status, e tentamos encontrar logs
00:05:39distintos por par de IP e status, ordenando por IP ascendente e código de status
00:05:47descendente. Como podem ver, ao rodar este teste, o Stulab ainda performa melhor que o SQLite,
00:05:53mas não por 14 vezes; apenas 1 a 1,5 vez mais rápido. Então, as métricas listadas estão um pouco infladas,
00:06:01na minha opinião. Mas, de qualquer forma, o Stulab é sim mais rápido que o SQLite, como vimos nos testes.
00:06:08Para ser justo, o autor também menciona áreas onde o SQLite ainda performa melhor que o Stulab.
00:06:13Geralmente são situações de operações em uma única linha. O Stulab é ótimo para
00:06:19consultas complexas e analíticas. Então, o Stulab é o “assassino” do SQLite? Sinceramente, não. Eles foram
00:06:26feitos para coisas totalmente diferentes. O SQLite continua sendo seu parceiro confiável para transações,
00:06:32mas o Stulab pode ser seu carro de corrida de alta performance para análise de dados. Mas o fato
00:06:38de termos agora um motor analítico puro em Rust que podemos integrar em um projeto Node.js com NAPI-RS
00:06:45é excelente. Os donos do projeto só precisam corrigir o pacote NPM atual,
00:06:50para que não tenhamos que compilar do código-fonte. Então, aí está pessoal. Esse é o Stulab em resumo.
00:06:55O que vocês acham? O ganho de performance vale a mudança para o Stulab ou vocês preferem
00:07:01a confiabilidade do SQLite? Contem para a gente nos comentários abaixo. E pessoal, se acharam
00:07:06este vídeo útil, por favor deixem o seu joinha clicando no botão de curtir. E também não
00:07:11se esqueçam de se inscrever no canal. Aqui foi o Andris, da Better Stack, e vejo vocês
00:07:17nos próximos vídeos.

Key Takeaway

Embora o Stulab ofereça um desempenho analítico superior ao SQLite em Node.js devido à sua arquitetura nativa em Rust, os ganhos reais de velocidade são significativos, porém inferiores aos 138x anunciados.

Highlights

O Stulab é um motor de banco de dados OLAP escrito em Rust com driver nativo para Node.js.

Utiliza o framework NAPI-RS para compartilhar memória entre Node.js e Rust

Timeline

Introdução ao Desafio do SQLite e o Novo Competidor

O vídeo começa discutindo as limitações do SQLite em projetos que escalam, mencionando problemas com bloqueio de arquivos e thread única. O apresentador introduz o Stulab como uma nova solução escrita em Rust que promete ser drasticamente mais rápida. É destacado o lançamento de um driver nativo para Node.js que visa resolver gargalos de performance. A promessa central é um aumento de velocidade de até 138 vezes em comparação ao SQLite tradicional. Este segmento estabelece a expectativa para os testes de benchmark que ocorrerão ao longo do conteúdo.

Arquitetura e Diferenciais Técnicos do Stulab

Nesta seção, o autor explica que o Stulab é um banco de dados focado em OLAP (Processamento Analítico Online), ao contrário do foco transacional do SQLite e Postgres. A utilização do framework NAPI-RS é detalhada como um diferencial que permite o compartilhamento de memória entre Rust e Node.js sem serialização. São explicados três pilares da velocidade do motor: o MVCC para concorrência, o escalonador Rayon para processamento paralelo em múltiplos núcleos e um otimizador de consultas baseado em custo. Essa base técnica justifica por que o sistema consegue processar grandes volumes de dados de forma eficiente. O contexto ressalta a importância de entender a diferença entre ferramentas transacionais e analíticas.

Preparação do Benchmark e Problemas de Instalação

O apresentador descreve a metodologia do teste prático utilizando um script em Node.js com dados de vendas aleatórios. Um ponto crítico mencionado é a falha atual no pacote NPM, que não inclui os binários nativos necessários para funcionar imediatamente. Para contornar isso, o autor demonstra a necessidade de clonar o repositório e compilar o código-fonte manualmente em Rust. O script foca na operação "count distinct" em tabelas que variam de 10.000 a 1.000.000 de linhas. Esta parte é essencial para desenvolvedores que desejam testar a ferramenta e precisam estar cientes dos obstáculos técnicos iniciais.

Resultados dos Testes e Comparação de Performance

Os resultados do benchmark revelam que o Stulab é de fato mais veloz, mas os números são mais modestos do que o marketing sugere. Em um milhão de linhas, o Stulab foi cerca de 6 vezes mais rápido que o SQLite, longe dos 138 vezes mencionados inicialmente. Um segundo teste envolvendo as operações "distinct" e "order by" mostrou uma vantagem ainda menor, de apenas 1 a 1,5 vez. O autor critica as métricas infladas, mas reconhece que a performance ainda é superior para o caso de uso analítico. O segmento fornece dados concretos para que o espectador avalie se o ganho justifica a complexidade adicional.

Conclusão: O Stulab é o Assassino do SQLite?

Na conclusão, o vídeo esclarece que o Stulab e o SQLite possuem propósitos distintos e podem coexistir em diferentes partes de uma aplicação. O SQLite permanece como a escolha ideal para transações confiáveis de linha única e persistência simples. Por outro lado, o Stulab é posicionado como um "carro de corrida" para processamento massivo de dados e consultas complexas. O apresentador reforça a importância de correções no ecossistema de pacotes para facilitar a adoção pela comunidade. O vídeo termina incentivando a participação do público e reforçando o valor da integração nativa entre Rust e Node.js.

Community Posts

View all posts