[TYPO3-UG Dutch] Serverbeheer MySQL vraag

[Bas v.d. Wiel]

 Hoi Jordan,

 InnoDB is wel enigzins configureerbaar, maar de ibdata-file wordt 
 inderdaad nooit kleiner. De reden daarvoor is om schijffragmentatie te 
 voorkomen. Krimpt de feitelijke omvang van je dataset, dan komt er 
 simpelweg ruimte vrij binnen je ibdata-bestand die bij latere groei 
 eerst gebruikt zal worden voordat het bestand verder groeit. Zou het 
 bestand zelf steeds mee krimpen met je dataset, dan is de kans heel erg 
 groot dat het bestand verspreid raakt over je fysieke disk. Op een 
 gewone harddisk geeft dat na verloop van tijd performanceproblemen.

 Een database die bij het dumpen in omvang explodeert, zou kunnen komen 
 door een hoeveelheid binaire BLOB-velden. Een dumpfile is ontzettend 
 inefficient m.b.t. ruimtegebruik omdat het een lange reeks letterlijk 
 leesbare SQL-commando's zijn. Er komt dus al omvang bij omdat alle data 
 ingekapseld moet worden in bijvoorbeeld INSERT-statements. Binaire 
 velden moeten worden omgecodeerd zodat ze in een ASCII-formaat dumpfile 
 kunnen bestaan, wat ook vrijwel altijd betekent dat ze aanzienlijk meer 
 ruimte zullen innemen.

 Je zou dit eens kunnen testen door je DB te dumpen en in een 
 splinternieuwe MySQL-instantie te laden. Mijn vermoeden is dat je dan 
 niet meer komt aan een 5GB ibdata-file. Gebruik je dumpfiles voor 
 backupdoeleinden, dan kun je die het beste ook nog even door bzip2 heen 
 halen. Dat scheelt gigantisch in de omvang.

 Een heel belangrijk voordeel van InnoDB boven MyISAM is de fijnmazigere 
 locking. Met name tabellen waar veel naar geschreven wordt, zoals de 
 diverse cache tabellen, hebben hier baat bij. InnoDB vergrendelt bij het 
 schrijven namelijk alleen de betreffende regel, terwijl MyISAM de hele 
 tabel op slot gooit. In een InnoDB-tabel kun je dus meerdere records 
 tegelijkertijd schrijven, terwijl MyISAM de requests ééń voor één 
 afhandelt. InnoDB is eigenlijk onontbeerlijk als je site veel bezoek 
 heeft. Ook voor backendgebruikers kan het prettig zijn dat ze niet op 
 elkaars transacties in bijvoorbeeld de DAM hoeven te wachten, wat bij 
 plm. 75 redacteuren een reëel probleem kan zijn.

 Uiteindelijk komt het er inderdaad wel op neer dat je met de omvang van 
 je database zult moeten leren leven. Heb je een file van 6GB, dan heb je 
 ooit die hoeveelheid data gehad en was die omvang dus nodig. Gezien de 
 nadelen van het snel 'teruggeven' van die ruimte, neem ik dit 
 persoonlijk voor lief.

 Groeten,
 Bas

> Vraag 1: er is een manier om per tabel dit soort innodb bestanden te
> genereren. Als je dan een tabel of databse weggooit wordt dit
> tenminste wel opgeschoond. Kent iemand die manier en hoe stel je dit
> in en hoe kom je dan af van die al bestande 6 GB ibdata1 file?
>
> Vraag 2: Een database geeft aan dat deze 360 MB is. Echter met het
> backup command mysqldump --opt etc. wordt het bestand 5 GB !. Dat 
> moet
> dus uit die ibdata1 tabel (innodb) data komen.
>
> Wie heeft hier wat zinnigs over te zeggen of wat suggesties? Ik post
> het hier maar omdat de TYPO3 debian nieuwsgroep al tijden niet meer
> gebruikt wordt.
>
> MvG,
>
> Jordan
> _______________________________________________
> TYPO3-UG-Dutch mailing list
> TYPO3-UG-Dutch at lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-ug-dutch