[Multi-Tier] Architekturfragen / Quellen gesucht

[Phoenix]

Kurz gesagt:
Ich sollte die Idee des 'lebenden' Weltmodells einfach vergessen und wirklich nur auf einzelne Anfragen reagieren.

Wenn das ganze aber auch im Middle-Tier stateless ist, muss ich mir den defakto aber existierenden Status irgendwo merken. Und das heisst: letzlich hämmern dann N stateless middle-tier server für idealerweise roundabout ne halbe million clients für jede einzelnen request - also sicher mehr als zig millionen mal pro minute - auf die datenbank ein.

Welches dbms hält das denn aus?

[Elvis]

Zitat von Phoenix:

Kurz gesagt:
Ich sollte die Idee des 'lebenden' Weltmodells einfach vergessen und wirklich nur auf einzelne Anfragen reagieren.

Genau.

Zitat:

Wenn das ganze aber auch im Middle-Tier stateless ist, muss ich mir den defakto aber existierenden Status irgendwo merken. Und das heisst: letzlich hämmern dann N stateless middle-tier server für idealerweise roundabout ne halbe million clients für jede einzelnen request - also sicher mehr als zig millionen mal pro minute - auf die datenbank ein.

Schon, aber es werden wohl nur max. 3-mal soviele verschiedene Statements werden wie du Tabellen haben wirst.
Du kannst dir Factory bauen, die dir vorkompilierte Statement für einen gegebenen SQL-String liefert (Läuft dann je eine Instanz auf für jedem WebServer).
Dadurch kannst du die Kosten für Parsing, Ablaufplangenerierung und Berechtigungsprüfung rapide senken. Die letzten beiden Punkte kosten übrigens erheblich mehr Zeit als ein simples SQL Statement wirklich braucht um ausgeführt zu werden.

Zitat:

Welches dbms hält das denn aus?

Keines wird 1 Mio Requests/min auf einer Maschine aushalten. Aber du wirst nicht mit 1 Mio Requests auf einer Maschine beginnen, und du wirst selbst nachdem du schon eine Weile erfolgreich bist noch nicht diese Zahlen haben.
Du kannst mit wachsender Popularität weitere DB server hinzustellen. (Ohne großes Kostenrisiko, mehr STress heißt ja auch mehr Kohle, right?)
Denn ein DB Server für 100 WebServer wäre ein wenig unverhältnismäßig, irgendwann wirst du auch DB Server dazustellen müssen.
Aber plane so dass du anfangs schon mit weiteren, billigen WebServern auf einen erhöhten Ansturm reagieren kannst.

[alzaimar]

Elvis hat es erkannt: Ich treibe mich im Umfeld der mittelständischen Unternehmen mit kleinem Budget rum: Die haben kein Geld für richtige DBMS, also muss man sich irgendwie behelfen.

Und was das Thema Cache anbelangt ist es so, das man in einem Umfeld, das ständig die aktuellsten Daten auf dem Schirm sehen muss ohne so ein Teil imho nicht auskommt, denn dieser Pipifax (ständig die aktuellen Daten vom Server laden) stresst die DB so sehr, das sie damit ausgelastet ist. Mit dem Cache sinkt die Auslastung von 50-60% auf < 1%

Bei Web-Anwendungen sieht das ganz anders aus. Da ist der Overhead, um Updates auf alle Caches zu kommunizieren, ungleich größer.
[OT]
Ein Punkt wird hier sehr ambivalent diskutiert:
Elvis meint (aus Erfahrung, nehme ich an), das ein DBMS eine Tabellenverwaltung ist, mehr nicht. Die Business Logik soll in der Mittelschicht stattfinden.

Ich meine (aus Erfahrung), das in einem DBMS durchaus BL implementiert werden kann (bis zu einem gewissen Abstraktionsgrad) (So wie es MS mit der 2005/2007er Version nachmacht und Oracle(?) schon lange kann)

Mir wäre ein in Java/C# programmierbares DBMS am liebsten. Ich kann aber nicht beurteilen, ob das nun performanter als die Trennung (DMBS + AppServer), oder nicht.
[/OT]
Gut, aber weiter zu Phoenix.

[Phoenix]

Dass Stored Procedures / Functions eine gehörige Last auf der DB erzeugen steht glaube ich ausser Frage.

Wenn ich durch den Verzicht auf diese Features und durch Optimierungen (z.B. die Factory mit kompilierten Statements) Last einsparen kann, brauche ich den zweiten DB-Server später bzw. ich brauche weniger DB-Server für eine bestimmte Nutzerzahl. Das spart Geld. Ein neuer Middle-Tier Server bzw. Webserver kostet zumindest mal keine DBMS-Lizenz und muss auch nicht so viel Hardware (Platten, Speicher) vorhalten. Dort kann man dann also einfacher (billiger) skalieren.

[alzaimar]

Zitat von Phoenix:

Dass Stored Procedures / Functions eine gehörige Last auf der DB erzeugen steht glaube ich ausser Frage.

Hmm... Ich dachte immer, das Views, Functions und SP gerade dazu da sind, das parsen und optimieren einzusparen.

Wenn ich also ein JOIN mit 5 Tabellen habe, dann ist es schneller, jedes Mal das SELECT zum Server zu schicken, als voher ne VIEW oder Function zu basteln? Hmmm. Glaub ich nicht.

Viel viel (um nicht zu sagen: viel) wichtiger ist doch sowieso ein DB-Design, das diese ganzen Performanceprobleme gar nicht aufkommen lässt. Ich sach nur: Die reine 3.NF hat sich die DBMS-Lobby ausgedacht

Ich habe ein Projekt, bei dem die komplexeste Abfrage aus drei Joins besteht (und das ist dann ne VIEW). Alle wichtigen Daten passen in eine Tabelle (also ohne Master-Detail). Das System besteht zwar aus ca. 500 Tabellen, SP, Views etc., aber für die Produktion (Daten reinschaufeln) werden genau drei Tabellen benötigt. Der Rest ist: Stammdaten, Beiwerk, Reports etc.

[Elvis]

Zitat von Phoenix:

...brauche ich den zweiten DB-Server später bzw. ich brauche weniger DB-Server für eine bestimmte Nutzerzahl. Das spart Geld...

Ganz genau mein Punkt.
Das DBMS wird hier eingesetzt weil es sehr schnell Datenschnipsel speichern und wiederfinden kann.
Businesslogik in der DB abzubilden ist so etwas, was in den 90'ern ganz hipp war[1].
Ich muss zu meiner Schande gestehen dass ich mir bis vor kurzem (vor 2,5 Jahren) ebenfalls noch auf die Art die Füße und Hände gefesselt habe.

@Alzhaimar, sicherlich sparst du dir mit Views theoretisch Parsingzeit, aber darum ging es mir nicht.
SProcs werden gerne benutzt um alles Mögliche zu prüfen, Phoenix wird aber nicht das nötige Geld haben um genügend DB Server heranzuschaffen, die ihre überteuerte Existenz darin fristen wertvolle CPU-Zyclen mit SPRocs in abartig lahmen DB-Skriptsprachen zu verbraten (Selbst PL/SQL ist lahm verglichen mit .Net, und es ist eine Schnecke verglichen mit FPC)...
Außerdem halte ich es generell für nicht so sinnvoll, Dinge in die DB zu packen, die nicht direkt mit Speichern oder Abfragen von Daten verbunden sind.
Wenn du das was in der DB steckt so einfach wie möglich hälst (einfach für die DB, nicht für dich ), ist es einfacher mehrere DBMS zu unterstützen oder wie hier mit einem freien DBMS zu beginnen um später (wenn Profit da ist, absehrbar ist) zum Beispiel auf Sybase oder DB2 zu wechseln.


[1]Aber auch nur aus Mangel/Popularität von Middleware-Technologien, nicht weil es performant oder einen anderen Vorteil als Zentralisierung oder alter Gewohnheit hätte.

[alzaimar]

Ok ok, aber warum verpasst MS dann seinem Server die Möglichkeit, eine Stored Procedure in C# zu schreiben? Etwa, damit die Leute darauf reinfallen und mehr Server kaufen (müssen)? Hmmm... Wenn ich mir das so überlege... stimmt.

Ich glaube, es gibt einen goldenen Schnitt, wieviel 'BL' ich in das DBMS packe und was in der Mittelschicht bleibt. Auch bei der Performance ist es so, das man bestimmte Prüfungen doch besser im DBMS macht, weil der Overhead dann doch kleiner ist. Bei Kontrollstrukturen jedoch hört der Spass auf.

BL über Trigger abzubilden ist schon ziemlich krank, aber ich hab z.B. grad eben einen Notschalter implementiert: Bestimmte Datensätze (ISO 9000) dürfen NIE gelöscht werden und das erreiche ich am sichersten über einen Trigger.

[Phoenix]

Hrm.

Jetzt kommt mir der nächste Punkt in dem Geschäft, der mich zum grübeln bringt: Gehen wir davon aus, wir haben eine stateless Architektur und alles was von den Usern kommt wäre damit abgedeckt.

Es gibt in der Anwendung aber auch kontinuierliche Prozesse.

Seien es Bewegungen von Objekten in einem Koordinatensystem von A nach B in einer variablen Geschwindigkeit, sei es der Preis von einem Gut welcher sich durch Angebot und Nachfrage modifiziert oder einfach ein Lager, dessen Bestand durch unregelmässige Zuflüsse und Abgänge modifiziert wird. Die Zugänge hängen von der Produktion ab, diese von der Anzahl der Produktionsstätten, deren Anzahl ist wiederum variabel und hängt von anderen Faktoren ab.

Wenn ich jetzt für sagen wir nur mal 100.000 Lagerobjekte (z.B. 10.000 User, jeweils 10 Lager - wie schon erwähnt rechne ich jedoch eher mal mit um die 300.000 User) die Bestände kontinuierlich aktuell halten will, muss ich für jedes dieser Lager immer sämtliche relevanten Daten abfragen, den Wert ändern und posten. Um durch 100.000 Objekte zu iterieren und die Werte zu aktualisieren (wenn die zugrundeliegenden Daten im Speicher sind) brauche ich wahrscheinlich nichtmal eine Sekunde. Um diese ganzen Änderungen zu posten aber dann gleich mal 100.000 Update-Statements. In 10 Sekunden sind wir schon bei einer Million Statements. Und da sind noch nichtmal die zugrundeliegenden Daten gefetcht (nagut, das ist eher ein Select * from 3 oder 4 Tabellen, die in den Speicher und dann damit arbeiten). Massenupdates gehen im Prinzip nicht, weil die Daten von etlichen Faktoren abhängen. Das liesse sich wohl mit einem Statement abbilden, jedoch würde das aller Wahrscheinlichkeit nach etliche Minuten lang laufen.

Wie kann ich also solche kontinuierlichen Vorgänge aufgrund vieler variabler Daten abbilden, ohne die Datenbank so massiv zu stressen, dass sie noch ohne normale Userrequests schon in die Knie geht?

[Phoenix]

*Push*

Zitat von Phoenix:

Wie kann ich also solche kontinuierlichen Vorgänge aufgrund vieler variabler Daten abbilden, ohne die Datenbank so massiv zu stressen, dass sie noch ohne normale Userrequests schon in die Knie geht?

[alzaimar]

Wenn deine DB schon so dermaßen viele Daten verwalten muss, dann wirst Du mit Sicherheit einen DB-Cluster haben. Oder einen Server nur für diese Daten.

Überleg mal: Du willst ein System, das Daten im RAM hält und sehr schnell Datensätze zu einer bestimmten ID liefert. Genau dafür ist ein DBMS gemacht. Bei uns war das Problem, das der DB-Server unterdimensioniert ist und/oder das DB-Design Schrott, also mussten wir zu so einer Lösung (Cache) greifen. Das Resultat ist allerdings beeindruckend: Von einer lahmen Krücke zu einem Ferrari mit 200 Zeilen Code und 2 Tagen Frickelei.