[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" ), 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 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 von Phoenix:

Ich befürchte nämlich (bzw. besser gesagt "Hoffe inständig" ), 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 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 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 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 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 von Phoenix:

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.