Laden...
F
Froschkoenig84
myCSharp.de - Member
13
Themen
63
Beiträge
Wenn einem eingefleischten Pessimisten ein Stein vom Herzen fällt, dann ganz bestimmt auf den Fuß!
Letzte Aktivität
vor 3 Jahren
Dabei seit
11.06.2015
Beruf
Trollschläger
Herkunft
Scheibenwelt
Interessen
Trolle erschlagen
Erstellt vor 3 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.

Erstellt vor 3 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.

Erstellt vor 3 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.

Erstellt vor 3 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.

Erstellt vor 3 Jahren

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.

Erstellt vor 5 Jahren

Na ja, Swagger mach ich ja nur, ums zu Testen. Postman wird aus irgendeinem Grund geblockt, da ich das SSL-Zertifikat vom IIS-Express nutze. - Mal sehen, wie das am Ende laufen wird.

Aber Danke für den Hinweis, werde ich am Wochenende mal reinschauen. - Wie gesagt, das ist nur ein Dumm, damit ich weiß, wie ich das zukünftig machen müsste. Feinschliff erfolgt später, ich kann eben nicht gleich perfekt anfangen, außerdem lerne ich mit der Erfahrung.

Am Wochenende muss ich mir mal die ASP.NET Core Identity Auth(s) anschauen. Da ich Dapper nutze, ließ sich das Identity Framework (EF) nicht nutzen. - Es gibt zwar ein paar Git-Projekte, die es mit Dapper realisieren, aber unabhängig davon benötige ich eine einfache Lösung für JWT-Tokens, die ich später mit OAuth-2 (sobald der Kunde etwas mehr Budget freigibt) verknüpfen kann. Ist nur ein internes Dashboard (quasi eine Verwaltungsplattform), daher nicht so kritisch, aber man möchte ja auch für spätere Projekte dazulernen. Wer weiß, vielleicht wird das Ding irgendwann mal riesig und sobald Rechnungen über die Plattform generiert werden, muss es auch wirklich ernsthaft sicher sein.

Aber dennoch vielen Dank für eure Unterstützung, ich nehme das wirklich alles sehr ernst.

Erstellt vor 5 Jahren

Sicherlich wäre es nützlich später noch eine Validierungsklasse zu erzeugen. Wie gesagt, ich probiere noch aus. Aber händisch erzeugt wäre es dieser Code... (Sorry wegen des Quick'n'Dirty-JSON-Objekts)

// PUT api/users/5
[HttpPut("{id}")]
public object Put(int id, [FromBody] Dictionary<string,object> modFields)
{
    var userProbs = typeof(User).GetProperties().Select(p => p.Name);
    var unknownFields = modFields.Keys.Where(k => !userProbs.Contains(k, StringComparer.OrdinalIgnoreCase));
    if (unknownFields.Count() == 0)
    {
        //return _repo.ModUser(id, modUser);
        return 1; //just a test-obj
    } 
    else
    {
        var httpStatusCode = 400;
        var fieldsErrJson = unknownFields.Select(f => "\"" + f + "\": [\"[User." + f + "] field is unknown.\"]").ToList();
        var statusJson = "{ \"errors\": { "+String.Join(", ",fieldsErrJson)+" }, \"title\": \"One or more validation errors occurred.\", \"status\": "+httpStatusCode+", \"traceId\": \"0:00000000\" }";
        
        HttpContext.Response.StatusCode = httpStatusCode;
        return JsonConvert.DeserializeObject<object>(statusJson);
    }
}

Und erzeugt...

Falls das irgendwie einfacher geht, immer her damit. 😃

Erstellt vor 5 Jahren

Wie ihr seht, hatte ich ja die Rückgabe nur testweise auf VOID zrückgesetzt. Daher ist die reguläre/erfolgreiche Rückgabe ja auch auskommentiert. Wobei ich gerade sehe, das sich - wieso auch immer das return weggenommen hab. - Aber egal...

Ich suche nur nach einer Möglichkeit, neben dem StatusCode noch eine zusätzliche ErrorMessage zurückzugeben. Aber ich denke, verstanden zu haben, dass ich die Fehler quasi als klassische Rückgabe definieren müsste, ...

...bei einem invaliden POST wurde diese Ausgabe automatisch generiert, auch wenn mir die Trace-ID noch nicht ganz klar ist. **:::

Notfalls baue ich die Ausgabe händisch nach.
Ich vermute mal
[400 Bad Request] und als ErrorMessage eben die obige Ausgabe mit den aufgelisteten unbekannten Feldern. Ggf. würde sicherlich auch ein 5XX gehen, aber ich finde keinen passenden.
Daher den 400er oder doch den 404er. Wobei die angefragte Ressource ja gefunden wurde, nur dass die übermittelten Felder nicht existieren.

Erstellt vor 5 Jahren

Na ja, die Reflection sei mal dahingestellt, aber gibt es in .NET Core keine individuelle ErrorMessages mehr?

Erstellt vor 5 Jahren

Infos:
:::

#:::

Hallo,

ich habe heute meine aller erste CRUD-API unter .NET Core gebaut und möchte gerne einen Fehler zurückgeben...

// PUT api/users/5
[HttpPut("{id}")]
public void Put(int id, [FromBody] Dictionary<string,object> modFields)
{
    var userProbs = typeof(User).GetProperties().Select(p => p.Name);
    var unknownFields = modFields.Keys.Where(k => !userProbs.Contains(k, StringComparer.OrdinalIgnoreCase));
    if (unknownFields.Count() == 0)
    {
        // _repo.ModUser(id, modUser);
    } 
    else
    {
        HttpContext.Response.StatusCode = 502;
    }
}

Okay, so kann ich also einen StatusCode zurückgeben, aber gibt es hierzu auch einen Status oder eine ErrorMessage? - Will dem Client sagen, dass sein Put-Data nicht unterstützte Felder besitzt und daher nicht verarbeitet wird.

Das muss ja möglich sein, hier auch einen Fehler-Text ausgeben zu können oder?

EDIT: Swagger-PUT-Screenshot: