Is SQLite nou echt zo traag?

[Verwijderd]

Ik heb hier een simpele db die er ongeveer een structuur heeft als volgt:

code:

Products
  ID number (primary key) UNIQUE
  Description varchar
  VendorID  number

Vendors
  ID number (primary key)  UNIQUE
  Name varchar

Invoices
  ID number (primary key)  UNIQUE
  ProductID number

Daar zit in de products een pakweg 1 miljoen rijen
De vendors heeft er een stuk of 50.000 en invoices nog maar iets van 500

Wanneer ik bijvoorbeeld zoiets uitvoer

SQL:

  SELECT p.ID,
         p.Description,
         v.Name,
         COUNT (inv.ID)
    FROM Products p
         LEFT JOIN Invoices inv
            ON inv.ProductID = p.ID
         LEFT JOIN Vendors v
            ON v.ID = p.VendorID
GROUP BY p.ID, p.Description, v.Name
ORDER BY COUNT (inv.ID) DESC;

Dan is ie ongeveer 30 seconden zoet. Los van de PK's zit er een index op Invoice.ProductID

Nu dacht ik dat ik wel met een beetje rommelen met mijn indexes een eind zou komen, maar ik krijg 'm niet echt sneller. Haal ik de indexes weg, dan lijkt ie oneindig lang door te gaan.
Om te testen heb ik de tabellen op mijn Oracle machine gezet en dezelfde query gedraaid.
Nog geen indexes aangemaakt etc en in toad op F9 rammen en hoppa: 260ms en resultaat.

Nu weet ik ook wel dat Oracle een andere klasse is dan SQLite, maar dit verschil is echt mega.
Als ik een beetje ga googlen dan vind ik mensen met SQLite db's van enkele gigabytes die niet eens klagen, hoe kan dat dan? Dit model is verre van complex en kom je ongeveer overal tegen.
Of doe ik iets fout?

[BertS]

Waarvandaan voer je die SQL uit? Vanuit een db-management tool, of vanuit code? De .NET provider geeft dacht ik nogal wat vertraging.

Heb er weleens problemen mee gehad, maar dat was eerlijk gezegd vooral omdat de recordsize > pagesize was (groot varchar veld in tabel).
Dat heb ik toen opgelost door de grote varchar naar een subtabel te zetten (was sowieso beter). Een lookop van één record was snel, maar een select op de hele tabel was een drama.

[Kwastie]

SQLite staat niet bekend om de hoogste performance, is er een specifieke reden dat je SQLite gebruikt i.p.v. een (gratis) DBMS zoals PostrgreSQL of MySQL?

[Verwijderd]

BertS schreef op vrijdag 06 april 2012 @ 14:13:
Waarvandaan voer je die SQL uit? Vanuit een db-management tool, of vanuit code? De .NET provider geeft dacht ik nogal wat vertraging.

Heb er weleens problemen mee gehad, maar dat was eerlijk gezegd vooral omdat de recordsize > pagesize was (groot varchar veld in tabel).
Dat heb ik toen opgelost door de grote varchar naar een subtabel te zetten (was sowieso beter). Een lookop van één record was snel, maar een select op de hele tabel was een drama.

Vanuit .NET , maar ook tools zoals Sqlite Maestro en Navicat geven dezelfde resultaten.
De Products.Description is in mijn Oracle versie 128 bytes, en daar kwam ik mee weg met de import. In Sqlite is ie gewoon 'text' omdat ik dacht dat het bij Sqlite onder de motorkap toch eigenlijk allemaal geen klap uitmaakt. Heb ook geprobeerd te spelen met verschillende PRAGMA opties (cache_size ed.) maar dat maakte helemaal geen verschil

Kwastie schreef op vrijdag 06 april 2012 @ 14:15:
SQLite staat niet bekend om de hoogste performance, is er een specifieke reden dat je SQLite gebruikt i.p.v. een (gratis) DBMS zoals PostrgreSQL of MySQL?

Het is een beetje uit de kluiten gewassen tool geworden waar het belangrijk is om op locatie te kunnen werken waar er niet altijd internet is. Thuis gaat diegene op een desktop verder door de boel te copy/pasten.
Verre van ideaal dus.
PostgreSQL sta ik open voor en MySQL gaat 'm niet worden omdat ik die verschrikkelijk vind
Oracle express zou kunnen, maar goed, dan komt er toch iets van synchronisatie om de hoek kijken

[joppybt]

Dit ziet er niet uit als een heel complexe query, naar mijn idee zou SQLite hier niet bijzonder moeite mee moeten hebben.
Hoeveel megabyte is je SQLite database?
Maak eens een kopietje van de database en strip alles er uit weg zodat je ook echt alleen de drie tabellen met de velden uit je beschrijving overhoudt. Doe vervolgens een VACUUM om alles te optimaliseren. Is de query nu nog zo traag?
Kun je eventueel ergens een kopietje van de (gestripte) database plaatsen? Ik wil wel eens kijken (stuur eventueel een DM met url).