Eine Frage des Caching

Hallo Community,

es existiert die Aufgabe, eine umfangreiche erweiterbare Unternehmenslösung für sozialpflegerische Einrichtungen zu entwickeln.
Den Kern der Anwendung bilden eine Reihe von Geschäftsobjekten, welche die interne Struktur des Unternehmens plastisch nachbilden.

Im Einzelnen sind dies hierarchisch gegliederte Organisationseinheiten und die ihnen angehörenden Mitarbeiter sowie an Einheiten und Personen geknüpfte Rollen u. Berechtigungssätze, die auf späteren Prozesse und Arbeitsabläufe angewendet werden sollen.
Im weiteren Sinne gehören noch die Patienten/Zubetreuenden dazu.

Anwendungszielgruppe sind mittlere bis grosse Unternehmen mit einigen hundert bis einige tausend Mitarbeiter und ebenso grosser Zahl an Zubetreuenden.

Datenspeicherung erfolgt in erster Linie über Datenbanken, zweitrangig kommen noch Verzeichnisdienste und XML-Strukturen hinzu.

Als Anwendungsserver sollen vorrangig Webserver eingesetzt werden.

Nun komme ich zur eigentlichen Frage...

Es besteht nun die konkrete Überlegung, die oben genannten strukturellen Elemente statisch (bzw. cached) zur Verfügung zu stellen, da auf diese Objekte häufig zugegriffen wird und sie äusserst selten geändert werden.
Weniger häufig benötigte Zusatzinformationen zu den aufgeführten Objekten (z. B. Privatadresse eines MA oder Angehörige eines Zubetreuenden) werden in Profilen gespeichert, die ggf. als nicht statische Instanz aufgerufen werden. Dies gilt auch für alle anderen Geschäftsobjekte.

Der Hauptgrund für eine solche Vorgehensweise ist in erster Linie die Minimalisierung von Datenspeicher-Zugriffen und damit verbundene Optimierung von Auslastung und Geschwindigkeit.

Dem entgegen steht die ständige Belastung des Hauptspeichers, die in ihrem Ausmass nur schwer zu kalkulieren ist, da sie einerseits von der Unternehmensgrösse und damit schlicht der Anzahl der Objekte und andererseits von der durchaus variierenden Grösse der in den Objekten gespeicherten Werte abhängig ist. Dazu kommen noch die wechselnd personenspezifischen Anzahlen von Berechtigungssätzen, die vor allem abhängig von der Zahl der später verwendeten Module sind, welche alle ihre eigenen Berechtigungssätze mitbringen, denn die Module repräsentieren die Arbeitsabläufe, die innerhalb des Unternehmens anfallen.

Nun ist meine Frage an Euch, wie würdet Ihr diese Überlegung bewerten - ist es sinnvoll, dieses Kompromiss aus Minimierung der DB-Zugriffe und Hauptspeicherbelastung zu machen oder haltet Ihr es eher für eine falsche Herangehensweise, mit einer grossen Zahl statischer Objekte zu arbeiten?

Hat jemand bereits Erfahrungen mit vergleichbaren bzw. ähnlichen Architekturen bzw. Aufgabenstellungen?
Ich selbst habe an etwas Vergleichbaren noch nie zuvor gearbeitet.

Ich freue mich über jeden Beitrag bzw. Anregung oder Denkanstoss zu dieser Fragestellung.

Grüße
Cord

Erstmal ist hier die Frage von was Du redest, von der Serverseite oder von der Clientseite?
Von der Serverseite wirst Du das Problem haben, dass Du irgendwann nicht mehr genug RAM hast, das bedeutet wahrscheinlich, dass Du von vornherein die Anzahl Deiner Datensätze begrenzen müsstest.
Von der Clientseite aus ist alles was im RAM ist grundsätzlich angreifbar, darüber hinaus muss dann jeder Client genügend RAM haben, kannste das gewährleisten?

Ansonsten ist es einfacher (und wahrscheinlich auch kostengünstiger) eine Datenbank zu vergrößern als den Hauptspeicher. Wobei der Hauptspeicher auch phsykalisch begrenzt ist, der Plattenplatz für die DB ist dagegen (beinahe) beliebig vergrößerbar: MS SQL Server: Die theoretisch maximale Datenbankgröße beträgt ca. 1 Exabyte (Million Terabyte).

Hi,

naja es kommt halt schon drauf an, welchen Umfang die statischen Objekte haben. Wenn wir von 100 MB reden ist das lachhaft, das sollte jeder Server und jeder Client leisten können (auch in einer sozialen einrichtung, wo das Geld auch net besonders locker sitzen dürfte).

Also wären zusätliche Informationen zu diesem Problem hilfreich, denn so können ja nur Vermutungen angestellt werden.

Grüße Oli

Naja, da unterstützen einige (die meisten oder eigentlich alle) Datenbankabstraktionsschichten dynamisches Preloading, manchmal unterstützt von einer dynamischen selbstverwalteten Statistik. Das reicht eigentlich in allen mir bekannten Fällen vollkommen aus. Es gibt halt eine maximale Anzahl von Objekten die gleichzeitig im Speicher gehalten werden (Wird statisch oder dynamisch gesetzt), danach werden die am wenigsten benutze wieder rausgehauen und nur die meistbenutzten im Speicher gehalten.

Du kannst ja auch eine Art Flag einführen z.B. "Das sind Stammdaten" und die dann immer im Speicher vorgehalten werden. Dieses Flag kann man dann manuell oder dynamisch vergeben.

Ich trau mich auch zu behaupten, von dem Thema etwas Ahnung zu haben. Habe vor einem Jahr eine lange Arbeit über persistent Frameworks geschrieben.
Laut meinen Erkenntnissen ist es schon sehr von Vorteil Daten auf die man öfters mal zugreift im Hauptspeicher (am Besten direkt im eigenen Programm) zu halten, als sie erst aus der Datenbank oder von der Festplatte zu holen. Da kann man die Zugriffsgeschwindigkeit schnell mal verzehnfachen oder auch vertausendfachen.

Die Anzahl an Objekten bzw. Datensätzen sollte natürlich begrenzt sein (je nach physikalischem Arbeitsspeicher). Wenn die Grenze erreicht wird, werden eben die am Seltensten benutzten Datensätze aus dem Arbeitsspeicher entfernt.

Gibt im Internet sicherlich einige Bibliotheken die sich mit dieser Thematik beschäftigen.

Mfg preli

Ja, z.b. die Enterprise Lib 3.1 von Microsoft.

Die hat neben DataAccess, Logging, Validation, Exceptionhandling und einigen
anderen sachen, auch einen Caching Block.

Zur not tut es aber auch der auch normal benutzbare Cache von ASP.NET.

Da kannst Du u.a. angeben, wie lange etwas gecached wird (Zeit, datei..).

Das ist vielleicht interessant für dich: http://blogs.msdn.com/ricom/archive/2007/06/25/caching-redux.aspx