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

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 ⁴⁷ 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?

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.}