¿Qué es un tamaño máximo realista y real para una base de datos SQLite?

De acuerdo con este artículo sobre Usos apropiados para SQLite , dice que, si bien SQLite está limitado a 140 terabytes , un RDBMS cliente / servidor puede funcionar mejor:

Una base de datos SQLite tiene un tamaño limitado a 140 terabytes (2 ⁴⁷ bytes, 128 tibibytes). E incluso si pudiera manejar bases de datos más grandes, SQLite almacena la base de datos completa en un solo archivo de disco y muchos sistemas de archivos limitan el tamaño máximo de los archivos a algo menos que esto. Entonces, si está contemplando bases de datos de esta magnitud, haría bien en considerar el uso de un motor de base de datos cliente / servidor que distribuya su contenido en múltiples archivos de disco, y quizás en múltiples volúmenes.

En general, estoy de acuerdo con esto, ¡pero me sorprendió saber que el límite máximo de SQLite era tan alto! En mi experiencia, he usado bastantes bases de datos de SQL Server en el tamaño de ~ 30-100GB. También he trabajado indirectamente con bases de datos mucho más grandes usando Oracle, Postgres o Cassandra. De ellos, al menos que yo sepa, ninguno se acercaba a 140 TB. No soy un DBA, así que esto es lo que consideraría "grande" por mi experiencia directa.

Solo he considerado SQLite para situaciones donde la base de datos sería pequeña; docenas de megabytes como máximo.

Después de leer este artículo, todavía no estoy convencido de considerar SQLite para algo que pueda requerir cientos de gigabytes. Pero me pregunto si he estado subestimando sus capacidades. ¿Cuál es un límite de tamaño máximo realista para una base de datos SQLite en uso en el mundo real?

El límite realista (del tamaño de alguna base de datos Sqlite) es el mismo que el límite realista para un archivo de datos. Y ese límite depende mucho de su computadora y sistema. En mi escritorio Linux actual, no puedo permitirme mucho más que un archivo de 350 Gbytes (porque, como regla general, evito que un solo archivo consuma más de la mitad de una partición de disco). Por cierto, ese límite práctico también afecta a otros RDBMS de SQL como PostGreSQL o MariaDB (pero la mayoría de ellos guarda datos en varios archivos, que puede guardar en diferentes sistemas de archivos, y algunos de ellos pueden administrar datos distribuidos en máquinas remotas. .)

Después de leer este artículo, todavía no estoy convencido de considerar SQLite para algo que pueda requerir cientos de gigabytes.

Tienes razón y estás equivocado.

Tiene razón, porque en la computadora de hoy (computadoras portátiles y de escritorio, no en supercomputadoras o servidores de centros de datos), cien gigabytes sigue siendo un espacio en disco bastante grande. Entonces, en la práctica, si piensa en una base de datos tan grande, será mejor que imagine un servidor SQL real (a la PostGreSQL) en particular porque es muy probable que desee un acceso remoto, un acceso concurrente efectivo y probablemente datos y tablas distribuidos.

Usted está (en principio, nunca lo intenté) equivocado porque muy probablemente SQLite sea capaz (y a veces probado) de manejar una base de datos de varios cientos de gigabytes, suponiendo que tenga un sistema de archivos capaz de manejar un archivo tan grande (y probablemente dos de ellos al menos).

Ciertamente (a veces) consideraría SQLite para bases de datos de varias docenas de gigabytes (e intenté una vez un .sqlitearchivo tan grande , IIRC de 40Gbytes). En las máquinas actuales (sin supercomputadora), dudaría en tener cientos de gigabytes de base de datos SQLite, simplemente porque dicho archivo es bastante grande según la práctica actual.

IIRC, un proveedor de hardware que vendía máquinas de sistemas de archivos especializados me habló una vez de una aplicación sqlite de terabytes (pero podría estar equivocado).

Por supuesto, el rendimiento de SQLite depende (como todas las bases de datos SQL) de gran parte del número y el ancho de las tablas, sus índices, las consultas SQL involucradas. Y no desea tener acceso simultáneo (por muchos procesos diferentes), y debe usar la transacción (por experiencia, incluso en una pequeña base de datos SQLITE de unos pocos megabytes, realmente desea envolver sus, por ejemplo, miles de solicitudes de inserción con BEGIN TRANSACTION&END TRANSACTION , no hacerlo es ralentizar Sqlite en un factor grande -más de 10x-).

Y por experiencia personal, con una configuración y organización adecuadas, SQLite puede administrar una base de datos más grande que la RAM disponible (por lo que 30Gbytes no es un problema), ¡pero probablemente desee que los índices encajen en la RAM!

Si codifica algo para una "supercomputadora" o una estación de trabajo costosa (por ejemplo, con 512Gbytes de RAM y 8Tbytes de disco y 512Gbyte de SSD), ciertamente puede tener una base de datos Sqlite de terabytes. Pero querrá hacer eso quizás solo si uno (o muy pocos) procesos está accediendo a esa base de datos. Si tiene una docena de procesos accediendo simultáneamente a la misma base de datos, instale mejor un RDBMS SQL real (a la MariaDB o PostGreSQL)

También tenga en cuenta que si bien el formato (binario) de los .sqlitearchivos de la base de datos está documentado como "portátil", prefiero hacer una copia de seguridad de las bases de datos en formato de texto SQL (usando sqlite3 mydb.sqlite .dump > mydb.sql). Entonces, también necesito un poco más de espacio en disco para ese volcado de texto (y eso reduce el límite realista).

Por lo general, Sqlite no es el cuello de botella. Pero el disco podría ser.

PD. El mismo razonamiento podría aplicarse a grandes archivos indexados utilizando GDBM .

^{PPS En mi expjs rama (sept.2016) de mi monitor de fusión (software libre GPLv3, en github) Estoy persistir toda la pila de aplicación en JSON dentro de una base de datos SQLite fresco. He realizado pequeños experimentos con varios millones de objetos (bastante "grandes") sin malas sorpresas. YMMV.}