Mein Team hat Angst vor relationalen Datenbankentitäten mit Fremdschlüsselbeziehungen, und ich verstehe nicht, warum

12

Ich habe das College noch nicht abgeschlossen und bin mit relationalen Datenbanken zum größten Teil vertraut, da in meinem Datenbankkurs alles, was nicht in BCNF oder 3NF enthalten ist, eine Farce ist. Sicher ist das ein Ende des Extrems, aber mein Team bei der Arbeit scheint es wirklich bis zum entgegengesetzten Ende zu bringen.

In unseren microservice db-Schemata haben Entitäten selten mehr als eine einzelne Tabelle. Alles, was Sie normalerweise in eine andere Tabelle normalisieren würden, wird in einer json-Spalte gespeichert. Wenn später festgestellt wird, dass eine der Eigenschaften in diesem JSON abgefragt werden muss, wird eine neue Spalte hinzugefügt und die Daten werden an beiden Stellen gespeichert (ja, in zwei verschiedenen Spalten in derselben Tabelle).

In vielen Fällen haben diese JSON-Spalten definitiv einen Vorteil. Wenn Sie diese Daten niemals abfragen müssen und niemals eine einseitige Änderung vornehmen müssen (was Sie offensichtlich nicht vorhersagen können), ist dies keine schlechte Idee. Darüber hinaus sehen viele unserer Services entweder keinen Server oder werden auf Computern gehostet, auf denen nicht genügend Speicherplatz zur Verfügung steht, sodass die Duplizierung von Daten kein großes Problem darstellt. (Obwohl ich etwas aus der Philosophie heraus generell vermeiden möchte)

Derzeit erstellen wir einen Service, der Regeln basierend auf einer Reihe von Bedingungen, deren Eigentümer sie sind, entspricht, und führen dann eine Reihe von Aktionen aus, die diesen Regeln zugeordnet sind, wenn die Regeln erfüllt sind (z. B. alle Bedingungen erfüllt sind). Mein Sub-Team, das diesen Service am schnellsten aufbaut, ist der Ansicht, dass die Normalisierung von Aktionen und Bedingungen von den Regeln im Schema weg einen erheblichen Vorteil hat. Offensichtlich pflegen diese Tabellen Fremdschlüsselbeziehungen mit der Regel-ID. Aus unserer Sicht können wir vermeiden, dass Daten bei Bedingungen dupliziert werden, sodass wir sicherstellen, dass sie nur einmal ausgewertet werden. Außerdem können wir die Bedingungen und Regeln, die wir benötigen, bei Bedarf leicht finden, ohne jede einzelne Regel herausziehen und im Speicher suchen zu müssen.

Er hat heute mit einem unserer Hauptingenieure gesprochen und versucht, mich von diesem Schema fernzuhalten. Der Versuch, in jeder Hinsicht zu argumentieren, dass wir es nicht wirklich brauchen, wird in Zukunft zu Leistungsproblemen führen und auf einen alten Monolithen verweisen, den wir besitzen und der eine Designtravestie darstellt. Er bezeichnete das, was wir tun, als "den alten Weg" und flache Tische mit json als "den neuen Weg". Er argumentierte, dass wir an Orten, an denen ich Atomizität will, diese nicht brauchen und dass wir anstelle von Abfragen mehr Dinge im Gedächtnis tun sollten. Dies ist ein Konstruktionsprinzip, dem viele unserer Dienstleistungen jetzt folgen. Wir gehen nicht davon aus, dass das Datenvolumen erheblich ansteigen wird, was unsere Abfragen beschleunigen dürfte. Was wir vorwegnehmen, ist viel Zeit, die für die Bewertung von Regeln und die Durchführung von Aktionen aufgewendet wird.

Ich verstehe, dass nicht relationale Datenbanken in den letzten Jahren immer beliebter wurden, aber selbst wenn ich aktiv nach Informationen über die Auswirkungen von Fremdschlüsselbeziehungen auf die Leistung suche, sehe ich nicht viele Informationen, die für ihn sprechen. Ich nehme an, dass sie dazu neigen, große Transaktionen einzuführen, die Probleme verursachen können, aber das scheint ein Problem zu sein, das vom Fremdschlüssel selbst unabhängig ist.

Ist das meine Naivität? Oder fehlt mir und meinem Sub-Team wirklich etwas? Ich habe ausdrücklich keine detaillierten Informationen zu unserem Problem angegeben, da ich nicht unbedingt nach einer Lösung dafür suche. Angesichts der Tatsache, dass dies ein allgemeiner Trend in unserem größeren Team ist, bin ich sehr gespannt, ob sie etwas damit anfangen können.

MichaelCook
quelle
Die Antwort auf Ihre Frage im Titel wäre "Sie haben Angst vor dem alten Monolithen in Ihrer Firma". Der Hauptteil Ihrer Frage scheint jedoch etwas ganz anderes zu fragen: "Führen Fremdschlüssel zu Leistungsproblemen?"
Christian Hackl
2
Ich frage mich, wie
viel
Ob der Ansatz gut ist oder nicht, hängt von der Art der Anwendung ab, die Sie erstellen, deren Anforderungen und der Richtung (Anforderungen, architektonische Einschränkungen) - etwas, das wir hier nicht wirklich einschätzen können. Was NoSQL angeht, ging es darum, eine massive horizontale Verkäuflichkeit zu unterstützen und zu erkennen, dass nicht alle Anwendungen die strengen Einschränkungen von RDBMS erfordern. Um mehr zu erfahren, verwenden Sie die Top 3 Antworten hier als Ausgangspunkt (die 2. und 3. gehen tiefer).
Filip Milovanović
2
Wenn ich Ihnen einen nicht-technischen Rat geben kann: Machen Sie es etwas ruhiger. Sie urteilen viel ("Ja, in zwei verschiedenen Spalten in derselben Tabelle", "Design-Travestie") über Arbeiten, bei denen Sie nicht an den Entwurfsentscheidungen beteiligt waren und die Sie aus einer Position mit minimaler realer Erfahrung durchführen . Ich kann nicht sagen, dass Sie Recht oder Unrecht haben, weil ich das Projekt nicht gesehen habe, aber bei Systemen handelt es sich in der Regel um eine Reihe von Kompromissen, die dazu führen, dass das fertige Produkt zwar funktionsfähig, aber weniger als konzeptuell rein ist. Dies wird im Laufe Ihrer Karriere klarer und das Treffen dieser Entscheidungen wird Teil Ihrer Arbeit.
Blrfl
@Blrfl Hervorragend ausgedrückt
Robbie Dee

Antworten:

8

Das Schlüsselwort, um zu verstehen, woher Ihr Team kommt, ist "microservices". Es lohnt sich, zuerst dieses Konzept zu lesen, insbesondere für die folgenden Informationen:

  • Wie sollen Daten gespeichert werden?
  • Design-Prinzipien?
  • Wie sind sie maßstabsgetreu gestaltet?

Wie bei jeder relativ neuen Art, Dinge zu tun (und 5-10 Jahre ist relativ neu, wenn es um Software-Architektur geht), werden Sie feststellen, dass die Ideale und die Realität ein bisschen anders sind.

Eines der Ideale ist, dass jeder Microservice einen eigenen Datenspeicher haben sollte. HINWEIS: Ich sagte Datenspeicher, nicht Datenbank. Es gibt Fälle, in denen Sie statt einer regulären Datenbank einfach eine Suchmaschine, einen Blob-Speicher oder ein einfaches Caching wünschen. Je nachdem, mit wem Sie sprechen, wird dieses Ideal möglicherweise sogar pro Microservice-Instanz in einem Datenspeicher gespeichert.

Das Fazit ist, dass die Sicherheit und Vertrautheit von ACID-Transaktionen (Atomicity, Consistency, Isolation and Durability) beim Aufrufen des Internet nicht skaliert werden kann, wenn Sie Millionen von Benutzern in einer Datenbank haben. Mit dem Aufkommen von NoSQL hat sich das Paradigma mehr in Richtung BASE (Basically Available, Soft State, Eventual Consistency) verlagert. ( Referenz )

Die Änderung der PH Ihrer Datenverwaltung hat folgende Auswirkungen:

  • Dinge, die die Datenbank für Sie erledigt hat, müssen jetzt im Code verwaltet werden
  • Es ist einfacher zu skalieren, indem mehr Microservice-Instanzen auf ein Problem angewendet werden, als einem Server "unendliche" Ressourcen hinzuzufügen
  • Sie erhöhen die Zuverlässigkeit auf Kosten einer erhöhten Komplexität

Ich kann nicht für die Details Ihres Teams antworten oder wie groß die Lösung sein soll, aber normalerweise müssen Sie keine Alles- oder Nichts-Lösung haben. Ich werde hier nicht sitzen und beurteilen, ob das Team die richtigen Entscheidungen trifft. Ich versorge Sie nur mit einem gewissen Kontext, damit Sie zumindest verstehen können, woher sie kommen.

Berin Loritsch
quelle
+1 Tolles Zeug - es gibt eine Menge Feinheiten in Bezug auf Microservices, die bedeuten, dass es nicht nur darum geht, Datenbanken auszutauschen.
Robbie Dee
@ RobbieDee, einverstanden. Es gibt eine Menge Komplexität in dieser Welt, und nicht alle sind sich in den Details einig.
Berin Loritsch
Das sollte die Antwort sein. Das Besondere an jedem Mikrodienst, der über einen eigenen Datenspeicher verfügt, ist der Differenzierungsfaktor. Dadurch ändern sich die Anforderungen und Lösungen für die Datenspeicherung erheblich, und ein ACID-kompatibler Datenspeicher ist nicht mehr so ​​vorteilhaft wie früher.
Greg Burghardt
7
Es ist eine gute Antwort und ich habe sie positiv bewertet. Ich möchte nur darauf hinweisen, dass das, was Sie als "Internet-Skala" bezeichnen, nur für das größte Unternehmen gilt. Für die überwiegende Mehrheit der Unternehmensdatenbanken und -websites (ich würde sagen, 95% von ihnen) sind "herkömmliche" normalisierte SQL-Datenbanken immer noch einwandfrei funktionsfähig.
Robert Harvey
@ Robert Harvey, ich stimme voll und ganz zu. Ich habe mehrere Artikel über Microservices gelesen, in denen angegeben ist, worüber ich geschrieben habe. In unseren eigenen Projekten verwenden wir eine SQL-Datenbank mit angemessener Normalisierung und Einschränkungen. Es würde das Herz des Puristen verletzen, aber in Wirklichkeit ist unsere Benutzerbasis eher klein (Hunderte oder Benutzer) und die Datenbank war für uns kein Leistungsproblem.
Berin Loritsch
3

OK, da Sie nicht der Hauptingenieur des Projekts sind, müssen Sie seinen Anweisungen für dieses Projekt wirklich folgen.

Ich möchte Sie ermutigen, Ihr eigenes Design des Systems und des Prototyps zu durcharbeiten, damit Sie alle Kompromisse verstehen. Tun Sie dies für Ihre eigene Ausbildung und erwähnen Sie es bei der Arbeit nur, wenn Sie Arbeitsbeispiele demonstrieren können.

Nach meiner Erfahrung gibt es eine Behauptung, dass Einschränkungen die Datenbankleistung beeinträchtigen. Und ja, Sie müssen diese Einschränkungen überprüfen. Es ist jedoch ein weitaus größeres Problem, wenn die Datenbank inkonsistent ist. Dies führt dazu, dass Sie SQL und mehr Code schreiben, um dies zu kompensieren. Dies erhöht häufig die Komplexität des Systems und verlangsamt es.

3nf beschleunigt bei entsprechender Ausführung die Datenbank, da mehr Daten zwischengespeichert werden können, da weniger redundante Daten gespeichert werden. In Ihrem aktuellen Job ist jedoch möglicherweise nicht genügend Daten vorhanden, um den Leistungsunterschied zwischen einer normalisierten und einer nicht normalisierten Datenbank zu erkennen.

Robert Baron
quelle
+1 Tolle Idee. Und wenn die Volumina für eine Entwicklungsmaschine zu groß sind, kann eine 1 in N-Stichprobe oft auch großartige Erkenntnisse liefern.
Robbie Dee
2

Ich denke, sie haben Angst davor, die alte "Travestie", die es zuvor gab, wieder herzustellen, anstatt die referenzielle Integrität selbst.

Er argumentierte, dass wir es an Orten, an denen ich Atomizität will, nicht brauchen ...

Wenn Sie eine solide Argumentation (auch bekannt als "Non-Functional Requirement") für die Notwendigkeit von Atomizität machen können, dann brauchen sie ein gutes, solides Gegenargument, um davon abzukommen, es bereitzustellen.

... anstelle von Abfragen sollten wir mehr im Gedächtnis behalten. Dies ist ein Konstruktionsprinzip. Wir gehen nicht davon aus, dass das Datenvolumen erheblich ansteigen wird.

Hoffen wir, dass Sie Recht haben. Ich würde vorschlagen, dass es riskant ist, sich darauf zu verlassen, dass die Daten "klein genug" sind, um leistungsfähig zu bleiben.

Wie schnell ändern sich diese Regeln? Je mehr Duplikate Sie haben, desto mehr Zeit (auch bekannt als Geld) werden Sie damit verschwenden, dasselbe an mehreren Stellen zu aktualisieren.

Phill W.
quelle
1

Die Schlüsselkonzepte hinter RDBMSs sind weit über 40 Jahre alt. Speicher war damals sehr teuer und jede Art von Redundanz wurde verpönt. Während die Konzepte hinter RDBMS noch stichhaltig sind, hat sich in den letzten Jahrzehnten die Idee der Denormalisierung für die Leistung (um Joins zu reduzieren) durchgesetzt.

Für ein RDBMS einer bestimmten Größe haben Sie normalerweise einen logischen Entwurf (ohne Redundanz) und einen physischen Entwurf (mit Redundanz) für die Leistung.

Schneller Vorlauf bis heute, wo Speicher billig ist und Prozessoren schneller sind als je zuvor, sind einige dieser Anforderungen an das Design nicht so wichtig. Letztendlich ist es ein Urteilsspruch, ob Sie sich für Redundanz und verwaiste Aufzeichnungen interessieren . Für einige Branchen wie das Bankwesen ist die Korrektheit der Daten von entscheidender Bedeutung, so dass schwer einzusehen ist, wie sie sich jemals von RDBMS entfernen werden. Für andere Branchen treten immer wieder neue Akteure in den Markt ein, sodass die Auswahlmöglichkeiten vielfältig sind.

Ob sich Ihr Team mit den Einschränkungen, die ein RDBMS mit sich bringen kann, unwohl fühlt - wer weiß? Sicherlich haben Nachwuchsentwickler, wie ich sehe, nicht das RDBMS, das die Entwickler früherer Generationen hatten, aber dies hängt wahrscheinlich mehr mit der Verbreitung von Entwicklertechnologien und Datenbankplattformen zusammen.

Es gibt kein Ende der Technologien, die ein Entwickler erlernen kann, und es kann schwierig sein, den richtigen Punt für Ihre Karriere zu finden. Die Zeiten, in denen Entwickler ein Alleskönner waren, sind sicherlich lange vorbei - man kann einfach zu viel lernen.

Aber - zur Frage in der Hand. Nach Ihrer eigenen Einschätzung erwarten Sie kein Wachstum des Datenvolumens und das System arbeitet gut. Es wäre eine ziemliche Anstrengung für Sie, die Idee der Neugestaltung von Dingen ohne erkennbaren Nutzen zu verkaufen. Vielleicht , wenn Sie ein Proof of Concept tun könnte , wo ein RDBMS Ansatz hat Vorteile ernten, das wäre eine andere Geschichte sein.

Robbie Dee
quelle
1
Warum wird das herabgestimmt? Das ist eine ausgewogene Antwort. Pragmatismus +1
Dirk Boer
Pragmatismus ist gut, aber Sie müssen trotzdem vorsichtig sein. Das Denormalisieren von Daten im Namen der Leistung zu Beginn eines Projekts ruft nach vorzeitiger Optimierung. Ein altes System, das funktioniert, nicht umzugestalten, ist offensichtlich eine gute, pragmatische Entscheidung. Es ist jedoch alles andere als ein gutes Argument, sich zu weigern, ein neues System nach Industriestandards zu entwerfen .
Vincent Savard
Denormalisierung von Daten im Namen der Leistung zu Beginn eines Projekts ... Hinweis: Sie nicht :)
Robbie Dee
1
Der Wert eines RDBMS hängt nicht von der Festplatteneffizienz ab.
TehShrike
0

Es hängt davon ab, welche Datenbank Sie verwenden.

In einem traditionellen RDBMS haben Sie Recht. Die Vervielfältigung von Daten ist ein Gräuel. Die Spalten und ihre json-Äquivalenz werden unweigerlich nicht mehr synchron sein, weil es nichts gibt, was sie erzwingen könnte. Die Unterstützung von Fremdschlüsseln ist bekannt und leistet hervorragende Arbeit bei der Beschreibung und Durchsetzung von Beziehungen. Und Atomizität ist entscheidend, um fast alles mit Daten zu tun.

In einer nosql-Art von Setup ist es weniger klar. Da keine festen Beziehungen bestehen, wird die Durchsetzung von Beziehungen weniger wichtig. Diese Art von JSON-Inhalten mit Spaltenindex ist auf diesen Systemen viel häufiger, da keine Beziehungen bedeuten, dass die Wahrscheinlichkeit geringer ist, dass sie nicht mehr synchron sind. Und die Atomarität ist auf eine einzelne Tabelle beschränkt, weil nosql so funktioniert.

Was besser ist, hängt davon ab, was Sie tatsächlich tun und was Sie tatsächlich brauchen.

Aber es hört sich so an, als wären Ihre Mitarbeiter in einem Frachtkult. Sie wurden von alten schlechten Sachen gebissen, also müssen die Dinge jetzt das neue glänzende Ding sein. In ein paar Jahren, wenn sie erst einmal von dem neuen, glänzenden Ding gebissen wurden, werden sie hoffentlich feststellen, dass SQL gegen noSQL ein Kompromiss ist.

Aber das werden sie nicht. Hoffentlich wirst du es aber.

Telastyn
quelle