[php/general] manual compression function - optimalisatie?

[Verwijderd]

Momenteel ben ik bezig met het maken van een applicatie voor een chemiebedrijf waarbij duizenden files worden ingelezen. Iedere file bevat tientallen lines, waarbij iedere line een bepaalde actie representeert. Voor de duidelijkheid, alles werkt reeds en de reden dat ik de volgende vraag hier stel ik puur uit eigen interesse, daar de applicatie al live is en pas over ruime tijd geëvalueerd/aangepast gaat worden.

De files dienen te worden opgeslagen in een MySQL-databaseveld (longtext). Ik heb een functie geschreven waarmee de inhoud van een file wordt teruggebracht naar één string. Alle acties hebben een drietal variabele kenmerken. Omdat ik de data hier niet mag plaatsen, een fictief voorbeeld van twee acties uit een file:

code:

100 liter water aangeleverd voor vleugel D.
50 kilo boter gebruikt in vleugel F.

De compressiefunctie maakt van die acties een string (compressed data dus), die er als volgt uitziet:

code:

x.100._a.d|y.50._b.f| etc. etc.

Je ziet dus dat de acties gescheiden worden door een seperator ("|"), en dat er per actie respectievelijk het type actie wordt opgeslagen (x = aanleveren, y = gebruiken, etc.). Vervolgens worden er per actie ook nog een drietal variabele kenmerken opgeslagen, gescheiden door een punt (hoeveelheid, productsoort (_a = water, _b = boter, etc.) en de vleugel van het gebouw (d, f, etc.).

De string wordt vervolgens opgeslagen in de database.

Ziet iemand een mogelijkheid om deze compressie verder te optimaliseren?
Voordat ik mijn eigen gedachten daarover uit (ik heb reeds enkele ideeën), graag jullie niet-beïnvloedde mening

[Croga]

Lijkt me niet zo heel lastig....

Aangezien alle onderdelen op aantal karakters gespecificeerd zijn kun je overbodige karakters weglaten.

code:

x.100._a.d

zou zonder meer kunnen worden:

code:

x100ad

Niet netjes, wel kleiner en functioneel gelijk.

[4VAlien]

Je kan in het kader van makkelijk bewerken de strings opsplitsen in 2 tabellen : 1 voor de referentie naar actie en een tabel met de corresponderende handelingen. Dit hoeft echter niet de hoeveelheid data te reduceren ten opzichte van de huidige situatie. Als je een dump van deze database of iets dergelijks wil comprimeren kan je de dump gewoon zippen. Dat werkt erg goed in het geval van tekst based data met veel herhaling. Dus noem nog even de reden waarom je denkt de data te moeten reduceren, het lijkt me niet dat de er problemen optreden bij een aantal duizend regels maar schaalbaar is het natuurlijk niet.

[Gerco]

Wat is het doel van het programma?

Indien je alleen de data kleiner wilt opslaan om later weer exact te reproduceren, gzip gebruiken. Indien je de data doorzoekbaar wilt opslaan maak een extra tabel aan en zet de data daarin in velden die voor deze datatypes geschikt zijn ("tinyint", "set", etc).

[Orion84]

* Orion84 vraagt zich dan af of het, als je het toch in een database stopt, niet handiger was geweest om die afzonderlijke onderdelen van elke regel in een aparte kolom te stoppen? Dus een kolom voor het type actie, een kolom voor de hoeveelheid, een kolom voor het product en een kolom voor de afdeling. Dan kan je er ook nog eens een keer lekker in selecteren, sorteren, groeperen etc.

Om de acties die uit één file afkomstig waren bij elkaar te houden kan je nog een kolom toevoegen met de naam van dat bestand ofzo.

En als je je zorgen maakt dat de database bestanden te groot worden, dan ondersteunt MySQL vast wel een of andere standaard compressietechniek op z'n database bestanden. Die waarschijnlijk efficiënter zal zijn dan dit soort handmatig geknutsel.

[Verwijderd]

Voor de duidelijkheid, omdat dit niet uit mijn topic start blijkt: het gaat om zeer veel data. Het zijn honderdduizenden files (ik verwacht dat dit op korte termijn in de miljoenen gaat lopen) waarbij per file honderden acties zijn opgeslagen. In mijn TS heb ik het verhaal vereenvoudigd verteld.

Het probleem is dat als ik de data één op één opsla in de database het teveel ruimte in beslag neemt. Dat is niet gewenst. Ook is het niet gewenst om de files als zijnde files op te slaan op de server.
De data wordt zeer veel aangeroepen. Ik moet dus snel kunnen comprimeren/decomprimeren, per file. De functie waar ik in de TS over spreek, is snel. De decomprimeerfunctie ook.

@Croga: de seperators weglaten is geen optie. In mijn voorbeeldcode spreek ik over simpele variabelen en waarden. In de praktijk echter zijn de productcodes van variabele lengte, en hebben de acties ook een variabel aantal parameters.

[Orion84]

* Orion84 wordt nu wel nieuwsgierig. Je wilt zeggen dat jouw zelfgeknutselde "compressie" sneller is dan wanneer je standaardlibraries als gzip en dergelijke gebruikt? Heb je dat getest, zo ja: hoe en wat waren de resultaten?

[ Voor 14% gewijzigd door Orion84 op 03-11-2009 14:17 ]

[Verwijderd]

Orion84 schreef op dinsdag 03 november 2009 @ 14:07:
* Orion84 vraagt zich dan af of het, als je het toch in een database stopt, niet handiger was geweest om die afzonderlijke onderdelen van elke regel in een aparte kolom te stoppen? Dus een kolom voor het type actie, een kolom voor de hoeveelheid, een kolom voor het product en een kolom voor de afdeling. Dan kan je er ook nog eens een keer lekker in selecteren, sorteren, groeperen etc.

Om de acties die uit één file afkomstig waren bij elkaar te houden kan je nog een kolom toevoegen met de naam van dat bestand ofzo.

En als je je zorgen maakt dat de database bestanden te groot worden, dan ondersteunt MySQL vast wel een of andere standaard compressietechniek op z'n database bestanden. Die waarschijnlijk efficiënter zal zijn dan dit soort handmatig geknutsel.

Dank.
Dit hebben we overwogen. Zie echter mijn reactie hiervoor. Honderdduizenden files maal honderden acties loopt in de tientallen miljoenen rows, met reële kans op uitbreiding in de toekomst. Om eerlijk te zijn heb ik me nog niet grondig verdiept in de mogelijkheden van MySQL, maar we overwegen sterk om een ander database type te gaan gebruiken.

De hamvraag voor nu is inderdaad over dit 'handmatig geknutsel' daadwerkelijk zo slecht is. Zal ik de huidige methode optimaliseren, of zoeken naar een reeds bestaande compressiemethode? Toch blijft het probleem dat de data constant gecomprimeerd/decomprimeerd dient te worden. Een dump van de DB maken en die comprimeren is zeker geen optie (wel voor back-up uiteraard, maar dit is uitstekend verzorgd).

[Orion84]

Als je minimale wijzigingen aan de huidige situatie wilt aanbrengen kan je altijd gewoon een bestand door gzip halen en dan de uitkomst daarvan in een databaseveld stoppen. Kan me niet voorstellen dat dat langzamer is en grotere bestanden oplevert dan wat jij nu "handmatig" doet.

[Verwijderd]

Orion84 schreef op dinsdag 03 november 2009 @ 14:15:
* Orion84 wordt nu wel nieuwsgierig. Je wilt zeggen dat jouw zelfgeknutselde "compressie" sneller is dan wanneer je standaardlibraries als gzip en dergelijke gebruikt?

We moeten sowieso door alles acties itereren omdat er gigantisch veel overbodige data in de acties staat die genegeerd dient te worden. We filteren dus om te beginnen reeds alle troep. Vervolgens houd je een geringe hoeveelheid nuttige data over, en dan ontstaat de vraag hoe je die data opslaat.

Stel dat je dit overhoudt aan nuttige data:

code:

Gebruiken 50 kilo boter vleugel F
// In dit voorbeeld 33 karakters

Dan kun je die data met een library compression method als GZIP comprimeren, maar je kunt er ook voor kiezen - zoals wij gedaan hebben - om de data nog meer te simplificeren, als zijnde:

code:

x.50._a.f
// 9 karakters

Vervolgens zou je ook deze data nog eens kunnen comprimeren met iets als GZIP, maar dubbele compressie is misschien teveel van het goede? Suggesties?

[Woy]

Verwijderd schreef op dinsdag 03 november 2009 @ 14:16:
[...]


Dank.
Dit hebben we overwogen. Zie echter mijn reactie hiervoor. Honderdduizenden files maal honderden acties loopt in de tientallen miljoenen rows, met reële kans op uitbreiding in de toekomst. Om eerlijk te zijn heb ik me nog niet grondig verdiept in de mogelijkheden van MySQL, maar we overwegen sterk om een ander database type te gaan gebruiken.

De hamvraag voor nu is inderdaad over dit 'handmatig geknutsel' daadwerkelijk zo slecht is. Zal ik de huidige methode optimaliseren, of zoeken naar een reeds bestaande compressiemethode? Toch blijft het probleem dat de data constant gecomprimeerd/decomprimeerd dient te worden. Een dump van de DB maken en die comprimeren is zeker geen optie (wel voor back-up uiteraard, maar dit is uitstekend verzorgd).

Waarom nemen mensen altijd aan dat het maar beter is om een hele hoop data in een enkele row in een kolom te plaatsen dan om het netjes over meerdere rows/columns te verdelen?

Je zegt dat je per actie 3 variabelen hebt, en elke actie hoort bij een file. Dan zou ik iets in de volgende trent doen

Tabel File:
FileId
Name
...

Tabel Actie:
ActieId
FileId
Hoeveelheid
Actie
Vleugel
...

[Verwijderd]

Woy schreef op dinsdag 03 november 2009 @ 14:22:
[...]

Waarom nemen mensen altijd aan dat het maar beter is om een hele hoop data in een enkele row in een kolom te plaatsen dan om het netjes over meerdere rows/columns te verdelen?

Je zegt dat je per actie 3 variabelen hebt, en elke actie hoort bij een file. Dan zou ik iets in de volgende trent doen

Tabel File:
FileId
Name
...

Tabel Actie:
ActieId
FileId
Hoeveelheid
Actie
Vleugel
...

Nogmaals, de situatie die ik hier schets is vereenvoudigd. Zie mijn uitspraak van hiervoor:

Verwijderd schreef op dinsdag 03 november 2009 @ 14:10:
@Croga: de seperators weglaten is geen optie. In mijn voorbeeldcode spreek ik over simpele variabelen en waarden. In de praktijk echter zijn de productcodes van variabele lengte, en hebben de acties ook een variabel aantal parameters.

Ook wijs ik je graag nog eens op de grote hoeveelheid data waar het om gaat. Jouw methode zou resulteren in tientallen miljoenen rows. Is dit acceptabel in jouw ogen (niet ironisch bedoeld)?

[trinite_t]

Verwijderd schreef op dinsdag 03 november 2009 @ 14:26:
[...]


Nogmaals, de situatie die ik hier schets is vereenvoudigd. Zie mijn uitspraak van hiervoor:


[...]


Ook wijs ik je graag nog eens op de grote hoeveelheid data waar het om gaat. Jouw methode zou resulteren in tientallen miljoenen rows. Is dit acceptabel in jouw ogen (niet ironisch bedoeld)?

en juist dat is waar een database voor bedoeld is. Zo veel mogelijk rows verwerken. Ik zou het JUIST doen zoals de hierboven vermelde manier, en dan de keys goed zetten, denk dat dat echt sneller is. Je kunt producten, acties enz., dan ook nog via een foreigen key en een aparte tabel aan elkaar linken, zo reduceer je je data volgens mij nog meer. Het is in ieder geval beter doorzoekbaar.

De manier waarop je de database nu gebruikt is alsof het een filesysteem is. Je zou namelijk al die acties ook op dezelfde manier in een file kunnen opslaan ipv in een text blob in de database. Levert exact hetzelfde resultaat op.

[Orion84]

Verwijderd schreef op dinsdag 03 november 2009 @ 14:22:
[...]


We moeten sowieso door alles acties itereren omdat er gigantisch veel overbodige data in de acties staat die genegeerd dient te worden. We filteren dus om te beginnen reeds alle troep. Vervolgens houd je een geringe hoeveelheid nuttige data over, en dan ontstaat de vraag hoe je die data opslaat.

Stel dat je dit overhoudt aan nuttige data:

code:

Gebruiken 50 kilo boter vleugel F
// In dit voorbeeld 33 karakters

Dan kun je die data met een library compression method als GZIP comprimeren, maar je kunt er ook voor kiezen - zoals wij gedaan hebben - om de data nog meer te simplificeren, als zijnde:

code:

x.50._a.f
// 9 karakters

Vervolgens zou je ook deze data nog eens kunnen comprimeren met iets als GZIP, maar dubbele compressie is misschien teveel van het goede? Suggesties?

Zo'n voorbeeldje ziet er heel spectaculair uit, maar als je met veel data en veel verschillende acties komt te zitten volstaat 1 letter niet meer, zoals je zelf al zegt. Dus zo kort als je het nu schetst wordt het niet met je handmatige oplossing.

Heb je je ooit verdiept in hoe compressiealgoritmes werken? Die doen in feite namelijke exact hetzelfde. Kort door de bocht: Ze kijken welke strings herhaaldelijk voorkomen en vervangen die door een vaste (kortere) string. Welke korte strings bij welke lange string hoort wordt in een tabel gezet en klaar is kees. Precies hetzelfde als wat jij doet dus. Alleen zijn die standaard algoritmes al jaren in ontwikkeling en volledig geoptimaliseerd, zowel qua snelheid als qua compressiekracht. Incl. bijbehorende wetenschappelijke onderzoeken etc.

Maargoed: ga eens testen, want ik krijg niet de indruk dat je dat al gedaan hebt

Verder sluit ik me aan bij de mensen hierboven: een database is bij uitstek geschikt om dergelijke gestructureerde gegevens op te slaan. In hoeverre MySQL geschikt is voor de hoeveelheid data waar jij het over hebt zou ik niet weten, daarvoor heb ik te weinig verstand van MySQL en te weinig inzicht in de daadwerkelijke hoeveelheid data. Maar ook dat zou jij prima zelf uit moeten kunnen zoeken als ontwikkelaar van een dergelijke applicatie. Hoe zou het presteren onder MySQL, zijn er alternatieven voor MySQL die geschikter zijn, wat worden de hardware eisen dan, past dat binnen budget etc. etc.

[ Voor 13% gewijzigd door Orion84 op 03-11-2009 14:35 ]

[Woy]

Verwijderd schreef op dinsdag 03 november 2009 @ 14:26:
[...]
Nogmaals, de situatie die ik hier schets is vereenvoudigd. Zie mijn uitspraak van hiervoor:

Ik zie anders tot nu toe nog nergens een goede reden waarom je zelf met een inefficiënte codering zou gaan werken.

Ook wijs ik je graag nog eens op de grote hoeveelheid data waar het om gaat. Jouw methode zou resulteren in tientallen miljoenen rows. Is dit acceptabel in jouw ogen (niet ironisch bedoeld)?

Hoezo zou dat niet acceptabel zijn?

[trinite_t]

idd, een paar miljoen rows met nette keys/indexes is voor een database peanuts.

[4VAlien]

Een database heeft over het algemeen geen problemen met veel rows. Wel met columns van ongelijke lengte zoals bij jouw huidige methode. Als er op index gezocht wordt dan is dat in principe een log(2) operatie wat betekent dat je maximaal 10 stappen nodig hebt in een tabel met 1024 rijen om iets via de index te zoeken en met 20 stappen bereik je al 1024*1024 rijen dus dat wordt echt geen probleem. Dit is standaard database theorie, praat er eens over met iemand

Probeer eens de structuur met 2 tabellen te maken en ga dan de datatypen zo specificeren dat het de minimale ruimte inneemt. Dan kun je de huidige opzet vergelijken met het optimale datamodel onder MySQL. Nu is het toch allemaal giswerk en dat levert uiteindelijk niks op.

Het suggereren van een andere database zonder dat je uberhaupt weet of MySQL geschikt is klinkt een beetje als paniekvoetbal. Wat limitaties van MySQL betreft:

"The InnoDB storage engine maintains InnoDB tables within a tablespace that can be created from several files. This allows a table to exceed the maximum individual file size. The tablespace can include raw disk partitions, which allows extremely large tables. The maximum tablespace size is 64TB. "

[NMe]

Verwijderd schreef op dinsdag 03 november 2009 @ 14:26:
[...]


Nogmaals, de situatie die ik hier schets is vereenvoudigd. Zie mijn uitspraak van hiervoor:

[...]

Ook wijs ik je graag nog eens op de grote hoeveelheid data waar het om gaat. Jouw methode zou resulteren in tientallen miljoenen rows. Is dit acceptabel in jouw ogen (niet ironisch bedoeld)?

Het feit dat je denkt dat tientallen miljoenen rows ook maar een klein probleem zou vormen voor een beetje database zegt mij genoeg over jouw ervaring als developer. Waarom denk je dat het fout zou gaan? Kijk voor de gein eens naar het ID van het bericht dat je hier post. We zitten op dit forum al bijna aan de 33 miljoen posts; da's echt geen enkel probleem.

Denk bovendien in jouw opzet eens na over dit praktijkprobleemje: schrijf eens een query die alle dagen ophaalt waarop er meer dan 100 eenheden water geleverd zijn in vleugel D.

[LoBbY_1]

4VAlien heeft wel een erg goed punt hierboven. Probeer gewoon beide methoden en bereken de verschillen in executietijd en load op een server. Dan heb je een goed idee wat het beste en snelste is. Misschien is het zelfs wel een combinatie van beide.

En ik moet me aansluiten bij de rest, een SQL server is gemaakt voor snelle lezing van heel veel records. Wat dan beter is, mssql, oracle, mysql of wat voor database engine ook is ook weer uit te zoeken.

Je hebt het over duizenden, is dat per seconde, per uur per dag? Kan je daarin iets specefieker zijn? En Hoe lang zijn je strings? Heb je dar echt een longtext voor nodig?

Met een redelijk grote website zit je al snel aan duizenden query's per seconde in allerlei verschillende tabellen, databases en noem maar op! Je mashine bepaald natuurlijk voor een groot gedeelte de snelheid van je verwerkingen.

Je kan ook alle acties specificeren en opslaan in tabellen:



Kort en krachtig, alles uitbreidbaar.
Per actie sla je maar 4 cijfers op in dit voorbeeld en je behoud alle informatie.

@ trinite_t haha was nog editen!
Wil nog niet echt goed blijven staan..
Door deze manier van opslaan kan je ook nog goed statistieken op je gegevens loslaten.

[ Voor 37% gewijzigd door LoBbY_1 op 03-11-2009 15:33 ]

[trinite_t]

LoBbY_1 schreef op dinsdag 03 november 2009 @ 14:53:
prod
1=boter
2=melk
3=pindakaas

Actie
1=leveren
2=afnemen
3=kopen
4=verkopen

Locatie
1=vleugel a
2=vleugel b
3=locatie a
4=locatie b

enz.. Op deze manier kan je makkelijk meerdere zaken toevoegen en vervolgens kan je ze opslaan als:
id x -> prod=1 ->actie3 -> locatie=1

waarbij je het laatste ook wilt doen in tabellen, nl:
Files (id, name, ...)
PerformedActions (id, file_id, product_id, value, actie_id, locatie_id)

Dan blijft je data namelijk ook doorzoekbaar, denk bijvorobeeld aan de hoeveelheid gebruikte boter/water, de bezettingsgraad van je vleugels, enz

[Soultaker]

Tja, de keuze tussen een genormaliseerde database met indices (waarvan LoBbY_1 al een opzet gaf) en een puur archiefformaat kunnen wij niet maken. Het gaat er dan om wat je met je data wil.

Ik vraag me wel af waarom je je gegevens überhaupt in een relationele database opslaat als je die zo gaat comprimeren dat je er vervolgens niet meer op kunt queryen. Bovendien vraag ik me af waarom je gecodeerde data in een tekstveld opslaat (in een BLOB veld kun je nog sterker gecomprimeerde gegevens opslaan).

Als het puur om opslag gaat, zijn algemene compressiemethoden (gzip, XZ, et cetera) wel bruikbaar, maar die hebben wel enige context nodig om goed te werken. Afzonderlijke regels comprimeren heeft weinig zin, maar hele bestanden misschien al wel, en alle bestanden bij elkaar nog meer. Handmatig kun je vermoedelijk betere resultaten voor afzonderlijke regels boeken (zeker als je er allerlei context-specifieke informatie bij kunt betrekken, zoals welke acties er mogelijk zijn en hoeveel parameters elke actie krijgt) maar dat wordt natuurlijk heel veel werk; het is de vraag of het de moeite waard is.

(Overigens is je voorbeeld ook al misleidend omdat je "x.100._a.d|y.50._b.f|" niet in je oorspronkelijk invoer kan omzetten zonder te weten waar x, _a, d, enzovoort voor staat. Het is me uit je beschrijving niet duidelijk of die contextinformatie vaststaat of ook in je compressieplan opgenomen moet worden.)

[Gomez12]

Tja, een eigen compressie mechanisme is bijna per definitie inefficienter dan de uitgekristalliseerde definities.

Maar heel simpel gesteld is jouw eigen compressie algoritme gewoon een normalisatie slag.

Ergens heb je staan wat x/y/_a/_b/f/d betekent, laten we dit even een tabel noemen en x/y/_a/_b/f/d een id.
Dan spreek je niet meer over 1 string, maar over verschillende kolommen in 1 tabel die bij elkaar gehouden worden met inefficiente keys ( ints zijn bijna altijd sneller als single chars )

Je bent gewoon op een heel inefficiente manier de werking van een genormaliseerde dbase aan het nabouwen, en dit doe je dan binnen 1 dbase veld.

Serieus ga eerst gewoon normaliseren, dit komt al voor 95% bij jouw compressie ( al zullen je id's groter zijn vanwege verschil tussen 10-tallig en 26-tallig stelsel ) en dan heb je nog alle standaard mogelijkheden van een dbase er gratis bij.
Heb je dan nog steeds een giga-ruimteprobleem en performance over, dan kan je nog eens gaan kijken naar of je je int's niet om kan zetten naar chars.

[Gerco]

Gomez12 schreef op dinsdag 03 november 2009 @ 21:21:
al zullen je id's groter zijn vanwege verschil tussen 10-tallig en 26-tallig stelsel

De database gaat dat id echt niet decimaal opslaan. Die gebruikt gewoon een enkele byte voor een int tussen 0 en 255, een 256-tallig stelsel, if you will.

In de praktijk zul je waarschijnlijk grotere ids gebruiken, maar als het ruimte scheelt en je hebt weinig verschillende waardes kun je gewoon enkele bytes gebruiken als id. Dingen die maar een beperkt aantal waardes hebben (zoals een set) kunnen in nog minder bits opgeslagen worden, de meeste databases zullen meestal minimaal een byte pakken voor zo'n veld omdat het sneller leest en schrijft, maar er zullen vast size optimalisaties aan te zetten zijn.

Van een int naar een char gaan maakt je data alleen maar groter, dat het in decimale representatie een langer getal is zegt helemaal niets over hoeveel ruimte het inneemt op schijf.

[ Voor 10% gewijzigd door Gerco op 03-11-2009 22:36 ]

[Gomez12]

Gerco schreef op dinsdag 03 november 2009 @ 22:34:
[...]
Van een int naar een char gaan maakt je data alleen maar groter, dat het in decimale representatie een langer getal is zegt helemaal niets over hoeveel ruimte het inneemt op schijf.

In theorie wel, maar voor het oog niet

En hoe een willekeurige database iets opslaat durf ik helemaal geen voorspelling over te doen.

Ik zou me iets kunnen voorstellen dat er voor een standaard int veld gewoon 11 bits gepakt worden ongeacht de data die erin staat ( variabele lengtes zuigen redelijk voor een grotere database ) terwijl er voor een char(1) echt maar 1 byte gepakt wordt.
Maar dan kom je echt in het veld van premature optimisation omdat over het algemeen indexen over ints weer sneller zijn dan indexen over chars

Ik zou het er eerst gewoon met allemaal ints erin gooien ( storage is cheap ). En als je dan echt tegen storage problemen aanloopt dan kun je nog eens kijken naar een alternatief voor ints.
Maar char als alternatief gaat je hooguit 10% extra storage opleveren ( als ik het al juist gok en alle ints gewoon 11 bits innemen ) tegen x % performance degradation.

En bij storage problemen zou mijn eerste suggestie toch echt zijn : schaf meer storage aan, dat is in de huidige tijd nog steeds goedkoper dan processing power.

[ACM]

Verwijderd schreef op dinsdag 03 november 2009 @ 14:16:
Honderdduizenden files maal honderden acties loopt in de tientallen miljoenen rows, met reële kans op uitbreiding in de toekomst. Om eerlijk te zijn heb ik me nog niet grondig verdiept in de mogelijkheden van MySQL, maar we overwegen sterk om een ander database type te gaan gebruiken.

Tientallen miljoenen rows is niet echt een probleem voor MySQL, hoewel daar in de buurt het vaak wel handig begint te worden om over een vorm van partitionering (of sharding zoals het vaak genoemd wordt) na te denken. MySQL 5.1 kan dat zelf automatisch voor je bijhouden daarna aan de hand van diverse opties.
Bij partitionering splits je je data op in verschillende tabellen, waarbij het van je applicatie afhangt of het zin heeft om dat virtueel een tabel te laten zijn of niet.
Andere databases kunnen wellicht beter met jouw data overweg, maar dat hangt heel erg af van wat je er mee wilt. Als je je data alleen maar voor algemene analyses wilt gebruiken (Bussiness Intelligence enzo) dan kan database met column-orientatie je wellicht een hoop winst bieden. Als je echter orders en dergelijke bij elkaar moet rapen en continu zaken toevoegt en/of kleine stukjes uitleest, dan is MySQL waarschijnlijk niet zo'n gekke keus.

De hamvraag voor nu is inderdaad over dit 'handmatig geknutsel' daadwerkelijk zo slecht is. Zal ik de huidige methode optimaliseren, of zoeken naar een reeds bestaande compressiemethode? Toch blijft het probleem dat de data constant gecomprimeerd/decomprimeerd dient te worden. Een dump van de DB maken en die comprimeren is zeker geen optie (wel voor back-up uiteraard, maar dit is uitstekend verzorgd).

Zoals Soultaker al aanstipte hangt het er helemaal van af wat je er mee wilt. Als je het alleen maar wilt opslaan, waarom zou je dan uberhaupt nog een database gebruiken?

Gomez12 schreef op woensdag 04 november 2009 @ 00:22:
En hoe een willekeurige database iets opslaat durf ik helemaal geen voorspelling over te doen.

Er zijn maar weinig databases die integers anders dan binair opslaan. Er zijn er vast een paar die alleen maar tekstvelden kennen, maar het gros gebruikt afhankelijk van hun opslagsysteem een of enkele bytes er voor.
MySQL kent int-varianten van 1 (tinyint), 2 (short), 3 (mediumint), 4 (integer) en 8 bytes (bigint) lang.

Ik zou me iets kunnen voorstellen dat er voor een standaard int veld gewoon 11 bits gepakt worden ongeacht de data die erin staat

Je bedoelt dan neem ik aan 32 bits, aka 4 bytes?

( variabele lengtes zuigen redelijk voor een grotere database ) terwijl er voor een char(1) echt maar 1 byte gepakt wordt.

Dat hangt er van af, maar bij MySQL is dat wel het geval. Er zijn echter ook wel databases die row-based compressie ondersteunen of juist alles in kolommen opslaan (luciddb/dynamodb bijv) en daar dan ook weer allerlei soorten compressie op los kunnen laten.

[NMe]

ACM schreef op woensdag 04 november 2009 @ 10:58:
Je bedoelt dan neem ik aan 32 bits, aka 4 bytes?

offtopic:
Nee, ik denk dat hij doelt op de "size" die in phpMyAdmin (MySQL?) automatisch op 11 (als in: INT(11) ) wordt gezet, wat naar ik aanneem duidt op de lengte in karakters van een 32-bits int met sign ervoor ( -2147483648 = 11 karakters). Op zich wel redelijk knullig van MySQL.

[Verwijderd]

Aantal vragen die wel belangrijk zijn om bepaalde keuzes te maken:

- Inlezen/Verwerken, moet dit realtime gebeuren, of batch gebaseerd achteraf ?
- Bevragen van de data, gebeurt dit continue of worden er periodieke rapporten gemaakt ?
- Verwerkingssnelheid, is dit van belang niet iedere DB kan als een gek maar continue miljoenen records "wegpompen", alhowel je performance kan "kopen" zoals men zegt.

Verder ben ik het met de meeste eens dat dit soort zaken opslaan als een "gecomprimeerde" string eigenlijk nergens opslaat. Klinkt alsof je een idee hebt gehad voor een probleem en dit idee maar "gepushed" hebt omt te realiseren ipv te kijken en/of te testen met andere/betere alternatieven.

Als je bang bent dat je tegen de limieten van een bepaalde DB aanloopt met dit soort zaken, zou je sowieso eens moeten kijken naar een DB waar die limieten wat hoger liggen.

als ik aan TS vraag of zijn compressie techniek technisch uitgevoerd wordt met regexpressies zal het antwoord denk ik Ja zijn,
Waarom de input concatten tot 1 string ?

-zomaar wat opmerkingen die m'n gedachten passeerden bij het lezen van deze thread.

[base_]

misschien kan je iets met de archive engine van mysql?
zie: http://dev.mysql.com/doc/...chive-storage-engine.html

[LoBbY_1]

Is de TS nog benieuwd naar de aangedragen ideeën?