Verwendung von Flatfiles vs. Datenbank / API als Transport zwischen Frontend und Backend

Ich habe eine Anwendung, die eine heftige Diskussion zwischen einigen Entwicklern ausgelöst hat.

Grundsätzlich ist es in eine Web-Ebene und eine Back-End-Ebene aufgeteilt. Die Webebene sammelt Informationen über ein einfaches Webformular und speichert diese Daten als JSON-Dokument (buchstäblich eine JSON-Datei) in einem Überwachungsordner, der vom Back-End verwendet wird. Das Back-End fragt diesen Ordner alle paar Sekunden ab, nimmt die Datei auf und führt ihre Funktionen aus.

Die Dateien selbst sind sehr einfach (dh alle Zeichenfolgendaten, keine Verschachtelung) und etwa 1-2 KB groß, wobei das System den größten Teil seiner Zeit im Leerlauf verbringt (aber bis zu 100 Nachrichten gleichzeitig platzen lässt). Der Backend-Verarbeitungsschritt dauert ca. 10 Minuten pro Nachricht.

Das Argument kommt auf, wenn ein Entwickler vorschlägt, dass die Verwendung des Dateisystems als Messaging-Ebene eine schlechte Lösung ist, wenn stattdessen beispielsweise eine relationale Datenbank (MySQL), eine noSQL-Datenbank (Redis) oder sogar ein einfacher REST-API-Aufruf verwendet werden sollte.

Es ist zu beachten, dass Redis an anderer Stelle in der Organisation für die Verarbeitung von Nachrichten in der Warteschlange verwendet wird.

Die Argumente, die ich gehört habe, setzen sich wie folgt zusammen

Für flache Dateien:

• Flache Dateien sind zuverlässiger als jede andere Lösung, da die Datei erst nach dem Aufnehmen aus einem "Überwachungs" -Ordner in einen "Verarbeitungs" -Ordner und schließlich nach dem Fertigstellen in einen "Fertig" -Ordner verschoben wird. Es besteht kein Risiko, dass Nachrichten verschwinden, es sei denn, es handelt sich um sehr niedrige Fehler, die andere Dinge zerstören würden.

• Für das Verständnis von Flat Files ist weniger technische Raffinesse erforderlich cat. Keine Anfragen zum Schreiben, keine Gefahr, versehentlich eine Nachricht aus der Warteschlange zu entfernen und für immer verschwunden zu sein.

• Dateiverwaltungscode ist vom Standpunkt der Programmierung aus einfacher als Datenbank-APIs, da er Teil der Standardbibliothek jeder Sprache ist. Dies reduziert die Gesamtkomplexität der Codebasis und die Menge des Codes von Drittanbietern, der eingegeben werden muss.

• Das YAGNI-Prinzip besagt, dass Flat Files derzeit einwandfrei funktionieren. Es ist nicht erwiesen, dass auf eine kompliziertere Lösung gewechselt werden muss. Lassen Sie es also.

Für eine Datenbank:

• Es ist einfacher, eine Datenbank zu skalieren als ein Verzeichnis voller Dateien

• Bei Flat Files besteht die Gefahr, dass jemand eine "done" -Datei zurück in das "watch" -Verzeichnis kopiert. Aufgrund der Art dieser Anwendung (Verwaltung virtueller Maschinen) kann dies zu einem katastrophalen Datenverlust führen.

• Die App erfordert mehr technische Raffinesse für T / S, was bedeutet, dass ungelernte Mitarbeiter weniger dazu neigen, etwas zu vermasseln, wenn sie nur an Dingen herumstöbern.

• DB-Verbindungscode, insbesondere für Redis, ist mindestens so robust wie die Standardfunktionen zur Verwaltung von Bibliotheksdateien.

• DB - Verbindungscode ist sichtbar (wenn nicht funktionell) einfacher von einem Entwickler Sicht, da seinem höheren Niveau als Dateimanipulation.

Soweit ich sehen kann, haben beide Entwickler viele gültige Punkte.

Von diesen beiden Personen, den Pro-Files-Entwicklern oder den Pro-Datenbanken-Entwicklern, entspricht die eine eher den Best Practices der Softwareentwicklung, und warum?

Ein Umstieg auf eine Lösung mit Datenbanken oder den von Ewan genannten Warteschlangensystemen wäre möglich

• Abhängigkeit von einem neuen, komplexen System sowohl im Backend als auch im Frontend schaffen
• unnötige Komplexität und eine Unmenge neuer Fehlerquellen einführen
• Kosten erhöhen (einschließlich Betriebskosten)

Das Verschieben / Umbenennen von Dateien innerhalb eines einzelnen Volumes ist auf allen aktuellen Betriebssystemen garantiert unübersehbar, unabhängig von den Schwierigkeiten, die beim Sperren von Dateien / Datensätzen auftreten können. Die Verwaltung von Rechten auf Betriebssystemebene sollte ausreichen, um ungewaschene Vorgänge zu unterbinden und unbeabsichtigte / versehentliche Manipulationen durch autorisierte Bediener (Administratoren / Entwickler) zu verhindern. Daher haben Datenbanken überhaupt nichts zu bieten, solange die Leistung der aktuellen Lösung dem Schnupftabak gewachsen ist.

In unserem Unternehmen verwenden wir seit Jahrzehnten ähnliche dateibasierte Schnittstellen mit großem Erfolg. Viele andere Dinge sind gekommen und gegangen, aber diese Schnittstellen sind aufgrund ihrer Einfachheit, Zuverlässigkeit und minimalen Kopplung / Abhängigkeiten geblieben.

Ich denke nicht, dass eine der beiden Lösungen von Natur aus eine schlechte Praxis ist. Daher kann es schwierig sein, die beste Praxis zu finden.

Ich glaube nicht, dass das YAGNI-Prinzip hier zutrifft, wenn Sie sich mit Skalierung beschäftigen. "Arbeiten" ist relativ, wenn Sie ein starkes Potenzial für einen katastrophalen Datenverlust und eine geringe Skalierbarkeit haben, würde ich dieses Arbeiten nicht wirklich in Betracht ziehen. Ich bin mir nicht ganz sicher, mit welcher Größenordnung Sie es zu tun haben, aber wenn Sie eine große Menge dieser Einträge haben, wird es mit jedem einzelnen schwieriger, auf ein neues System umzusteigen. Wenn dies der Fall ist, würde ich sagen, dass eine Datenbank die beste Vorgehensweise ist.

MongoDB oder Redis (ich habe keine Erfahrung mit Redis, lese nur gute Dinge) sollten in Ordnung sein, da Ihre Daten bereits gut hineinpassen sollten (JSON-Dokumente werden für MongoDB oft trivial in BSON-Dokumente geändert). Es hat auch den zusätzlichen Vorteil, dass viele Daten im Speicher bleiben, anstatt dass die Festplatte ständig häufig gelesen / geschrieben wird. Außerdem wird sichergestellt, dass gleichzeitige Lese- / Schreibvorgänge nicht zu Beschädigung oder Blockierung führen.

Wenn das YAGNI-Prinzip hier zutrifft und die Dateien keinen Engpass darstellen, skalieren sie innerhalb des Gültigkeitsbereichs und haben keine katastrophalen Probleme. Ich würde sagen, dass das Festhalten an den Dateien "Best Practice" ist. Es gibt keinen Grund, irgendetwas zu ändern, wenn es keine Probleme gibt, schreiben Sie vielleicht einige Tests, betonen Sie es und sehen Sie, wo Ihre Grenzen und Engpässe liegen.

Ich bin mir nicht sicher, ob eine Datenbank in diesem Zusammenhang die Lösung ist. Wenn Sie mit Dingen auf demselben Server kommunizieren, könnte eine Art IPC durchgeführt werden, nicht wahr?

Während das Gute daran ist, eine Datei zu speichern und in ein fertiges Verzeichnis zu kopieren, ist dies eine Heftklammer vieler Kommunikationsebenen, insbesondere mit älteren Hauptrahmensystemen und dergleichen. Die 'Anti'-Leute haben einen Punkt; dadurch, dass es viele Probleme und Randfälle hat. Diese Probleme sind schwer zu lösen, wenn Sie eine 100% ige Zuverlässigkeit benötigen. Sie treten häufiger auf, wenn Sie die Häufigkeit und das Volumen von Dateien erhöhen.

Wenn Sie beide Seiten der Transaktion kontrollieren, würde ich vorschlagen, dass Sie sich einige der vielen einfachen Warteschlangensysteme ansehen, die verfügbar sind. ZeroMQ, RabbitMQ, MSMQ usw. statt einer Datenbank. Aber wie Sie andeuten, wenn es nicht kaputt ist ...

Die Datenbanklösung ist die richtige. Es löst eine große Abhängigkeit von einem bestimmten Host oder Randbedingungen.

Beide Lösungen sind ähnlich, mit der Ausnahme, dass die Datenbank nicht auf einem bestimmten Host gehostet wird. Dadurch werden Firewall- / Zugriffsprobleme mit Unix-Systemen beseitigt. Wir hatten Fälle von "versehentlichem" Löschen auf Dateisystemen und niemandem die Schuld.

Mit der Datenbank können Sie das gleiche Problem haben, aber Sie können die Prüfung aktivieren oder nur die Logik einfügen, um Löschungen zu beseitigen.

Wenn Sie im Dateisystem eine Anwendung in den Dateinamen einfügen müssen, z. B. OASIS, müssen Sie die Dateien OASIS.john_doe.system1.20160202 erstellen. Dies wird mühsam und kann in der Datenbank einfacher dargestellt werden. Darauf aufbauend können Sie sogar Nullfelder in der Datenbank und in der Logik haben

Es ist auch einfach, Datenbanken zu aktualisieren, anstatt ein ganzes Dateiverzeichnis, falls Sie Patches oder Korrekturen für Tabellen vornehmen möchten. Natürlich können Sie dies im Dateisystem tun, aber die Datenbankaktualisierung ist intuitiver.

Beispiel: Sie möchten eine erneute Ausführung, aber mit einem anderen System als OASIS. Sagen Sie DESERT und john_doe zu doe_smith und datieren Sie von 20160101 bis 20151231

Einfache Generierung von Zeilen für DESERT / doe_smith / 20151231 aus dem Originalsatz, anstatt diese Dateien mit einem Shell-Skript zu erstellen.

Aus Gründen der Lesbarkeit ist die Datenbanklösung aus Sicht der Erweiterung besser.