Kann ‚moving Geschäftslogik Anwendungsschicht‘ die Leistung steigern?

Question

In meinem aktuellen Projekt, die Business-Logik in gespeicherten Prozeduren (a 1000 von ihnen) umgesetzt und jetzt wollen sie es skalieren, wie das Geschäft wächst. Architekten haben beschlossen, die Geschäftslogik auf Anwendungsebene zu bewegen (.net) Leistung und Skalierbarkeit zu steigern. Aber sie sind nicht neu zu gestalten / alles neu zu schreiben. Kurz gesagt, die gleichen SQL-Abfragen, die von einem SP abgefeuert werden werden von einer .net-Funktion ADO.Net abgefeuert werden. Wie kann diese jede Leistung ergeben?

Um das Beste aus meinem Verständnis müssen wir die Geschäftslogik Anwendungsschicht bewegen, wenn wir DB Unabhängigkeit benötigen, oder es gibt einig Business-Logik, die besser in einer OOP-Sprache implementiert werden kann als eine RDBMS-Engine (wie eine Hierarchie durchlaufen oder einig Bildverarbeitung, etc ..). Im Rest der Fälle, wenn es keine komplizierte Geschäftslogik zu implementieren ist, glaube ich, dass es besser ist, die Business-Logik in DB selbst zu halten, zumindest die Netzwerkverzögerungen zwischen der Anwendungsschicht und DB können auf diese Weise vermieden werden.

Bitte lassen Sie mich Ihre Meinung wissen. Ich bin ein Entwickler bei einigen Architekturentscheidungen mit einem wenig Zögern suchen, entschuldigen Sie meine Unwissenheit in dem Thema.

Answer 1

Wenn Sie Ihre Geschäftslogik noch in SQL-Anweisungen ist, wird die Datenbank so viel Arbeit wie vor zu tun, und Sie werden nicht eine bessere Leistung. (Kann mehr Arbeit sein, wenn sie nicht in der Lage ist Abfrage zwischenzuspeichern planen als effectivily wie wenn gespeicherte Prozeduren verwendet wurden)

Um ein bessere Leistung erhalten Sie müssen einige Arbeiten an die Anwendungsschicht bewegen, können Sie zum Beispiel Cache-Daten auf dem Anwendungsserver, und führen Sie einen Nachschlag oder eine Plausibilitätsprüfung, ohne die Datenbank zu schlagen?

Answer 2

Architektur Argumente wie diese müssen oft viele Trades-off, wenn man bedenkt Leistung in Isolation oder ideed betrachten nur ein Aspekt der Leistung wie Reaktionszeit unter Berücksichtigung dazu tendiert, das größere Bild verpassen.

Es eindeutig einige Trade-off-Logik in der Datenbankschicht und den Versand der Daten zurück an die applciation Schicht zwischen der Ausführung und dort verarbeitet werden. Daten-Schiffskosten im Vergleich zu Prozesskosten. Wie Sie die Kosten und die Komplexität der Geschäftslogik wird ein wichtiger Faktor, die Größe der Daten zeigen, zu versendenden eine andere wäre.

Es ist denkbar, wenn die DB-Schicht besetzt ist immer, dass auf eine andere Ebene Verarbeitung Offloading erlauben kann größer Gesamtdurchsatz, auch wenn die einzelnen Antworten der Zeit erhöht werden. Wir könnten dann das App Tier um skalieren mit einigen zusätzlichen Lasten zu bewältigen. Würden Sie nun, dass die Leistung sagen wird verbessert (höheren Gesamtdurchsatz) oder verschlechtert (Soem Erhöhung der Reaktionszeit).

Jetzt prüfen, ob das App Tier interessant Caching-Strategien implementieren könnte. Vielleicht bekommen wir eine sehr große Leistung gewinnen - keine Last auf der DB überhaupt für einige Anfragen

!

Answer 3

Ich denke, diese Entscheidungen sollten nicht architektonisches Dogma gerechtfertigt werden. Daten würden sehr viel mehr Sinn machen.

Statements wie „All Geschäftslogik gehört in Stored Procedures“ oder „Alles soll auf der mittleren Ebene sein“ neigen dazu, von Menschen gemacht werden, dessen Wissen auf Datenbanken oder Objekte beschränkt sind. Besser zu kombinieren, sowohl wenn Sie beurteilen, und tun es auf der Grundlage von Messungen.

Zum Beispiel, wenn einer Ihrer Verfahren wird eine Menge Daten Knirschen und eine Handvoll Ergebnisse der Rückkehr gibt es ein Argument, das heißt es auf der Datenbank bleiben soll. Es gibt wenig Sinn, in Millionen von Zeilen in dem Speicher auf der mittleren Ebene zu bringen, Knirschen sie, und dann die Datenbank mit einer anderen Rundfahrt zu aktualisieren.

Eine weitere Überlegung ist, ob die Datenbank zwischen Anwendungen gemeinsam genutzt wird. Wenn ja, sollte die Logik in der Datenbank bleiben, damit alle sich verwenden können.

Mittlere Ebene sind in der Regel kommen und gehen, aber die Daten bleiben für immer.

Ich bin ein Objekt Kerl mir, aber ich würde vorsichtig vorgehen.

Es ist ein kompliziertes Problem. Ich glaube nicht, dass Schwarz-Weiß-Anweisungen in jedem Fall funktionieren werden.

Answer 4

Nun, wie andere schon gesagt haben, es hängt von vielen Faktoren ab. Aber von Ihnen hinterfragen es scheint, haben die Architekten in der Anwendung die gespeicherten Prozeduren von innen DB auf dynamische SQL bewegen schlagen. Das klingt mir sehr zweifelhaft. SQL ist eine Reihe orientierte Sprache und Geschäftslogik, die in SQL wäre besser Massieren der großen Menge an Datensätzen erfordert. Denken Sie komplizierte Such- und Berichtstyp-Funktion. Auf der anderen Seite Position Bearbeitungen mit Validierung von Business Logic entspricht, ist viel besser in einer Programmiersprache getan. Caching von sich langsam ändernden Daten in App-Tier ist ein weiterer Vorteil. Dies ist sogar besser, wenn Sie Middle-Tier-Dienst gewidmet haben, der als Gateway zu allen Daten handelt. Wenn Daten direkt zwischen unterschiedlichen Anwendungen gemeinsam genutzt wird, dann kann gespeicherte Prozedur eine gute Idee sein. Sie haben auch die Verfügbarkeit / Erfahrung von SQL Talent vs Programmierung Talent in der Organisation zu berücksichtigen. Es gibt wirklich keine allgemeine Antwort auf diese Frage.