[MySQL] Database opschonen met behoud van meest recente data

[Verwijderd]

Mijn vraag:

Ik wil graag mijn mySQL database opschonen. Er staan momenteel een hoop transacties in, waaronder die van 2015. We willen eigenlijk alle oude transacties eruit gooien, waardoor de database weer wat leger wordt. We willen wel de recente klantgegevens(data) (zoals hoeveelheid punten bij laatste transactie) behouden.

Daarna willen we dus in staat zijn verder te gaan met de meest recente gegevens en hopen dat het systeem ook sneller wordt, doordat de database een stuk leger is. (het is een klantensysteem met punten)

Wat zijn mijn opties om dit op te lossen?

Relevante software en hardware die ik gebruik:

Het is een mySQL database die met PHPmyadmin beheert wordt (als ik dat zo goed zeg)


Wat ik al gevonden of geprobeerd heb

Er zijn sowieso van (als het goed is) iedere dag backups, dus klopt het dat je daar de hele database weer mee kan terugzetten als het nodig is?
Ik heb de query voor alle data uit 2015 uitgevoerd en kreeg dus alle data van 2015, maar weet dus niet of ik dit zo maar weg kan doen en het systeem nog werkend blijft daardoor, vandaar mijn vraag.


Alvast bedankt!

[Daos]

Je zegt het niet goed: beheerd is met een d op het eind

Maar of je het veilig kan verwijderen is zo niet te zeggen.

Je kan twee dingen doen:
- maker systeem benaderen en vragen of hij het wilt doen
- verwijderen en als het systeem problemen geeft backup terug zetten.

edit: hoe goed de backups zijn is ook niet te zeggen door ons

[ Voor 10% gewijzigd door Daos op 14-02-2016 18:10 ]

[Speedmaster]

En wat moet je volgens de Belastingdienst bewaren....?

[Freeaqingme]

hopen dat het systeem ook sneller wordt, doordat de database een stuk leger is.

Heb je ook al gemeten (niet gokken) waardoor het nu zo langzaam is? Als dat inderdaad de database blijkt te zijn kan je daarna gaan kijken welke queries het om gaat. Ik weet niet om hoeveel rijen het gaat, maar doorgaans kan een RDBMS zoals Mysql makkelijk met een paar honderdmiljoen rijen omgaan - mits je de juiste indexes gebruikt.

[pedorus]

Meestal is een oplossing met indices (of partities/shards bij vele miljoenen rijen) beter inderdaad. Of een aantal settings tweaken kan vaak ook al een stuk helpen, vooral als er veel schrijfacties plaatsvinden (zoals meer geheugen toekennen aan mysql, bedenken wat je wil als innodb_flush_log_at_trx_commit, of filesystem configureren)..

Maar wat je ook doet, maak eerst een backup van de laatste data. En test vooral ook of deze backup werkt. Je kunt prima "iedere dag backups" hebben die niet werken, dan zou je niet de eerste zijn. Zet deze backup eens terug op een testomgeving en kijk of dit goed werkt.

Dan zou je daarna wat kunnen proberen, liefst eerst op een kopie in een testomgeving. En dat is natuurlijk gewoon een kwestie van delete gebruiken ipv select.

Maar veelal denken mensen dat ze veel data hebben die in de weg zit, terwijl dat onzin is. Anderen denken dat je nosql nodig hebt, ook vaak onzin. Maar de tool is niet het probleem:

quote: http://www.commitstrip.co...m-is-not-the-tool-itself/

[ajakkes]

Speedmaster schreef op zondag 14 februari 2016 @ 18:14:
En wat moet je volgens de Belastingdienst bewaren....?

Een werkende back-up van je database ga ik van uit.

[Duumke]

ajakkes schreef op maandag 15 februari 2016 @ 07:03:
[...]


Een werkende back-up van je database ga ik van uit.

Ik denk meer dat er bedoeld wordt welke retentie er nodig is voor de belastingdienst.

Een werkende backup heb je puur voor jezelf / het bedrijf, voor de belastingdienst maakt het namelijk niet uit waar je data vandaan komt zolang je het maar kunt aanleveren.

[ajakkes]

Duumke schreef op maandag 15 februari 2016 @ 07:09:
[...]

Ik denk meer dat er bedoeld wordt welke retentie er nodig is voor de belastingdienst.

Een werkende backup heb je puur voor jezelf / het bedrijf, voor de belastingdienst maakt het namelijk niet uit waar je data vandaan komt zolang je het maar kunt aanleveren.

Een werkende back up heb je voor de belastingdienst. Want de data heb je alleen nog nodig voor de retentie. Je kan wel een niet werkende back-up aanleveren, maar ik gok dat de belasting geen moeite doet de data eruit te krijgen.

Of kijk jij nog maandelijks naar je omzetdetails van afgelopen jaren.

[Janoz]

In een backup staan niet alleen de omzetdetails van de afgelopen jaren, maar ook die van vandaag..

[emnich]

Met alle respect maar ga dit niet zelf doen maar vraag iemand die er (meer) verstand van heeft. Als ik de OP lees dan denk ik niet dat de benodigde kennis voldoende aanwezig is bij je.

Als je toch eigenwijs bent en het zelf wil doen, richt een goede testomgeving in en ga gewoon deleten. Als je iets verkeerd doet, begin je weer opnieuw.

Ga niet in je live omgeving klooien, ook al kan je een backup terug zetten, je komt dan weer nieuwe problemen tegen (zoals missende data van ná de laatste backup).

Maar nogmaals, laat iemand anders het doen....

[xzaz]

emnich schreef op maandag 15 februari 2016 @ 09:55:
Maar nogmaals, laat iemand anders het doen....

Waarom omdat iemand anders het al eens heeft gedaan, zo kom je natuurlijk nooit verder. Gewoon een backup maken en agressief gaan testen. Kijk naar indexes, joins, table structures etc.

[DJMaze]

Verwijderd schreef op zondag 14 februari 2016 @ 17:55:
Mijn vraag:

Ik wil graag mijn mySQL database opschonen. Er staan momenteel een hoop transacties in, waaronder die van 2015. We willen eigenlijk alle oude transacties eruit gooien, waardoor de database weer wat leger wordt. We willen wel de recente klantgegevens(data) (zoals hoeveelheid punten bij laatste transactie) behouden.

Daarna willen we dus in staat zijn verder te gaan met de meest recente gegevens en hopen dat het systeem ook sneller wordt, doordat de database een stuk leger is. (het is een klantensysteem met punten)

Wat zijn mijn opties om dit op te lossen?

Je systeem is niet sneller. Het kan zelfs zo zijn dat hij langzamer is.
Dat komt omdat MySQL bijvoorbeeld besluit om geen index te gebruiken omdat er te weinig in de database zit.

Zorg gewoon dat een capabele DB Architect de database fatsoenlijk inricht.

Daarnaast is de meeste winst te halen in het programmeer gedeelte. Als je PHP gebruikt denk ik dat daar je grootste probleem zit.
9 van de 10 programmeurs is gewoon niet geschikt voor het werk.

Zou fijn zijn als je kan vertellen wat de code is (Magento, CS Cart, OpenCart, VirtueMart, Woo, etc. etc.)

[TRON]

Over hoeveel rijen spreken we eigenlijk? + wat DJMaze vraagt: welk softwarepakket wordt er gebruikt?

[Duumke]

ajakkes schreef op maandag 15 februari 2016 @ 07:29:
[...]


Een werkende back up heb je voor de belastingdienst. Want de data heb je alleen nog nodig voor de retentie. Je kan wel een niet werkende back-up aanleveren, maar ik gok dat de belasting geen moeite doet de data eruit te krijgen.

Of kijk jij nog maandelijks naar je omzetdetails van afgelopen jaren.

Niet direct, maar ze zijn vaak wel bruikbaar voor trendanalyses. Ik zou de data dan ook gewoon live houden en zorgen dat de backups goed geregeld zijn voor als je systeem omvalt.

Daarnaast gaat de belastingdienst niet in een backup kijken, die vragen gewoon een export van de benodigde data in een algemeen formaat. Op welke manier jij de backup ingericht hebt, en welke oplossing je daarvoor gebruikt is voor de belastingdienst ook niet relevant. Voor jezelf is het het handigst als je simpelweg een export kunt draaien vanuit productie en niet bijvoorbeeld de jaarlijkse data bij elkaar moet vegen.

Het is heel onlogisch om na het boekjaar de data in een backup te zetten en er niet meer naar om te kijken tenzij de belastingdienst er naar vraagt. De data blijft doorgaans gewoon live beschikbaar in de systemen.

[emnich]

xzaz schreef op maandag 15 februari 2016 @ 15:52:
[...]

Waarom omdat iemand anders het al eens heeft gedaan, zo kom je natuurlijk nooit verder. Gewoon een backup maken en agressief gaan testen. Kijk naar indexes, joins, table structures etc.

Omdat ik uit de OP opmaak dat TS een probleem opgelost wil hebben en niet lekker wil stoeien met MySQL en zodoende er van leren.

Verder is het, zoals door meerdere mensen aangegeven, zeer de vraag of het geïdentificeerde probleem wel het echte probleem is.

Maar nogmaals, als TS' primaire doel is om te leren dan moet hij vooral een test omgeving inrichten en lekker spelen. Als er dan vragen zijn, dan zijn we hier heel graag bereid om te helpen.

[xzaz]

emnich schreef op maandag 15 februari 2016 @ 18:54:
[...]

Omdat ik uit de OP opmaak dat TS een probleem opgelost wil hebben en niet lekker wil stoeien met MySQL en zodoende er van leren.

Dat is wat jij er van maakt.

Verder is het, zoals door meerdere mensen aangegeven, zeer de vraag of het geïdentificeerde probleem wel het echte probleem is.

Dat zal hij zien door middel van monkey testen.

Maar nogmaals, als TS' primaire doel is om te leren dan moet hij vooral een test omgeving inrichten en lekker spelen. Als er dan vragen zijn, dan zijn we hier heel graag bereid om te helpen.

We zijn hier altijd bereid om te helpen. Die arrogante houding van Tweakers komt me langzamerhand echt de strot uit.

[Verwijderd]

Bedankt voor de reacties.

Ik ben er alleen op zaterdag, dus ga er dan ook mee aan de slag. Ik ga er een testomgeving van maken op mijn eigen laptop, om er inderdaad ook van te leren en hopelijk het probleem op te lossen.

Nu ik lees dat een mySQL database makkelijk honderdmiljoenen rijen kan hebben, met juist gebruik van indexen, denk ik niet dat dat het probleem is, aangezien ik vorige week heb gezien dat het er ongeveer 42000 waren.

Het is voor een vrijwilligersorganisatie, ik zei ook mijn database, maar het is niet de mijne, ik ben gewoon degene die het wil gaan oplossen. Maar het systeem maakt gebruik van punten, er komt geen geld aan te pas, dus ik denk dat de belastingdienst ook weinig interesse heeft in deze data.

Voor het softwarepakket zou ik zaterdag even moeten kijken.

Ik kom er op terug

[Voutloos]

42000 rows is een praktisch lege DB. Dus je zou sowieso inderdaad het echte probleem moeten fixen, anders merk je ook al een bottleneck bij een gestage groei van klanten.

[ Voor 6% gewijzigd door Voutloos op 16-02-2016 10:57 ]

[borft]

Als er 42000 rijen zijn, dan vermoed ik dat er ergens een hele verkeerde join gebeurt, die ook nog es geen idex gebruikt

Ik beheer hier een MySQL db met miljarden rijen, en die is ook nog steeds gewoon snel

[Gomez12]

borft schreef op dinsdag 16 februari 2016 @ 10:56:
Als er 42000 rijen zijn, dan vermoed ik dat er ergens een hele verkeerde join gebeurt, die ook nog es geen idex gebruikt

Ik beheer hier een MySQL db met miljarden rijen, en die is ook nog steeds gewoon snel

Zinloze opmerking zolang je de verdere omgeving niet kent.
Jouw MySQL db met miljarden rijen gaat keihard op zijn bek als je die gaat draaien op een VM met 512MB geheugen, dan kan je er indexen tegenaan gooien wat je wilt.

[borft]

Alhoewel je niet ongelijk hebt, is jouw opmerking denk ik zo mogelijk nog zinlozer. De kans dat de hardware van de server de bottleneck is bij een tabel met 42K rijen lijkt me nihil. Tenzij er blobs van gigabytes inzitten zou de complete tabel (zowel data als indeces) makkelijk in memory moeten passen, zelfs op de gemiddelde smartphone.

Ik denk daarom dat performance problemen meer in de queries en tabelstructuren gezocht moeten worden. Persoonlijk zou ik beginnen met het uitvinden van welke queries specifiek traag zijn, en dan dmv bv explain bekijken wat het queryplan is. Dat gaat je wat meer vertellen over wat je bottleneck is.

[DJMaze]

borft schreef op dinsdag 16 februari 2016 @ 13:35:
Tenzij er blobs van gigabytes inzitten zou de complete tabel (zowel data als indeces) makkelijk in memory moeten passen, zelfs op de gemiddelde smartphone.

Zelfs met blobs kan het, in php een unbuffered query aanroepen.
https://www.percona.com/b...ing-of-big-parts-of-data/

[emnich]

Dan nog, als de hardware echt de bottleneck zou zijn dan redt je het ook niet door een x aantal records weg te gooien maar zal je toch de structuur van je DB aan moeten passen.

[Gomez12]

emnich schreef op dinsdag 16 februari 2016 @ 15:38:
Dan nog, als de hardware echt de bottleneck zou zijn dan redt je het ook niet door een x aantal records weg te gooien maar zal je toch de structuur van je DB aan moeten passen.

Alleen is de structuur (grof gezegd) al zo ruk opgesteld dat hij schijnbaar kraakt bij 42k records.

Dan zou ik de originele bedenker er niet meer bij laten, dan zou ik TS er niet bij laten (opschonen doet niets als je maar 42k records hebt) dan zou ik gewoon een ander inhuren (en dat hoeft in dit geval echt geen expert te zijn)

[Voutloos]

Doe niet zo dramatisch joh, het is voor vrijwilligers en het gaat blijkbaar niet om financiële data. Inmiddels is het punt wel gemaakt dat opschonen niet de enige of beste oplossing is, en ts heeft al aangegeven er verder in te willen duiken.