Multithreading und Datenbanken

[QuickAndDirty]

Hallo,
Im moment arbeiten wird mit AnyDac auf Firebird und MSSql server es wird wohl noch Oracle 11g und MySQL hinzukommen.
Wir verwenden kein Storedprocedures alles wird eben über Parameter und Statements abgewickelt.

Das Problem: Wie kann ich einen Multithreaded zugriff auf die Datenbank umsetzen?

Es geht darum das man evtl. 2000 Zugriffe gleichzeitig hat...und wenn alles gequeued wird kann das mal für den letzten 2000 Minuten Dauern. Andererseits weiß ich auch nicht wie ich bei 2000 gleichzeitigen schreib oder lesezugriffen so eine Datenbank Konsistent halten könnte, außer ich mache laaaaange transaktionen auf, aber ich meine gehört zu haben das lange transaktionen böse sind.


Wie macht ihr das? Queuen bis der Arzt kommt oder irgendwie multithreaden und wie?

[Bernhard Geyer]

Wieso denkst du das du in einem laufende Prozess deiner Anwendung 20.000 gleichzeitige Zugriffe benötist?

[QuickAndDirty]

nur 2000 ...so als peek
Und nun wir haben hier einen Kunden der eine Webanwendug mit 2800 Benutzern sehr stark in Anspruch nimmt.
unter anderem werden viele Berichte gleichzeitig angefordert. Wir queuen diese Vorgänge dann... und je nach Bericht kann das sehr sehr lange dauern. Es kann auch mal eine Minute oder 3 Dauern PRO Bericht in der Queue! Wobei die Datenbank der eigentliche Flaschenhals ist.

[Sir Rufo]

Hmmm, das mit der Queue ist ok, aber was hat das mit den Transaktionen zu schaffen?
So ein Bericht ist doch von der Kategorie Ausgabe und der schreibt eigentlich keine Daten zurück in die DB.

Die Transaktionen helfen doch nur dabei, dass gerade die Berichte keine inkonsistenten Daten anzeigen.

Und trotz Transaktion kann ich die Daten noch lesen (nur die aktuell in der Transaktion befindlichen gehen halt nicht - logisch).

Evtl. wäre es aber sinnvoll für die Abfrage einen Snapshot von der DB anzufordern, damit alle Informationen im Bericht die gleiche Basis haben.

[Bernhard Geyer]

Zitat:

Zitat von Sir Rufo (Beitrag 1139481)

Und trotz Transaktion kann ich die Daten noch lesen (nur die aktuell in der Transaktion befindlichen gehen halt nicht - logisch).

Dann bekommt man halt die konsistenten etwas ältern Daten (Jedenfalls bei jeder DB die das Multiversion Concurrency Control unterstützt).

Zitat:

Zitat von Sir Rufo (Beitrag 1139481)

Evtl. wäre es aber sinnvoll für die Abfrage einen Snapshot von der DB anzufordern, damit alle Informationen im Bericht die gleiche Basis haben.

ich würde eher schauen ob es immer ähnliche Berichte sind so das man evt. die Daten vorkomprimiert, d.h. rechenintensive daten schon Vorberechnet und in schnell abrufbare Form bereitstellt.

[QuickAndDirty]

Zitat:

Zitat von Sir Rufo (Beitrag 1139481)

Hmmm, das mit der Queue ist ok, aber was hat das mit den Transaktionen zu schaffen?
So ein Bericht ist doch von der Kategorie Ausgabe und der schreibt eigentlich keine Daten zurück in die DB.

Die Transaktionen helfen doch nur dabei, dass gerade die Berichte keine inkonsistenten Daten anzeigen.

Und trotz Transaktion kann ich die Daten noch lesen (nur die aktuell in der Transaktion befindlichen gehen halt nicht - logisch).

Evtl. wäre es aber sinnvoll für die Abfrage einen Snapshot von der DB anzufordern, damit alle Informationen im Bericht die gleiche Basis haben.

Kann FB das? Und kann MSSQL das? und wenn ja wie geht das mit anydac?

[QuickAndDirty]

Aber Multithreading ist nicht möglich oder?

[tsteinmaurer]

@QuickAndDirty: Das ist so eine Alles-oder-Nichts Problemstellung. Man kann schon mit ein paar Abfragen eine Datenbank dicht machen, wenn die Abfragen nicht optimiert sind. Noch besser SQL Server in einem Read/Write-Mischbetrieb, wenn keine Snapshots verwendet werden.

Prinzipiell kann Firebird mehrere Datenbankverbindungen mehr oder weniger "gleichzeitig" bedienen. Kommt halt drauf an wie viele CPUs/Cores du drinnen hast und wie schnell dein I/O-System ist. Vorausgesetzt, wir reden hier vom Firebird Classic oder SuperClassic Server, wo mehrere CPUs/Cores genutzt werden können.

Ich bezweifle, dass auch Oracle 2000 gleichzeitige physische Verbindungen, sofern diese auch etwas tun, einfach wegsteckt. Kann ich mir nicht vorstellen. Hier läuft es in der Regel dann auf ein Connection Pooling raus und wenn alles größer wird eine Architektur mit Load Balancer etc ...

Auf der Firebird Konferenz 2011 wurde eine Fallstudie vorgestellt, wo eine Firebird Datenbank mit ca. 120 GB und ~ 400 Benutzern verwendet wird. Also, technisch ist viel machbar. Kommt halt auf die Qualität des Produzierten etc ... drauf an.

[Bernhard Geyer]

Zitat:

Zitat von tsteinmaurer (Beitrag 1139487)

Ich bezweifle, dass auch Oracle 2000 gleichzeitige physische Verbindungen, sofern diese auch etwas tun, einfach wegsteckt. ...

Also wir haben Oracle schon bei einem Kunden mit einem einzigen laufen Programm und optimierten Import (Ohne Threads) so in die Knie bekommen das sich selbst der Admin nicht mehr mit den Server per Admintools verbinden konnte :mrgreen:
Hat sich aber rausgestellt das der Server in HD-Platz-Mangel gelaufen ist ...

[QuickAndDirty]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1139483)

ich würde eher schauen ob es immer ähnliche Berichte sind so das man evt. die Daten vorkomprimiert, d.h. rechenintensive daten schon Vorberechnet und in schnell abrufbare Form bereitstellt.

nun, dann müssten wir das gesammte Berichtswesenändern. So das wir quasi auf alte Auswertungen unangetasteter Daten zurrückgreifen könnten und nur neu entstandenen Daten auswerten um dann alles entsprechend zu kombinieren. Das wäre sicher eine nicht ganz unwesentliche Änderung des Berichtswesens...andererseits müsste ich es nicht Programmieren :=) .