[Multi-Tier] Architekturfragen / Quellen gesucht

[Phoenix]

Hi,

für ein Studienprojekt wollen wir eine recht komplexe Anwendung entwickeln. Sollte gute Themen für Diplomarbeiten abwerfen, deswegen wollen wir das wirklich komplett Ingenieursmässig durchziehen.

Das ganze soll eine Anwendung sein, die über Webservices angesprochen und dann auf 'dummen' Clients bzw. mit einer Weboberfläche bedient werden soll.

Da nicht zu viel auf der Datenbank passieren soll, die einzelnen Usern aber viele Daten untereinander austauschen müssen dachte ich da an eine Mittelschicht, in der alles passiert, und auf die die Webservices dann zugreifen.

Nun meine Fragestellung:
Wo finde ich gute Literatur bzw. Hinweise oder noch besser Erfahrungsberichte, wie man so eine Mittelschicht geschickt skalierbar, ggf. auch verteilbar entwirft?

Ich befürchte nämlich (bzw. besser gesagt "Hoffe inständig" :mrgreen:), dass die Anwendung aufgrund sehr vieler User ziemlich unter Stress gerät. Wenn ich dann aber nicht reagieren und die Anwendung auf mehrere Rechner verteilen kann hab ich ein Problem. Also kurz: Wie geht man sowas am besten an?

[merlin17]

Hallo Phoenix,

evtl. findest Du hier etwas bei DataAbstract ... (gegoogelt hast Du sicherlich schon)

http://www.remobjects.com/product/?id={E5C06C0F-B41C-4468-B0AD-DDB5F164EF73}


:-) thomas

[Phoenix]

Hi,

das ist ein konkretes Produkt, aber leider gibts da keine theoretischen Grundinformationen über das allgemein Thema, und das war eher was ich gesucht habe.

Edit Nachtrag: Bin nur neugierig: Kennst Du das nur oder arbeitest Du auch damit? ;-)

[dfried]

Zitat:

Zitat von Phoenix

das ist ein konkretes Produkt, aber leider gibts da keine theoretischen Grundinformationen über das allgemein Thema, und das war eher was ich gesucht habe.

Edit Nachtrag: Bin nur neugierig: Kennst Du das nur oder arbeitest Du auch damit? ;-)

Der Artikel von denen dürfte aber schon an das rankommen was du suchst, bezieht sich zwar auf Dataabstract, erklärt aber auch ein bisschen die Grundinformationen von MultiTier.

Ich arbeite übrigends auch schon mehrere Jahre mit deren Komponenten (sowohl RemObjects auch auch DataAbstract).

[Elvis]

Zitat:

Zitat von Phoenix

Ich befürchte nämlich (bzw. besser gesagt "Hoffe inständig" :mrgreen:), dass die Anwendung aufgrund sehr vieler User ziemlich unter Stress gerät. Wenn ich dann aber nicht reagieren und die Anwendung auf mehrere Rechner verteilen kann hab ich ein Problem. Also kurz: Wie geht man sowas am besten an?

Ich habe dir ja schon in public.Chrome ein paar Ansätze geliefert.
Nun wärst du an der Reihe spezifische Fragen zu stellen.
Um's nochmal zu wiederholen:

• reduziere die Arbeit des DBMS auf das absolut Notwendigste[1] und du wirst lange Zeit mit nur einem DB Server auskommen
  (solange der auch genug Dampf hat)
• Richte dich auf eine wachsende Anzahl von billigen WebServer-Pizzakartons ein, die alle Strom, Bandbreite, Klimatisierung und ein Dach über dem Kopf haben wollen. ;)

[1]keine Sortierungen in der DB, möglichst einfache Abfragen, möglichst wenige Joins in DB-Abfragen.

[alzaimar]

Zitat:

Zitat von Elvis

... möglichst wenige Joins in DB-Abfragen.

Das lässt sich mit komplexen Anwendungen nur schwer vereinbaren, insbesondere, wenn eman mit polymorphen bzw. Metadaten hantiert.

Ich würde eher zu folgender (algemeingültiger) Maxime raten:

Jede Aufgabe wird dem Experten zugewiesen, der dieses Problem am besten lösen kann:

Daten in das DBMS, Logik i.A. in die Mittelschicht. Wobei die 'Logik' zwischen DBMS und Mittelschicht verteilt wird. Oder anders herum: Man sollte DBMS und Logik ('Geschäftsregeln') als einheit betrachten, also Mittelschicht und DBMS logisch zusammenfassen. Innerhalb dieser Entität muss man natürlich deine Grundregeln unbedingt beachten, aber das mit den vielen JOINS lässt sich nunmal nicht immer vereinfachen.

Wir haben gerade sehr erfolgreich einen Cache installiert, der die Datensätze einer VIEW bestehend aus ca. 10-15 Tabellen im Speicher hält und zwischen Mittelschicht und DBMS installiert wird. Er parst das SQL-Statement und schafft es in einem Bruchteil der Zeit, die notwendigen (und zuvor bereits geladenen) Daten aus seinem Cache zu liefern, sodaß wirklich nur neue Datensätze nachgeladen werden müssen (Übrigens ein gutes Beispiel für eine Studienarbeit)

Aber grundsätzlich muß ich Elvis Recht geben: Ein gutes DB-Design ist unumgänglich für effektive und performante Datenzugriffe.

Weiterhin würde ich schon im Ansatz den DB-Zugriff im DBMS so abstrahieren, das nachträgliche Änderungen am Design direkt vorgenommen werden können. Damit meine ich: Für den Zugriff: Views statt Tabellen und Stored Procedures statt INSERT/UPDATE und DELETE. Als Alternative auch die 'updateable Views' und Trigger auf diesen Views.

Ich würde undbedingt eine logische Abstraktionsschicht zwischen DBMS und Mittelschicht und MS und Client vorsehen. Erst damit wird das Teil richtig 'Fett'.

[Phoenix]

Zitat:

Zitat von Alzaimar

Für den Zugriff: Views statt Tabellen und Stored Procedures statt INSERT/UPDATE und DELETE. Als Alternative auch die 'updateable Views' und Trigger auf diesen Views.

Insert / Update -SP's sind eh ne gute Idee. Ein Call, und wenn's den Datensatz noch nicht gibt ist er drin und wenn's ihn schon gibt wird er upgedatet.

Auf die Idee mit einer Art Cache bin ich auch schon gekommen.

Meine Vorstellung wäre: Die Mittelschicht hält alle für die Clients benötigten Daten im Speicher. Nennen wir es mal das 'Weltbild' der Anwendung, angelehnt an das Daten-Weltbild unseres Fußballroboters hier an der Hochschule.

Die Mittelschicht berechnet das lebende Weltbild laufend fort und sorgt dafür, dass die Daten in der Datenbank aktuell gehalten werden. Auf der anderen Seite beschickt sie die Clients auf Anfrage mit den Daten und nimmt Änderungen von den Clients an.

Was aber, wenn das Weltbild zu komplex oder groß wird, so dass die Schicht das nicht mehr ordentlich (=performant) verwalten kann? Was, wenn es zu viele Clients / Connections werden und die Schicht die nicht mehr alle versorgen kann (Anzahl Connections zu groß)?

Ganz konkrete Frage:
Wie plant man so eine Mittelschicht, wenn diese ggf. später auf mehrere Rechner verteilt werden muss?
Ich will die ja nicht immer zu Tode synchronisieren. Und permanent auf der DB nach geänderten Daten pollen ist auch nicht gut.

Ich sehe da zwei Möglichkeiten:

1.) Aufbrechen des Weltmodells in N Teile. Begrenzt die Sache auf maximal N Rechner, und da ein Client ja früher oder später doch Daten aus allen Teile braucht connected schliesslich doch jeder einzelne Client auf jeden Weltmodellrechner. Die Anzahl der Connections bleibt also für jeden der N Rechner gleich hoch. Was hier, wenn es zu viele Clients werden?

2.) Verteilen des kompletten Weltmodells auf X Rechner. Dann kann man für jeweils N Clients einen Middletier-Rechner nehmen und die Anzahl der Connections so effektiv begrenzen. Problem: Synchronisierung der Daten zwischen den Middle-Tier-Rechnern? Und weiteres Problem: Was, wenn das Weltmodell zu komplex/groß für einen Rechner wird?

[alzaimar]

Ich würde einen Cache zum Schluss installieren, der die aktuellsten Daten gespeichert hat: unser hält 50MB-Daten. Wenn die 50MB voll sind, werden die Datensätze, die am längsten ungenutzt rumliegen, verworfen (LRU: Least Recently Used)

Persönlich würde ich einen Cache nicht als Bestandteil einer Mittelschicht definieren. Die Mittelschicht bündelt Anfragen und bildet die 'Geschäftslogik' ab (Schulwissen).

Um auf das Problem der verteilten System zu kommen, fehlt mir das Fachwissen: Denn es gibt mit Sicherheit fertige Systeme (CORBA, ORB etc.).

Ich bastel gerade an einer Studie für so ein System. Die Eckpunkte sind
1. Einzelne miteinander kommunizierende Module (DLL) können jederzeit ausgetauscht werden, ohne das System herunter zu fahren. Die Module sind auch per Remote austauschbar
2. Der Aufruf der einzelnen Methoden/Prozeduren erfolgt nach einer einheitlichen Schnittstelle:

Code:

CALL Module.Function InParam OutParam ResultParam

Die Parameter sind dabei XML/JSON oder was Du willst.
3. Einem Modul, das ein anderes Modul aufruft, ist es egal, wo konkret dieses Modul installiert ist. Alle Appserver tauschen ständig ihre installierten Module aus, Konflikte (also Mehrfachinstallationen eines Moduls) werden schnell erkannt und angezeigt. Der Appserver leitet einen CALL ggf. an die richtige Stelle weiter und transportiert das Ergebnis auch gleich weiter zum Aufrufer.

Eigentlich besteht das ganze System 'nur' aus einer sehr robusten DLL-Verwaltung mit TCP Anbindung, denn alle Module sind ihrerseits DLL. So lässt sich das gesamte System jederzeit upgraden, austauschen und verbessern.

Vielleicht wäre diese Architektur ein guter Ansatzpunkt für Euch.

[Phoenix]

Zitat:

Zitat von alzaimar

Um auf das Problem der verteilten System zu kommen, fehlt mir das Fachwissen: Denn es gibt mit Sicherheit fertige Systeme (CORBA, ORB etc.).

CORBA ist eine Technologie. Der ORB der Kern davon ;-)

Das Problem ist nicht, wie ich die Dinger miteinander kommunizieren lasse, sondern wie ich die Struktur aufbaue damit ich weiss was wann von wem wohin kommuniziert werden muss. Die Fragestellung setzt also eine Ebene höher an. Die verwendete Technologie ergibt sich dann aus den Anforderungen der gewählten Struktur.

Edit Nachtrag:

Zitat:

Zitat von alzaimar

Der Appserver leitet einen CALL ggf. an die richtige Stelle weiter und transportiert das Ergebnis auch gleich weiter zum Aufrufer.

Eigentlich besteht das ganze System 'nur' aus einer sehr robusten DLL-Verwaltung mit TCP Anbindung, denn alle Module sind ihrerseits DLL. So lässt sich das gesamte System jederzeit upgraden, austauschen und verbessern.

Auch hier habe ich das Problem: Ein Modul, dass z.B. eine sehr zentrale Stelle einnimmt und bei nahezu jeder Clientanfrage benötigt wird (z.B. Sessionverwaltung bzw. Ping dass die Session noch lebt), kommt was die Anzahl der gleichzeitigen Verbindungen angeht massigst unter Stress. So ein Rechner kann aber nur N Verbindungen gleichzeitig managen. Stoße ich irgendwann an diese Grenze habe ich ein massives Problem.

[Elvis]

Zitat:

Zitat von Phoenix

Zitat:

Zitat von Alzaimar

Für den Zugriff: Views statt Tabellen und Stored Procedures statt INSERT/UPDATE und DELETE. Als Alternative auch die 'updateable Views' und Trigger auf diesen Views.

Insert / Update -SP's sind eh ne gute Idee. Ein Call, und wenn's den Datensatz noch nicht gibt ist er drin und wenn's ihn schon gibt wird er upgedatet.
Auf die Idee mit einer Art Cache bin ich auch schon gekommen.

Ist aber, sorry, eine grottenschlechte Idee für das was du vorhast.
DBMS' != Oracle[1], Sybase oder DB2 skalieren im allgemeinen furchtbar.
MSSQL skaliert zum Beispiel gar nicht, da dort Parallelität nur zur mehr Sicherheit, nicht zu mehr Performance führt.
Cluster aus einem der ersten 3 DBMS werden aber schnell abartig teuer und zwar aus 2 Gründen:

• Lizenzen für das DBMS
• Ein weiterer DB-Server kostet mal eben das 5-10-fache als das, was 4 weitere Pizzakartons kosten, die als weitere WebServer gut genug sind.
  (zig Highend-HDDs, Tonnenweise RAM, zig Highend-Prozis for den DB Server)

Ein einzelner lahmer DB Server im Cluster kann diesen signifikant ausbremsen.
Du solltest also nur Kick-Ass Hardware nehmen und möglichst nur einen DB Server benutzen, solange es geht. Diese(n) aber nicht mit solchen Pippifax stressen, den die Mittelschicht übernehmen sollte/kann.

Zitat:

Meine Vorstellung wäre: Die Mittelschicht hält alle für die Clients benötigten Daten im Speicher.

Wozu?
Du hast einen DB Server mit sagen wir 30 GB RAM, dürfte reichen um alle benötigten Indizes kontinuierlich im Speicher zu halten. Du kannst auch mit weniger anfangen.
Ein eigenes DBMS zu friemeln, das sich selbst in ein anderes persistiert macht doch keinen Sinn. ;)
Caching skaliert so grottenschlecht, dass es für dich praktisch als Performancebremse herausstellen würde.
Alzaimars System ist wahrscheinlich anders ausgelegt und wahrscheinlich muss er nicht auf annähernd so viele gleichzeitige Requests acht geben wie du.
Je ein kleiner Minicache für jeden Webserver wäre eine Möglichkeit, aber die Vorteile/Machbarkeit von sowas wirst du jetzt noch nicht beurteilen können.

Zitat:

Die Mittelschicht berechnet das lebende Weltbild laufend fort und sorgt dafür, dass die Daten in der Datenbank aktuell gehalten werden. Auf der anderen Seite beschickt sie die Clients auf Anfrage mit den Daten und nimmt Änderungen von den Clients an.

Dein Fussballroboter muss aber nicht über 20 Maschinen verteilt werden, die alle einen synchronen Datenbestand haben wollen. ;)
Für mich klingt das wieder nach etwas was schlecht bis gar nicht skalierbar ist und somit nicht nur zum Flaschenhals sondern sogar zum Strohhalm wird...

Zitat:

Was aber, wenn das Weltbild zu komplex oder groß wird, so dass die Schicht das nicht mehr ordentlich (=performant) verwalten kann? Was, wenn es zu viele Clients / Connections werden und die Schicht die nicht mehr alle versorgen kann (Anzahl Connections zu groß)?

DU hättest dir da praktisch ein eigenes DBMS gebastelt und bisher habe ich noch keinen Fall gesehen, in dem der Weg des "eigenen DBMS" nicht komplett für'n *piep* war. ;)

Zitat:

Ganz konkrete Frage:
Wie plant man so eine Mittelschicht, wenn diese ggf. später auf mehrere Rechner verteilt werden muss?

Jeder RemObjects SDK Service oder .Net WebService ist standardmäßig state-less.
Du müsstest schon einiges falsch machen, damit er das nicht mehr ist.
Wenn ein Service keinen Status halten muss, ist es egal welcher Server den Request bekommt.
Das ist das Grundprinzip von skalierbaren Services. Und ja, es ist wirklich so simpel. :)

Zitat:

Ich will die ja nicht immer zu Tode synchronisieren. Und permanent auf der DB nach geänderten Daten pollen ist auch nicht gut.

Polling bringt dir auch rein gar nix.
WebServices sind HTTP, also Request->Response. Der Client fragt dich was, du antwortest, du schickst niemals einfach so etwas raus.
Und da du dein Weltmodell nicht in einer skalierbaren Umgebung implementieren kannst wird auch das Polling vom Server zur DB unnütz.


[1]Wobei Oracle mittlerweile zu buggy ist um für Neuentwicklungen noch ernst genommen werden zu können.

[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:

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:

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. :gruebel:

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 :zwinker:

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:

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:

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?

:duck:

[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.