Hallo Experten,

unsere Anwendung cached die Daten als Baumstruktur minütlich aus der Datenbank. Aus diesem Cache werden die abnehmenden Systeme (bis zu 20 parallel) bedient. Derzeit nimmt die Baumstruktur des Caches etwa 2GB RAM ein. Der Cache selbst ist eine ältere "Eigenerfindung", die nicht wirklich performant ist. Oft werden darin auch mehrfach gleiche Daten gecached. Mit der derzeit anstehenden Erweiterung würden wir etwa 4GB benötigen, wenn kein Umbau erfolgen würde - also so nicht tragbar.

Der Cache soll performanter werden und mit den jetzigen Daten weniger RAM verbrauchen.

Welche Cache-Api könnte dafür eventuell in Frage kommen?
Ich habe schon von Terracotta gehört - wie läßt sich damit arbeiten? Ist das mit eigenen fachlichen Modellen anreicherbar? Ist das performant und resourcenschonend?
Gibt's da vielleicht was viel besseres - und ich kenn's bloß nicht?

Über Anregungen Eurerseits freu' ich mich schon.

In der Umfrage fehlt mir ein wenig der JBoss Cache

Mag sein, doch wir nutzen den JBoss nicht.

Zitat von schnuffie

Mag sein, doch wir nutzen den JBoss nicht.

Nur weil JBoss dransteht, braucht man kein JBoss AS dafür. Klar dreht sich alles darum den JBoss AS zu erweitern/verbessern, aber es ist kein fester Bestandteil (wie andere Dinge von JBoss auch), sondern "nur" eine Bibliothek.

Was anderes, was benutzt ihr zum DB-Zugriff? JDBC, hibernate...?

Bei hibernate könnte man zum Beispiel einen 2nd level Cache definieren und dafür z.B. JBoss Cache, EhCache verwenden.

Wenn eure Daten in Baumstruktur organisiert sind, bietet sich die Methodik des 'lazy read' an. Dabei werden die Kinder eines Knotens erst dann eingelesen, wenn darauf zugegriffen werden soll. Die derzeit als Blätter anzusehenden Knoten werden in einer doppelt verketteten Liste verwaltet; sobald Knoten seine Kind-Knoten einliest, hängt er sich aus der Liste aus und hängt seine Kinder hinten an; dadurch sind die in der Liste verwalteten Knoten nach dem Einlesezeitpunkt sortiert. Die jeweiligen Daten verbleiben dann im Speicher, bis der Speicherverbrauch einen Maximalwert überschreitet; sobald das geschieht, wird der erste Eintrag (welcher der älteste ist) und dessen Geschwisterknoten entfernt, deren Elternknoten mit einem aktualisierten Zeitstempel wieder angehängt, und der Speicher für die betroffenen Knoten kann wieder freigegeben werden. Das wird solange wiederholt, bis der Speicherverbrauch wieder einen Schwellwert unterschreitet.

Hallo,

um eine einigermaßen vernünftige Antwort auf deine Frage geben zu können bräuchte ich da noch ein paar Antworten zu folgenden Fragen:
1) Wird ein O/R Mapper verwendet mit dem der Cache arbeiten soll?
2) Welche Daten werden gecached?
3) Wie sehen die Objekte aus die gecached werden? (Objektstruktur, nur einzelne "lose" Knoten, oder ganze Teilbäume?)
4) Was genau verbaucht so viel Speicher? Mit Profiler geprüft?
(Eventuell kann man die Daten auf die wirklich notwendigen zucachenden Attribute reduzieren
und dann bei Bedarf aus der DB laden.)

5) Wie und in welchem Intervall wird auf die Daten zugegriffen? Über hierarchischen Schlüssel (Pfad)?
6) Wie, wann soll der Cache invalidiert / refreshed werden?
7) Sollen gecachedte Elemente dauerhaft unter Cache-Controlle bleiben oder können Elemente
nach einer bestimmten Zeit oder sonstiger Metrik wieder aus dem Cache herausfliegen? (LRU, MRU, Timeout?)
8) Lässt sich die Datenbankstruktur ändern bzw. dürfen Views hinzugefügt werden?
Hierarchische Strukturen mit festen Tiefen lassen sich relativ einfach "flachklopfen" und ermöglichen
so einen einfachen, performanten Zugriff. Dann kann man sich die Sache relativ einfach machen und sich den Cache mitunter komplett sparen...
9) Soll/Muss der Cache verteilt sein? Ist die dazugehörige Serveranwendung verteilt?

Gruß Tom

Erst mal vielen Dank allen, die geantwortet haben.

In Bezug auf Eure Fragen:
Es soll ab jetzt Hibernate eingesetzt werden, bisher war es normaler JDBC-Zugriff einer gepoolten (Eigenimplementierung) JDBC-Datasource via Name-Lookup.
Wir verwenden bislang ein generisches, viel zu umständliches Datenmodell, da diese Eigenentwicklung als kleines Etwas gewachsen ist, wurde alles Mögliche hinzuprogrammiert. Diese bisherige Baumstruktur ist zu komplex, auch werden viele Daten mehrfach vorgehalten, hier ist viel Optimierungsbedarf. Das gilt für die Daten, die aus zahlreichen Tabellen eines Nachbarverfahrens regelmäßig (minütlich) gelesen werden. Mit diesen Daten wird derzeit die Baumstruktur gefüttert, jede Minute. Das dauert...
Die abnehmenden Systeme sind via http angebunden und beziehen die Daten als xml (kein Webservice, nur normales http). Gecacht werden alle Nutzdaten (der gesamte Baum) und zusätzlich dazu die Metadaten (nur einmal eingelesen). Cachen müssen wir alle Daten, da die DB des Nachbarsystems nur 1x/min abgefragt werden darf (fachliche Vorgaben). Die abnehmenden Systeme ziehen regelmäßig Daten ab (ca. alle 10s, bis zu 20 parallel).
Sinn und Zweck unseres Caches ist die Entlastung des Nachbarsystems und der Performancegewinn! Die gecachten Daten dürfen nicht verfallen, sie müssen minutenaktuell sein.
Profiler sagt: Baumstuktur, ist aber auch riesig. Die Metadaten sind leicht optimierbar. Da wir nur die Daten lesen, können wir auch nur Referenzen auf das gleiche immutable Object halten. Das ist jetzt noch nicht so.
Jeder Strang muss nur die Daten der abnehmenden Systeme halten. Ich gehe aber trotzdem davon aus, daß aufgrund der ständig wachsenden Datenmenge immernoch ca. 1GB dafür nötig sind, was jetzt im noch nicht-optimierten Fall nicht möglich ist.

Bisherige Erfahrungen (Stand heute):
Ja, Eh-Cache sagt mir was. Hatten wir in einem anderen Projekt auch mal mit Hibernate verwendet.
Den JBoss-Cache kenne ich bislang nicht.
Eine Beispiel-Anwendung hatte ich Ruck-Zuck mit dem JCS von Apache hinbekommen. Gut und einfach dokumentiert. Allerdings unterstützt der nicht Generics. Alles was raus kommt muß man casten, sonst recht performant.
Terracotta habe ich auf die Schnelle nicht zum Laufen bekommen, scheint recht kompliziert zu sein. Vielleicht auch etwas überzogen für uns.
Zahreiche Caches cachen nur in Web-GUIs, damit der Seitenaufbau schnell geht. Das brauchen wir nicht.

Gruß schnuffie