Websites für den internen Gebrauch: Gibt es einen überzeugenden Fall gegen SQLite?

Viele Webframeworks wie Flask oder Django verwenden SQLite als Standarddatenbank. SQLite ist überzeugend, weil es in Python enthalten ist und der administrative Aufwand ziemlich gering ist.

Die meisten öffentlichen Produktionsstätten mit hohem Datenaufkommen verwenden jedoch eine umfangreichere Datenbank: mySQL, Oracle oder postgresql.

Die Fragen :

Annehmen:

• Der Datenverkehr auf der Website ist mäßig und es wird gleichzeitig Lese- / Schreibzugriff auf die Datenbank gewährt
• Wir werden SQLAlchemy mit SQLite-Schreibsperren verwenden (obwohl dieser Kommentar mich etwas nervös macht)
• Die Datenbank wird möglicherweise 60.000 Datensätze enthalten
• Datenstrukturen erfordern keine erweiterten Funktionen in schwereren Datenbanken

Gibt es jemals ein überzeugendes Argument gegen die SQLite- Parallelität für Websites, die als interne Tools für Unternehmen mit mäßigem Datenverkehr dienen? Wenn ja, unter welchen Bedingungen treten bei SQLite Parallelitätsprobleme auf?

Ich suche nach bekannten spezifischen Ursachen, anstatt nach allgemeiner Angst / unbegründetem Fingerzeigen.

Ich empfehle, die offizielle Antwort auf Ihre Frage " Geeignete Verwendungen für SQLite" zu lesen . Insbesondere warnt "Situationen, in denen ein anderes RDBMS möglicherweise besser funktioniert", dass SQLite das gleichzeitige Schreiben nicht unterstützt:

SQLite unterstützt eine unbegrenzte Anzahl gleichzeitiger Leser, lässt jedoch zu jedem Zeitpunkt nur einen Schreiber zu. In vielen Situationen ist dies kein Problem. Jede Anwendung erledigt ihre Datenbankarbeiten schnell und fährt fort, und keine Sperre dauert länger als ein paar Dutzend Millisekunden. Es gibt jedoch einige Anwendungen, die mehr Parallelität erfordern, und diese Anwendungen müssen möglicherweise nach einer anderen Lösung suchen.

Aus der Perspektive der Angemessenheit neige ich dazu, SQLite als ein sehr ausgefeiltes Dateiformat anzusehen, das SQL-Abfragen unterstützt. Ich würde SQLite eher vermeiden, wenn ich meine Datenbank von meiner Webanwendung trennen möchte, da sie nicht für diesen Fall optimiert ist. Kurz gesagt, SQLite ist für die Verwendung in einigen Szenarien nicht ausreichend skalierbar. Daher ist es für Benutzer von Websites, die hoffen, dass sie irgendwann populär werden, möglicherweise besser, mit etwas Skalierbarem zu beginnen, als mit SQLite zu arbeiten und später zu wechseln.

Trotzdem ist SQLite für die meisten internen Websites in Ordnung. In der Regel erfordern interne Websites nicht dasselbe Maß an Parallelität und Skalierbarkeit.

Wenn ich meinen IT-Direktor aufsetze, sehe ich hier ein paar No-Gos:

• Gefahr der Datenkorruption. Vielleicht mehr als real, aber am Ende des Tages ist dies ein nicht-transaktionaler Dateityp-DB, der nicht viel zu tun hat, außer zu fragen, ob Sie ein aktuelles Backup haben. Apropos. . .
• Wie kann ich dieses Ding sichern? In gewisser Weise weiß ich, dass ich ein gutes Exemplar habe. Am besten ohne die App offline zu nehmen.
• Wie kann ich den Zugriff auf die DB sichern? Mein allgemeines Verständnis ist, dass SQL Lite keinen Zugriff außerhalb des Dateisystems hat. Dies ist ein guter Anfang, aber nicht das A und O. Besonders für Web-Apps, bei denen Sie möglicherweise mehr abgestufte Berechtigungen als DBA oder nichts möchten.

Aus Entwicklersicht ist es meiner Meinung nach wichtig zu wissen, warum SqlLite die Standardeinstellung ist - weil es einfach ist und sich gut als Demo eignet. Wenn Sie eine Plattform an neue Entwickler "verkaufen", ist es entscheidend, dass Sie eine funktionierende Web-App mit minimalem Aufwand starten können. Das Aufstehen und die ordnungsgemäße Konfiguration eines Datenbankservers wäre ein massiver Stolperstein, der vermieden werden muss.