Schnelle DB / Dateibasierend

[p80286]

20000 am Morgen?
das sind dann über den ganz dicken Daumen 3000 pro Stunde. Da ein Stunde aber 3600 Sekunden hat, sollte eine Transaktion pro Sekunde reichen.

Gruß
K-H

[Jackie1983]

Zitat von p80286:

20000 am Morgen?

Jup. Das heist für eine Nachricht eine Sekunde
20.000 Nachrichten = 20.000 Sekunden = ca 5 Stunden bis die letzte bearbeitet wurde.

Und in der Zeit stauen sich neue Nachrichten an.
Also zulangsam....

[shmia]

Man könnte aber auch eine NoSQL Datenbank wie z.B. CouchDB verwenden.
Dabei muss man aber ganz neue Dinge lernen.
Von der Performance und der Flexibilität her ist so etwas aber sehr interessant.

[himitsu]

Eventuell statt einem Insert auch mal über ein Append nachdenken.
(hier bei einem MemDataSet dauerte DS.Insert+DS.Post wesentlich länger, als DS.Append+DS.Post)


Privat versuche ich mich grade an Firebird-Embedded zu gewöhnen.

[neo4a]

Zitat von Jackie1983:

Jup. Das heist für eine Nachricht eine Sekunde
20.000 Nachrichten = 20.000 Sekunden = ca 5 Stunden bis die letzte bearbeitet wurde.

Und in der Zeit stauen sich neue Nachrichten an.
Also zulangsam....

Das Speichern kann immer "zu langsam" sein, auch wenn die DB pfeilschnell arbeitet: Fehler in der Netzwerkverbindung, Windows Update, Virenscanner, DB Maintainance etc.

Um auf der sicheren Seite zu sein, kann eine "2-Phasen-Persistenz" helfen: Einkommende Nachrichten werden zuerst lokal gespeichert (z.B. in einer Log-Datei), um anschließend von dort in die DB übertragen zu werden. Das hat u.a. den Vorteil, dass das transaktionsbasierte SQL-Insert im "Bulk-Mode" wesentlich schneller abläuft, als wenn jeder einzelne Insert commited wird. Beide Prozesse sollten natürlich als Threads oder in getrennten Services/Programmen ablaufen.

Fällt der Client aus, so kann aus der lokalen Log-Datei jederzeit die Übertragung wieder aufgenommen werden.

Dieses Szenario hat sich z.B. bei BDE-Nachrichten-Verarbeitung über viele Jahre hinweg als robust und performant erwiesen.

[p80286]

Genau das soll es ja nicht sein,
da die Einträge in die Log-Datei komplexer werden, -was bedeutet das eigentlich?-
soll jetzt in eine DB geschrieben werden.
Mein Schluß daraus, eine Datei zum Vortschreiben der Log-Ereignisse ist untauglich.
(nur verstehen tu ich's nicht)

Gruß
K-H

[neo4a]

Zitat von p80286:

Genau das soll es ja nicht sein

Sorry, ich habe mich da nicht ganz klar ausgedrückt.

Der erste Prozess schreibt z.B. 10 oder 100 Nachrichten in eine Datei 0001.txt, die nächsten 10 oder 100 in 0002.txt usw. Der 2. Prozess liest 0001.txt, wandelt sie in ein SQL-Script mit Inserts und führt sie aus. Anschließend löscht Prozess 2 0001.txt und macht mit 0002.txt weiter.

Damit mache ich mich bei der Übernahme der Daten unabhängig von deren Weitergabe.

Zur Phase 2: 1000 Datensätze en-bloc sind in eine Firebird-Datenbank in wenigen Sekunden eingefügt, wenn da keine großartigen Trigger etc. mitlaufen. Damit wird die Übernahme von 20000 Datensätzen ein Minuten-Job.

[divBy0]

So einen ähnlichen Fall hatte ich auch mal. Über TCP habe ich Nachrichten erhalten und musste diese in eine Datenbank schreiben. Die empfangenen Nachrichten habe ich dann erst mal in einer Datei mittels TFileStream gesichert und dann von dort aus in die Datenbank geschrieben.

Vorteil war, dass keine Nachrichten verloren gegangen sind wenn der Datenbankserver wärend der Inbetriebnahme mal nicht erreichbar war (was öfters vorkam).

[himitsu]

Wobei man die ankommenden Daten auch in eine Queue schieben kann. Also analog zu den LogTemp-Dateien.
Dieser Queue/Zwischenspeicher wird dann einfach regelmäßig/kontinuierlich geleert und in die DB übertragen.
Sozusagen alles im RAM, anstatt erst über die HDD zu gehn.

OK, wenn der Rechner, bzw. das Programm abstürzt, dann sind die in der Cache befindlichen Daten natürlich weg,
aber auch diese Temp-Dateien können nach einem Absturz korrupt sein.

Kommt also mehr darauf an, wieviel Zeit der Zwischenspeicher überstehen soll.
- länger und öfters > Datei
- nur kurze Spitzen abfangen > RAM

[Furtbichler]

Also ich habe einen Workerthread, der die zu speichernden Daten in einer Stringliste puffert. Der Thread an sich schnappt sich den nächsten String und speichert ihn in der DB. Ich verwende Firebird und komme auf ordentliche 600 Zeilen pro Sekunde. Es ist zwar der Server, aber auf dem selben PC.

Mit dem Puffern im Workerthread kann ich kurzzeitige Spitzen locker abfedern.

Wenn vorher die Sicherheit einer Text-Datei ausreichend war, kann man auch mit Tranksaktionen bzw. gepuffertem Speichern arbeiten, d.h. man sammelt X Daten und bläst die en block (oder in einer Transaktion gekapselt). Ein commit/write wird dann z.B. alle 500ms aufgerufen (sofern daten da sind). Damit sollten noch ein paar 100 Datensätze mehr pro Sekunde verarbeitbar sein.