ReTabNews

E ai, silvestrini ! Beleza ?

Na sua opinião o que de fato ele está perdendo em utilizar o SQLite nessa situação ? É uma pergunta honesta, tenho zero conhecimento...

kht há 3 meses

Falando de maneira geral, primeiro a gente tem que definir o que seria "colocar em produção". Pois no meu entendimento, este termo significa que o produto/sistema/aplicativo foi lançado e está sendo efetivamente utilizado pelos usuários/clientes.

E nesse sentido, o SQLite é um dos softwares mais usados - senão o mais usado - do mundo em ambiente de produção, se considerarmos a quantidade de instâncias ativas. Afinal, só no seu computador e celular estão instalados vários programas que usam o SQLite de alguma forma. A lista de sistemas e programas usando-o em produção é enorme (esta lista parcial dá uma ideia de que não é só "peixe pequeno" que usa).

Ou seja, o SQLite está em produção e muito bem, com bilhões (talvez trilhões) de instâncias ativas. Por isso dizer que ele é "fraco para colocar em produção" eu acho bem equivocado, pois na verdade depende muito da situação. Tem casos em que ele funciona e atende muito bem a demanda, e casos em que outros bancos atendem melhor.

Sobre o caso específico do post, pela breve descrição parece que haverá múltiplas escritas simultâneas e muitos acessos vindos de clients diferentes a um servidor único, e neste cenário o SQLite não se sai bem. E isso não é demérito: toda tecnologia tem casos em que ela atende bem e outros nos quais ela não é a melhor opção.

Acho que o problema é que a maioria das pessoas costuma considerar apenas sistemas web distribuídos, e aí realmente existem outros bancos de dados que podem se encaixar melhor nestes cenários.

Mas isso não quer dizer que o SQLite é "fraquinho" ou não sirva pra web. No próprio site deles diz o seguinte (em tradução livre):

O SQLite funciona bem como banco de dados para sites com tráfego pequeno e médio (que é a maioria dos sites). O tráfego que ele suporta depende muito de como o site usa o banco. De forma geral, qualquer site que tenha menos de 100 mil acessos por dia funcionará bem com SQLite. E este número é uma estimativa conservadora, não um limite. O SQLite já mostrou que consegue lidar com tráfego 10 vezes maior que isso.

O próprio site do SQLite (https://www.sqlite.org) usa SQLite, claro, e atualmente (2015) suporta entre 400 e 500 mil requests HTTP por dia, dos quais cerca de 15% a 20% são páginas dinâmicas que são consultadas no banco. Este conteúdo dinâmico usa cerca de 200 instruções SQL por página. Esta configuração roda em uma única máquina virtual que compartilha um servidor físico com outras 23, e ainda sim mantém uma carga média de 0.1 na maior parte do tempo.

Claro que o site do SQLite não parece fazer uso extensivo do banco, e os acessos são todos (ou a grande maioria) de leitura. E obviamente que eles vão tentar vender o próprio peixe. Mas a questão não é ser "fraquinho", e sim ser o resultado de várias decisões de design para que ele atinja sua proposta, que inclusive é citada no mesmo link indicado acima:

O SQLite não pode ser comparado com engines de bancos de dados cliente/servidor como MySQL, Oracle, PostgreSQL ou SQL Server, porque o SQLite está tentando resolver problemas diferentes.

Então não é questão de ser "fraco", apenas de seguir uma abordagem diferente a fim de atacar problemas que os bancos "tradicionais" não conseguem resolver tão bem quanto ele.

E nesses tipos específicos de problema que o SQLite quer atacar, ele serve muito bem para colocar em produção. Tudo depende do que vc precisa, e claro que ele não vai servir para todos os casos. Inclusive, no link já citado tem uma lista bem extensa de situações em que ele pode ser usado sem problemas, e casos em que outros bancos de dados se saem melhor.

O problema é que - pelo menos essa é minha impressão - as pessoas geralmente pensam em sistemas web distribuídos, com muitos clients acessando o banco através de rede, escritas simultâneas, etc (situação na qual o SQLite realmente não é a melhor opção). E aí generalizam para "SQLite é fraco", "não serve pra produção", etc.

maniero há 3 meses

Curiosamente na web é onde o SQLite deveria ser mais usado. Claro que tem sistemas que está falando que caem na questão de grande escrita simultânea, mas é raro e provavelmente não deveria ser web. Existem soluções prontas e não é tão difícil fazer o SQLite suportar escritas simultâneas (em geral fazendo fila). Não é o ideal e dá um pouco de trabalho, pelo menos uma vez, mas é possível usar para este objetivo também, ainda que eu não esteja recomendando, de fato existem outros mais adequados. Tem que pesar o que é mais importante. O ponto fraco dele é este mesmo, mas tem solução se a pessoa realmente quiser, e souber fazer. Escrita simultânea acontece bem menos do que as pessoas imaginam na esmagadora maioria dos casos. O site deles descreve onde deve ser usado de forma extremamente conservadora e foi escrito e nunca mudado na época que o SQLite era bem mais limitado, inclusive não podia fazer escrita e leitura simultânea. Hoje ele é adequado para muito mais que eles descrevem lá, nem vendem bem o peixe. Websites mesmo é para ele ser adequado em praticamente 100% dos casos. O autor do comentário deu mais parâmetros para a opinião dele e vimos que o SQLite é fraquinho usando o Laravel. Aí já diz muito. Portanto "a culpa é do SQLite e não do Laravel". O segundo item dele não faz o menor sentido, inclusive inverte o próprio argumento. e não entende como os outros dbs funcionam, parece achar que é mágica. O SQLite realmente funciona melhor na mão de quem sabe desenvolver software, que não precisa se valer de *frameworks* e coisas prontas. Você o coloca onde quiser e for adequado para a necessidade, igual acontece com os outros SGDBs que você instala um software para poder usar. O item 3 ignora que a maioria das aplicações só precisa ter acesso a um usuário que é a própria aplicação e o sistema tem seu próprio controle de usuários. O sistema de usuários do banco de dados é feito para casos em que os usuários acessam diretamente o db e não através de um sistema. Se a pessoa souber fazer sistemas e ainda assim precisa ter controle de usuários nele de fato o SQLite não é adequado, que é diferente de ser fraquinho ou não servir para produção. A pessoa ignora também que qualquer um pode acessar os dados do MySQL, PostgreSQL, SQL Server, etc. O fato dele não saber disso é que deixa **tudo** inseguro. O que pode ser feito para tornar esses sistemas seguros, pode ser feito de forma idêntica com o SQLite. Uma coisa é certa, para quem não conhece o SQLite, e outros aspectos da computação, realmente essa pessoa não deve usá-lo, porque ela é fraquinha e não deveria colocar coisas em produção. Eu não tenho dados suficientes para avaliar se o Kairos deveria ou não usar o SQLite, mas estatisticamente a chance é grande de ser uma boa ou até a melhor ferramenta para a tarefa. Espero que o autor esteja usado ele certo e tenha sucesso pensando fora da caixa. --- Farei algo que muitos pedem para aprender a programar corretamente, **gratuitamente** (não vendo nada, é retribuição na minha aposentadoria) ([links aqui](https://github.com/maniero/SOpt) no perfil também).

silvestrini há 3 meses

Se velocidade, confiabilidade e segurança importar para o seu projeto, então sim, está perdendo. Por que?

1 - (Velocidade/Performance) - Eu utilizo Laravel para meus projetos, o padrão dele é SQLite, pois é muito fácil, não precisa instalar nada demais, então para iniciantes é ótimo. Você só instala uma extensão para ler o arquivo no VS Code e já era.

Porém, nem tudo são flores. Quando se roda as migrations para criar as tabelas e popular o banco de dados com dados fake, aí que você percebe o abismo de velocidade que tem entre SQLite e PostgreSQL, por exemplo, o primeiro sendo o mais lento e o segundo o mais rápido. E o MySQL fica no meio do caminho. O Artisan mostra o tempo que levou para cada coisa. Como o exemplo na imagem abaixo. E isso impacta o seu sistema como um todo, todas as queries são mais lentas.

2 - (Confiabilidade) - Um banco de dados SQLite, nada mais é que apenas um arquivo com a extensão .sqlite, que é guardado em qualquer lugar, geralmente na pasta do projeto, pois não suporta multiplos databases no mesmo arquivo. Cada arquivo se refere apenas a um banco de dados. Como é um arquivo que pode ser salvo em qualquer lugar, há a possibilidade, por exemplo, de se corromper mais fácil, ou ter algum problema com permissões e você não conseguir utilizá-lo.

3 - (Segurança) - Aqui é um pouco indiscutível, pois é o que define que o SQLite realmente não seja utilizado em produção, a não ser em casos muitos específicos, como app mobile. No SQLite não se tem controle de usuários, permissões, controle de hosts que podem acessar, como existe no MySQL e no PostgreSQL (que ainda tem o pg_hba para configurar ips liberados). Qualquer um pode acessar o seu banco e ver todas as informações nele contidas, o que não é nada interessante.

Ou seja, em geral, SQLite deve ser utilizado somente para desenvolvimento, pois peca nos aspectos por mim citados acima. Claro que essa é uma visão pessoal, mas fica a reflexão desses pontos. Mesmo em desenvolvimento, dificilmente utilizo SQLite, pois para mim, a performance importa muito.