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

[TigerLilly]

Schön für dich. Es wäre nett, wenn du die Lösung auch noch postest.

[stalkingwolf]

Code:

{$IFNDEF NEXTGEN}
var  TD : TTransactionDesc;
 {$ENDIF !NEXTGEN}
begin
    .
    .
    {$IFNDEF NEXTGEN}
    TD.TransactionID := 1;
    TD.IsolationLevel := xilREADCOMMITTED;    
    MobilConnection.StartTransaction(td);
    {$ELSE}
    MobilConnection.BeginTransaction;
    {$ENDIF !NEXTGEN}
    .
    .
    .
    {$IFNDEF NEXTGEN}
    MobilConnection.Commit(td);
    {$ELSE}
    MobilConnection.Commit;
    {$ENDIF !NEXTGEN}

Wobei es unter Android (Samsung Galaxy S2) immer noch langsamer als unter Windows ist. D.h ca 3sek Windows mit 10k Datensätzen zu 20s auf dem Tablet.

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

[himitsu]

Auf dem Tablet mußt du eventuell auch den geringeren Arbeitsspeicher gegenüber einem großen PC in Betracht ziehen.

Zitat von stalkingwolf:

Code:

    {$IFNDEF NEXTGEN}
    TD.TransactionID := 1;
    TD.IsolationLevel := xilREADCOMMITTED;    
    MobilConnection.StartTransaction(td);
    {$ELSE}
    MobilConnection.BeginTransaction;
    {$ENDIF !NEXTGEN}
    ...

Statt "überall" diese IFDEFS zu machen, würde ich einmal bei {$IFNDEF NEXTGEN} z.B. einen Class-Helper für die MobilConnection, mit BeginTransaction und Commit erstellen, welche das mit der TTransactionDesc übernehmen,
und dann überall nur noch BeginTransaction; und Commit; verwenden.

Nja, bezüglich TTransactionDesc:
* man könnte das als ThreadVar speichern (Multithreaded wäre damit schonmal abgefangen, solange da nur einfachte Typen drin vorkommen > Bytes, Integer)
* oder statt dem Class-Helper die Connection-Klasse ableiten und das da als privates Feld rein
Eventuell noch einen verschachtelten Aufruf von BeginTransaction beachten.

[stalkingwolf]

Ich bin mit dem wie es nun funktioniert zufrieden.
Die Datei der SQLlite ist nicht groß das Log wird ebenfalls nicht sonderlich groß.
Daher werde ich nun nicht in 1000er oder 100er Schritten commiten.
Das mache ich in der Regel nur wenn ich mehrere 100.000 oder >1 Millionen Datensätze importiere.

Die IFDEFS habe ich genau so wie aus der Data.SqlExpr genommen, damit ich hier auf der sicheren Seite beim übersetzen bin.
Das Ding wird nachher aber eh nur auf Android laufen. Ich entwickle nur erst einmal unter Windows und passe es dann auf das PAD an, da auch der compile Vorgang auf das PAD erheblich länger dauert.