Viele Daten: Wechsel von tDS zu SQLite sinnvoll?

  • VB.NET

Es gibt 8 Antworten in diesem Thema. Der letzte Beitrag () ist von Khartak.

    Viele Daten: Wechsel von tDS zu SQLite sinnvoll?

    Hallo zusammen,

    ich arbeite schon länger mit typisierten DataSets und bin sehr zufrieden mit diesem Format, eben weil es typisiert ist! Die Geschwindigkeit ist auch super. Einziger Wermutstropfen sind die Ladezeiten mit ReadXML.

    Hintergrund:
    Ich habe ein Statistik Programm entwickelt, mit welchem ich Umsätze auswerte. Mir war bereits am Anfang schnell bewusst, dass ich hier mit den initialen Ladezeiten Probleme bekommen werde, daher teile ich die DataSets (XML Dateien) in mehrere Dateien (pro Jahr eine Datei) auf. Wenn ich jetzt mehrere Jahre laden möchte (intern merge ich die DataSets zu einem) dauert das schon sehr lange. Je nach Rechnerleistung schon mal 30-60 Sekunden (~660MB insgesamt).

    Nebenbei beschäftige ich mich auch immer mehr mit MySQL und spiele inzwischen mit dem Gedanken mir mal das SQLite Format anzuschauen. Sowie ich das verstehe, würde ich hier auch eine "Connection" aufbauen und via Abfrage nur die Daten abrufen die ich zur Auswertung benötige. Also entweder nur einen bestimmten Monat oder direkt mehrere Jahre.

    Daher meine Frage:
    Macht es in meiner Situation Sinn zu SQLite zu wechseln (der Programmieraufwand wäre enorm, da im Programm alles auf das DataSet aufgebaut ist)?
    Würde ich hier einen signifikanten Geschwindigkeitsvorteil erfahren? Für 10% mehr Leistung mache ich mir den Aufwand nicht.
    Ich würde auch die Vorteile der Typisierung verlieren, die ich so sehr zu schätzen gelernt habe.

    Eine Umstellung auf einen zentralen Datebankserver ist auch noch keine Option, da die Anwendung auch offline funktionieren muss bzw sollte.

    PS: Meine Datenbank hat 3 Tabellen. 1:n mit einer Haupttabelle und 2 via ForeignKeyConstraint (Cascade) verknüpften Child Tabellen. Hier müsste ich auch dann in MySQL (SQLite) das umständliche LeftJoin verwenden wenn ich die Child-Daten abfrage.

    Hier eine Beispielabfrage mit welcher ich aus Daten aus einer Parent und einer Child Tabelle abrufe:

    VB.NET-Quellcode

    1. Dim SelectedOrderRows As EnumerableRowCollection(Of OrderDataSet.ORDERRow) =
    2. RefODB.MergedOrderDS.ORDER.Where(Function(o) _
    3. o.HAS_DOCUMENT = True AndAlso
    4. o.ORDER_TYPEID = OrderTypeID AndAlso
    5. o.NET_TOTAL >= 0 AndAlso
    6. Convert.ToDateTime(o.DATE_IN) >= DateFrom AndAlso
    7. Convert.ToDateTime(o.DATE_IN) <= DateTill)
    8. For Each rwOrder In SelectedOrderRows
    9. For Each rwItem As OrderDataSet.ITEMRow In rwOrder.GetITEMRows

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Khartak“ ()

    Nach meiner Erfahrung lag es bisher nie an typDataset.ReadXml.
    Es lag immer an angebundenen DataGridviews.
    Das kannst du aber nur testen, wenn du ein gänzlich ungebundenes typDataset befüllst. mach dir eine TestMethode, die mit New typDataset() eine eigene Instanz erstellt, befüll die und miss die Zeit.
    Es ist tatsächlich so, dass ich keine DataGridviews verwende, sondern die Daten lade und mit diversen Algorithmen die hinterlegten Daten auswerte. Ausgegeben werden letzen Endes nur zahlen, sprich Ergebnisse. Ich messe also nur die Zeit die ReadXML benötigt, eine relativ große XML Datei zu laden.

    Das Befüllen mit Daten geht in der Tat blitzschnell. Damit habe ich keine Probleme. Das habe ich alles schon getestet. Insofern kann hier ein Haken dran gemacht werden.

    Ich stelle mir vor, dass eine SQLite Datenbank(Datei) garnicht komplett geladen wird, sondern immer nur das was abgefragt wird. Liege ich da falsch?

    PS: Ich bin nicht scharf darauf zu wechseln :D

    ErfinderDesRades schrieb:

    was dauert denn nun lange


    Nur das laden der XML Datei. Das ist ja alles auch relativ. Aber der XML Reader muss ja alles erst mal in den Arbeitsspeicher laden.
    So habe ich beispielsweise auf einem 4GHz i5 Prozessor eine Ladezeit von 3,4 Sekunden für 140 MByte.
    Insgesamt könnte ich aktuell 625 MB an Daten laden. Das dauert dann (inklusive merging) 34 Sekunden und erfordert 1,2 GB RAM
    ok, das ist nun wirklich viel.
    Jo, da kann SqLite oder sonstwer Abhilfe schaffen, indem abhängig vom aktuellen Vorgang nur der dafür benötigte Teil geladen wird.
    Mit Dataset->Db habich einen Mechanismus gebastelt, der Änderungen ungefähr ebenso komfortabel in die DB schreibt, wie zuvor das gesamte Dataset auf Platte ging.
    Damit man nicht für 100 komplexe Vorgänge 400 komplexe Datenzugriffe schreiben muss (Select Update Insert Delete).
    Dennoch ist son Unterfangen ein gewaltiger Umbau - man muss die Vorgänge identifizieren, und welche Daten man für was braucht, und wann, und wie damit umgehen, wenn ein Teil der Daten schon da ist, und wie das überhaupt feststellen - solche Sachen.
    Vor einiger Zeit habich mit Tragl an einem recht komplexen Teil gewerkelt.
    Da war als Strategie möglich, alle Tabellen bis auf einige wenige (sehr fette) im Speicher zu halten.
    Das ist vlt. nicht super-optimiert, aber man kommt recht gut durch.
    Daten nachladen wird ja erst richtig knifflig, wenn zu den Daten zunächstmal auch übergeordnete nachzuladen sind.
    Solange man sich mittm Nachladen auf die niedrigst-rangigen Tabellen beschränken kann, die keine weiteren ChildTables haben, ists unkompliziert.
    Und grade diese niedrigst-rangigen sind ja die Tabellen, wo so viele Daten anfallen.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Danke für deinen Input. Ich werde mal überlegen was ich machen werde. Jedenfalls werde ich mir SQLite mal anschauen (müssen) und wenn ich damit fit bin, versuche ich es mit der Ersetzung meines geliebten tDS.

    Khartak schrieb:

    Ersetzung meines geliebten tDS

    Es ist überhaupt keine Ersetzung.
    Du hinterlegst "nur" eine andere Datensenke.
    Wenn du dir wie im Tut gezeigt eine DbPersistance baust, brauchst du an deiner Anwendung zunächstmal nichts ändern (dann lädt er aber wie gehabt alle Daten komplett).
    Die erweiterten Möglichkeiten dieser neuen Datensenke dann richtig zu nutzen - das ist dann die Herausforderung.

    Ich hab auch iwo einen DbGenerator verlinkt - der kann aus einem Dataset die passende Strutur in eine Datenbank generieren.
    Ist aber tackelig, und bei SqLite gibts vermutlich Nacharbeiten.