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

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

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

Ontem eu 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 ele colocou no meu host, ele correu bem devagar. Isso ocorre porque o banco de dados inteiro foi bloqueado toda vez que alguém visualizava a página porque ela 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 recebendo um erro de banco de dados bloqueado ao tentar executar consultas do shell no sqlite. Dito isto, estou executando outro site do SQLite muito bem. A diferença é que o site é estático (ou seja, eu sou o único que pode alterar o banco de dados) e, portanto, funciona muito bem para leituras simultâneas. Moral da história:

edit : Acabei de perceber que talvez não tenha 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 de bloqueio de banco de dados permanece - se você tiver atualizações particularmente onerosas, o desempenho do SQLite não corresponderá ao MySQL ou ao Postgres.

Outra edição: desde que publiquei isso há quase três meses, tive a oportunidade de examinar atentamente a escalabilidade do SQLite e, com alguns truques, pode ser bastante escalável. Como mencionei na minha primeira edição, os índices de banco de dados reduzem drasticamente o tempo de consulta, mas isso é mais uma observação geral sobre bancos de dados do que sobre SQLite. No entanto, há um outro truque que você pode usar para acelerar 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 ocorrerá apenas uma vez quando a transação for concluída.

O site que mencionei que lançamos no primeiro parágrafo foi alterado novamente para o SQLite e está funcionando sem problemas depois que eu ajustei meu código em alguns lugares.

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

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

Mas como é usuário único, depende do tipo de dimensionamento que você está falando.

Em resposta a 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 (com efeito, toda instrução SQL que modifica o banco de dados) bloqueia o arquivo , o que impedirá que outros usuários acessem o banco de dados em tudo .

Portanto, se você tiver feito muitas modificações no banco de dados, terá 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 é claro que o Sqlite funcionará em um ambiente multiusuário, mas não terá um bom desempenho .

O SQLite dirige o site sqlite.org e outros que têm muito tráfego. Eles sugerem que, se você tiver menos de 100 mil ocorrências por dia, o SQLite funcionará bem. E isso foi escrito antes da entrega do recurso "Writeahead Logging".

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

• atualizar para o SQLite 3.7.x
• Ativar log 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 ficando sem memória diretamente.

Você pode dar uma olhada no meu vídeo no YouTube chamado " Melhorar o desempenho do SQLite com o log do Writeahead ", que mostra como usar o log write-ahead e demonstra uma melhoria de velocidade de 5x em gravações.

SQLite é uma área de trabalho ou em processo de banco de dados. SQL Server, MySQL, Oracle e seus irmãos são servidores .

Os bancos de dados da área de trabalho, por natureza, não são uma boa opção para qualquer aplicativo que precise oferecer suporte ao 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 algo, provavelmente precisará de acesso de gravação ao banco de dados.

Você leu esses documentos SQLite - http://www.sqlite.org/whentouse.html ?

O SQLite geralmente funciona muito bem como o mecanismo de banco de dados para sites de tráfego baixo a médio (ou seja, 99,9% de todos os sites). A quantidade de tráfego da Web que o SQLite pode suportar depende, é claro, da intensidade com que o site usa seu banco de dados. De um modo geral, qualquer site que receba menos de 100 mil hits / dia deve funcionar bem com o SQLite. O número de 100 mil acessos / dia é uma estimativa conservadora, não um limite superior rígido. Demonstrou-se que o SQLite trabalha com 10 vezes essa quantidade de tráfego.

A escalabilidade do SQLite dependerá muito dos dados utilizados e de seu formato. Eu tive uma experiência difícil com tabelas extra longas (registros GPS, um registro por segundo). A experiência mostrou que o SQLite diminuiria a velocidade dos estágios, em parte devido ao constante reequilíbrio das árvores binárias em crescimento que mantêm os índices (e com índices com registro de data e hora, você sabe que a árvore ficará muito reequilibrada, mas é vital para o seu pesquisas). Então, no final, com cerca de 1 GB (muito parecido, eu sei), as consultas se tornam lentas no meu caso. Sua milhagem varia.

Uma coisa a lembrar, apesar de todos os gabaritos, o SQLite NÃO é feito para armazenamento de dados. Existem vários usos não recomendados para SQLite. As pessoas legais por trás do SQLite dizem:

Outra maneira de analisar o SQLite é o seguinte: o 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), SQLite não é para todos os usos, enquanto o MySQL pode cobrir muitos usos variados, mesmo que não seja ideal. Por exemplo, você pode ter o MySQL armazenando cookies do Firefox (em vez do SQLite), mas você precisa desse serviço em execução o tempo todo. Por outro lado, você pode ter um site transacional em execução no SQLite (como muitas pessoas fazem) em vez do MySQL, mas espera muito tempo de inatividade.

Eu acho que um servidor Web (no número 1) atendendo a centenas de clientes aparece no back-end com uma única conexão com o banco de dados, não é?

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

Pense desta maneira. O SQL Lite será bloqueado sempre que alguém o usar (o SQLite não trava na leitura). Portanto, se você estiver fornecendo 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. Portanto, existe um problema de escala. Se for um aplicativo para uma pessoa, apenas uma biblioteca de músicas, onde você detém centenas de títulos, classificações, informações, uso, reprodução e tempo de reprodução, o SQL Lite escalará lindamente, mantendo milhares, se não milhões, de registros (se o disco rígido estiver disponível)

Por outro lado, o MySQL funciona bem para aplicativos de servidores, onde pessoas de todo o mundo o usarão simultaneamente. Ele não trava e é muito grande em tamanho. Portanto, para a sua biblioteca de músicas, o MySql seria superado como apenas uma pessoa a veria, A menos que seja uma biblioteca de músicas compartilhada, na qual milhares a adicionam ou atualizam. Então MYSQL seria o único a usar.

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

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

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

Pode valer a pena conferir o REAL SQL Server , que é um servidor de banco de dados criado no SQLite.