Performance-Frage bei Datenbank mit 60.000+ Datensätzen

Hallo,

ich wollte mal fragen ob es für mein Problem, zu dem ich auch schon eine Lösung habe, es eine performatere Lösung gibt!

Ich habe eine Datenbank mit 60.000+ Einträgen(Je ca 20 Attribute).

Ich habe eine Appliaktion, die alle diese Einträge in einer Tabelle darstellt.

Über gewisse such-Eingabefelder kann man diese Felder noch diferenzieren.

Ich hatte jetzt das Problem, das die Applikation beim laden unheimlich lange gebracht hat, weil sie halt erst alle Werte gelesen hat, in die Tabelle packte und dann erst weiter machte.

Um dieses zu umgehen, habe ich die TAbelle beim Systemstart leer implementiert und einen Thread im Hintergrund gestartet, der Schreibzugriff auf die Tabelle hat und sie halt zur Laufzeit füllt.

Am anfang schmeisst der Thread in 20er schritten daten rein, damit der Benutzer das gefühl hat, schon mal was machen zu können, so bald dann 100 Datensätze drin sind, steige ich auf 5.000er Schrittte um.

Denkt ihr, das ist ein sinnvoller ansatz, oder hat da vieleicht der ein oder andere noch einen guten tip, wo ich mich mal einlesen sollte oder vieleicht sogar ein beispiel, für eine Gute lösung.

Ich meine ich rede hier derzeit noch über Sekunden, aber der Kunde beschwert sich bislang, das er wenn er die Applikation erstmal 15 sek warten muss.


Vielen dank

Als Performancebremse würde ich hier auf den ersten Blick das Backend ansehen - zumindest mit den Informationen die du gegeben hast. Generell halte ich persönlich es für keine gute Idee, den Anwender schonmal auf einem Teilbereich der Daten loszulassen, allerdings ist das vielleicht auch von den Daten selbst abhängig.

Was ist denn das Backend wo die Daten herkommen? Gibt es da vielleicht Möglichkeiten Daten zu cachen, um so den Ladevorgang zu beschleunigen?

Muss der Anwender alle Datensätze gleichzeitig in einer Tabelle haben? Kann man das eventuelle in kleinere Mengen splitten, die dann zudem auch übersichtlicher sind?

Ist die Tabelle nur zum Anzeigen der Daten, oder kann man sie damit auch editieren? Wenn Zweiteres, ist es nicht kritisch, wenn der Anwender die Daten bereits ändert, während sie geladen werden?

Ich verwende meist einen expliziten Ladebildschirm, wenn so viele Daten vorhanden sind. Ist das vielleicht für dich eine Lösung?

@mehlvogel: "Zweiteres"??? So nach dem Motto "zwei-zweiter-am zweitesten"? Muss denn sowas sein? Was hast Du gegen das altbewährte "Letzteres"? Sorry, aber bei solchen Ausrutschern wird mir ganz anders...

Zum Thema:
Als erstes würde ich auch prüfen, ob die gewählte Datenbank für derartige Tabellengrößen als performant gilt (wenn's dazu konkrete Testergebnisse gibt, wär's natürlich noch besser). Und wenn sich aus der Datenbank selbst nichts mehr herausquetschen lässt, würde ich über ein paar Taschenspielertrick immer nur einen Ausschnitt aus der Tabelle im Frontend halten, d.h. ich würde z.B. die Scrollbalken so anpassen, dass sie aus Sicht des Kunden den ganzen Tabellenbereich abdecken, in Wirklichkeit lädt die Anwendung aber immer nur den Ausschnitt, der gerade sichtbar sein müsste. Ich gehe mal davon aus, dass Deine Datenbank so um die 100 Datensätz in wenigen Millisekunden liefern kann nachdem die Verbindung erst einmal etabliert ist.
Ich weiß jetzt nicht, wie das konkret mit den Java-Komponenten geht, aber aus meinen Erfahrungen mit anderen GUI-Frameworks weiß ich, dass das eigentlich kein Thema sein sollte.

So long,
Liberty

P.S.:
Über 60.000 Datensätze in einer einzigen Tabelle und das bei 20 Attributen? Schreien solche Tabellen nicht geradezu nach einer grundlegenden Strukturänderung? Was sind denn das für Daten, wenn man fragen darf?

Zitat:

---

Zitat von Liberty

@mehlvogel: "Zweiteres"??? So nach dem Motto "zwei-zweiter-am zweitesten"? Muss denn sowas sein? Was hast Du gegen das altbewährte "Letzteres"? Sorry, aber bei solchen Ausrutschern wird mir ganz anders...

---

Na dann hoffe ich doch, das meine sprachliche Inkompetenz, die ich leider nicht leugnen kann, zumindest wenn ich mir nicht für jeden Satz eine halbe Stunde Zeit nehme, nicht dafür gesorgt hat, dass du deinen Schreibtisch zugesaut hast. :rolleyes:

@mehlvogel: Keine Sorge, ich war in der Uni :D

Also gerade für so etwas ist doch Ajax gedacht. Ich empfehle hier openrico LiveGrid oder LiveGridPlus. Habe gerade ein ähnliches Problem und fahre gut mit der AjaxLösung. Das Problem ist bis jetzt nur noch IE 6+7.

Aber damit kannst du nur einen Ausschnitt nachladen und der Client muss nicht alle Daten halten.

Ein bisschen DynamicSQL dazu und schwupps hat man schon erste Ergebnisse.

mfg, Christian

Also die Datenbank ist leider nur eine MySQL Datenbank.

Der Kunde ist da der ansicht, frei ist gut genug.

Die 60.000+ Datensätze sind bis auf die Berechnungs-ID alles von anderen Programmen aufwendig errechnete Werte. Also da ist leider nix, was sich ausgliedern lassen würde.


Da es sich nicht um eine Web-Anwendung handelt, denke ich mal, das Ajax sicherlich für mich nicht das ist was mir hilft(ajax ist doch nur Web-bezogen, oder?? Bin ich da falsch informiert??)


Der Benutzer kann sich in der angesprochenen Applikation die Werte nur ansehen. Wenn er sie auswählt, startet eine extra Applikation, die sich dann auf seine gewählte Auswahl bezieht.


Die Idee, nur sagen wir mal 100 Elemente zu laden und die scoll-Leiste anzupassen finde ich sehr interessant, wenn sie vermutlich auch ein aufwand ist, der sich sicherlich nicht deckt. Aber interessant ist es auf jeden fall...
Werde mir da mal privat gedanken zu machen ^^

Wußte nicht dass es eine Nicht-Webanwendung ist. Da bist du natürlich mit Ajax aufgeschmissen. Aber das Prinzip, dass du nur einige Daten nachlädst, also z.B. 25 Datensätze werden angezeigt, dann lädst du die 50 Datensätze davor und die 50 Datensätze danach noch zu ist auch für normale Anwendungen denkbar. Ich denke dass Squirrel ebenso arbeitet. Der Scrollbalken verhält sich allerdings so, als ob alle 60k Datensätze geladen wären.

mfg, christian

Na, das Prinzip des Nachladens lässt sich doch auch auch java-clienten anwenden. Der Benutzer muss ja eine Auswahl treffen. Z.B. Tabelle:
Geladen werden zunächst einmal etwa zwei mal so viele Daten, wie angezeigt werden sollen. Der Rest wird beim Scrollen geladen (Tabellenmodell austauschen). Ähnliches geht auch mit comboboxen. We du Filterfelder verwendest, bist du ohnehin aus dem Schneider.

Ich sehe da in dem Ansatz kein generelles Problem.
Die Tabelle aus der Datenbank zur Laufzeit nach und nach zu laden klingt doch eigentlich sehr gut. Das gleiche passiert übrigens auch, wenn ich mir unter Windows alle Netzwerkbenutzer auflisten lasse (~1800): Es dauert eine ganze Weile und wenn ich sie sortieren lasse, werden nur die bis dahin eingelesenen sortiert. Der Mauszeiger zeigt dabei an, dass der Vorgang noch nicht abgeschlossen ist.
Wenn Du eine Tabelle anzeigst, wirst Du das sicher bei diesen Datenmengen in View und Model getrennt haben, oder? Das Model, das möglicherweise das TableModel erweitert oder beinhaltet, könnte in einem eigenen Thread doch leicht die Datenbank auslesen und das View gelegentlich (alle 1000, alle 10%, wie auch immer) aktualisieren. Einen Ladebalken bekommt man über diesen Weg auch leicht hin, denn das wäre nur ein weiterer View, der vom Model aktualisiert wird.

Also - passt doch eigentlich, es wären nur ein paar kleinere Änderungen zu machen.

HTH,
mamue