*SQL vs "noSQL"

Moin Moin,

ich würde sagen, dass es auf das Projekt drauf ankommt. Gerade wenn es größer wird, ist IMHO SQL die bessere Wahl. Man kann SQL wunderbar skalieren.

Es hängt - wie mein Vorredner schon sagte - vom Anwendungsbereich ab.

Wenn ich wirklich konsequent mit Microservices arbeite, dann ist der noSQL Ansatz sicherlich sinnvoller. Um Beispielsweise User und ihre Password-Hashes zu prüfen reicht mir ein einfacher Key-Value Store. Der Vorteil daran ist, dass das ganze wie ein Lego-Bausatz ist und ich problemlos neue Komponenten in meine Architektur aufnehmen kann wobei dieses eher dem Buzzword Microservice als noSQL zu verdanken ist.

Im Umgekehrten Fall sehe ich allerdings Probleme bei großen Datenmengen. Jede Interaktion zwischen den Daten muss in einem Service abgebildet werden, welcher dann u.U. auf mehreren Datenbanken erforderliche CRUDs durchführt. Das kann man in einer klassichen SQL-Datenbank eben weitgehend per Foreign-Key, Trigger oder Stored Procedures automatisieren und befreit sich so von ein wenig Komplexität im eigentlichen Programmcode.

Ich selbst habe bisher erst ein einziges Mal einen Ausflug in die noSQL Welt gewagt: eine einfache Logging-Database. Im großen und Ganzen habe ich persönlich jedoch keinen Anwendungszweck an noSQL, da fast alle meine Projekte irgendwie an ein ERP-System auf einer relationalen DB angebunden sind.

Ich bin ein Feind aller Marketingwörter wie Microservices, Hyperconverged, etc, aber die Architektur der Microservices macht sehr viel Sinn, egal wie gross das Projekt ist. Wer sich mit Microservices auseinandersetzt wird aber auch schnell merken das relationelle SQL Transaktionen nicht ganz ins Konzept passen, und hier kommt dann noSQL zum Zuge, und auch nur hier. Es macht keinen Sinn eine monolithische Applikation via noSQL mit Daten zu füttern, aber wenn die Dienste fragmentiert sind und die Abstraktion der Funktionen und ihrer Dienste sehr weit fortgeschritten ist, dann ist es schlicht unmöglich mit reinem SQL von einer Quelle zu arbeiten. Was aber nicht heisst das SQL tot ist. Ich habe mittlerweile diverse Applikationen von mono zu services umprogrammiert, und verwende beides, sprich SQL und noSQL. noSQL wo die Daten eher flüchtiger Natur sind und SQL dort wo tiefe Verknüpfungen über FK realisiert werden müssen, weil die Daten anders nicht strukturiert werden können. Wobei hier aber auch gesagt werden muss, viele Applikationen brauchen gar kein SQL, es macht keinen Sinn wenn man nur n-Tabellen hat welche alle 1:n verknüpft sind.

Beispiel: Rohdaten Speichern von hunderten Sendern >> noSQL (da keine Relation nötig ist). Buchhaltung >> SQL (da Doppelte Buchführung in noSQL etwas schwierig umzusetzen ist).

Und genau hier sieht man den Anwendungsbereich: noSQL dient zum Speichern von nur schwach verknüpften Daten (Kommentare auf Instragram Fotos, Twitter, etc) aber in grossen, schier unmenschlichen Massen. Ein ERP auf SQL mit > 1 Mia Buchungen ist mit noSQL nicht performant umsetzbar, jede Eintrag ist mit n anderen Elementen verknüpft.

... immer, wenn ich einen solchen Thread lese, vergesse ich, dass ich im Joyclub lese. .
MfG Sheldon.
P.S. Ach nee, wollte -jay schreiben
P.P.S. Nix Java, no noSql: In meinem Job (Infrastruktur) komme ich nur mit c# und SQL aus.
P.P.P.S. Nichtsdestotrotz muss ich die Qualität der Diskussion sowohl wegen der Korrektheit als auch der dargebotenen Dialektik loben.

Ahoihoi,

es ist immer die Frage der Rahmenkonditionen. Wenn man was braucht, was einfach nur allein im world-wide-wait steht und nicht zuletzt die Backup-Frage geklaert ist, warum nicht? Wenn man bei noSQL ein sauberes Backup hinkriegt? Wir haben bei uns die grossen Dinger laufen. MSSQL, MySQL, Oracle und PostgreSQL. Daher kann ich zu den anderen Loesungen nichts sagen.

Wenn Du jedoch auf einmal vor den BSI-Bausteinen* stehst, sieht das Ganze schon anders aus. Die schreiben ganz eindeutig vor, dass pro Server nur ein Dienst laufen soll. Wie das jetzt bei noSQL aussieht, muesste man in den Ergaenzungslieferungen gucken oder die einschlaegigen BSI-Hilfsprogramme waelzen. Bei dem Regulierungswahn wuerds nicht wundern.

So oder so - man sieht erst was besser ist, wenns geknallt hat oder Performanceengpaesse kommen Man kann einen Webserver natuerlich mit Varnish entlasten, weil der mehrere gleichlautende Anfragen buendelt, selbst nur eine Anfrage an den Webserver macht und alle Anfragenden mit der Antwort abspeist. Aber ich mag Lastverteilung auf mehrere Server.

Es ist zuletzt aber auch ne Frage, was die Vorgesetzten grad als Schlagwoerter praesentiert bekommen haben. Bei den vergangenen Anstellungen in diversen Rechenzentren, habe ich schon viele Schnappsideen gehoert.