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.