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

[stalkingwolf]

Ich habe bisher meine Android Apps mit einer lokalen SQLite DB laufen lassen.
Das ging ganz gut, da die Daten welche ich gespeichert habe sehr klein waren.

Nun muss ich ca 10.000 Datensätze speichern ( imo immer noch klein ) und das dauert ca 2 min.
Das SQLite nun nicht das schnellste ist, ist mir bewusst. Das es so extrem langsam ist dachte ich nicht.

Was ist mit IBLite/ToGo?
Ich habe die InterBase XE7 ToGo Edition.
Ist das IBLite/ToGo? Kann ich damit lokale Datenbanken auf dem Pad anlegen?

[RWarnecke]

Mal eine Frage, wo holst Du die Daten her und wie kommen diese auf Dein Gerät ? Ich habe schon Experimente mit 100.000 Datensätzen in einer SQLite Datenbank gemacht. Da gingen die Abfragen alle sehr performant. Vielleicht liegt es ja nicht an der SQLite Datenbank sondern, wie Du die Daten in die Datenbank bringst.

[SebastianZ]

Zitat:

Zitat von stalkingwolf (Beitrag 1380905)

...
Nun muss ich ca 10.000 Datensätze speichern ( imo immer noch klein )
..

Klein ist relativ, es kommt nicht nur auf die Anzahl an, sondern auch wie groß die Daten in den Datensätzen sind. Wenn ich pro Datensatz 10 Bilder mit je 1 MB speichere dauert das deutlich länger, als wenn ein Datensatz nur aus 10 Integer-Werten besteht.
Auch relevant für die Geschwindigkeit ist, woher die Daten geladen/erstellt werden.

Wenn es sich hier um kleine Datenmengen und ein performantes laden/erstellen der Daten handelt, sind eventuell unglückliche Indizes in der Tabelle definiert, die das ganze ausbremsen?

[bra]

Zumal SQLite nicht zum Speichern von größeren Daten in der Datenbank geeignet ist. Ich spreche hier nicht von der Anzahl, sondern der Größe des einzelnen Eintrags. Also Dateien in die SQLite-Datenbank speichern ist sehr langsam.

[stalkingwolf]

es liegt definitiv an sqlite.
Ich lade die Daten per JSON herunter.
Aber wenn ich in der Schleife um den JSONArray das ExecSQL von meinem TDataset auskommentiere, dann rast er durch den Array.

Ich lasse das aktuell noch unter Windows laufen.
Bisher auf einem UNC Pfade und nun habe ich es lokal auf meine Platte geschrieben.
Programm 0% Auslast und die Platte rattert sich nen Ast.
Und selbst auf meiner SSD ist es nicht schneller ( nur leiser :-) )

evtl habe ich auch meine Tabelle falsch definiert.

Code:

const createflgpl_1 = 'CREATE TABLE IF NOT EXISTS FLGPL_1 ('+
        ' LG_NR TEXT NOT NULL PRIMARY KEY,'+
        ' LG_FIL TEXT,'+
        ' LG_PLATZ TEXT,'+
        ' LG_ARTIKEL TEXT,'+
        ' LG_TEIL TEXT,'+
        ' LG_BMGB REAL,'+
        ' LG_BMGV REAL,'+
        ' LG_EKPR REAL,'+
        ' LG_BMGB_ORG REAL,'+
        ' LG_BMGV_ORG REAL,'+
        ' LG_EKPR_ORG REAL,'+
        ' LG_WEDATUM TEXT,'+
        ' LG_ERSTWE TEXT,'+
        ' LG_LETZTERWE TEXT,'+
        ' LG_AEDT REAL)';


.
.
.

            if feld = 'LG_NR' then  flgpl_1_insert.parambyname('LG_NR').asstring := myvalue;
            if feld = 'LG_FIL' then  flgpl_1_insert.parambyname('LG_FIL').asstring := myvalue;
            if feld = 'LG_PLATZ' then  flgpl_1_insert.parambyname('LG_PLATZ').asstring := myvalue;
            if feld = 'LG_ARTIKEL' then  flgpl_1_insert.parambyname('LG_ARTIKEL').asstring := myvalue;
            if feld = 'LG_TEIL' then flgpl_1_insert.parambyname('LG_TEIL').asstring := myvalue;
            if feld = 'LG_BMGB' then begin
                flgpl_1_insert.parambyname('LG_BMGB').asstring := myvalue;
                flgpl_1_insert.parambyname('LG_BMGB_ORG').asstring := myvalue;
            end;
            if feld = 'LG_BMGV' then begin
                flgpl_1_insert.parambyname('LG_BMGV').asstring := myvalue;
                flgpl_1_insert.parambyname('LG_BMGV_ORG').asstring := myvalue;
            end;
            if feld = 'LG_EKPR' then begin
                flgpl_1_insert.parambyname('LG_EKPR').asstring := myvalue;
                flgpl_1_insert.parambyname('LG_EKPR_ORG').asstring := myvalue;
            end;
            if feld = 'LG_WEDATUM' then  flgpl_1_insert.parambyname('LG_WEDATUM').asstring := myvalue;
            if feld = 'LG_ERSTWE' then  flgpl_1_insert.parambyname('LG_ERSTWE').asstring := myvalue;
            if feld = 'LG_LETZTERWE' then  flgpl_1_insert.parambyname('LG_LETZTERWE').asstring := myvalue;
        end;

        flgpl_1_insert.ExecSQL; // <- Kommentiere ich das aus, rennt er durch den Array

Edit : Die DB hat mit den 10.000 Datensätze dann eine Größe von 2.320kb. Also nichts.

[bra]

Da fehlt irgendwie der entscheidende Teil der Schleife in deinem Beispiel oben. Das "Create Table" wird aber nur einmal ausgeführt und nicht bei jedem der 10.000 Schritte, oder?

Mache mal vor (außerhalb) der Schleife ein StartTransaction und danach ein Commit. Wenn der jede Abfrage einzeln Commited wird das sicher auch langsam. Das dürfte bei anderen Datenbanken aber nicht besser sein.

[nahpets]

Interessant wäre es zu sehen, wie das Insert-Statement aussieht, im obigen Beispiel sieht man ja nur die Parameterbefüllung.

Ließe die sich eventuell etwas vereinfachen?

Delphi-Quellcode:

   if feld = 'LG_BMGB' then begin
     flgpl_1_insert.parambyname('LG_BMGB').asstring := myvalue;
     flgpl_1_insert.parambyname('LG_BMGB_ORG').asstring := myvalue;
   end else
   if feld = 'LG_BMGV' then begin
     flgpl_1_insert.parambyname('LG_BMGV').asstring := myvalue;
     flgpl_1_insert.parambyname('LG_BMGV_ORG').asstring := myvalue;
   end else
   if feld = 'LG_EKPR' then begin
     flgpl_1_insert.parambyname('LG_EKPR').asstring := myvalue;
     flgpl_1_insert.parambyname('LG_EKPR_ORG').asstring := myvalue;
   end else begin
     flgpl_1_insert.parambyname(feld).asstring := myvalue;
   end;

[DeddyH]

Vielleicht sollte man sich Array DML einmal anschauen, oder das Ganze zumindest versuchsweise in eine Transaktion packen.

[stalkingwolf]

Die fehlende Transaktion war es. Dachte ich könnte mir diese sparen, da wenn das Ding auf dem Pad läuft eh nu einer zugreift.

Danke für den Tipp.

[TigerLilly]

Was hast du in eine Transaktion geklammert - nur das Statement oder alles?

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

Zitat von TigerLilly (Beitrag 1381001)

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:

Zitat von stalkingwolf (Beitrag 1380987)

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

Delphi-Quellcode:

{$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.

[TigerLilly]

Zitat:

Zitat von jobo (Beitrag 1381006)

Zitat:

Zitat von TigerLilly (Beitrag 1381001)

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.

[Ghostwalker]

Hihi,

vielleicht noch am Rand eine andere Sache. So wie ich das in deinem Code sehe ist der Primärschlüssel ein Textfeld und speichert eine Nummer. Das ist jetzt nicht wirklich optimal, da das verwalten des Index so länger dauert, als z. B. bei einem Integer. Von den Lese/Such-Operationen mal ganz abgesehen.

Ist es denn wirklich notwendig das Feld als Text zu definieren ?

[stalkingwolf]

da Text drin steht ... ja :wink:

[TigerLilly]

Zitat:

Zitat von Ghostwalker (Beitrag 1381093)

So wie ich das in deinem Code sehe ist der Primärschlüssel ein Textfeld und speichert eine Nummer. Das ist jetzt nicht wirklich optimal, da das verwalten des Index so länger dauert, als z. B. bei einem Integer. Von den Lese/Such-Operationen mal ganz abgesehen.

Das halte ich für eine sehr gewagte Behauptung. In der Regel wirst du den Unterschied nicht mal messen können. Integer-Keys brauchen weniger Platz als String-Keys, darum geht der Vergleich ein kleines bisschen schneller, aber da sind andere Faktoren viel viel wichtiger. Je mehr Datensätze es sind und je länger der Key ist, desto mehr schlägt das zu Buche, aber ich würde sagen, da reden wir von > x Mio Datensätzen und Keylänge > 250 (wobei du da ziemlich sicher schon einen Designfehler hast).

Also: Index so bauen, wie es die Daten nahelegen + keine Kopfstände machen.

[jobo]

Zitat:

Zitat von TigerLilly (Beitrag 1381196)

Zitat:

Zitat von Ghostwalker (Beitrag 1381093)

So wie ich das in deinem Code sehe ist der Primärschlüssel ein Textfeld und speichert eine Nummer. Das ist jetzt nicht wirklich optimal, da das verwalten des Index so länger dauert, als z. B. bei einem Integer. Von den Lese/Such-Operationen mal ganz abgesehen.

Das halte ich für eine sehr gewagte Behauptung. In der Regel wirst du den Unterschied nicht mal messen können. Integer-Keys brauchen weniger Platz als String-Keys, darum geht der Vergleich ein kleines bisschen schneller, aber da sind andere Faktoren viel viel wichtiger. Je mehr Datensätze es sind und je länger der Key ist, desto mehr schlägt das zu Buche, aber ich würde sagen, da reden wir von > x Mio Datensätzen und Keylänge > 250 (wobei du da ziemlich sicher schon einen Designfehler hast).

Also: Index so bauen, wie es die Daten nahelegen + keine Kopfstände machen.

Naja, wenn im Feld tatsächlich text steht, sollte es natürlich ein Textfeld sein. Wobei es sqlite glaub ich sogar egal ist.

Tatsächlich sollte aber ein Primärschlüssel ein technischer sein, also nicht fachlich und nicht Daten enthalten, die fachlich verwendet werden. Ist also eine Auftragsnummer aus Zahlen,Tagesdatum und Bearbeiterkürzel zusammen gesetzt (und natürlich eindeutig) nehme ich sie dennoch nicht als Primärschlüssel.

Insofern ist die Behauptung von Ghostwalker nicht sonderlich gewagt, sondern entspricht mehr oder weniger der gängigen Praxis.

[TigerLilly]

Zitat:

Ist also eine Auftragsnummer aus Zahlen,Tagesdatum und Bearbeiterkürzel zusammen gesetzt (und natürlich eindeutig) nehme ich sie dennoch nicht als Primärschlüssel.

Das würdest du nur dann nicht tun, wenn dein Datennmodell das verhindert. Dein Beispiel ist ein zusammengesetzter Schlüssel - dessen Teile müssen foreign keys sein oder elementare Datentypen. Wenn du zusätzlich zu diesem Key noch einen weiteren PK einführst, hast du nichts gewonnen und nur Aufwand.

Aber du hast trotzdem recht - manche DB-Systeme unterstützen kaskadierende Änderungen nicht + dann müssen wir notgedrungener Weise einen zusätzlichen PK einführen, aber nie freiwillig. :-)

[mkinzler]

Ich würde grundsätzlich einen "künstlichen" Primärschlüssel verwenden.

[TigerLilly]

Natural key vs surrogate key - das Netz ist voll davon :-)

Ich geb dir recht, manchmal macht ein "künstlicher" Primärschlüssel einem das Leben leichter. Aber für mich ist das immer ein Hinweis, dass das Datenmodell nicht stimmt. Oder das abzubildende Problem nicht verstanden wurde.

Ein künstlicher Primärschlüssel macht Datenaustausch/Datenabgleich nahezu unmöglich. Ich fürchte mich vor surrogate keys wie der Teufel vor dem Weihwasser :-)

[Ghostwalker]

@TigerLilly

Ich stimm dir schon zu, das das bei kleineren Datenmengen eher irrelevant ist. Ich hab mir aber grundsätzlich einfach angewöhnt, möglichst eindeutige Zahlen (Integer usw. ) als Primärschlüssel zu verwenden (auch wenn er dann "nur" ein technischer Schlüssel ist), da mir die Erfahrung gezeigt hat, das die Datenmenge am Projektanfang grundsätzlich viel zu niedrig angesetzt wird. Hinterher ist der Aufwand größer, das ganze zu ändern.

Unter der Voraussetzung, das dort wirklich nur Zahlenwerte gespeichert werden, sollte man auch in einer DB den richtigen Datentyp verwenden. Im Programm verwendet man ja auch für Ganzzahlen Integer-Variablen und nicht Strings :)

[stalkingwolf]

Ob Natural oder Surrogate Key ist abhängig davon was man drin speichern will.
Das wird auch bei jedem Vergleich der beiden Logiken angesprochen.

Das Datenmodell was ich hier genutzt habe für die Tabelle auf dem Pad i
st die gleiche wie in unserer DB, so dass ich einfach alles 1 zu 1 übernehmen kann ohne mir große einen Kopf zu machen.

[jobo]

Zitat:

Zitat von TigerLilly (Beitrag 1381229)

Zitat:

Ist also eine Auftragsnummer aus Zahlen,Tagesdatum und Bearbeiterkürzel zusammen gesetzt (und natürlich eindeutig) nehme ich sie dennoch nicht als Primärschlüssel.

Das würdest du nur dann nicht tun, wenn dein Datennmodell das verhindert. Dein Beispiel ist ein zusammengesetzter Schlüssel - dessen Teile müssen foreign keys sein oder elementare Datentypen. Wenn du zusätzlich zu diesem Key noch einen weiteren PK einführst, hast du nichts gewonnen und nur Aufwand.

Diese Rechnungsnummer und wie sie aufgebaut ist soll ja nur ein beliebiges Beispiel sein. Jede Firma macht da so ihr Ding, oft sind heterogene Systeme im Einsatz, Quelle/Format der Rechnungsnummer oder irgendeiner anderen Bearbeitungsnummer sind häufig nicht in der (alleinigen) Hoheit der eigenen Anwendung.
Hinzu kommt, dass diese "Welten" nicht statisch sind. Der Tag kommt also, wo dank einer Änderung eines Ablaufs oder dem Austausch einer Software die Dinge plötzlich anders laufen.
Ich sehe das eher so, das die Verwendung natürlicher Schlüssel aus Zeiten stammt, wo Speicherplatz noch kostbar war. Heute liegen die Prioritäten anders, mehr Schnittstellen, mehr Interoperabilität, mehr Flexibilität sind gefordert.
Kleines Beispiel: Kontonummer / BLZ könnte man vielleicht mal als Primärschlüssel verwendet haben. Schwierig wird es schon mit der Bankenkonsolidierung, immer mehr Zweigstellen werden unter einer BLZ zusammengefasst. Dann kommt SEPA und alles ist ganz anders.
Fazit: Je mehr ich die reine Mechanik von fachlicher Funktion trenne, desto besser kann ich ein System auf Änderungen einstellen oder schlicht customizen, wenn ich Stangenwahre anbiete, die der Kunde sich zurecht biegen kann.