Quão escalável é o SQLite?[fechado]

Question

Recentemente li esta pergunta sobre SQLite versus MySQL e a resposta apontou que o SQLite não escala bem e o site oficial meio que confirma isso, no entanto.

Quão escalável é o SQLite e quais são seus limites superiores?

Answer 1

Ontem lancei um pequeno site^* para rastrear seu representante que usou um banco de dados SQLite compartilhado para todos os visitantes.Infelizmente, mesmo com a carga modesta que colocou no meu host, ele funcionou bem devagar.Isso ocorre porque todo o banco de dados era bloqueado sempre que alguém visualizava a página porque continha atualizações/inserções.Logo mudei para o MySQL e embora não tenha tido muito tempo para testá-lo, parece muito mais escalável que o SQLite.Só me lembro de carregamentos lentos de páginas e, ocasionalmente, de receber um erro de bloqueio de banco de dados ao tentar executar consultas do shell no sqlite.Dito isto, estou executando outro site do SQLite perfeitamente.A diferença é que o site é estático (ou seja,Eu sou o único que pode alterar o banco de dados) e por isso funciona muito bem para leituras simultâneas.Moral da história:use SQLite apenas para sites onde as atualizações do banco de dados acontecem raramente (menos frequentemente do que cada página carregada).

editar:Acabei de perceber que posso não ter sido justo com o SQLite - não indexei nenhuma coluna no banco de dados SQLite quando o estava servindo em uma página da web.Isso causou parcialmente a desaceleração que eu estava enfrentando.No entanto, a observação do bloqueio de banco de dados permanece - se você tiver atualizações particularmente onerosas, o desempenho do SQLite não corresponderá ao MySQL ou Postgres.

outra edição: Desde que publiquei isso há quase 3 meses, tive a oportunidade de examinar de perto a escalabilidade do SQLite e, com alguns truques, ele pode ser bastante escalonável.Como mencionei em minha primeira edição, os índices de banco de dados reduzem drasticamente o tempo de consulta, mas esta é mais uma observação geral sobre bancos de dados do que sobre SQLite.No entanto, há outro truque que você pode usar para acelerar o SQLite: transações.Sempre que você precisar fazer várias gravações no banco de dados, coloque-as dentro de uma transação.Em vez de gravar (e bloquear) o arquivo toda vez que uma consulta de gravação for emitida, a gravação acontecerá apenas uma vez quando a transação for concluída.

O site que mencionei que lancei no primeiro parágrafo voltou para SQLite e está funcionando perfeitamente depois que ajustei meu código em alguns lugares.

^{*o site não está mais disponível}

Answer 2

O Sqlite é escalável em termos de usuário único, tenho um banco de dados multi-gigabyte que funciona muito bem e não tive muitos problemas com ele.

Mas isso é usuário único, então depende de que tipo de dimensionamento você está falando.

Em resposta aos comentários.Observe que não há nada que impeça o uso de um banco de dados Sqlite em um ambiente multiusuário, mas toda transação (na verdade, toda instrução SQL que modifica o banco de dados) bloqueia o banco de dados. arquivo, o que impedirá que outros usuários acessem o banco de dados de forma alguma.

Portanto, se você fizer muitas modificações no banco de dados, basicamente encontrará problemas de dimensionamento muito rapidamente.Se, por outro lado, você tiver muito acesso de leitura em comparação ao acesso de gravação, pode não ser tão ruim.

Mas o Sqlite irá, é claro função em um ambiente multiusuário, mas não executar bem.

Answer 3

SQLite impulsiona o site sqlite.org e outros que têm muito tráfego.Eles sugerem que se você tiver menos de 100 mil hits por dia, o SQLite deve funcionar bem.E isso foi escrito antes de entregarem o recurso "Writeahead Logging".

Se você quiser acelerar as coisas com SQLite, faça o seguinte:

• atualizar para SQLite 3.7.x
• Habilitar registro de gravação antecipada
• Execute o seguinte pragma:"Pragma cache_size = número de páginas;" O tamanho padrão (número de páginas) é de 2000 páginas, mas se você aumentar esse número, aumentará a quantidade de dados que estão saindo diretamente da memória.

Você pode querer dar uma olhada no meu vídeo no YouTube chamado "Melhore o desempenho do SQLite com registro Writeahead" que mostra como usar o registro de gravação antecipada e demonstra uma melhoria de 5x na velocidade de gravação.

Answer 4

SQLite é um Área de Trabalho ou em processo base de dados.SQL Server, MySQL, Oracle e seus irmãos são servidores.

Os bancos de dados de desktop não são, por natureza, uma boa escolha para qualquer aplicativo que precisa suportar acesso de gravação simultâneo ao armazenamento de dados.Isso inclui, em algum nível, a maioria dos sites já criados.Se você precisar fazer login para alguma coisa, provavelmente precisará de acesso de gravação ao banco de dados.

Answer 5

Você leu esta documentação do SQLite - http://www.sqlite.org/whentouse.html ?

O SQLite geralmente funcionará muito bem como o mecanismo de banco de dados para sites de tráfego de baixo a médio porte (ou seja, 99,9% de todos os sites).A quantidade de tráfego da Web que o SQLite pode lidar depende, é claro, de quão fortemente o site usa seu banco de dados.De um modo geral, qualquer site que obtenha menos de 100 mil hits/dia deve funcionar bem com o SQLite.A figura de 100k acertos/dia é uma estimativa conservadora, não um limite superior duro.Demonstrou -se que o SQLite trabalha com 10 vezes essa quantidade de tráfego.

Answer 6

A escalabilidade do SQLite dependerá muito dos dados usados ​​e de seu formato.Tive algumas experiências difíceis com tabelas extra longas (registros GPS, um registro por segundo).A experiência mostrou que o SQLite ficaria lento em etapas, em parte devido ao constante reequilíbrio das crescentes árvores binárias contendo os índices (e com índices com carimbo de data e hora, você apenas saber essa árvore vai ser muito reequilibrada, mas é vital para suas pesquisas).Então, no final, com cerca de 1 GB (muito aproximado, eu sei), as consultas ficam lentas no meu caso.Sua milhagem irá variar.

Uma coisa a lembrar: apesar de toda a ostentação, o SQLite NÃO foi feito para armazenamento de dados.Existem vários usos não recomendado para SQLite.As boas pessoas por trás do SQLite dizem elas mesmas:

Outra maneira de ver o SQLite é esta:SQLite não foi projetado para substituir o Oracle.Ele foi projetado para substituir fopen().

E isso leva ao argumento principal (não quantitativo, desculpe, mas qualitativo): o SQLite não é para todos os usos, enquanto o MySQL pode cobrir muitos usos variados, mesmo que não seja o ideal.Por exemplo, você poderia fazer com que o MySQL armazenasse cookies do Firefox (em vez do SQLite), mas você precisaria desse serviço em execução o tempo todo.Por outro lado, você poderia ter um site transacional rodando em SQLite (como muitas pessoas fazem) em vez de MySQL, mas esperaria muito tempo de inatividade.

Answer 7

acho que um servidor web (em números 1) que atende centenas de clientes aparece no backend com uma única conexão com o banco de dados, não é?

Portanto não há acesso simultâneo no banco de dados e portanto podemos dizer que o banco de dados está funcionando em 'modo de usuário único'.Não faz sentido discutir o acesso multiusuário em tal circunstância e, portanto, o SQLite funciona tão bem quanto qualquer outro banco de dados baseado em servidor.

Answer 8

Pense desta forma.O SQL Lite será bloqueado toda vez que alguém o usar (o SQLite não bloqueia na leitura).Portanto, se você estiver servindo uma página da web ou um aplicativo que tenha vários usuários simultâneos, apenas um poderá usar seu aplicativo por vez com o SQLLite.Então, aí está um problema de escala.Se for um aplicativo individual, digamos, uma biblioteca de música onde você mantém centenas de títulos, classificações, informações, uso, reprodução, tempo de reprodução, o SQL Lite será dimensionado lindamente, mantendo milhares, senão milhões de registros (se for necessário o disco rígido)

O MySQL, por outro lado, funciona bem para aplicativos de servidores onde pessoas de todo o mundo o usarão simultaneamente.Não trava e é bastante grande.Portanto, para a sua biblioteca de música, o MySql seria um exagero, pois apenas uma pessoa o veria, A MENOS que esta seja uma biblioteca de música compartilhada onde milhares de pessoas a adicionam ou atualizam.Então o MYSQL seria o único a usar.

Então, em teoria, o MySQL é melhor dimensionado que o Sqllite porque ele pode lidar com vários usuários, mas é um exagero para um aplicativo de usuário único.

Answer 9

O site do SQLite (a parte que você referenciou) indica que ele pode ser usado para diversas situações multiusuário.

Eu diria que ele aguenta bastante.Na minha experiência, sempre foi muito rápido.Claro, você precisa indexar suas tabelas e, ao codificá-las, certifique-se de usar consultas paramerizadas e similares.Basicamente a mesma coisa que você faria com qualquer banco de dados para melhorar o desempenho.

Answer 10

Talvez valha a pena conferir Servidor SQL REAL, que é um servidor de banco de dados construído em SQLite.