[Java] Grote datafiles, snelheid behouden

[armageddon_2k1]

Ik ben bezig met een projectje waar ik nogal veel data bij elkaar hark. Nu heb ik dit voor een testcase opgeslagen in een simpel csv format en kwam ik op 4GB uit. Een snel berekeningetje leert me dat ik voor een complete set uitkom op zo'n 80GB. Dit gaat dus aardig lastig worden om in het geheugen te laden.

Hoe kan ik dit het beste aanpakken als ik data wil zoeken / bewerken en zijn hier goede libraries voor of best practices voor?
Het is een dataset van een tiental parameters en dan miljoenen rijen aan doubles.

Omdat een double 8 bytes is weet ik natuurlijk waar in de file ik die moet zoeken, dus in feite kan ik wel een wrapper maken die gebruik maakt van een simpele RandomAccesFile en op de juiste locatie de bytes inleest.
Alleen heb ik het donkerbruine vermoeden dat dit al minstens een miljoen keer eerder gedaan is door anderen. Ik weet ook niet helemaal met wat voor performance dingen ik rekening moet gaan houden bij files van 80GB.

Overigens had ik de Java.nio library al gezien, welke wat performanter schijnt te zijn.

Iemand tips?

[Sleepkever]

Tja. 80GB ga je sowieso niet in memory redden inderdaad. Ook niet met wat efficiëntere data structuren als dat java zelf voor floats aanlevert.

Je 8 bytes aanname gaat trouwens sowieso niet werken in een cvs bestand aangezien je daar alles omzet naar tekst. Zou voor jezelf even nagaan hoeveel regels het ongeveer zijn en even grof narekenen hoeveel data je zonder overhead overhoud. Grote kans dat je dan al lager als die 80gb uitkomt.

Als je wilt inlezen met een offset van 8 bytes moet je eerst alles op die manier wegschrijven en dan uitlezen met een simpele wrapper class. Het zou me inderdaad niet verbazen als het er al is, echter is het dermate simpel dat je het zelf ook vrij vlot zou kunnen schrijven.

Wat voor bewerkingen wil je er eigenlijk op uit gaan voeren, en wat let je om het hele zooitje in een database systeem te gooien?

[armageddon_2k1]

Wat betreft het CSV format kan ik het makkelijk omzetten naar byte-format. Ik vroeg me voornamelijk af hoe goed de performance is als ik het met een RandomAccessFile zou doen bijvoorbeeld.

Ik ga eens klussen met een wrapper-class. Dat is inderdaad niet heel erg moeilijk.

Een database heb ik ook overwogen en eerder al eens gebruikt voor meerdere datasets van 2GB. Ik gebruikte toen sqlite en toen viel de performance mij redelijk tegen helaas.

[beany]

armageddon_2k1 schreef op woensdag 28 november 2012 @ 14:24:
Een database heb ik ook overwogen en eerder al eens gebruikt voor meerdere datasets van 2GB. Ik gebruikte toen sqlite en toen viel de performance mij redelijk tegen helaas.

Toch denk ik dat een database wel de oplossing is. Dat de performance tegen viel kan meerdere oorzaken hebben. Bijvoorbeeld het verkeerd gebruik(of zelfs het niet gebruiken) van indexen.

Als je wilt zoeken binnen een grote hoop data dan gaat er qua performance niks boven databases. Zelfs 80GB in het geheugen gaat je tijd kosten als je daar ruw door heen ploegt.

Misschien dat sqlite(ik heb er nooit mee gewerkt) niet de juiste database voor deze case is. Kijk eens naar Sql Server of MySQL.

[Kwistnix]

Een RandomAccessFile heeft al een readDouble() vanuit de DataInput interface. Als je alle doubles sequentieel gaat uitlezen denk ik dat je beter de DataInputStream implementatie van die interface kan pakken, gewrapped door een BufferedInputStream voor efficiëntere I/O. Eventueel zou je ook een MappedByteBuffer kunnen gebruiken, welke je uit een FileChannel kan halen (de NIO API).

Maar het ligt aan hetgeen je uiteindelijk met de data wil doen of dit überhaupt wel de beste aanpak is.

[.oisyn]

Ik heb weinig verstand van dit soort zaken in Java, maar native zou ik gewoon voor memory mapped files gaan. Blijkbaar biedt MappedByteBuffer inderdaad die functionaliteit.

Maar als je de volledige 80GB wilt mappen heb je natuurlijk wel een 64-bits address space nodig.

[ Voor 22% gewijzigd door .oisyn op 28-11-2012 14:36 ]

[armageddon_2k1]

Bedankt voor jullie reacties
Ik zal eens kijken wat het beste werkt. Het is gelukkig nogal exploratief en geen productiewerk (godzijdank), dus er mag wel wat trial and error by komen kijken.

[chime]

Je kan ook altijd met hadoop gaan spelen ... mss wel wat overkill voor je 80 GB ...

[Hydra]

Is het sowieso volledig random of is het redelijk sequentieel? Als je nog wat sequentieel doet (of de access kunt voorspellen) heb je een stuk meer profeit van alle disk en windows caching dan je hebt als je echt willekeurige doubles uit de hele space op gaat vragen.

De java.nio.* package heeft memory mapped files als ik me goed herinner.

Edit: java.nio.MappedByteBuffer

Edit 2: net voorbeeld: http://www.linuxtopia.org...ng_in_java/TIJ314_029.htm

[ Voor 17% gewijzigd door Hydra op 28-11-2012 15:58 ]

[armageddon_2k1]

Ik kan de access precies voorspellen ja. Ik ga eens even kijken naar de MappedByteBuffer die .oisyn ook al aanraadde.

Bedankt voor het voorbeeld.

[armageddon_2k1]

Ben uiteindelijk voor Sqlite3 gegaan. In combinatie met goede indices zetten heb ik nu aardig hoge snelheid en ook gewoon query mogelijkheden

Mijn data is grotendeels sparse, dus ik dacht slim te zijn door een data-format te maken welke lekker efficient is wat dat betreft. Maar veel knappe koppen hebben dat al voor me gedaan dus waarom het wiel opnieuw uitvinden. Ik heb mijn tabellen gewoon ingericht door een tabel [data-types] te hebben en een tabel [data] met een referentie naar het type. Is de sparseness ook opgelost.

Wel veel geleerd van data-structuren opslaan Ook leuk om eens te doen.

[Hydra]

armageddon_2k1 schreef op maandag 03 december 2012 @ 08:54:
Wel veel geleerd van data-structuren opslaan Ook leuk om eens te doen.

Ik vind dat een van de leukste dingen van de hele IT. Ik moet mezelf ook altijd bedwingen om niet zelf 'databases' opnieuw uit te gaan vinden

[armageddon_2k1]

Sowieso is het leuk om het wiel opnieuw uit te gaan vinden Je leert er altijd wat van.
Je moet dat niet-ronde wiel alleen niet in productie gaan gebruiken.

[Knutselsmurf]

armageddon_2k1 schreef op maandag 03 december 2012 @ 08:54:
...Mijn data is grotendeels sparse, dus ik dacht slim te zijn door een data-format te maken welke lekker efficient is wat dat betreft. Maar veel knappe koppen hebben dat al voor me gedaan dus waarom het wiel opnieuw uitvinden....

Deze opmerking mag wat mij betreft met hoofdletters en uitroeptekens in de FAQ. Hoe vaak het niet voorkomt dat mensen niet in willen zien dat er goede, ronde wielen zijn, in plaats van de vierkante wielen die ze persé zelf willen bouwen.....

[armageddon_2k1]

Hoho, ik heb er wel enorm veel van geleerd, maar vanuit efficiency was het handiger naar een oplossing te grijpen die al bewezen is. Het is die zoektocht geweest van het zelf klussen van mij (met hulp in dit topic) wat uiteindelijk naar de juiste oplossing heeft geleid

Het ligt aan de toepassing. Het is voor mijn eigen werk hier wat niet in productie komt, maar waar ik flinke analyses op los laat. Het had dus geen kwaad gekund als ik gewoon mijn gang had gegaan en dan was het waarschijnlijk ook gelukt. Ik was al aardig ver, maar uren kosten geld en ik kwam tot de conclusie dat SQLite me meer boodt wat ik in de toekomst nodig zou hebben.

Men moet 'het wiel opnieuw uitvinden wat tot onveilige situaties kan leiden' niet verwarren met het uitzoeken van bewandelde wegen en je ook stoten tegen de stenen waar alle anderen zich ook al tegen gestoten hebben en van hebben geleerd. Alleen maar mensen terechtwijzen dat ze niet het wiel opnieuw uit moeten vinden schrik je enthousiaste beginnende programmeurs alleen maar mee af.

Wil iemand een PHP framework bouwen? Zeker doen! Wil ie hem bij een klant inzetten. Zeker niet doen! Wil ie een eigen dynamische router inbouwen voor z'n eigen framework en dan met die kennis een bestaand veilig framework verbeteren met een mooie Github pull request dan lijkt me dat fantastisch.

Je kan geen goede programmeur worden zonder af en toe eens flink op je bek te gaan. Je moet alleen zorgen dat je dan alleen op het ijs staat en niet de hele sporthal meesleurt.

[ Voor 8% gewijzigd door armageddon_2k1 op 03-12-2012 16:13 ]