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

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

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

Infelizmente, não tenho dados para você sobre os recursos de carregamento, mas alguns comentários sobre alguns dos fatores de restrição de desempenho:

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

• Transações são iniciados por padrão, mas você obter um desempenho melhor se você começar e confirmar a transação. Eu tive inserções em massa muito rápidas ao manipular a transação programaticamente

• Se você geralmente está apenas lendo dados, obtém um bom desempenho em minha experiência. Portanto, o SQLite pode ser usado como um sistema de armazenamento em cache para armazenar leituras do servidor de banco de dados, principalmente remotas ou consultas complexas.

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

• Se você precisar que várias gravações simultâneas sejam possíveis, um servidor de banco de dados (por exemplo, MySQL, Postgres) pode muito bem atendê-lo melhor

Como Devrim afirmou, o site 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

Tenho alguns pontos a acrescentar a essas boas respostas.

A versão atual do SQLite possui WAL (Write-Ahead Logging) para que a leitura e gravação possam prosseguir simultaneamente. Portanto, a limitação tradicional de escritor único mencionada nas respostas anteriores não existe mais. Ainda não vi o WAL em produção, portanto não posso comentar o quão bem ele é dimensionado.

Usando o WAL ou não, se o seu banco de dados SQLite for somente leitura (ou for atualizado em lote) e se encaixar na RAM (seu sistema operacional possui RAM suficiente para mantê-lo em buffers), ele pode ser dimensionado muito bem em um aplicativo Web de produção. Pessoalmente, fiquei muito cético em relação a seu desempenho, escalabilidade e robustez, mas agora, após nove meses de produção, ele provou rodar até mesmo as partes mais complexas do sistema muito bem.

O Sqlite é ótimo para incorporar aplicativos, e é para isso que ele foi projetado, mas certamente não é "incrivelmente rápido". Eu o uso para vários de 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 no 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 aumenta, embora eu não possa ter certeza, pois eu o usei apenas com bancos de dados com menos de 100 MB.

Eu acho que o sqlite é apenas mais rápido que um arquivo de texto / xml (você pode se surpreender se tiver tentado). E ele não suporta simultaneidade, se você deseja criar um site para intranet onde as pessoas registrem suas horas de trabalho ou usem bilhetes com rastreamento, isso pode servir bem. Fora isso, deve ser evitado e substituído pelo mysql ou couchdb.

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

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