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

[MyRealName]

Ich bin mir nicht ganz sicher, aber ich meine dass SqlLite eh nur mit einer transaction geht. Zumindest hatte meine mobile app gemeckert, alt ich 2 transaktions gleichzeitig laufen lassen wollte

[stalkingwolf]

Hab nun alles drin.
musste den Code noch für Android extra anpassen, aber es funktioniert.

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

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