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 Performance
bremse 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 Serv
er 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.