MyISAM vs InnoDB, waarom toch eerst MyISAM

[Verwijderd]

Korte vraag. Jullie zaten al op innodb, nu moesten de tables toch al geconvert worden waar jullie ook heen gingen... maar waarom hadden jullie vorige week éérst besloten naar myisam te gaan, terwijl die toch duidelijk als trager te boek staat en wat feat. mist. Waarom niet gewoon bij het snellere innodb blijven(in eerste instantie dan) ?

pardon topictitel moet myisam staan....

[Femme]

Topic titel gefixt.

[Floor-is]

Omdat het eigenlijk in stappen gedaan had moeten worden, eerst MyISAM draaien, dan langzaam over op InnoDB, maar helaas pindakaas...

[Compubiter]

Wat ACM op de FP schreef:

Gepost door ACM dinsdag 30 juli 2002 - 18:53 Score: 3 (Informatief)
Even ter info voor de a-technici en anderen.

De database converteren betekend in het eerste geval NIET dat het van innodb naar myisam of whatever gaat, maar dat het formaat, de manier van opslaan, zelfs de uitgepoepte html voor de ubb-tags allemaal opnieuw moesten.

Wees blij, _dat_ was allemaal al gedaan. Wat restte was het inlezen van die database, het goedzetten van de indices, het aanpassen van allerlei andere zaakjes (kost een paar uur) en het aanmaken (kostte ook een paar uur) van oa de rechten.

Waar we niet op rekenden was dat mysql meerdere malen er de brui aan gaf, wat ons oa verplichtte enkele file-checks uit te voeren (minstens 15 minuten verder voor je wat kan doen) en sommige queries (een paar keer) te herhalen... Die dan minimaal al 45minuten duurden...

Al met al kostte het alleen daardoor al zoveel langer dat we alleen aan gisteren niet genoeg hadden.

Toen we eindelijk de database up-and-running hadden bleek dat de horde ongeduldige tweakertjes het systeem direct platlegde.

Of dit alleen aan myisam te wijten was betwijfel ik, ook de gebruikte mysql-versie bleek een beetje 'buggy' om te gaan met hoge load.
(die dus de hele conversie en de HK test-periode prima draaide, behalve dat ie tijdens het converteren af en toe 'mysql-achtig' vervelend deed).

De tweede conversie die dus gedaan moest worden was 'simpelweg' de myisam tables anders opslaan in het innodb-formaat.

Roepen "maar ze waren toch al innodb" is dan ook complete onzin, want ook als we van 'innodb -> innodb' waren gegaan had er een uitgebreide (en erg slome) conversie van opslagmanier/formaat uitgevoerd moeten worden.

Al met al hopen we vanavond online te kunnen, met innodb-tabellen en een oudere mysql (die weer een patch nodig voor react mist ) en een heel (niet leuke, soms wel leerzame) ervaringen rijker.

Overigens, de got-database grootte tegenwoordig al ruim 6GB.
En zijn er dik 7miljoen messages te converteren.

In Floris z'n ondertitel schreef hij:
Hardstikke op vakantie!

Ja, dat zien we

[Verwijderd]

das waarom ze zo'n vertraging hadden, k neem aan dat het ook van inno->inno kon want jullie gingen wel draaien met myisam. maar waarom terwijl het bekend is dat tie trager is. als het alleen voor conversie is ga je neit het forum eerst weer up brengne neem ik aan?

[Compubiter]

Verwijderd schreef op 03 augustus 2002 @ 22:25:das waarom ze zo'n vertraging hadden, k neem aan dat het ook van inno->inno kon want jullie gingen wel draaien met myisam. maar waarom terwijl het bekend is dat tie trager is. als het alleen voor conversie is ga je neit het forum eerst weer up brengne neem ik aan?

Bedoel je dit:

Roepen "maar ze waren toch al innodb" is dan ook complete onzin, want ook als we van 'innodb -> innodb' waren gegaan had er een uitgebreide (en erg slome) conversie van opslagmanier/formaat uitgevoerd moeten worden.

Of bedoel je iets anders?

[Verwijderd]

nee ik snap dat er toch al een conversie nodig was, ook als je weer innodb gaat draaien. maar wat ik niet snap is dat jullie het als langzamer bekende myisam gebruikten en niet meteen gewoon een conversie van inno->inno deden, maar het forum met myisam up brachten

[_JGC_]

Je kunt niet alles zomaar op InnoDB gaan draaien. InnoDB heeft een heleboel mooie features: betere caching, transactions, foreign keys, en waarschijnlijk nog een paar, maar wat InnoDB mist tov MyISAM: Delayed inserts. Wat je destijds met Topix zag was dat guests niet veel konden, omdat hun sessies bijgehouden werden in een tabel waar ze met delayed inserts inkwamen. Dit is later veranderd.
Behalve het gemis van delayed inserts, vreet InnoDB nog eens extra resources. Voor een kleine site kan je met gemak MyISAM draaien op een Pentium 75 met 48MB geheugen, draait redelijk. Als je op zo'n machine dan InnoDB gaat draaien, schiet de load omhoog en begint ie als een gek te swappen. Als je geen InnoDB nodig hebt, gebruik het dan ook niet.

[chem]

ik denk dat ACM het allemaal heel mooi verwoord heeft.

InnoDB vreet idd resources, en bij de HK test heeft alles zonder noemenswaardige problemen op MyISAM gedraaid. Vandaar dat we in 1e instantie de innodb 2myisam conversie wilde laten wachten, om iig sneller online te kunnen.

[eth0]

Hier een shell scripie wat ik gemaakt heb om snel alle bestaande databases omtezetten naar innodb

code:

#!/bin/bash

#set -x

PASS=""
if test -z $PASS
 then
  echo "Mysql password not in script"
  exit 1
fi

echo 'show databases' |/opt/mysql/bin/mysql -u root -p$PASS | grep -v ^mysql | grep -v ^Database |while read db ; do
    echo "Converting $db to InnoDB"
    echo 'show tables' |/opt/mysql/bin/mysql $db -u root -p$PASS | grep -v ^Tables_in_ |while read tbl ; do
    echo "  setting table $tbl to InnoDB"
    echo "alter table $tbl Type = InnoDB" |/opt/mysql/bin/mysql $db -u root -p$PASS

    done

done

code parsed niet helemaal ok, BUG??? &qoute hoort er dus niet in moet zijn "

#!/bin/bash

#set -x

PASS=""
if test -z $PASS
then
echo "Mysql password not in script"
exit 1
fi

echo 'show databases' |/opt/mysql/bin/mysql -u root -p$PASS | grep -v ^mysql | grep -v ^Database |while read db ; do
echo "Converting $db to InnoDB"
echo 'show tables' |/opt/mysql/bin/mysql $db -u root -p$PASS | grep -v ^Tables_in_ |while read tbl ; do
echo " setting table $tbl to InnoDB"
echo "alter table $tbl Type = InnoDB" |/opt/mysql/bin/mysql $db -u root -p$PASS

done

done


mmm zonder code is hij wel goed

[ Voor 0% gewijzigd door eth0 op 04-08-2002 15:23 . Reden: code not ok ]

[Femme]

_JGC_ schreef op 04 augustus 2002 @ 12:45:
Je kunt niet alles zomaar op InnoDB gaan draaien. InnoDB heeft een heleboel mooie features: betere caching, transactions, foreign keys, en waarschijnlijk nog een paar, maar wat InnoDB mist tov MyISAM: Delayed inserts. Wat je destijds met Topix zag was dat guests niet veel konden, omdat hun sessies bijgehouden werden in een tabel waar ze met delayed inserts inkwamen. Dit is later veranderd.
Behalve het gemis van delayed inserts, vreet InnoDB nog eens extra resources. Voor een kleine site kan je met gemak MyISAM draaien op een Pentium 75 met 48MB geheugen, draait redelijk. Als je op zo'n machine dan InnoDB gaat draaien, schiet de load omhoog en begint ie als een gek te swappen. Als je geen InnoDB nodig hebt, gebruik het dan ook niet.

Het ontbreken van delayed inserts is geen gemis. Je hebt 't helemaal niet nodig opder InnoDB ivm row-level locking. Op MyISAM tabellen is het soms een vereiste om de vaart erin te houden, aangezien de performance van MyISAM echt in elkaar kan storten als er teveel gelijktijdige selects en inserts worden gedaan.

Dat je meer geheugen nodig had met InnoDB ligt waarschijnlijk gewoon aan de gebruikte settings. De standaard instelling voor geheugengebruik (buffer pool e.d.) zijn wat ruimer bemeten dan die van MySQL/MyISAM. Op een serieuze server met 512MB of meer geheugen is dat geen enkel probleem.