Alternative für SQLite auf Android Gerät (fmx)

[TigerLilly]

Und du schließt den ganzen Import in eine(!) Transaktion ein?
In der Regel macht das die Sache langsam. Hast du versucht, kleinere Blöcke (zB 10 Datensätze) in eine Transaktion zu packen?

[bra]

Warum sollte das langsamer sein? Ein Bulk Insert o.ä. macht auch nichts anders. Einzelne Transaktionen bremsen das ganze gerade aus.

[TigerLilly]

Weil je größer das transaction log wird, desto langsamer wird die Sache. Bulk Insert etc sind nicht notwendigerweise in einer Transaktion, siehe BATCHSIZE.
Außerdem bekommt man bei großen und lang dauernden Transaktionen meistens Platzprobleme, weil das Log explodiert.

Deshalb frage ich ja. Ich würde gern wissen, wie die Laufzeiten sind, wenn zB 100 Sätze in einer Transaktion gesammelt sind.

[jobo]

Zitat von TigerLilly:

Weil je größer das transaction log wird, desto langsamer wird die Sache...

Das ist pauschal nicht richtig und vielleicht auch nicht im Fall von SQLite.

Erstmal
Transaktionen sind nicht dafür geschaffen, schnell oder langsam zu sein, sondern fachlich richtige Datenoperationen zu granatieren.
Braucht man das nicht oder wird es nicht so von der Datenbank unterstützt, kann man rumwurschteln wie man will.

Verwendet man Transaktionen im Sinne fachlicher Transaktionen, dann muss der Log Mechanismus entsprechend dimensioniert sein (Platz haben) und idealerweise auch darauf optimiert sein, möglichst flott zu arbeiten. Das ist dann Aufgabe des Admin, sowas nach Bedarf bereitzustellen.

Und mal als kleines Gedankenexperiment:

Was ist schneller?
1 Millionen Inserts plus
1 Millionen Commits

oder
1 Millionen Inserts plus
1 einziges Commit

Ein Commit als Programmschritt ist tatsächlich als eine Art Overhead zu sehen, die Sicherheit einer fachlich vollständigen und richtigen DML Operation (egal wie groß) bekommt man nicht geschenkt.

Wenn SQLite tatsächlich mit vielen kleinen Transaktionen (commits) schneller ist, dann würde ich das als Besonderheit von SQLite sehen.

[TigerLilly]

Zitat von jobo:

Zitat von TigerLilly:

Weil je größer das transaction log wird, desto langsamer wird die Sache...

Das ist pauschal nicht richtig und vielleicht auch nicht im Fall von SQLite.

Also in MEINER Welt ist das schon so, egal ob Oracle, mySQL oder MSSQL. Das ist in 1-Benutzersystemen nicht so sehr das Problem, da geht es eher um Performance und Platz, aber bei Mehrbenutzersystem jedenfalls, denn lange/große Transaktionen killen dann das System.

Eine Transaktion sorgt dafür, dass Operationen "danach" vollständig ungeschehen gemacht werden können. Abgesehen davon, dass das nicht für alle Operationen gilt (zB DDL, manche Formen von Löschen (TRUNCATE), etc), gibt es drei Probleme, wenn die Transaktion lange dauert oder sehr groß wird:
- der Platzbedarf für das notwendige loggen steigt - vor allem in Mehrbenutzersystemen!
- die Operationen werden langsamer (auch für andere User) weil der Verwaltungsaufwand immer größer wird
- mit dem COMMIT müssen alle gepufferten Operationen ausgeführt werden - die Wahrscheinlichkeit, dass das mit einer Änderung eines anderen Users kollidiert, steigt

Darum hätte mich das hier bei SQLite ja interessiert. SQLite funktioniert da ja anders, eher auf Dateiebene, als auf Satzebene, was ich weiß.

[jobo]

Ok, ich will das hier nicht sprengen, in SQLite ist es vielleicht irgendwie anders.

Ich würde sagen, Du wirst keinen Oracle Mitarbeiter finden, der behauptet, mach kleine Transaktionen, weil es dann schneller ist. Und ein Redolog muss so groß sein, dass alle Transaktionen, die die Businesslogik fordert auch durchgezogen werden können. (Natürlich kann man Operationen definieren, die ein -immer nur endlich großes- Redolog sprengen).

Und richtig, Transaktionen sorgen für die Möglichkeit eines vollständigen Rollback.
Welchen Sinn macht es dann, logisch zusammenhängende Oprationen in mehrere kleine Transaktionen zu zerlegen, so dass im Fall eines Rollbacks ein inkonsistenter Zustand zurückbleibt?

In keinem meiner Programme gibt es irgendeine Codezeile, die sich damit auseinandersetzt, wie weit eine Operation bereits fortgeschritten ist, was auf den Schrott kommt, geschweige denn vielleicht kommen müsste. Dafür ist die DB mit ihren Transaktionen zuständig.

Na vielleicht etwas übertrieben, wenn Millionen von Datensätzen importiert werden müssen, kann man eine Entwickler DB schon etwas schonen und stückeln, aber es ist m.E. prinzipiell falsch.

Wenn eine große Transaktion in einem Produktivsystem andere Benutzer behindert und das häufig der Fall ist, ist das System unterdimensioniert, falsch administriert oder falsch konzipiert.

[mkinzler]

SnapShots machen nur Sinn, wenn man auf Teil-Transaktionsebene rücksetzen möchte.