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 .sqlite
arquivo 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 .sqlite
arquivos 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.