Sites de uso interno: existe um caso convincente contra o SQLite?


23

Muitas estruturas da web, como Flask ou Django, usam SQLite como seu banco de dados padrão. O SQLite é atraente porque está incluído no python, e a sobrecarga administrativa é bastante baixa.

No entanto, a maioria dos sites de produção pública de alto tráfego acaba usando um banco de dados mais pesado: mySQL, Oracle ou postgresql.

As perguntas :

Assumir:

  • O tráfego do site é moderado e o acesso simultâneo de leitura / gravação ao banco de dados ocorrerá
  • Usaremos SQLAlchemy com bloqueios de gravação SQLite (embora esse comentário me deixe um pouco nervoso)
  • O banco de dados conterá talvez 60.000 registros
  • As estruturas de dados não exigem recursos avançados encontrados em bancos de dados mais pesados

Existe um caso convincente contra a concorrência SQLite para sites que servem como ferramentas corporativas internas de tráfego moderado? Em caso afirmativo, quais condições farão com que o SQLite tenha problemas de simultaneidade?

Estou procurando causas-raiz específicas conhecidas, em vez de medo geral / apontamento sem fundamento dos dedos.


Como é o sqllite com recursos como replicação etc que podem ser úteis para backups etc? No SQLlite, tenho a impressão de que o aplicativo possui o banco de dados. Você pode executar scripts de administração etc. enquanto seu aplicativo estiver ativo?
Doug T.

1
Algumas anedotas sobre SQLite e simultaneidade (na maior parte positivos): acesso simultâneo sqlite3
Daniel B

1
No caso de um site interno, qual é o motivo convincente para o SQLite? Alguma restrição na instalação de um RDBMS?
JeffO 3/13/13

Além de simplificar o ambiente de desenvolvimento nos laptops de desenvolvedores individuais, não há um motivo. A questão, claro, é se podemos razoavelmente simplificar o desenvolvimento e produção ambiente
Mike Pennington

Respostas:


23

Eu recomendo a leitura da resposta oficial à sua pergunta, Usos apropriados para SQLite . Especificamente, as "Situações em que outro RDBMS pode funcionar melhor" avisa que o SQLite não oferece suporte à gravação simultânea:

O SQLite suporta um número ilimitado de leitores simultâneos, mas permitirá apenas um gravador a qualquer instante no tempo. Para muitas situações, isso não é um problema. Cada aplicativo faz seu trabalho de banco de dados rapidamente e segue em frente, e nenhum bloqueio dura mais do que algumas dezenas de milissegundos. Mas existem alguns aplicativos que exigem mais simultaneidade e esses aplicativos podem precisar procurar uma solução diferente.

Do ponto de vista da adequação, costumo ver o SQLite como um formato de arquivo muito sofisticado que suporta consultas SQL. Eu tenderia a evitar o SQLite se quisesse separar meu banco de dados do meu aplicativo da Web, pois não é otimizado para este caso. Em suma, o SQLite é insuficientemente escalável para uso em alguns cenários; portanto, as pessoas que executam sites que esperam algum dia se tornar populares podem ter uma melhor idéia começando com algo escalável, em vez de usar o SQLite e depois serem forçadas a mudar.

Tudo isso dito, o SQLite provavelmente é bom para a maioria dos sites internos; sites geralmente internos não exigem o mesmo nível de simultaneidade e escalabilidade.


Nem a maioria dos sites externos. O mecanismo de banco de dados pode ser trocado se algo como EF for usado, embora o PostGres provavelmente seja uma escolha melhor desde o início.
Robert Harvey

@RobertHarvey o que é EF?
Mike Pennington

@ MikePennington: Entity Framework. Imagino que existam outros ORMs que também tenham transparência no banco de dados ou, pelo menos, possam trocar os drivers.
Robert Harvey

1
O equivalente pythônico seria algo como SQL Alchemy
Wyatt Barnett

"Costumo ver o SQLite como um formato de arquivo muito sofisticado que suporta consultas SQL." Definição perfeita.
Curinga

4

Colocando meu chapéu de diretor de TI, vejo alguns não-gos aqui:

  • Risco de corrupção de dados. Talvez seja mais percebido do que real, mas no final do dia esse é um banco de dados não transacional do tipo DB que não tem muito ou nenhum recurso a gravações ruins, além de perguntar se você tem um backup recente. Falando nisso . . .
  • Como eu apoio essa coisa? De certo modo, sei que tenho uma boa cópia. De preferência sem colocar o aplicativo offline.
  • Como posso proteger o acesso ao banco de dados? Meu entendimento geral é que o SQL Lite não tem nenhum fora do acesso ao sistema de arquivos, que é um começo decente, mas não o princípio final. Especialmente para aplicativos da Web onde você pode querer mais permissões graduadas do que DBA ou nada.

Do ponto de vista do desenvolvedor, acho importante saber por que o SqlLite é o padrão - é por ser fácil e demonstrar bem. Se você está "vendendo" uma plataforma para novos desenvolvedores, é fundamental ativar um aplicativo da web que funcione com o mínimo de esforço. E ter que se levantar e configurar adequadamente um servidor de banco de dados seria um enorme obstáculo a ser evitado.


1
Bem, os backups podem ser feitos através da API de backup do SQLite . Reconheço que o SQLite pode não ser tão seguro por padrão, pois, diferentemente dos sistemas orientados a serviços, os clientes SQLite conversam com o arquivo do banco de dados mais diretamente. Dito isso, o SQLite usa um diário para se proteger contra falhas no sistema e deve ser confiável se o sistema operacional host suportar adequadamente os primitivos de bloqueio que o SQLite usa (a E / S do disco de rede não). O site oficial lista vários cenários que levarão a um banco de dados SQLite corrompido.
Brian

SQLite é transacional . Use a API de backup ou adapte o script de backup do MediaWiki para realizar backups online. Seu entendimento geral do modelo de segurança do SQLite está correto. O conselho oficial de segurança é 'use o bom senso': pense em como as pessoas poderiam acessar seu arquivo de banco de dados e projetar seu aplicativo Web de acordo.
Iain Samuel McLean Elder

@ Brian - Eu seria difícil pensar em outro banco de dados que tenha uma página inteira dedicada a "como esse banco de dados pode ser corrompido". Vou acrescentar que acho o projeto sql lite incrível - eles provavelmente têm essa página porque são doidos e também têm algo como 10 linhas de código de teste para cada linha de código de produção e realmente gostam de ter certeza e de que estão bem.
Wyatt Barnett
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.