Servlet Einschätzung anderer zu Daten-Repositories

[JuanRocaDelThor]

Hallo!

Ich habe eine ganz allgemeine Frage zu der Architektur einer Web-Anwendung.

Wir benötigen einen Webservice der uns umfangreiche Datensätze als XML (nicht SOAP), aber in Zukunft auch als JSON, zurückliefert.
Diese Datensätze werden in einem separaten Schritt über XSL in Webausgaben gerendert.

Derzeit wird das Ganze als sogenanntes "Depot" gelöst:
Dabei wird bei der Initialisierung und in unregelmäßigen (zufallsbasierten) Abständen eine Aktualisierung gestartet, die die gesamten (sinnvollen) Daten unserer zentralen Datenbank in Objekte (im wesentlichen JAXB-basiert) verwandelt und diese Objekte jeweils in eine typisierte Tree/HashMap bzw. ImmutableMap einliest bzw. die vorherige ersetzt.

Bei einer Abfrage an den Webservice (Suche nach Kriterien oder mit ID) erstellen wir basierend auf der - ebenfalls zu einem JAXB-Objekt ge"unmarshallt"en - eigegangenen Request-Message eine JAXB-baierte Response-Message.

Dazu
* liefert die Map das zum Key passende Objekt zurück bzw.
* werden einer "requestlokalen" Liste zunächst entweder
** alle Elemente hinzugefügt und anschließend die, die nicht zu der Abfrage passen, gelöscht oder
** genau andersherum, wird über alle Objekte im Depot iteriert und die Kriterien erfüllenden der lokalen Liste hinzugefügt.
Danach wird die JAXB-basierte Message durch den Marshaller geschickt und als XML-Baum ausgeliefert.

Ich halte dieses Vorgehen in mehrfacher Hinsicht für ineffizient, obwohl die Antwortzeiten recht gut sind.
Aber, dass die Antwortzeiten gut sind, ist auch logisch: es ist schließlich alles im Hauptspeicher des Servers hinterlegt. Dafür haben wir aber auch einen hohen Speicherverbrauch für Objekte, die nie angefragt werden - insgesamt ca 20GB RAM.
Hinzu kommt ein Memory-Leak, dass sich bislang nicht exakt lokalisieren ließ.
Meine Vermutung ist, dass es mit den Depots zusammenhängt, ich kann es aber bislang nicht belegen.

Mein Ansatz wäre eine Lösung in der ich über JPA/EclipseLink die Daten in der Datenbank zu einem Request über ein im Request erzeugtes Abfrage-Objekt suche. Dieses liese sich so weit ich es verstehe nicht nur in EclipseLink, sondern auch in einem Cache - z.B. dem ehcache - hinterlegen.

Welches Vorgehen ist - unabhängig von einer guten Architektur schneller, effizienter? Lohnt es sich, dass ich hier Entwicklungszeit investiere?

Außerdem sind die JAXB-konvertierten Objekte IMHO
* unkomfortabel für die Programmierung
* unkomfortabel für die Navigation im Ergebnisbaum, da nicht bidirektional
* der Status kann nur über die Response- oder Request-Message zwischen den Layern transportiert werden (was das gesamte Depot und die Messages weiter aufbläht)

Hat jemand Erfahrungen mit solchen Konzepten?

Außerdem würde ich gerne eher auf Filter/Interceptor setzen, die den Response "eventgetrieben" modifizieren kann, statt über eine feste Liste von Tasks zu iterieren, die jeweils das komplette Request- und Reponse-Message als Parameter erhalten und dann anpassen.

Habt Ihr allgemeine Einschätzungen, Ideen zu diesem Aufbau?

Welches Framework (Apache CXF, Jaxter, ...) ist leichtgewichtig, gut zu lernen, usw. - kurz aus Erfahrung empfehlenswert?

Die Struktur möchte der Kollege weiter ausbauen und immer mehr Inhalte in diese Depots packen.
Bislang habe ich nur ein Gefühl, dass das nicht sinnvoll ist. Sollte ich meine Idee ausprobieren?

Danke vielmals,

Juan

Wir verwenden: Oracle 12c, Tomcat 7, Java 7

 

[ChristianK]

Ich verstehe nicht, wieso du alles in deine Liste packst und die Requests anhand dieser Liste durchführst. Eine Datenbank ist um ein vielfaches schneller im Suchen nach Einträgen als Java. Eventuell wäre hier eine Datenbank mit Memory-Tabellen noch eine Idee.

 

[JuanRocaDelThor]

Nun, diese Idee stammt nicht von mir.
Wie geschrieben, mein Kollege, der das auch entwickelt hat, möchte das ausbauen - ich halte das Ganze in besten Fall für konzeptionell absurd, höchstwahrscheinlich aber auch ineffizient gegenüber einer Lösung basierend auf JAX-RS, über Ehcache cachebaren Suchobjekten und JPA.

Kurz:
Ich halte das, schon aus konzeptionellen Gründen nicht für sinnvoll, aber er ist begeistert von der Performance.

Ich vermute leider auch, dass die Datenbank nicht schneller sein wird. Die DB kann solche komplexen Strukturen in der Menge, die wir an Produkten und Konfigurationen haben, nicht gecacht vorhalten. Wenn die DB diese von der File-Ebene einlesen muss, dauert dir Antwort sicherlich länger, als direkt aus dem Hauptspeicher.

Da wir die Informationen auch nicht editierten müssen, nachdem sie geladen sind, ist das Vorgehen prinzipiell möglich. Allerdings sehe ich keinen Sinn darin, die Entscheidung, was im “Cache“ (Hauptspeicher) landet, nicht dem verhalten der Nutzer der Website zu überlassen.

Außerdem zweifle ich daran, dass es sinnvoll ist, solche Abläufe, wenn sie doch schon von anderen effizient gelöst worden sind
1. Nicht standardkonform zu lösen und
2. Selber zu implementieren.

Interessant ist also tatsächlich eine Rückmeldung, wie man das Problem - sehr geringe Reaktionszeit, viele komplexe, tabellenüberschreitende Objekte - gut lösen kann bzw. ob der vom mir skizzierte Weg ais Erfahrung funktioniert wo Stolpersteine liegen.

Danke,

Juan

 

[ChristianK]

Wieso sollte die DB diese Mengen an Daten nicht vorhalten können? Das ist ja nur eine Frage davon, wie viel RAM du dem Server zufügst. Zudem ist eine Datenbank oft auch sehr schnell, wenn sie zuerst auf die Festplatte muss. Eine Pauschalaussage "ist nicht schneller" möchte ich hier aus Prinzip nicht zulassen. Ausprobieren, testen und überprüfen.

Die Frage ist noch über wie komplexe Strukturen und welche Mengen wir hier sprechen. Wenn es dann wirklich rasante Mengen sind, wäre eventuell NoSQL noch eine Alternative.

So wie ich das verstehe lädst du im Moment aus einer Datenbank potentiellen Informationen und speicherst diese in Java-Lists. Sobald nun ein Request kommt werden diese Informationen gefiltert und sortiert und ausgeliefert. Mir stellt sich hier primär folgende Fragen:
- Nach welchen Kriterien aus der DB auslesen?
- Gibt es eine Möglichkeit einzuschätzen, welche Informationen eher benötigt werden oder welche eher weniger?
- Wie gross ist der effektive (gemessener, nicht geschätzter) Zeitunterschied zwischen der Abfrage auf dieses System und der zugrunde liegenden Datenbank?