it-swarm.com.de

Was ist eine realistische, reale, maximale Größe für eine SQLite-Datenbank?

Gemäß diesem Artikel über Geeignete Verwendungen für SQLite heißt es, dass SQLite auf 140 Terabyte beschränkt ist, ein Client/Server RDBMS funktioniert möglicherweise besser:

Die Größe einer SQLite-Datenbank ist auf 140 Terabyte (2) begrenzt47 Bytes, 128 Tibibytes). Und selbst wenn es größere Datenbanken verarbeiten könnte, speichert SQLite die gesamte Datenbank in einer einzigen Festplattendatei, und viele Dateisysteme beschränken die maximale Dateigröße auf etwas weniger. Wenn Sie also Datenbanken dieser Größenordnung in Betracht ziehen, sollten Sie ein Client/Server-Datenbankmodul verwenden, das den Inhalt auf mehrere Festplattendateien und möglicherweise auf mehrere Volumes verteilt.

Im Allgemeinen stimme ich dem zu, aber ich war überrascht zu erfahren, dass das maximale Limit von SQLite so hoch war! Nach meiner Erfahrung habe ich einige SQL Server-Datenbanken mit einer Größe von ~ 30-100 GB verwendet. Ich habe auch indirekt mit viel größeren Datenbanken mit Oracle, Postgres oder Cassandra gearbeitet. Zumindest meines Wissens näherte sich keiner von diesen 140 TB. Ich bin kein DBA, daher würde ich dies aus meiner direkten Erfahrung als "groß" betrachten.

Ich habe SQLite nur für Situationen in Betracht gezogen, in denen die Datenbank winzig wäre. höchstens Dutzende Megabyte.

Nach dem Lesen dieses Artikels bin ich immer noch nicht davon überzeugt, SQLite jemals für irgendetwas in Betracht zu ziehen, das Hunderte von Gigabyte erfordern könnte. Aber ich frage mich, ob ich seine Fähigkeiten unterschätzt habe. Was ist eine realistische maximale Größenbeschränkung für eine SQLite-Datenbank in der Praxis?

38
Ben Harrison

Das realistische Limit (der Größe einiger Sqlite-Datenbanken) entspricht dem realistischen Limit für eine Datendatei. Und diese Grenze hängt stark von Ihrem Computer und System ab. Auf meinem aktuellen Linux-Desktop kann ich mir nicht viel mehr als eine 350-GByte-Datei leisten (da ich als Faustregel vermeide, dass eine einzelne Datei mehr als eine halbe Festplattenpartition verbraucht). Übrigens wirkt sich diese praktische Grenze auch auf andere SQL-RDBMS wie PostGreSQL oder MariaDB aus (aber die meisten von ihnen speichern Daten in mehreren Dateien, die Sie möglicherweise auf verschiedenen Dateisystemen aufbewahren, und einige von ihnen sind in der Lage verteilte Daten auf Remotecomputern verwalten ...)

Nach dem Lesen dieses Artikels bin ich immer noch nicht davon überzeugt, SQLite jemals für irgendetwas in Betracht zu ziehen, das Hunderte von Gigabyte erfordern könnte

Du bist richtig und falsch.

Sie haben Recht, denn auf dem heutigen Computer (Laptops und Desktops, keine Supercomputer oder Rechenzentrumserver) sind 100 Gigabyte immer noch ein ziemlich großer Speicherplatz. Wenn Sie also in der Praxis an eine so große Datenbank denken, sollten Sie sich einen echten SQL-Server (à la PostGreSQL) besser vorstellen, insbesondere, weil Sie sehr wahrscheinlich Remotezugriff, effektiv gleichzeitigen Zugriff und wahrscheinlich verteilte Daten und Tabellen wünschen.

Sie liegen (im Prinzip habe ich es nie versucht) falsch, weil SQLite höchstwahrscheinlich in der Lage (und manchmal getestet) ist, mit einer Datenbank von mehreren hundert Gigabyte umzugehen, vorausgesetzt, Sie haben ein Dateisystem, das mit einer so großen Datei umgehen kann (und wahrscheinlich zwei davon) sie zumindest).

Ich würde SQLite sicherlich (manchmal) für Datenbanken mit mehreren Dutzend Gigabyte in Betracht ziehen (und ich habe einmal eine so große .sqlite-Datei mit einem IIRC von 40 GB versucht). Auf aktuellen (Nicht-Supercomputer-) Computern würde ich zögern, viele hundert Gigabyte SQLite-Datenbank zu haben, einfach weil eine solche Datei nach heutiger Praxis ziemlich groß ist.

IIRC Einige Hardwareanbieter, die spezialisierte Dateisystemmaschinen verkaufen, haben mich einmal von einer Terabyte-SQLite-Anwendung gesprochen (aber ich könnte mich irren).

Natürlich hängt die SQLite-Leistung (wie alle SQL-Datenbanken) sehr viel von der Anzahl und Breite der Tabellen, ihren Indizes und den beteiligten SQL-Abfragen ab. Und Sie möchten keinen gleichzeitigen Zugriff haben (durch viele verschiedene Prozesse), und Sie sollten die Transaktion verwenden (erfahrungsgemäß möchten Sie selbst in einer winzigen SQLITE-Datenbank von wenigen Megabyte Ihre z. B. tausend Einfügeanforderungen wirklich mit BEGIN TRANSACTION umschließen & END TRANSACTION, wenn Sie dies nicht tun, wird Sqlite um einen großen Faktor verlangsamt (mehr als 10x-).

Aus persönlicher Erfahrung kann SQLite mit einer geeigneten Konfiguration und Organisation eine Datenbank verwalten, die größer als verfügbar ist RAM (30 GB sind also kein Problem) - aber Sie möchten wahrscheinlich, dass die Indizes in den RAM passen !

Wenn Sie etwas für einen "Supercomputer" oder eine teure Workstation codieren (z. B. mit 512 GByte RAM und 8 TByte Festplatte und 512 GByte SSD)), können Sie sicherlich eine Terabyte-SQLite-Datenbank haben. Aber Sie Ich möchte das vielleicht nur tun, wenn ein (oder sehr wenige) Prozesse auf diese Datenbank zugreifen. Wenn ein Dutzend Prozesse gleichzeitig auf dieselbe Datenbank zugreifen, installieren Sie besser ein echtes SQL-RDBMS (à la MariaDB oder PostGreSQL).

Beachten Sie auch, dass das (binäre) Format von .sqlite Datenbankdateien dokumentiert als "portabel" ist, ich es jedoch sehr bevorzuge, Datenbanken im SQL Text Format (unter Verwendung von sqlite3 mydb.sqlite .dump > mydb.sql) zu sichern ). Dann brauche ich auch zusätzlichen Speicherplatz für diesen Text-Dump (und das senkt die realistische Grenze).

Normalerweise ist Sqlite nicht der Engpass. Aber die Festplatte könnte sein.

PS. Die gleiche Überlegung könnte mit GDBM auf große indizierte Dateien angewendet werden.

PPS. In meinem expjs Zweig (September 2016) meines MELT-Monitors (GPLv3-freie Software, auf Github) bin ich weiterhin der gesamte Anwendungsheap in JSON in einer neuen Sqlite-Datenbank. Ich habe winzige Experimente mit mehreren Millionen Objekten (ziemlich "groß") ohne böse Überraschungen durchgeführt. YMMV.

28