O que é um tamanho máximo realista, do mundo real, para um banco de dados SQLite?


33

De acordo com este artigo sobre usos apropriados para SQLite, ele diz que, embora o SQLite esteja limitado a 140 terabytes , um RDBMS cliente / servidor pode funcionar melhor:

Um banco de dados SQLite é limitado em tamanho a 140 terabytes (2 47 bytes, 128 tibibytes). E mesmo que pudesse lidar com bancos de dados maiores, o SQLite armazena o banco de dados inteiro em um único arquivo de disco e muitos sistemas de arquivos limitam o tamanho máximo dos arquivos a algo menor que isso. Portanto, se estiver contemplando bancos de dados dessa magnitude, convém considerar o uso de um mecanismo de banco de dados cliente / servidor que espalhe seu conteúdo por vários arquivos de disco e, talvez, por vários volumes.

Em geral, eu concordo com isso, mas fiquei surpreso ao saber que o limite máximo do SQLite era tão alto! Na minha experiência, usei alguns bancos de dados do SQL Server no tamanho de ~ 30 a 100 GB. Também trabalhei indiretamente com bancos de dados muito maiores usando Oracle, Postgres ou Cassandra. Desses, pelo menos que eu saiba, nenhum deles se aproximava de 140 TB. Eu não sou um DBA, então é isso que eu consideraria "grande" da minha experiência direta.

Eu considerei o SQLite apenas para situações em que o banco de dados seria pequeno; dezenas de megabytes, no máximo.

Depois de ler este artigo, ainda não estou convencido a considerar o SQLite para algo que possa exigir centenas de gigabytes. Mas estou pensando se estive subestimando suas capacidades. O que é um limite de tamanho máximo realista para um banco de dados SQLite em uso no mundo real?


3
Apenas acho que normalmente precisamos considerar o número de conexões simultâneas, já que grandes conjuntos de dados costumam ser consumidos por vários usuários. Existe uma maneira de você testar isso em seu próprio sistema, não existe?
JeffO 26/09/16

3
Para algo como um banco de dados de transações arquivadas que praticamente nunca precisa ser acessado, o SQLite pode ser uma ótima opção, e haverá apenas um usuário por vez (se houver), e você não precisa ter um todo Configuração do servidor de banco de dados para suportá-lo. Se você tiver vários usuários simultâneos, por outro lado, poderá facilmente encontrar problemas com o bloqueio do caminho muito antes de chegar a um banco de dados com vários shows.
Michael Kohne


2
@Pacerier - sim, para instalar o software. Depois, é necessário atribuir funções de banco de dados, descobrir como integrar-se ao seu sistema de backup, garantir que o sistema de backup coloque o servidor de banco de dados no estado adequado no início e no final dos backups, etc. configurar um servidor db do que apenas instalar o software. Além disso, é mais um serviço com o qual você deve se preocupar do ponto de vista de segurança de rede e mais uma coisa com a qual você precisa acompanhar os patches. Se você PRECISA de um serviço de banco de dados, vá em frente, mas não precisa dele, o SQLite tem um custo muito menor.
precisa saber é o seguinte

11
@ leeand00 - Ou você pode alugar espaço por um mês.
JeffO 6/07

Respostas:


26

O limite realista (do tamanho de algum banco de dados Sqlite) é o mesmo que o limite realista de um arquivo de dados. E esse limite depende muito do seu computador e sistema. Na minha área de trabalho atual do Linux, não posso pagar muito maior que um arquivo de 350 GB (porque, como regra geral, evito que um único arquivo consuma mais da metade de uma partição de disco). BTW, esse limite prático também afeta outros SQL RDBMS como PostGreSQL ou MariaDB (mas a maioria deles mantém dados em vários arquivos, que você pode manter em diferentes sistemas de arquivos, e alguns deles conseguem gerenciar dados distribuídos em máquinas remotas. .)

Depois de ler este artigo, ainda não estou convencido a considerar o SQLite para algo que possa exigir centenas de gigabytes

Você está certo e errado.

Você está certo, porque no computador atual (laptops e desktops, não em supercomputadores ou servidores de datacenter), cem gigabytes ainda são um espaço em disco bastante grande. Portanto, na prática, se você pensar em um banco de dados tão grande, é melhor imaginar um servidor SQL real (à PostGreSQL) em particular, porque você pode querer muito provavelmente acesso remoto, acesso simultâneo efetivo e provavelmente dados e tabelas distribuídos.

Você está (em princípio, nunca tentei) errado, porque provavelmente o SQLite é capaz (e às vezes testado) de lidar com um banco de dados de várias centenas de gigabytes, supondo que você tenha um sistema de arquivos capaz de lidar com um arquivo tão grande (e provavelmente dois pelo menos).

Certamente (às vezes) consideraria o SQLite para bancos de dados de várias dezenas de gigabytes (e tentei uma vez um .sqlitearquivo tão grande , o IIRC de 40Gbytes). Nas máquinas atuais (sem supercomputadores), eu hesitaria em ter centenas de gigabytes de banco de dados SQLite, simplesmente porque esse arquivo é bastante grande pela prática de hoje.

IIRC, algum fornecedor de hardware que vendia máquinas especializadas em sistemas de arquivos me falou uma vez de um aplicativo sqlite terabyte (mas eu posso estar errado).

É claro que o desempenho do SQLite depende (como todos os bancos de dados SQL) de grande parte do número e largura das tabelas, seus índices e das consultas SQL envolvidas. E você não deseja ter acesso simultâneo (por muitos processos diferentes) e deve usar transações (por experiência, mesmo em um minúsculo banco de dados SQLITE de poucos megabytes, você realmente deseja agrupar, por exemplo, milhares de solicitações de inserção com BEGIN TRANSACTION& END TRANSACTION, não fazer isso está diminuindo o Sqlite por um grande fator - mais que 10x -).

E por experiência pessoal, com configuração e organização adequadas, o SQLite é capaz de gerenciar um banco de dados maior que a RAM disponível (portanto, 30 Gbytes não é um problema) - mas você provavelmente deseja que os índices se ajustem à RAM!

Se você codificar algo para um "supercomputador" ou uma estação de trabalho cara (com, por exemplo, 512 Gbytes de RAM e 8 Tbytes de disco e 512 Gbyte de SSD), certamente você pode ter um banco de dados Sqlite de terabytes. Mas você desejará fazer isso apenas se um (ou muito) processo (s) estiver acessando esse banco de dados. Se você tiver uma dúzia de processos acessando simultaneamente o mesmo banco de dados, instale melhor um SQL RDBMS real (à MariaDB ou PostGreSQL)

Observe também que, embora o formato (binário) dos .sqlitearquivos de banco de dados seja documentado como "portátil", prefiro fazer backup de bancos de dados no formato de texto SQL (usando sqlite3 mydb.sqlite .dump > mydb.sql). Além disso, também preciso de espaço em disco adicional para esse despejo de texto (e isso reduz o limite realista).

Geralmente, o Sqlite não é o gargalo. Mas o disco pode estar.

PS. O mesmo raciocínio pode ser aplicado a grandes arquivos indexados usando o GDBM .

PPS. Na minha filial expjs ( set.2016 ) do meu monitor MELT (software livre GPLv3, no github), estou persistindo por todo o heap de aplicativos no JSON dentro de um banco de dados Sqlite novo. Realizei pequenas experiências com vários milhões de objetos (bastante "grandes") sem surpresas ruins. YMMV.


7
Você poderia ter parado de escrever após o quarto parágrafo. Mas +1 de qualquer maneira.
Robert Harvey

3
Talvez, mas fiquei desagradavelmente muito surpreso ao notar que, mesmo em um banco de dados sqlite novo de apenas alguns megabytes, as transações são tão importantes na prática (com apenas um único processo acessando, na verdade, escrevendo esse novo arquivo).
Basile Starynkevitch

3
Isso certamente é verdade para gravações. Na prática, é difícil imaginar um banco de dados SQLite com tamanhos como o OP descreve. O Postgresql provavelmente seria uma escolha melhor, não por seus recursos de tamanho, mas pela concorrência industrial que o SQLite não possui.
Robert Harvey

5
Existem muitas situações legítimas nas quais você pode ter bancos de dados SQLite com grandes tamanhos de arquivo. Dos próprios desenvolvedores do SQLite: pense nisso menos como um substituto para o MySql e mais como um substituto para o fopen. Escrever algum software 3D cad e usar bancos de dados SQLite para armazenar dados sobre objetos pode ser perfeitamente razoável.
Whatsisname

2
@Pacerier: arquivos de filmes e blobs binários semelhantes normalmente não são armazenados no banco de dados. Eles são armazenados no sistema de arquivos e os links para eles são armazenados no banco de dados.
Robert Harvey
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.