ugrás a tartalomhoz

MyISAM-ból InnoDB-be. Van-e valamilyen funkcionális hátránya?

hNczy · 2012. Szep. 20. (Cs), 18.15
Sziasztok!

Egy nagyságrendileg 200 táblát tartalmazó - összesen körülbelül 8 millió soros - adatbázisnál át kellene térni végre az InnoDB-re a MyISAM-ról. Okozhat-e ez bármilyen működési problémát?

Azzal tisztában vagyok, hogy a két motor működése jelentősen eltér. De lehet-e hogy valamilyen SQL kérés ami jelenleg lefut, az a váltás után nem fog menni? Úgy gondolom nem, hiszen MySQL szerver kezeli az egészet, és "csak" a tárolás módja változik meg, de azért megnyugtató lenne néhány hozzászólás a nálamnál tapasztaltabbak részéről.

Előre is köszönöm!
 
1

nem lesz gond.. elvileg :)

szabo.b.gabor · 2012. Szep. 20. (Cs), 19.42
nem lesz gond.. elvileg :) legyen mentés, és először próbáld ki teszt szerveren
9

mentés, teszt, ok

hNczy · 2012. Szep. 21. (P), 10.28
Mentés egyértelmű, de azért köszi! :)
Teszt localban megvolt, eddig nem tapasztaltam problémát.
2

Némileg lassulni fog a

eddig bírtam szó nélkül · 2012. Szep. 20. (Cs), 19.48
Némileg lassulni fog a rendszered (valószínű, bár nem 100%) és nem lesz full text search (ez utóbbit most láttam, ahogy rákerestem a témára a google-n, nekem nem sokat mond)
20

A keresést segíti

inf3rno · 2012. Szep. 25. (K), 14.40
A keresést segíti valamennyivel, MATCH AGAINST-et kell írni bele a LIKE helyett, ami sokkal szebb kódot eredményez. Kiváltható egy rakat OR LIKE-al egymás után, ami annyira nem probléma, ha generáltatod valahogy a condition részt. Nyilván maga az SQL csúnya lesz, de nem szépségre megyünk...

Tranzakció kezelés nélküli adatbázis gyakorlatilag öngyilkosság. Egyedül akkor lehet használni bármire is, ha nincsenek kapcsolt táblák, vagy nincs olyan helyzet, hogy egyszerre több táblát kellene módosítani. Ellenkező esetben inkonzisztens adatok kerülnek fel... Mondjuk ezeket meg lehet időzítetten elleőriztetni, meg törölni, de ez már olyan szintű gányolás, hogy egyszerűen nem éri meg. Egyszer követtem el ilyesmit, többször nem fogok...
3

Minek?

Pepita · 2012. Szep. 20. (Cs), 20.03
Mi okból térsz át?
Kell tranzakciókezelés?
Tudtommal - remélem szól vki, ha tévedek! - más igazán jelentős különbség nincs. Na jó, ott vannak még az idegen kulcsok és a csak rekordszintű zárolás (ami szerintem weben majdnem felesleges), de cserébe lassabb.
Ha nem kell vmi olyat újítanod, amihez InnoDB kell, akkor szerintem kár átvariálni.
4

Megelőztél, ott a pont.

hunkris · 2012. Szep. 20. (Cs), 20.16
Megelőztél, ott a pont.
5

Nekem úgy tűnik,

eddig bírtam szó nélkül · 2012. Szep. 20. (Cs), 20.41
7

Dolgoztam velük

Poetro · 2012. Szep. 20. (Cs), 21.10
Dolgoztam velük, és igen jó munkát végeznek a srácok adatbázis téren. Respect.
8

Köszi!

hNczy · 2012. Szep. 21. (P), 10.27
Érdekes cikk, eddig még nem olvastam. Köszönöm, mindenképp hasznos volt.
11

"Régi"

Hidvégi Gábor · 2012. Szep. 21. (P), 12.00
A cikk 2008-as, azóta sokat fejlesztettek az InnoDB-n, az 5.5-ösben sokat javítottak a sebességén, optimálisabbak az alapbeállítások is.

Ettől függetlenül, amit leírnak, az igaz. Én mondjuk nem használnék MyISAM-ot, mert nem felel meg az ACID követelményeinek, legfeljebb nem kritikus adatokat tárolnék ilyen táblákban.
12

Mondjuk nem véletlen, hogy az

eddig bírtam szó nélkül · 2012. Szep. 21. (P), 12.12
Mondjuk nem véletlen, hogy az innodb lett a default engine.
De az az említett full text search bizonyos esetekben jól jöhet, ha jól értem, amit olvastam róla.
És olvasási performanciában még mindig lehagyja a myisam... :-)
6

Beszúrás, frissítés

Poetro · 2012. Szep. 20. (Cs), 21.06
Ha az táblában több az INSERT / UPDATE mint a SELECT, akkor sokkal jobb lesz a teljesítmény InnoDB-vel.
13

Ha ennyi a lényeg,

Pepita · 2012. Szep. 21. (P), 23.22
akkor elég ritka szitu az, amikor megéri.
A tranzakciókezelés már érdekesebb.

A cikket (HZ) még csak átfutottam, így elsőre nem úgy tűnik, mintha nagyon rossz lenne a myisam... Inkább csak mindkettő előny / hátrány - felsorolása. Mindegy, majd átrágom, attól bajom nem lesz.

Szerk.: na, átrágtam, amennyire megértettem, igazam volt. Kereséshez sokszor jobb lehet a myisam. Nagyobbacska rekordszámnál főként. Sokszor gyorsabb az innodb, de erőforrásigényesebb is. Szóval nem kell váltani mindenképp.
14

Az egy szép világ lenne, ha

BlaZe · 2012. Szep. 22. (Szo), 00.46
Az egy szép világ lenne, ha az alkalmazásokban az adatbáziskezelő sebessége lenne a szűk keresztmetszet :) Nem mondom, van ilyen, de ez annyira ritka eset, hogy a fejlesztők többsége szerintem nem is találkozik ilyennel, és ott általában máshogy is nyúlnak már a problémához. Illetve az adatbáziskezelők azért optimalizálva vannak sebességre is, míg a rájuk épülő alkalmazások sajnos már ritkábban. Szóval fejlesztőként sokkal fontosabb a konzisztencia, a tranzakciók (weben is), row lock stb, minthogy 1, vagy 1,3 msec alatt ad vissza valamit az sql szerver. Ezekkel tuti minden fejlesztő találkozik, aki adatbázishoz nyúl. Így én igazából a myisamnak szinte csak read-only, vagy primitíven egyszerű adatbázisoknál látom értelmét. Épkézláb adatbázist én nem bíznék rá.

Nekem spec az a kedvencem, ahol innodb, és nincs fk, meg semmi constraint :)
15

Ezt kifejtenéd bővebben?

hNczy · 2012. Szep. 24. (H), 12.03
Ezt kifejtenéd bővebben? Érdekelne, hogy mire gondolsz.

Nekem spec az a kedvencem, ahol innodb, és nincs fk, meg semmi constraint :)
16

Amíg ő előkerül: gyanítom,

eddig bírtam szó nélkül · 2012. Szep. 24. (H), 12.24
Amíg ő előkerül: gyanítom, arra célzott, hogy az InnoDB-t használva már lennének eszközök az adatbázis integritásának, konzisztenciájának megőrzésére, de nem használják őket.
21

Igen, erre gondoltam.

BlaZe · 2012. Szep. 25. (K), 16.41
Igen, erre gondoltam.
17

Hogyne, persze...

Pepita · 2012. Szep. 25. (K), 03.42
1...1.3 msec az tényleg mindegy. Elég kicsi adatbázisokkal volt eddig dolgod, ha csak ilyen időket láttál. Nem itt van a leggyengébb pont, de nem is lényegtelen. A motor arra lehet optimalizálva, amit az adott táblatípus megenged / tud. Persze, egy PHP szkriptet írhat Szomszéd Pistike is, nem vitatom, hogy bele lehet gyilkolni egész másodperceket is.

De túlsarkítod a dolgot, nincs ekkora minőségi különbség, és sok fontos szolgáltatás meg az innodb-ben nincs meg. Nekem sem a sebessége a legfontosabb, de az is fontos.
18

Mi az a sok fontos

Hidvégi Gábor · 2012. Szep. 25. (K), 07.18
Mi az a sok fontos szolgáltatás, ami MyISAM-ban megvan és InnoDB-ben nincs? Egyébként a MySQL 5.6-ban lesz Fulltext indexelés InnoDB-re is.
19

Akkor szorozd be tízzel, vagy

BlaZe · 2012. Szep. 25. (K), 12.32
Akkor szorozd be tízzel, vagy százzal, ha úgy jobban tetszik :) Nem ez volt a lényeg. Itt tipikusan webről beszélgetünk, az pedig (általában) pl nagyon jól cache-elhető. Így pedig gyakorlatilag lehet 5 sec is egy query, ha csak bizonyos feltételeknek megfelelően (ttl, változás, háttér process) kell lefuttatni. Illetve (szintén általában) a lekérdezett adatokkal való bűvészkedés tovább tart, mint a lekérdezése. Én erre utaltam. Van olyan feladat, ahol a lekérdezések viszik a több időt, de weben nagyon nem ez a jellemző. És ha már nagyon sql sebességre kell gyúrni, vannak hatékonyabb eszközök is, mint az innodb -> myisam csere. Pl tablespace-ek kialakítása, particionálás stb. Ilyenformán továbbra is tartom, hogy a legtöbb webes rendszerben az sql sebessége nem annyira lényeges (megfelelő rá épülő alkalmazással persze), a konzisztencia megtartása, a tranzakciók támogatása viszont elég alapvető, ha már adatbázisról beszélünk. Ergo hatalmas minőségi különbség van a myisam és az innodb tudása között.

Én egyébként nem kifejezetten az innodb mellett voksolok (nem is igazán használok mysqlt), hanem a minek tranzakció, meg constraintek a webre, ha a myisam gyorsabb hozzáállás ellen.

És dolgoztam, dolgozok is nagyobb adatbázisokkal, láttam már 1msecnél nagyobb válaszidőt :)
22

innodb -> myisam csere?!

Pepita · 2012. Szep. 26. (Sze), 02.48
Na, azért én semmi ilyesmit nem mondtam!
Pusztán megkérdőjeleztem - meglévő adatbázisnál - a myisam -> innodb csere hasznosságát. Ezt fent is tartom.

De azt sem mondtam, hogy én nem használok innodb-t. Ha kell külső kulcs, tranzakciókezelés (gyakran), akkor kell. Viszont néha még hasznos is tud lenni a tábla szintű zárolás.

A fulltext (jövő) kétségkívül erősen az innodb felé nyomja a mérleg nyelvét, köszönöm Gábor, még nem tudtam.

Szerk.: ja és a sebesség. Való igaz, a (PHP) szkripted sokkal több ideig dolgozik az adatokon, mint amennyi idő alatt megkapja. Csakhogy amíg kapja, addig "vár rá", tehát ez az idő is számít annyiban, hogy hozzáadódik a nagyobb időhöz.
23

"Ha kell külső kulcs,

BlaZe · 2012. Szep. 26. (Sze), 10.00
"Ha kell külső kulcs, tranzakciókezelés (gyakran), akkor kell."

Így van. És én erre utaltam, hogy ez a feltétel eléggé elméleti (amennyiben írjuk is az adatbázist, márpedig jellemzően szoktuk), ergo a myisam sebességelőnyével szemben jóval fontosabb ezen feature-ök megléte (tranzakció, fk, row lock). Ezért eléggé indokolt szerintem innodbt használni myisam helyett. Illetve van még egy igen fontos dolog szerintem. Ez pedig az MVCC. Arra gondolok, hogy egy esetleges crash esetén mennyi idő (ha egyáltalán lehet myisam fileokból) helyreállítani egy adatbázist. Ez nem fejlesztői, hanem üzemeltetői kérdés, de jó tisztában lenni ezzel a különbséggel is. Jó nagy adatbázisnál a myisamchk eléggé komoly büntetés is lehet :)
10

Köszönöm mindenkinek! Ezek

hNczy · 2012. Szep. 21. (P), 10.31
Köszönöm mindenkinek! Ezek (és a teszt) alapján meg fogom lépni a váltást.
24

innodb

EL Tebe · 2012. Okt. 4. (Cs), 09.57
InnoDb esetén valahogy máshogy van kalkulálva/tárolva az autoincrement érték. Ez nem lenne baj, ha mindent úgy csinálunk, ahogy a nagykönyben meg van írva. Nahde:

Ha mégis "fizikailag" törölsz autoincrementált értékű sorokat egy InnoDd táblából, DE ezen oszlop/kulcs alapján kapcsolt táblában viszont nem törlöd a hozzá csatolt sorokat (tehát valójában csak a reláció egyik oldalát törlöd ki), majd a mysql szerver újra lesz indítva (enélkül nem jön elő a hiba!) és az adott (autoincrement-es) táblába újabb adatok kerülnek be az újraindítás után szintén autoincrement-tel, azok a sorok felvehetik a korábban törölt sorok automatikusan kiosztott, de törölt értékeit.

Így nagyon "érdekes" eredményeket fogsz kapni különösebb hibaüzenet nélkül.

Max akkor fog feltűnni és lesz hiba, ha nem 1-sok kapcsolat van a táblák közt, hanem 1-1 kapcsolat, mert elvileg ilyenkor a kapcsolt tábla kulcsa egyedi és így - egy insert + last insert id után - "duplikált sor/ez az érték már létezik" szerű hibaüzenetet fogsz kapni.
--
Nem tudom, hogy a frissebb MySQL-ben ez hogyan van, ebbe kb. 2,5 éve futottam bele és néztem egy igencsak nagyot.

Persze mindig mondják, hogy "fizikálisan" nem szokás törölni sorokat, csak egy flag-gel megjelölni a töröltet.
25

leírás

EL Tebe · 2012. Okt. 4. (Cs), 10.22
Itt van egy leírás az innodb autoincrement-ről
26

Hát ez így nem igaz, ha

inf3rno · 2012. Okt. 4. (Cs), 12.03
Hát ez így nem igaz, ha rendesen létrehozol foreign key-eket meg indexeket az egyes sorokra, akkor nem engedi törölni, hanem foreign key constraintre hivatkozva hibával elszáll...
27

Pont ezt írtam fentebb, mint

BlaZe · 2012. Okt. 4. (Cs), 22.36
Pont ezt írtam fentebb, mint kedvencemet :) Aki innodb-t használ, használjon fk-t is, különben szivatni fogja magát. Ettől függetlenül az autoincrement ilyen működése tényleg nem feltétlenül a legelőnyösebb megoldás, mert nem csak belső, de külső táblák, adatbázisok stb is függhetnek az általa kiosztott értéktől. Ilyenformán a problémafelvetés jogos.

Biztosabb egy ilyen: http://stackoverflow.com/questions/282099/whats-the-hi-lo-algorithm. Bár phpban ennek kicsit macerásabb a megvalósítása (kell hozzá pl memcached).

De még célszerűbb olyan adatbázist választani, amiben van pl sequence :)
28

foreign keys

EL Tebe · 2012. Okt. 5. (P), 09.53
Arról nem is beszélve hogy átláthatóbb az egész db.

Csak azért írtam le, mert a kérdező a myisam->innodb átállásról kérdezett,
és ha ezt úgy intézi, hogy kiválasztja a másik táblatípust és kész ezzel átállt - akkor akár így is járhat :)