Goed opslagformaat, indexeerbaar en veel data.

[MKe]

Hoi,

Ik zoek een goed opslagformaat voor een grote hoeveelheid data. Het gaat om miljoenen datapunten per keer. Gebruikers moeten hier op basis van zelf gedefinieerde criteria data uit kunnen filtreren. Hierbij moet gedacht worden aan dingen als "kolom A niet gelijk aan Kolom B", "Kolom C > 10" etc. Sommige kolommen bevatten integers, andere tekst.
De bedoeling is om een desktop progje te maken waarmee data gefilterd kan worden. Dit progje moet zowel op Windows als op Linux gebruikt kunnen worden, dus multiplatform. Daarom heb ik het in python geschreven. Het is pertinent niet de bedoeling een centrale opslagsysteem te maken, dus geen client-server systeem als mysql, maar dus file-based.

SQlite leek mij ideaal ondanks dat de data niet relationeel is. Ik heb dus een 1 tabel database gemaakt. Dit werkt op Linux (Kubuntu) heel behoorlijk. De performance is goed genoeg, zeker gezien de hoeveelheid data. Op windows echter niet. Er blijkt een enorme performance gap te liggen tussen deze systemen bij het gebruik van sqlite. Een simpele select count query met een paar parameters duurt op het Linux systeem 3 seconden en op Windows 30 minuten. Dit is dus onacceptabel en voor mij enigszins onbegrijpelijk. Voor de duidelijkheid, dit is op een dualboot machine, dus beide op dezelfde hardware en Kubuntu-64 en Win7-64.


Mijn vraag is: wat voor alternatieven kan ik proberen?
- XML lijkt me niet geschikt. Heeft volgens mij ook geen indexering.
- Ik heb Mongo-db gevonden, is dat bruikbaar? edit: MongoDB is een client-server systeem, dus valt af.
- shelves. lijkt meer een soort stored dictionary (key-value), waar je dus niet de queries op kunt loslaten die aangaf
- heeft iemand een andere suggestie?

[Cheap Applications]

Ik ben geen expert, maar ik kwam pas voor Python csv tegen, een functie van Python zelf, misschien dat dat ook een optie is.

[commandoline]

Ik zoek een goed opslagformaat voor een grote hoeveelheid data. Het gaat om miljoenen datapunten per keer. Gebruikers moeten hier op basis van zelf gedefinieerde criteria data uit kunnen filtreren. Hierbij moet gedacht worden aan dingen als "kolom A niet gelijk aan Kolom B", "Kolom C > 10" etc. Sommige kolommen bevatten integers, andere tekst.

Als er toch iets van een structuur in zit, wil het wel eens helpen om indexes in sqlite aan te maken. Ik meen me te herinneren dat sqlite dat in de latere versies soms zelfs automatisch doet. (gokje: Misschien zou dat het verschil verklaren?)

Als de database verder niet al te groot is (zeg < 50MB) zou je kunnen overwegen om 'm naar een in-memory-database te kopiëren. Ook dat maakt mogelijk een verschil: zie http://stackoverflow.com/questions/3850022/python-sqlite3-load-existing-db-file-to-memory voor hoe dat werkt. Kijk ook even naar het derde antwoord in die link, daar staan nog een aantal performancesuggesties.

Als sqlite dan nog niet voldoet (het zou me verbazen), wordt het verder zoeken naar een geschiktere database. XML, shelves, json, csv en alle andere in Python ingebouwde serialisatiemogelijkheden (op sqlite na) hebben allemaal geen index en zullen dus vermoedelijk afvallen. (Tenminste, uit je startpost maak ik op dat het zonder te traag is.)

[MKe]

Als er toch iets van een structuur in zit, wil het wel eens helpen om indexes in sqlite aan te maken. Ik meen me te herinneren dat sqlite dat in de latere versies soms zelfs automatisch doet. (gokje: Misschien zou dat het verschil verklaren?)

Als de database verder niet al te groot is (zeg < 50MB) zou je kunnen overwegen om 'm naar een in-memory-database te kopiëren. Ook dat maakt mogelijk een verschil: zie http://stackoverflow.com/questions/3850022/python-sqlite3-load-existing-db-file-to-memory voor hoe dat werkt. Kijk ook even naar het derde antwoord in die link, daar staan nog een aantal performancesuggesties.

Als sqlite dan nog niet voldoet (het zou me verbazen), wordt het verder zoeken naar een geschiktere database. XML, shelves, json, csv en alle andere in Python ingebouwde serialisatiemogelijkheden (op sqlite na) hebben allemaal geen index en zullen dus vermoedelijk afvallen. (Tenminste, uit je startpost maak ik op dat het zonder te traag is.)

Er is idd veel te halen met ander typen indices heb ik vandaag ontdekt. Door samengestelde indices te maken i.p.v. indices op elke kolom (wat ik tot nu toe gedaan had) wordt de zoektijd erg verkort. Weliswaar heeft dit enorm invloed op de grootte van het bestand, maar dat is een kleine prijs voor het feit dat het nu bruikbaar is. Blijkbaar wordt er maar 1 index gebruikt per query. Probleem is wel dat het aantal kolommen nogal kan toenemen, dus daar moet ik nog iets op verzinnen.
Het is dus een bestand van 3 GB, maar ik sluit niet uit dat dit nog veel groter kan worden. Ik geef er dus de voorkeur aan om het niet in geheugen te lezen, vanwege de slechtere schaalbaarheid.
Tja, het verschil in snelheid tussen Windows en Linux kan ik nog steeds niet verklaren, omdat ze volgens mij dezelfde sqlite hebben. Het kan zijn dat die voor Windows alleen in 32 bits is, maar dat weet ik niet zeker.