SQLite em um servidor de produção? [fechadas]

Question

Eu conheço o SQLite há muito tempo e sei que é muito rápido, mas nunca tentei em um servidor de produção. Nunca consegui encontrar uma estimativa sólida sobre o volume de tráfego que ele poderia suportar antes de falhar.

Alguém tem algum número ou um artigo sobre isso?

    

Answer 1

Infelizmente, não tenho dados sobre recursos de carregamento, mas alguns comentários sobre alguns dos fatores que restringem o desempenho:

• A velocidade do SQLite é afetada pela velocidade do disco em que está e se há muitas inserções / atualizações acontecendo (por exemplo, acesso de gravação). O bloqueio de gravação é limitado pela velocidade de rotação do disco

• As transações são iniciadas por padrão, mas você obtém um melhor desempenho se você iniciar e confirmar a transação. Tive inserções em massa muito rápidas ao manipular a transação programaticamente

• Se você geralmente só tiver leitura dados, obterá um bom desempenho na minha experiência. Assim, o SQLite pode ser usado como um sistema de cache para armazenar as leituras do servidor de banco de dados, especialmente as remotas ou consultas complexas.

• Ele usa menos recursos do que um servidor de banco de dados, portanto, isso pode afetar o desempenho do site, liberando mais recursos para o servidor Web e o código do aplicativo

• Se você precisar de um número de gravações simultâneas para ser possível, então um servidor de banco de dados (por exemplo, MySQL, Postgres) pode muito bem atendê-lo

Como Devrim afirmou, o site do SQLite afirma que cerca de 100 mil usuários / dia devem estar bem. Um sistema Trac requer gravações, portanto, o desempenho provavelmente seria mais lento nesse caso

    

Answer 2

Eu tenho alguns pontos para adicionar a essas boas respostas.

A versão atual do SQLite tem o WAL (Gravação à frente) para que a leitura e a gravação possam prosseguir simultaneamente . Portanto, a limitação tradicional do escritor único mencionada nas respostas anteriores não existe mais. Eu ainda não vi o WAL na produção, então não posso comentar como ele é escalável.

Usando o WAL ou não, se o seu banco de dados SQLite for somente leitura (ou for atualizado em lote) e couber na RAM (seu sistema operacional tem RAM disponível suficiente para mantê-lo em buffers), ele pode ser dimensionado muito bem em um aplicativo da Web de produção. Eu pessoalmente fiquei muito cético em relação ao seu desempenho, escalabilidade e robustez, mas agora depois de nove meses em produção , ele provou que funciona mesmo as partes mais complexas do sistema muito bem.

    

Answer 3

O Sqlite é ótimo para incorporar aplicativos, e é para isso que é projetado, mas certamente não é "incrivelmente rápido". Eu o uso para vários dos meus próprios aplicativos, apenas para a conveniência de ter apenas dois arquivos que podem ser copiados para outra máquina para fornecer um aplicativo totalmente funcional. Testes contra o MySQL, usando a mesma estrutura, índices, etc., mostram que o Sqlite é consideravelmente mais lento, mesmo para bancos de dados pequenos. Eu esperaria que a diferença de desempenho aumentasse à medida que o tamanho do banco de dados aumentasse, embora eu não possa dizer com certeza, já que usei apenas com bancos de dados de menos de 100 MB.

    

Answer 4

Eu acho que o sqlite é apenas mais rápido que um arquivo texto / xml (você pode se surpreender se você tentou). E não suporta simultaneidade, se vc quiser criar um site para intranet onde as pessoas registrem suas horas de trabalho ou usem o ticketing trac ele pode servir bem. Além disso, deve ser evitado e substituído por mysql ou couchdb.

O site sqlite diz que 100k usuários / dia devem estar bem, mas eu duvido muito, já que um simples projeto trac fica preso muito com o uso de escritório de 10 ppl.

    

Answer 5

O Sqlite não é um aplicativo de banco de dados cliente / servidor tradicional. É essencialmente uma biblioteca incorporada em outro aplicativo. Ele é projetado para aplicativos de desktop de usuário único. Você absolutamente não quer tentar usá-lo como algum tipo de substituição MySQL / PostgreSQL / MS-SQL independente em um ambiente multiusuário porque o banco de dados inteiro está bloqueado na gravação. Você estará lidando com problemas de contenção mesmo com uma carga leve que destruirá o desempenho.