Schnelle DB / Dateibasierend

[jobo]

Hallo,

falls es noch um das gleiche Thema geht wie neulich. Hier ein nochmal mein Hinweise zu SQLITE und Transaktionen, falls Du das übersehen hast.

http://www.delphipraxis.net/1144412-post11.html

Besorg oder compilier dir eine Version ohne Journaling und Transkationshandling. Brauchst Du ja für s Logging nicht, oder?

[Jackie1983]

Zitat von jobo:

Hallo,

falls es noch um das gleiche Thema geht wie neulich. Hier ein nochmal mein Hinweise zu SQLITE und Transaktionen, falls Du das übersehen hast.

http://www.delphipraxis.net/1144412-post11.html

Besorg oder compilier dir eine Version ohne Journaling und Transkationshandling. Brauchst Du ja für s Logging nicht, oder?

Sorry deine Nachricht habe ich übersehen. Ja es geht noch um das gleiche Thema.
Nein das brauche ich nicht.....

[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.

[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.

[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

[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.