SQLite auf einem Produktionsserver? [geschlossen]

Ich kenne SQLite schon lange und weiß, dass es sehr schnell geht, aber ich habe es noch nie auf einem Produktionsserver ausprobiert. Ich konnte nie eine solide Schätzung darüber finden, wie viel Verkehr es verarbeiten konnte, bevor es fehlschlug.

Hat jemand irgendwelche Zahlen oder einen Artikel dazu?

Leider habe ich keine Zahlen zu den Ladefähigkeiten für Sie, aber ein paar Kommentare zu einigen der leistungsbeschränkenden Faktoren:

• Die Geschwindigkeit von SQLite wird von der Geschwindigkeit der Festplatte beeinflusst, auf der es sich befindet, und davon, ob viele Einfügungen / Aktualisierungen ausgeführt werden (dh Schreibzugriff). Die Schreibsperre ist durch die Disk-Spin-Geschwindigkeit begrenzt

• Transaktionen werden standardmäßig gestartet, aber Sie erhalten eine bessere Leistung, wenn Sie die Transaktion starten und festschreiben. Ich hatte sehr schnelle Masseneinfügungen, als ich die Transaktion programmgesteuert abwickelte

• Wenn Sie im Allgemeinen nur Daten lesen , erhalten Sie meiner Erfahrung nach eine gute Leistung. Daher kann SQLite als Caching-System zum Speichern von Datenbankserver-Lesevorgängen, insbesondere von Remote-Lesevorgängen oder komplexen Abfragen verwendet werden.

• Es verbraucht weniger Ressourcen als ein Datenbankserver, daher kann dies die Site-Leistung beeinträchtigen, da mehr Ressourcen für den Webserver und den Anwendungscode freigegeben werden

• Wenn Sie mehrere gleichzeitige Schreibvorgänge benötigen, um möglich zu sein, kann ein Datenbankserver (z. B. MySQL, Postgres) Ihnen möglicherweise bessere Dienste leisten

Wie Devrim feststellte, sollten laut SQLite-Site etwa 100.000 Benutzer pro Tag in Ordnung sein. Ein Trac-System erfordert Schreibvorgänge, sodass die Leistung in diesem Fall wahrscheinlich geringer ist

Ich möchte diesen guten Antworten einige Punkte hinzufügen.

Die aktuelle Version von SQLite verfügt über WAL (Write-Ahead Logging), sodass das Lesen und Schreiben gleichzeitig erfolgen kann. Daher besteht die in den vorherigen Antworten erwähnte traditionelle Einschränkung für einzelne Autoren nicht mehr. Ich habe WAL noch nicht in der Produktion gesehen, daher kann ich nicht sagen, wie gut es skaliert.

Wenn Sie WAL verwenden oder nicht, kann Ihre SQLite-Datenbank, wenn sie schreibgeschützt ist (oder stapelweise aktualisiert wird) und in den Arbeitsspeicher passt (Ihr Betriebssystem verfügt über genügend freien Arbeitsspeicher, um sie in Puffern zu halten), in einer Produktionswebanwendung sehr gut skaliert werden. Ich persönlich war sehr skeptisch in Bezug auf Leistung, Skalierbarkeit und Robustheit, aber jetzt, nach neun Monaten in der Produktion , hat sich gezeigt, dass selbst die komplexesten Teile des Systems sehr gut funktionieren .

Sqlite eignet sich hervorragend zum Einbetten in Anwendungen, und dafür wurde es entwickelt, aber es ist mit Sicherheit nicht "blitzschnell". Ich verwende es für mehrere meiner eigenen Anwendungen, nur um nur zwei Dateien zu haben, die auf einen anderen Computer kopiert werden können, um eine voll funktionsfähige Anwendung zu erhalten. Tests gegen MySQL mit derselben Struktur, denselben Indizes usw. zeigen, dass Sqlite selbst für kleine Datenbanken erheblich langsamer ist. Ich würde erwarten, dass der Leistungsunterschied mit zunehmender Datenbankgröße zunimmt, obwohl ich nicht sicher sagen kann, dass ich ihn nur mit Datenbanken mit weniger als 100 MB verwendet habe.

Ich denke, SQLite ist nur schneller als eine Text- / XML-Datei (Sie könnten überrascht sein, wenn Sie es versucht haben). Und es unterstützt keine Parallelität, wenn Sie eine Site für das Intranet erstellen möchten, auf der Benutzer ihre Arbeitszeiten registrieren oder Trac-Ticketing verwenden, kann dies hilfreich sein. Ansonsten sollte es vermieden und durch MySQL oder Couchdb ersetzt werden.

Auf der SQLite-Website heißt es, dass 100.000 Benutzer / Tag in Ordnung sein sollten, aber ich bezweifle es sehr, da ein einfaches Trac-Projekt bei einer Nutzung von 10 Personen im Büro häufig hängen bleibt.

SQLite ist keine herkömmliche Client / Server-DB-Anwendung. Es ist im Wesentlichen eine Bibliothek, die in eine andere Anwendung eingebettet ist. Es wurde für Einzelbenutzer-Desktopanwendungen entwickelt. Sie möchten auf keinen Fall versuchen, es als eigenständigen MySQL / PostgreSQL / MS-SQL-Ersatz in einer Mehrbenutzerumgebung zu verwenden, da die gesamte Datenbank beim Schreiben gesperrt ist. Sie werden selbst bei geringer Belastung mit Konfliktproblemen zu tun haben, die die Leistung beeinträchtigen.