Wann werden Transaktionen mehr zur Last als zum Vorteil?

Question

Die transaktionale Programmierung ist in der heutigen Zeit ein Grundpfeiler der modernen Entwicklung. Parallelität und Fehlertoleranz sind entscheidend für die Langlebigkeit einer Anwendung, und zu Recht ist die Transaktionslogik einfach zu implementieren. Mit dem Anwachsen von Anwendungen scheint es jedoch so zu sein, dass transaktionaler Code die Skalierbarkeit der Anwendung immer mehr belastet. Wenn Sie in verteilte Transaktionen und gespiegelte Datensätze einbinden, werden die Probleme sehr kompliziert. Ich bin neugierig, was scheint der Punkt zu sein, in der Datengröße oder Anwendungskomplexität, dass Transaktionen häufig Quelle der Probleme werden (verursacht Zeitüberschreitungen, Deadlocks, Leistungsprobleme in kritischen Code usw.), die lästiger zu beheben sind, Problembehandlung oder Problemumgehung als das Entwerfen eines Datenmodells, das in sich selbst fehlertoleranter ist, oder das Verwenden anderer Mittel, um die Datenintegrität sicherzustellen. Welche Entwurfsmuster dienen auch dazu, diese Auswirkungen zu minimieren oder die Standardtransaktionslogik obsolet oder unproblematisch zu machen?

-

EDIT: Wir haben bisher einige Antworten von angemessener Qualität bekam, aber ich denke, ich werde eine Antwort schreiben mir einige der Dinge zu bringen, die ich gehört habe über zu inspirieren, um zu versuchen etwas zusätzliche Kreativität; Die meisten Antworten, die ich bekomme, sind pessimistische Ansichten des Problems.

Eine weitere wichtige Anmerkung ist, dass nicht alle Deadlocks ein Ergebnis von schlecht kodierten Prozeduren sind; manchmal gibt es missionskritische Operationen, die von ähnlichen Ressourcen in unterschiedlichen Aufträgen abhängen, oder komplexe Verbindungen in verschiedenen Abfragen, die aufeinander treten; Dies ist ein Problem, das manchmal unvermeidlich scheint, aber ich war Teil der Überarbeitung von Workflows, um eine Ausführungsreihenfolge zu ermöglichen, die weniger wahrscheinlich ist.

Answer 1

Ich denke, dass kein Entwurfsmuster dieses Problem an sich lösen kann. Ein gutes Datenbankdesign, eine gute Programmierung von Geschäftsprozeduren und vor allem das Lernen, wie Sie Ihre Transaktionen kurz halten, werden die meisten Probleme lindern. Es gibt keine 100% garantierte Methode, keine Probleme zu haben.

Im Grunde jeden Fall, dass ich, obwohl in meiner Karriere gesehen habe, wurden die gespeicherten Prozeduren gelöst Deadlocks und Verlangsamungen durch Fixieren:

• sicherstellen, dass alle Tabellen, um Zugriff verhindert Deadlocks
• Befestigungs Indizes und Statistiken machen alles schneller (daher verringert die Wahrscheinlichkeit von Deadlock)
• manchmal gab es keinen wirklichen Bedarf an Transaktionen, es sah nur aus wie
• manchmal Transaktionen konnten eliminiert werden, indem mehrere Anweisung gespeichert p Verfahren in Einzelaussagen.

Answer 2

Die Verwendung von gemeinsam genutzten Ressourcen ist auf lange Sicht falsch. Denn durch die Wiederverwendung einer bestehenden Umgebung schaffen Sie immer mehr Möglichkeiten. Sehen Sie sich nur die beschäftigten Biber an :) Die Art, wie Erlang arbeitet, ist der richtige Weg, um fehlertolerante und leicht verifizierbare Systeme zu erstellen.

Der Transaktionsspeicher ist jedoch für viele Anwendungen, die weit verbreitet sind, unerlässlich. Wenn Sie beispielsweise eine Bank mit ihren Millionen von Kunden konsultieren, können Sie die Daten nicht einfach aus Gründen der Effizienz kopieren.

Ich denke, Monaden sind ein cooles Konzept, um das schwierige Konzept des Zustands zu ändern.

Answer 3

Wenn Sie hier von "Cloud Computing" sprechen, wäre die Antwort, jede Transaktion an dem Ort zu lokalisieren, an dem sie in der Cloud stattfindet.Es ist nicht erforderlich, dass die gesamte Cloud konsistent ist, da dies die Leistung beeinträchtigen würde (wie Sie bemerkt haben). Behalten Sie einfach im Auge, was sich geändert hat und wo Sie sich befinden, und verarbeiten Sie mehrere kleine Transaktionen, während sich Änderungen im System verbreiten. Die Situation, in der Benutzer A den Datensatz R und Benutzer B am anderen Ende der Cloud aktualisiert, sieht (noch) nicht, dass Benutzer A die Änderung noch nicht in der aktuellen strikten Transaktionsumgebung vorgenommen hat. Dies könnte zu Diskrepanzen in einem update-lastigen System führen, so dass Systeme so konzipiert werden sollten, dass sie mit Updates so wenig wie möglich arbeiten - Dinge auf die Aggregation von Daten verlagern und die Aggregate herausziehen, sobald die genaue Zahl kritisch ist Schreibzeit in kritische Lesezeit).

Nun, nur mein POV. Es ist schwierig, ein System zu entwerfen, das in diesem Fall anwendungsunabhängig ist.

Answer 4

Versuchen Sie, Änderungen auf der Datenbankebene mit der geringsten Anzahl möglicher Anweisungen vorzunehmen.

Die allgemeine Regel ist, eine Ressource so früh wie möglich zu sperren. Mit T-SQL, PLSQL, Java auf Oracle oder einer ähnlichen Art und Weise können Sie die Zeit reduzieren, in der jede Transaktion eine freigegebene Ressource sperrt. I fact-Transaktionen in der Datenbank werden mit Sperren auf Zeilenebene, Multiversionen und anderen Arten von intelligenten Techniken optimiert. Wenn Sie die Transaktion in der Datenbank durchführen können, speichern Sie die Netzwerklatenz. Appart von anderen Schichten wie ODBC/JDBC/OLEBD.

Manchmal versucht der Programmierer, die guten Dinge einer Datenbank zu erhalten (Es ist transaktional, parallel, verteilt,), aber behalten Sie ein Caché der Daten. Dann müssen sie einige der Datenbankfunktionen manuell hinzufügen.

Answer 5

Ein Ansatz, von dem ich gehört habe, besteht darin, ein versioniertes Insert-Modell zu erstellen, bei dem keine Aktualisierungen jemals stattfinden. Während Select wählt die Version nur die letzten Zeilen aus. Ein Nachteil, den ich bei diesem Ansatz kenne, ist, dass die Datenbank sehr schnell sehr groß werden kann.

Ich weiß auch, dass einige Lösungen, wie FogBugz, keine erzwungenen Fremdschlüssel verwenden, was meiner Meinung nach auch einige dieser Probleme mildern würde, da der SQL-Abfrageplan verknüpfte Tabellen während Auswahlen oder Aktualisierungen sperren kann, selbst wenn nein Daten ändern sich in ihnen, und wenn es eine stark umkämpfte Tabelle ist, die gesperrt wird, kann sie die Chance von DeadLock oder Timeout erhöhen.

Ich weiß nicht viel über diese Ansätze, da ich sie nie benutzt habe, also nehme ich an, es gibt Vor- und Nachteile für jeden, den ich nicht kenne, sowie einige andere Techniken, die ich nie habe davon gehört.

Ich habe auch etwas Material von Carlo Pescios recent post untersucht, das ich leider nicht genug Zeit hatte, um es gerecht zu werden, aber das Material scheint sehr interessant.