Laden...

modernes DataStorage: relationales SQL oder KeyValue-Pairs

Erstellt von Froschkoenig84 vor 2 Jahren Letzter Beitrag vor 2 Jahren 624 Views
F
Froschkoenig84 Themenstarter:in
63 Beiträge seit 2015
vor 2 Jahren
modernes DataStorage: relationales SQL oder KeyValue-Pairs

Hallo Leute.

Kurz zur mir. Ich bin C#.NET-5 Entwickler und arbeite normalerweise mit MSSQL, welches ich serverseitig via GraphQL-API anspreche.
Privat habe ich nun ein paar Tage Zeit, mich etwas mit Alternativen zu relationalen SQL-DBs zu beschäftigen.

Ich habe in der Vergangenheit auch schon in Projekten gearbeitet, in denen MongoDB in Kombination mit Redis genutzt wurde.
Das waren aber bereits existierende Projekte, so dass ich dort nur zugearbeitet hatte und kaum am Data-Design mitwirken konnte.

Ich bin also bislang noch relativ altmodisch veranlagt.

Gehen wir mal von einem einfachen privaten Test-Projekt aus:

  • JS-Client (simples web, kein CMS)

  • C#.NET-5.0 (serverseitig)

  • Film-Datenbank (DVDs und OnDemand, etc...)

  • Objekte:

  • Filme & Beschreibungen

  • Schauspieler & Biografien

  • Genres & Altersbeschränkungen

  • Regisseure

  • Produzenten & Labels

  • Veröffentlichungsdatum & verfügbare Sprachen

  • Romane auf denen die Filme basieren

  • Freunde & deren Vorlieben (welcher Freund passt zu welchem Filmabend)

  • keine Lust zahlreiche Endpunkte in der REST-API - für unterschiedlichste Filter und Abfrage-Kombinationen (Zusatzinfos) - zu erzeugen

  • komplexe Abfragen (clientseitig erzeugt) via serverseitiger API (um nicht zahlreiche Endpunkte, sondern gezielt kombinierte Objekte mit einer Abfrage zu erhalten)

  • CRUD-Optionen (also auch Mutationen)

Ich dachte entweder an GraphQL oder an eine JSON-API, gerne aber auch etwas ganz anderes. 🙂
Wichtiger ist sowieso eher die Datenspeicher-Technologie. Also GraphDB oder klassisches relationales SQL oder doch Key-Value-Pairs?
Bei den KVPs habe ich die Befürchtung, dass die Struktur schnell entarten kann. Und ist eine GraphDB tatsächlich eine Kombination aus KVPs und wie strukturiert man dann Fremdschlüssel?

Ich habe hier absolut noch keine Idee und würde mich freuen, ein paar Vorschläge für DataStorage-Technologien und Anregungen zur Nutzung von euch zu lesen. 🙂
Ich wollte immer auch schon mal PostGreSQL mit JSONB probieren. Aber auch GraphDBs (ich kenne ehrlich gesagt keine einzige) klingen interessant.

Meine Idee, war es die DataStorage-Technologie via dynamischer Abfrage-API als serverseitige Schnittstelle zu betreiben und dann clientseitig komplexe Requests/Responses abzufragen.

16.807 Beiträge seit 2008
vor 2 Jahren

Die Technologien, die Du vor der Datenbank hast, sind prinzipiell irrelevant.
Man wählt einen Datenbank-Typ (nicht das Produkt) primär anhand seiner Daten aus. Eine Hobby-Film-Datenbank ist halt alles andere als komplex oder hat immense technische Anforderungen.
Ist halt ein Unterschied zu komplexe Strukturen mit tausender Entitätstypen, 10GB Daten pro Minute bzw 1 Mio Requests pro Minute verarbeiten muss.

  • Strukturelle Daten: relationale DB (SQL)
  • Unstrukturelle Daten: nicht-relationale DB (NoSQL Documents)
  • Beziehungen mit Eigenschaften: Graph Database (NoSQL Graphs)
  • Unstrukturierte Daten basierend auf Keys: (NoSQL KVP)
  • ...

Da sich Daten oft mit mehreren Datenbanken prinzipiell darstellen lassen, spielt der Use Case mittlerweile auch eine sehr große Rolle:

Grobe Regeln:

  • Generell ist NoSQL schneller als SQL
  • Generell skaliert SQL meist vertikal besser, NoSQL meist horizontal besser
  • Generell garantiert SQL eine höhere Datensicherheit (ACID)
  • Graph- und KVP Datenbanken sind schnell im Lesen, nicht wirklich toll für viele Änderungen

Aber ja: einzelne Produkte kann sich im ein oder anderen Punkt unterscheiden und jedes Produkt hat gewisse eigene Features.

Mein Tipp: schau Dich mal im Netz um, wer so mit welcher Datenbank unterwegs ist und wieso.
Gibt da eigentlich viele richtungsweisende Tutorials / Videos zu, an denen Du Dir was abschauen kannst.

Bei großen Projekten arbeitet man zusätzlich oft mit gewollten Redundanzen über verschiedene Datenbank-Typen hinweg, um die jeweils optimale Datenbank zu nutzen.
Damit kann man sehr viel Performance raus holen und immense Kosten sparen.

Meine Idee, war es die DataStorage-Technologie via dynamischer Abfrage-API als serverseitige Schnittstelle zu betreiben und dann clientseitig komplexe Requests/Responses abzufragen.

Ah, die klassische Einhorn-Anforderung 😉 : wünscht sich jeder, existiert aber nicht.

M
368 Beiträge seit 2006
vor 2 Jahren

Weiterhin könnte man sich zum Thema "Repository Pattern" informieren, da langfristig vermutlich mehrere Datenbanken inkl. Abfragen getestet oder eingesetzt werden.

Goalkicker.com // DNC Magazine for .NET Developers // .NET Blogs zum Folgen
Software is like cathedrals: first we build them, then we pray 😉

16.807 Beiträge seit 2008
vor 2 Jahren

Die Grundidee (und Realität) vom (klassischen) Repository Pattern ist jedoch die Abstraktion des Produkts und nicht des Typs umgestellt wird, also dass man zB. ein MSSQL Server statt PostgreSQL verwenden kann.
Für eine Umstellung von MSSQL auf zB MongoDB muss man i.d.R. den gesamten Stack inkl. Entitätsstruktur anpassen. Daher hilft das bei sowas nur sehr bedingt / selten.

F
Froschkoenig84 Themenstarter:in
63 Beiträge seit 2015
vor 2 Jahren

Die Technologien, die Du vor der Datenbank hast, sind prinzipiell irrelevant.
Man wählt einen Datenbank-Typ (nicht das Produkt) primär anhand seiner Daten aus. Eine Hobby-Film-Datenbank ist halt alles andere als komplex oder hat immense technische Anforderungen.
Ist halt ein Unterschied zu komplexe Strukturen mit tausender Entitätstypen, 10GB Daten pro Minute bzw 1 Mio Requests pro Minute verarbeiten muss.

Wobei ich hier wie gesagt ein Test-Projekt fahre. Also mit mindestens 10 Mio Datensätzen bei den Filmen und vermutlich 50 Mio Darsteller.
Ich könnte auch meine Konzertbesuche im großen Stil aufbauschen und eine Community-Plattform für Musik- und Konzert-Fans, inkl. Ticketsystem usw... hochziehen.

Tatsächlich skaliere ich aktuell für Bestellungen in einem Hardware-/Game-PC-Shop überraschend altmodisch (vertikal) da ich häufiger auf Collections zurückgreife, als auf komplexe Objektverzweigungen. Dennoch tauchen diese ab und zu auf und ich benötige eine dann vor allem schnelle Abfragen. Derzeit bin ich mit MSSQL-EF-GraphQL zufrieden, auch wenn ich vermutlich mit den Bibliotheken von Dapper und BulkCopy schneller wäre, aber EF war leider vorgeschrieben. Aber wie gesagt, vorerst muss ich mich um ein DataStorage-Typ (also relational, NoSQL, Graphs, etc...) entscheiden, bevor ich mich um die Zugriffs-Bibliotheken oder Server-Client-Schnittstellen/APIs kümmere.

Ich werde sicherlich weder ein zweites Facebook, noch ein zweites Amazon oder Eventim bauen. Aber ich orientiere mich genau an diesen Riesen, da ich vermute, dass Daten bald schon sehr billig werden. - Nicht missverstehen, ich meinte damit die Payloads (Transferraten) und die Speicherung (Festplatten). Nicht, dass man mir hier gleich wieder Datenschutzmissachtung oder leichtsinnige Datensicherheit vorwirft.

  • Strukturelle Daten: relationale DB (SQL)
  • Unstrukturelle Daten: nicht-relationale DB (NoSQL Documents)
  • Beziehungen mit Eigenschaften: Graph Database (NoSQL Graphs)
  • Unstrukturierte Daten basierend auf Keys: (NoSQL KVP)
  • ...

Da sich Daten oft mit mehreren Datenbanken prinzipiell darstellen lassen, spielt der Use Case mittlerweile auch eine sehr große Rolle:

Genau das macht es kompliziert. Ich hab mehrere Projekte im Kopf, die ich bislang ausschließlich relational weggespeichert habe. Aber viele diese Projekte stoßen an ihre Grenzen. Beispielsweise eine Tool, das mein Team damals für einen großen Reiseanbieter entwickelt hatte, bei dem Meeting-Räume vom Kunden aus nach Wunsch bestückt, ausgestattet und gebucht werden konnten, nur eben, dass hier ca. 11K Hotels weltweit in der Liste standen und es sowohl eine B2B-Vewaltungsplattform für die Hotels, als auch eine B2C-Plattform für Endkunden gab. Hier hatten wir mit MSSQL-DBs und EF gestartet und sind dann auch MongoDB und filtering/pagination REST-APIs gewechselt. Damit haben wir zwar zu Beginn die Datenzugriffszeiten halbiert, aber leider bei jeder Anpassung/Erweiterung der Objekte eben auch einen Grad der Entartung gebrochen. Nach der vierten Version, hatte ich wirklich lust auf klar strukturierte relationale SQL-DBs. 😉

Das ist der Grund, wieso ich mich seither nicht mehr heran gewagt habe. Also weder an KVP, noch an Documents. GraphDBs kenne ich noch gar nicht, aber mir gefallen die unstrukturierten (dynamischen) Schemas, aber die Entitäten und die Beziehungen, um zumindest halbwegs klare Strukturen getrennter (unabhängiger) Datenmodelle (bspw. in 3. Normalform) zu realisieren. Das macht es etwas aufgeräumter. - Übrigens auch der Grund, wieso ich immer schon mal PostGreSQL (also relational, aber mit JSONB-Datenfeldern) ausprobieren wollte. Auch, weil man schnell Daten weg schreiben kann.

Grobe Regeln:

  • Generell ist NoSQL schneller als SQL
  • Generell skaliert SQL meist vertikal besser, NoSQL meist horizontal besser
  • Generell garantiert SQL eine höhere Datensicherheit (ACID)
  • Graph- und KVP Datenbanken sind schnell im Lesen, nicht wirklich toll für viele Änderungen

Aber ja: einzelne Produkte kann sich im ein oder anderen Punkt unterscheiden und jedes Produkt hat gewisse eigene Features.

Mein Tipp: schau Dich mal im Netz um, wer so mit welcher Datenbank unterwegs ist und wieso.
Gibt da eigentlich viele richtungsweisende Tutorials / Videos zu, an denen Du Dir was abschauen kannst.

Bei großen Projekten arbeitet man zusätzlich oft mit gewollten Redundanzen über verschiedene Datenbank-Typen hinweg, um die jeweils optimale Datenbank zu nutzen.
Damit kann man sehr viel Performance raus holen und immense Kosten sparen.

Meine Idee, war es die DataStorage-Technologie via dynamischer Abfrage-API als serverseitige Schnittstelle zu betreiben und dann clientseitig komplexe Requests/Responses abzufragen.
Ah, die klassische Einhorn-Anforderung 😉 : wünscht sich jeder, existiert aber nicht.

Ja vermutlich, die eierlegende Wollmilchsau gibt es eben nicht. Aber genau was du bereits sagtest, ich müsste mir die Beispiele anschauen. Allerdings ist das leichter gesagt, als getan, wenn man quasi nur die klassischen relationalen Datensysteme gewohnt ist. Ich weiß gar nicht genau, wonach ich suchen soll, ganz zu schweigen, dass viele größere Projekte oft gerne ein wenig ein Geheimnis um ihre Technologien machen.

Mein zweites Problem ist der Zeitmangel. Ich werde vermutlich weder die Zeit finden mich in alle Schemata und Datentypen perfekt einzulesen und das Wissen darüber hinaus noch zu erweitern. Aber vielleicht finde ich interessante Anregungen für eventuell spätere Anforderungen.

Aber deine Infos sind schonmal wegweisend und hilfreich für meine Recherche. 🙂
Danke schön.

F
Froschkoenig84 Themenstarter:in
63 Beiträge seit 2015
vor 2 Jahren

Weiterhin könnte man sich zum Thema "Repository Pattern" informieren, da langfristig vermutlich mehrere Datenbanken inkl. Abfragen getestet oder eingesetzt werden.

Ja, meine GraphQL-API nutzt quasi ein Repository, das über mehrere Datenquellen (externe APIs, interne DBs, externe DBs) bedient wird.
Wobei ich inzwischen auch sämtliche Clients (in meinem aktuellen Job handelt es sich beim Client um eine Anwendungssoftware, UI = WinForms) auf async umgestellt habe, um dort je nach Anforderung auf die Payloads und unnötige Datentransfers zu verzichten. Aber das Repository Pattern nutze ich bereits sowohl clientseitig, als auch serverseitig.

Es hilft mir nur leider bei der Frage der primären Daten-Speicherung relativ wenig weiter.
Ich muss erstmal recherchieren, welche DataStorage-Typen ich wie und für was sinnvoll und schnell nutzen kann.

16.807 Beiträge seit 2008
vor 2 Jahren

Ich werde sicherlich weder ein zweites Facebook, noch ein zweites Amazon oder Eventim bauen. Aber ich orientiere mich genau an diesen Riesen

Gut gemeiner Rat: lass das. Bleib in der Liga, in der Du spielst und orientier Dich an solchem.
Datenbanken sind ohnehin schon komplexe Systeme und erfordern teilweise komplexe Architekturen; mit Overengineering wirst Du Dir das Leben unnötig schwer(er) machen - und wenn Du Pech hast wächst Dir das über den Kopf.
Hoch-skalare Datensysteme sind Full Time Jobs.

Also mit mindestens 10 Mio Datensätzen bei den Filmen und vermutlich 50 Mio Darsteller.

Das ist nichts. Das ist ein kurzer Schluckauf für jedes gängige Datenbanksystem. Setzt paar intelligente Indizes auf die Tabellen und gut ist. Dein Beispiel so ist nen typisches stark lese-lastiges System und weeeeit weg von hoch-skalaren Anforderungen im volatilen Sinne.
Ich hab nicht umsonst oben Angaben nach IO gemacht und eben nicht nach statischen Datenmengen, wie Du nun geantwortet hast.
Geb aber zu, dass das Absicht war, Dich da reinlaufen zu lassen - so als Piekser 🙂

Ich hab einen Kunden, der erzeugt pro Minute pro Maschine >10 GB an Daten.
Unser IO Problem hätte mit keinem DBMS auf einem System gelöst werden können - wir waren einfach am Limit der Hardware und vom Netzwerk mit einer einzigen Instanz.

Ich könnte auch meine Konzertbesuche im großen Stil aufbauschen und eine Community-Plattform für Musik- und Konzert-Fans, inkl. Ticketsystem usw... hochziehen.

Dann mach das doch? Was hindert dich? 🙂
Orientier Dich am besten an den großen, wie Du selbst gesagt hast: die haben nicht sofort versucht das weltweite System zu bauen 😉

Das, was Du da mit Community, Musik, Tickets und Co aufzählst.. da wirst Du niemals nur eine einzige Datenbank-Art finden, die für alles die perfekten Evaluierungskennzahlen liefert.
Da fahren die großen Plattformen Microservices, die durchaus mit verschiedenen Datenbanksystemen arbeiten, mit gewollten Redundanzen und mit verteilten Keys.
Das ist ein mega komplexes Szenario.

Overengineering endet meist nicht gut; genauso wie das krasse Gegenteil.
Und OE zu korrigieren ist viel aufwändiger als wenn Du einfach ein System gesund und verantwortlich wachsen lässt.

aber EF war leider vorgeschrieben

Und? Auch mit EF Core (nicht EF6) kannst Du mittlerweile hoch-performante Systeme bauen.
Wir haben hier im Forum unsere Datenbank-Migration auch problemlos mit ner EF Core Schnittstelle und SqlBulk gemacht.
Das hat aber nichts mit dem DBMS zutun sondern mit dem Verständnis von performanten Code.
Das Dapper Team (Marc und Nick) war heute auch im EF Community Standup: https://www.youtube.com/watch?v=txiQar6PqvA

Hier hatten wir mit MSSQL-DBs und EF gestartet und sind dann auch MongoDB und filtering/pagination REST-APIs gewechselt. Damit haben wir zwar zu Beginn die Datenzugriffszeiten halbiert, aber leider bei jeder Anpassung/Erweiterung der Objekte eben auch einen Grad der Entartung gebrochen.

Tjo.. ich kenn genug SQL Berater, die sowas ausbaden, weil so ein unüberlegter, nicht ordentlich evaluierter Umzug durch SQL Optimierungen oft hätten vermieden können. Bekommt man auch immer wieder in Erfahrungsberichten auf User Group Events zu Best Practises in Vorträgen mit.
Oft scheitert es nicht an der relationalen Datenbank, sondern am Wissen die relationale Datenbank performant einzusetzen. NoSQL ist nicht pauschal schneller; es ist aber i.d.R. im einfachsten Setup schneller - aufgrund der Art und Weise wie NoSQL funktioniert - aber NoSQL kommt auch nicht ohne Nachteile.

Ich gehör definitiv auch nicht zu den SQL Profis und ich/wir haben uns hier beim Forum auch Feedback von nem gut befreundeten Profi geholt, mit dem wir sehr sehr viel optimieren konnten; und für mich war hier vieles ein Wow-Effekt. Vieles, was ich dabei gelernt habe, hab ich mittlerweile in Kundenprojekte umsetzen können - mit sehr positiven Effekten in Kosten- und Performance-Optimierung. Meine Erkenntnis war definitiv: SQL ist viel mächtiger als man denkt. Aber als Dev lernt man die Optimierungen einfach selten - und neigt dann überhastet und nicht ordentlich evaluiert zu Produktwechseln...

Generell versteh ich Dich: Du musst Fehler machen um draus zu lernen 😉
Tob Dich aus, wenn das ein privates Projekt ist; geh verantwortungsbewusst vor, wenn es ein Kunden- oder Team-Projekt ist.

309 Beiträge seit 2020
vor 2 Jahren

Interessant wäre auch der Einsatzort. Falls es mal Überlegungen geben sollte, später in die Cloud zu ziehen oder dort bereits läuft, könnten NoSQL-Datenbanken Kostenvorteile bieten.
Das ist z.B. der Hauptgrund warum csharpfritz mit seinem Projekt KlipTok von MySQL zu RavenDb umzieht, bei dem er wahrscheinlich eine ähnlich komplexe Datenstruktur wie du hast.
Milestone Reached - 4 MILLION Clips Indexed!

F
Froschkoenig84 Themenstarter:in
63 Beiträge seit 2015
vor 2 Jahren

Generell versteh ich Dich: Du musst Fehler machen um draus zu lernen 😉
Tob Dich aus, wenn das ein privates Projekt ist; geh verantwortungsbewusst vor, wenn es ein Kunden- oder Team-Projekt ist.

Jo, ich werde mich in den kommenden Tagen damit auseinandersetzen und mal wild verschiedene Systeme ausprobieren.
Was das OE betrifft, na ja, da hast du schon Recht. Aber vor 20 Jahren war ich noch ungemein sparsam mit DB-Daten und und heute ... 😉
Okay, ich orientiere mich nicht direkt an allen Problemen von Google, Facebook oder Amazon. Aber an den gröbsten Schwierigkeiten und auch deren Lösungsansätze. So bin ich bspw. über die JSON-API auf GraphQL gekommen. Und bei den DataStorage-Technologien/-Typen hat @JimStark natürlich auch nicht ganz Unrecht, wenn man die Cloudnutzung nicht ganz außer Sicht lässt.

Ich denke, ich werde mich erstmal auf GraphDatabases stürzen, da ich hier ein wenig den Mix von NoSQL und relational erkenne und mich hoffentlich schneller zurecht finden werde.
Mich reizt sehr, dass es nicht nur Abhängigkeiten wie Primär- und Fremdschlüssel, sondern auch die gesamte Abhängigkeitsstruktur und sogar die Verknüpfungen als eine Art integrierte Abfrage ermöglicht. Anstatt komplexe Abfragen, lassen sich zweckdienliche Sub-DataSets "erzeugen" und die Abfragekomplexität auf die DB selbst verlegen. Das macht es spannend, denn es beinhaltet sowohl die klassischen Records (bspw. Shop: Produkt, Infos, Kategorie, Preis, Verfügbarkeit, Lagerstandorte, Bestellung, Kunde, Rechnung, Versand, ...), aber eben auch die rasche Analyse und die Herauslösung jener gefilterten SubDataSets (also nur das, was gerade benötigt wird), wie ein riesiger Join, aber clevere Indizies und übergreifende Selects. Die meisten aufgeführten Beispiele beschreiben die Analysen von Kaufverhalten oder die Kundenanalyse. Aber auch Social-Communities (Beziehungsanalysen) und Risiko-/Fehleranalysen werden immer wieder mit den GraphDatabases in Verbindung gebracht.

Bei einer SocialCommuniy für Musikliebhaber mit besonderem Augenmerk auf Konzerte, Veranstaltungen (Finanzierung: Ticketverkäufe oder Affiliate-Marketing) oder Merchandise, sowie CDs und Musik-Downloads (Affiliate-Marketing oder CPC/CPL/CPV) wären bspw. solche Analysen sehr wichtig. Außerdem sind die meisten dieser GraphDatabases aktuell für das schnelle Webspeichern (oft noch schneller als BulkCopy) und das enorm rasche Auslesen gefilterter Datensätzen für spezielle PartialObjects (hier stelle ich mir C#-seitig regulary-depended LightObjects vor, die entweder reflected POCOs sind oder mit Func/Action, sowie Properties arbeiten). Na ja, das schnelle Auslesen und die simple Verwendung der Datenbank-API klingt spannend. Einige APIs lassen sich vollständig über den Client (in meinem Fall JavaScript) verwalten, ich bin aber ein Fan, einer eigenen API um OAuth, Rollen und Berechtigungen integrieren zu können. Leider gibt es noch keine standardisierte Abfragesprache, also werde ich mir erstmal nur die wichtigsten, wie GraphDB, Neo4j, AWS-Neptun und OrientDB zu Auge führen können.

Wie gesagt, erstmal nur ein kleines privates Projekt, habe eigentlich gar nicht die Zeit eine marktreife Idee zu erzeugen und auch noch nutzbar umzusetzen. Es ist also nur ein Tryout-Project, aber vielleicht läuft es ja aus irgendeinem Grund und kann tatsächlich eine Wirtschaftlichkeit damit erreichen.

Sofern ich es nicht vergesse, werde ich hier immer mal wieder neue Erkenntnisse zu meinen Versuchen mit den NoSQL-Datenbanken darunter posten. 🙂
Danke an alle für die vielen Infos.

16.807 Beiträge seit 2008
vor 2 Jahren

Das ist z.B. der Hauptgrund warum csharpfritz mit seinem Projekt KlipTok von MySQL zu RavenDb umzieht, bei dem er wahrscheinlich eine ähnlich komplexe Datenstruktur wie du hast.

Weiß nicht, ob das der Hauptgrund ist...

.. Du musst bedenken, dass Jeff Fritz im Developer Marketing für .NET bei Microsoft angestellt ist und bezahlt wird, für das was er da macht - und er macht das gut und mit Leidenschaft.
Daher wird da auch nen hoher Faktor an "schaut mal wie einfach ein Umzug von MySQL auf RavenDB mit .NET und Azure ist" bzw. "schaut mal, wir haben auch RavenDB" dabei sein.

Ich zB. würde in realen Kundenprojekten einige Dinge in seinem Projekt durchaus anders machen; zB. die API nicht über Functions (weil das nicht der Sinn der Functions ist) und auch die Software Architektur, die er mit State Sharing in Blazor macht.
Daher denke ich schon, dass man die Inhalte durchaus einordnen sollte - auch wenn Du recht haben könntest.

Aber vor 20 Jahren war ich noch ungemein sparsam mit DB-Daten und und heute ...

... und heute ist das immer noch ein weit verbreiteter und wichtiger Aspekt in der Evaluierung von Anwendungen.

Der große Unterschied ist: man sammelt heute Daten anders. Das heisst aber nicht, dass Du diese in die Rohdaten haust.
Auch das macht Google, Facebook und Co nicht. In der Daten-Architektur gibts mehr als eine Produktivdatenbank, sondern auch sowas wie Cold Storage, Raw Data, ETL Prozesse, Data Eventing etc..

So bin ich bspw. über die JSON-API auf GraphQL gekommen.

.. und warum ist die GraphQL immer noch eher eine Randerscheinung bzw. wird von manchen Herstellern wieder zurück gebaut?
Ich lehr auch die GraphQL in meinem HTTP API Workshops; finde ich ein tolles Thema. In der realen Welt wirst Du aber kaum Einsatz finden.

Eine GraphQL ordentlich zu implementieren, dass der Nutzen wirklich heraus kommt, ist vergleichsweise extrem aufwändig. Du musst auch prinzipien wie Microservice Kommunikation brechen, um GraphQL richtig nutzen zu können - wer will das?
Hinzu kommt, dass die Client-Implementierung noch viel aufwändiger im Verhältnis ist. GraphQL wird daher vermutlich von den meisten technologisch einfach geskipped.
Die meisten nehmen direkt gRPC für die interne Kommunikation und REST für die externe Kommunikation: Verbreitungsgrad Millionenfach höher - brauchst GraphQL nicht mehr.

Mich reizt sehr, dass es nicht nur Abhängigkeiten wie Primär- und Fremdschlüssel, sondern auch die gesamte Abhängigkeitsstruktur und sogar die Verknüpfungen als eine Art integrierte Abfrage ermöglicht.

Hinweis: genau das macht GraphDBs langsam.

F
Froschkoenig84 Themenstarter:in
63 Beiträge seit 2015
vor 2 Jahren

Obwohl ich ein großer Fan von MicroServices bin, habe ich inzwischen auch die Vorteile gesehen, die ein thematisch angepasst-übergreifendes Projekt bietet. Ich mag auch nicht diese Common-MicroServices, da nutze ich ausschließlich die im Hauptprojekt (und somit namespace-seitig "offen liegenden") Bibliotheken und Module.

Andererseits muss GraphQL nicht zwangsläufig die MicroServices brechen. Klas, nach EVA dürfte jedes Teilprojekt auch nur die Daten laden/speichern können, die für das Modul gedacht sind, aber wenn man bspw. Produktions-Simulatoren entwickelt, hat man mir riesigen Datenmengen zu tun, aber nur wenige Grunddaten, wenn auch aus völlig unterschiedlichen Modulen. Ich nutze GraphQL nur, um meine Analyse-Objekte wegzuspeichern, das mache ich aber auch sehr simpel, quasi via 1-Single-POCO-Object (Table). Aber natürlich, ich habe nach Außen meine REST-Schnittstellen (Anforderung) für die Nutzung des Moduls und nach "Innen" eben GraphQL, um mir Daten aus verschiedensten Tables zu holen, dann alles in zahlreichen Loops zu verarbeiten und schließlich nur noch das Ergebnis via Response zurückzuliefern. Allerdings speichere ich ein paar Ergebnislisten weg, damit beim nächsten Aufruf (der ohne Veränderungen stattfand) die Ergebnisse direkt aus der DB kommen und nicht alles neu berechnet werden muss. Aber ich finde GraphQL auch toll, wenn man tatsächlich dynamisch über alle Tabellen seine Daten zusammensuchen muss. Einzig die Integration von OAuth und den berechtigten Rollen, sowie die Einschränkung endlessloops oder zu großen Rückgabedaten fiel mir etwas schwer. Läuft aber inzwischen auch. - Ich mag GraphQL, aber hier muss noch einiges gemacht werden. Ähnlich wie in der JSON-API fehlen ein paar standardisierte Abfragen, die man eben immer benötigt. Ich hatte neulich mit einigen Jungs von ChilliCream in Slack gequatscht und die Bibliothek wird es dann mit modularen Erweiterungen geben. Das Prinzip finde ich aber toll. - Perfekt wäre ein Mix aus REST, JSON-API und GraphQL, aber ich werde einen Teufel tun, etwas eigenes zu entwickeln. 😉

Und zurück zu den Datenbanken-Typen. Japp, GraphDatabases sind langsamer, aber ebenso optimierbar. Man muss nur entsprechendes Verständnis mitbringen und wissen, an welchen Stellen man sie optimiert. Gleiches gilt ja auch für SQL, Ich habe mal ein interessantes Gespräch mit dem technischen Leiter der Kantar über die riesigen Datenmengen (die verdienen Ihr Geld in der Sammlung und Auswertung von "Statistiken") und da habe ich gemerkt, dass meine bisherigen Anpassungen in SQL ein Witz sind, im Vergleich was dort gemacht wird. Wobei BigData-Schemas natürlich auch einfacher zu optimieren sind, als hunderte separate Tables nach was-weiß-ich-Normalform.

Aber ich bin davon überzeugt, wenn man es korrekt und sauber macht, kann auch eine GraphDatabase sehr schnell laufen, trotz der vielen integrierten Abfragen basierend auf den Abhängigkeiten. - Wie gesagt, ich probiere mich mal dran. 😉

Aber ich vermute fast, ich werde am Ende alles dreis parallel nutzen (klassisch relationales SQL, KVP-NoSQL und für die Analysen GraphDatabases), abhängig vom Verwendungszweck der Daten. Anders wird sich die Geschwindigkeit kaum optimieren lassen.

16.807 Beiträge seit 2008
vor 2 Jahren

Es wird aus meiner Sicht immer mehr zum Buzzword-Bingo, was auf dem Level einfach kein Sinn mehr macht.
Daher klinke ich mich auch und wünsch Dir alles Gute für die Zukunft. Kannst ja Deine Erfahrungen teilen.

Was ich Dir aber noch mitgebe: vielleicht auch nochmal bisschen Lektüre lesen, was ein Microservice so wirklich ist, was er mit Bibliotheken zutun hat, was der damalige Sinn von GraphQL war, bisschen Architektur, warum man Datenbank-Objekte nicht direkt per API (GraphQL, REST...) verfügbar macht war etc etc
Gibt genug Tech Blogs von bedeutenden Engineers, die Einblicke geben (zB. Google, Netflix) warum sie zB Technologie A nicht nehmen oder Technologie B zurück bauen etc...
Ich bleib auch bei meiner Ansicht, dass Du, nach dem was ich hier lese, die ein oder andere Technologie vermutlich nicht so einsetzt, wie sie gedacht ist - Du aber die Nachteile einfach (noch) nicht spürst; sie Dir aber in größeren Umgebungen um die Ohren fliegen würden.

Viel Erfolg! 🙂