ugrás a tartalomhoz

InnoDB vs MyISAM - gyakorlatban

Szekeres Gergő · 2008. Feb. 21. (Cs), 15.44
adott egy nagy méretű adatbázis, táblánként milliós nagyságrendű rekordokkal. Mit használnál?
innoDB vagy MyISAM táblatípust? Fő szempont a sebesség és az erőforrásigény. Az innoDB mellett szól a row-lock, mig a MyISAM csak table-lockot támogat. Ellenben MyISAM elméletileg gyorsabb... De valakinek van már tapasztalata erről? Vagy esetleg ha a gyakran írt/módosított táblák innoDBk, mig amiből leginkább lekérdezünk myISAM típusuak?

Kicsit hiányosnak érzem a mySQL manualt ezen a téren...
 
1

tranzakció

rrd · 2008. Feb. 21. (Cs), 18.02
nekem általában kisebb táblákkal van doglom, de többynire az alap MyISAM-ot használom, és azoknál a tábláknál ahol szükség van tranzakciókezelésre ott InnoDB-t.
2

InnoDB.

janoszen · 2008. Feb. 21. (Cs), 21.07
Az InnoDB egy csomó dolgot támogat, amit a MyISAM nem. Row-locking, tranzakciók, foreign keyek... a sebesség pedig csak marginálisan esik, nem vészes. Kérdés, hogy mire optimalizálsz. Ha egy szerverre vagy többre? Mekkora terhelésre?

Az alkalmazás okos tervezése is segíthet a terhelés csökkentésében, plusz a cache is nagyon sokat számít.
5

nem kell..

Szekeres Gergő · 2008. Feb. 22. (P), 13.45
nem kellenek extra funkciók, tranzakciók le vannak kezelve kódszinten back-trackkekkel, foregin keyre szintén nincs szükség. a row-locking az egyetlen, amiért elgondolkoztam az egészen. Egyenlőre egy szerverre optimalizálnánk, de ez még késöbb változhat...

okos tervezés megvan.. :)
6

"tranzakció kódból"

Hodicska Gergely · 2008. Feb. 22. (P), 23.02
Tranzakciókat nem fogsz tudni kód szinten kezelni. Még ha nagyon sokat kűzködsz, akkor talán a közelébe tudsz jutni annak, hogy ha hiba van, akkor visszagörgesd a már bevitt adatokat, de ez akkor is messze lesz egy ACID adatbáziskezelőtől. Egyrészt abszolút nem vagy védve attól, ha valamiért leáll a DB (hálózati para, gond van a géppel, bármi), más részt ott van még a párhuzamos tranzakciók kérdése: megfelelő izolációs szintet nem fogsz tudni biztosítani kódból.


Üdv,
Felhő
7

Re: Tranzakció kódból

Max Logan · 2008. Feb. 22. (P), 23.42
Ez a komment épp jókor jött.

Kicsit off következik:

Nos ezzel a kódból tranzakciót kezelni dologgal én is szembetalálkoztam, bár még nincsen kész, sőt neki sem álltam.

A szitu:

Adott egy modul, ami a jelszó kezelést valósítja meg. Van egy modell, és 3 controller, ami ugyanazt a modellt használja. Két modellnek egyforma az interface-e, ők történetesen a jelszó mentést és módosítást valósítják meg (előtte elvégzik a jelszó ellenőrzést, hogy megfelel-e az érvényben lévő jelszóházirendnek).

A jelszó mentés csak adminban lesz használva, míg a jelszó modosítás adminban és a felhasználói oldalon is szerepel (lévén, mind a felhasználó, mind az admin megváltoztathatja a jelszót).

A probléma akkor kezdődik, amikor az admin új felhasználót akar létrehozni. Ebben az esetben első körben el kell menteni a felhasználó adatait egy táblába, majd a jelszót és a hozzá kapcsolódó adatokat egy másik táblába. Ezt alap esetben egy MySQL tranzakcióval oldanám meg, de mivel a jelszó mentést külön modul végzi, ezért nem igazán kivitelezhető a natív tranzakciókezelés. Tehát célszerű lenne a felhasználó mentésekor kód szinten tranzakciókezelést megvalósítani.

Ezek szerint rossz nyomon járok?
11

feltétel az spben

Szekeres Gergő · 2008. Feb. 23. (Szo), 10.57
ha nem darabolod szét ennyire, hanem csak egyszerűen lefuttatsz egy tárolt eljárást mindkét esetben? amikor az admin ment egy flagnak 1-es értéket adsz, ha user akkor 0-át. az spben pedig egy feltétellel eldöntöd, hogy mentse-e a jelszót.. lehet php szintent nem annyira szép, de legalább hatékony.
13

Tárolt eljárás

Max Logan · 2008. Feb. 23. (Szo), 12.21
Jelenleg nincsen engedélyezve a tárhelyszolgáltatónál a tárolt eljárások létrehozása. Ha szépen beszélek a rendszergazdával talán engedélyezi (meg már gondolkodunk saját webserverben, de ez még nem eldöntött kérdés).

Szóval mit is kellene a tárolt eljárásba tennem?

Az egész elgondolásom azon alapult, hogy a jelszókezelést egy külön modul valósítsa meg, ergo bárhol felhasználható ez a modul.

Három fő részből áll (egyelőre), az egyik ellenőrzi, hogy a megadott jelszó egyezik-e az adatbázisban tárolttal, valamint megmondja, hogy lejárt-e a jelszó érvényességi ideje. A második a jelszó mentést végzi, a harmadik pedig a módosítást. A módosítás nem sokban különbözik a mentéstől, de ha a házirendben az előző jelszavak nem használhatók megszorítás él, akkor a lejárt jelszót el kell menteni egy táblába (itt ugye a jelszó ellenőrzés is kicsit más, mint az új jelszó mentésnél, mert adott esetben össze kell vetni a tárolt, lejárt jelszavakkal a megadott új jelszót, míg első jelszó esetén ennek nincsen értelme, mert nincsen még mivel összevetni).

Tehát a lényeg az lenne, hogy pl. a jelszó módosítás logikát ne kelljen a felhasználói résznél és az adminnál is megvalósítani. A felh. csak a jelszót tudja módosítani, de az admin a felhasználó minden adatát, aminek egy része a jelszó módosítása.

UpDate:

Átgondoltam egy kicsit a logikát és arra jutottam, hogy elvetem ezt a jelszókezelés modult, mert bár elméletben szépen hangzik, a gyakorlatban nem jó külön egységként kezelnem ...
16

Tárolt eljárások

janoszen · 2008. Feb. 24. (V), 19.11
Én nagyon szeretem a tárolt eljárások, csak ritkán nem tudok meglenni nélkülük. Ahhoz hogy működjenek, MySQL 5.0+ és MySQLi vagy PDO kell. Figyelned kell arra, hogy több result settel térnek vissza, tehát mindegyiket ki kell olvasnod, hogy ne legyenek belőle gondjaid.

A userkezelés egy nagyon jó dolog és értelme van szétválasztani. Maga az autentikálás nem eszik meg egy külön szervert (Hacsak nagyon sok usered nincs), érdemes lehet összekötni a sessionökkel (nem a session adatok tárolásával, hanem csak az élő session kezelésével).

Ha nagy méretekben gondolkozol, érdemes külön API-t csinálni, amit meglöksz, hogy hozzon létre egy új felhasználót és elhiszed neki, hogy azt csinálja amit szeretnél. Kicsit lassabb lesz, de nagyságrendekkel karbantarthatóbb.

Ami a tárolt eljárásokat illeti, még egy kitétel. Olyan szolgáltatót válassz, aki ad SSH hozzáférést, mert PHPMyAdminból tökéletesen elfelejthető a tárolt eljárások kezelése. Azt mondja magáról, hogy tudja, de random szívások vannak vele. Viszont ilyen hostot találsz szerintem egy párat.

Saját szerverrel csak óvatosan, mert tud munkaidőt enni a simogatása. Tavaly ősz óta üzemeltetek ilyet és igazából egy szerveres tételben aránytalanul sok munka van vele.
18

Saját szerver

Max Logan · 2008. Feb. 24. (V), 21.21
A saját szervert nem én konfigolnám, hanem kerítenék egy rendszergazdit aki ért hozzá. Előbb vagy utóbb mindenképpen az lesz a megoldás, mert már most olyan problémáink vannak, hogy a tárhelyszolgáltatónknak kicsi külföld felé a sávszélessége. Mivel pár héten belül egy szervert viszünk fel Pestre farmba, valószínű, hogy az mellé megy egy webserver is. Ez egyébként az adatok biztonsága miatt is indokolt.

Tárolt eljárásokkal eddig még nem volt dolgom, csak tudom, hogy lehet ilyet és hogy adott esetben gyorsabb mint ha PHP-ben oldanám meg a dolgokat. Ha lesz időm utánaolvasgatok a dolognak (és éppen most állok át MySQLi-re).

A userkezelésnél mit kellene szétválasztani? Jelenleg úgy oldom meg, hogy van egy login modul, ami használ egy session manager modult.
19

Pont nem

janoszen · 2008. Feb. 25. (H), 08.17
Ezek szerint nem mondtam el elég érthetően. Én arra gondoltam, hogy a user/session kezelést érdemes az alkalmazáslogikától elválasztani.

Ami a tárolt eljárásokat illeti, akkor lesz igazán gyors tőlük az alkalmazás, ha eleve úgy tervezed meg hogy kihasználja a tudásukat.

MySQLi-vel lehet érdemes próbálkozni, de ha jól mértük, a tárolt eljárásoknál a PDO nagyságrendekkel gyorsabb volt, ha van is néhány bugja.

A külföldi sávszél elég nagy probléma tud lenni, mindenkinek kevés. Ha fontos, érdemes külföldön venni egy root szervert (pl. Németországban egész normális áron lehet kapni gépbérletre) és a kettő között szinkronizálni a dolgokat.
9

nyilván

Szekeres Gergő · 2008. Feb. 23. (Szo), 10.49
de azért arra elég pici az esély, hogy a két query közötti 1/100 másodpercben szálljon el az adatbázis. amúgy jogos. viszont én körülbelül két helyen mentek egyszerre két táblába, maximum írok rá egy óránkénti crontabot, hogy ellenőrizze hogy mindkét táblában megvan-e a rekord, ha nincs majd beszúrja. (ezek pont nem annyira fontos adatok, ha elvesznek akkor sincs világvége. ezért nem áldoznék fel semmit a gyorsaságból).
12

esélyek

zila · 2008. Feb. 23. (Szo), 12.03
Pont ugyanannyi esélye van a db elhalálozásnak két query között mint bármikor máskor. Ilyen alapon a db soha nem száll el. A gyakorlatban persze bármikor elszállhat. Ez az egész tranzakciót kezelek kódban, meg crontabból korrigálok ha baj történne ronda maszatolás, ahelyett, hogy rendes adatbázist használnál. (pl. oracle-t, postgres-t, de akár mysql-t is tisztán innodb-vel) Csináltál teszteket, hogy mennyit nyersz/vesztesz az alkalmázás szintű tranzakciókezeléssel?
14

fordítsd meg a gondolatot

Hodicska Gergely · 2008. Feb. 23. (Szo), 18.13
Valamikor történik egy DB crash, folyamatosan jönnek a queryk (legalábbis gondolom, ha ennyire fontos a teljesítmény), pontosan annak nagyon kicsi az esélye, hogy ne egy "tranzakció" közepén legyél (hisz ezekből több van időben elcsúsztatva egymástól).


Üdv,
Felhő
15

nem feltétlenül

Szekeres Gergő · 2008. Feb. 24. (V), 16.50
lehet ilyen eset, de például nálam azokat a funkciókat, ahol tranzakciókezelés van, pont kevésbé használják. kb 100 queryből csupán 3-4 ilyen.
17

Megéri?

janoszen · 2008. Feb. 24. (V), 19.16
Kérdés, hogy megéri-e kockáztatni. Szerintem, egy nagyobb vas olcsóbb, mint az esetlegesen fellépő konkurencia-hibákból adódó random bugok kergetése (alias munkaidő-per-forint összegre).
3

írás olvasás aránya

Hodicska Gergely · 2008. Feb. 22. (P), 00.13
Talán a legfontosabb az írás és az olvasás aránya. A nagy könyv szerint ha bármelyik 10% alatt van, akkor érdemes lehet elgondolkodni MyISAM használatában. A MyISAM gyorsasága is relatív, InnoDB esetében az elsődleges kulcs egy clustered index, ami azt jelenti, hogy a tábla fizikailag e szerint van rendezve. Ezért egy elsődleges kulcs szerinti lookup az nagyon gyors tud lenni, vagy pl. egy e szerinti tartomány lekérdezése.

Szintén érdekes lehet, hogy bizonyos funkciókat csak a MyISAM ismer, pl. full text index, ha erre van szükséged, akkor kénytelen vagy ezt használni. Adott esetben játszhatsz olyat is, hogy a master DB az InnoDB, és ezt replikálod, de a replikán (vagy az egyik replikán) átállítod a tábla típusát MyISAM-re, és a kereséseket ezen hajtod végre.

Aztán ott van persze, hogy szeretnél-e tranzakciót kezelni, külső kulcsokat, ilyesmi. Itt pl. szintén lehet trükközni a replikációval. A master DB használod az InnoDB által nyújtott eszközöket, amikkel meg tudod őrizni az adatok konzisztenicáját, aztán a replikán már csak MyISAM, ami adott helyzetben tud gyorsabb lenni.


Üdv,
Felhő
4

és keverve?

Szekeres Gergő · 2008. Feb. 22. (P), 13.43
igazából az InnoDb funkcióira nincs szükségem(tranzakció stb), mint aholgy a full text indexre sem. Az alkalmazás nagyrészt kész van, pontosan tudom mely táblákba írnék, és melyek azok, amikből inkább csak olvasok.
Ugye az innoDB esetén az írás gyorsabb (row lock miatt), míg olvasni myIsamból érdemes. mi lenne, ha készítenék egy InnoDbs adatbázist, amibe csak írnék, majd ezt replikálnám egy myISAM táblakörnyezetbe, ahonnan pedig a select queryket futtatnám? Elméletileg ez lenne a leggyorsabb módszer(viszont nem tudom hogy a replikálás egyáltalán működik így, eddig csak teljesen megegyező táblák esetén használtam...).

Arra van valami tapasztalat, hogy egy több táblás lekérdezésben, ahol az egyikt tába InnoDB míg a másik MyISAM mennyire hatékony? Magyarul egy azon adatbázison belül mennyire érdemes "keverni" a táblatípusokat?
8

ennél azért bonyolultabb

Hodicska Gergely · 2008. Feb. 23. (Szo), 00.18
Ennyire azért nem egyszerű a dolog. Pl. ha egy táblát túlnyomó részt csak írsz (több mint 90%), akkor megintcsak jobban járhatsz egy MyISAM táblával, ugyanis a tábla végéhez tud úgy sort adni, hogy az nem lockol. Szintén nem feltétlenül igaz, hogy olvasás esetén gyorsabb a MyISAM, a clustered index (InnoDBnél ilyen a primary key szerinti index) adott esetben nagyon hasznos tud lenni. És vannak még finomságok, érdemes kísérletezgetni, utánaolvasni a témának. Ha van egy kis időd, akkor olvasd el a Pro Mysql című könyvet. Nem minden a táblatípus, sok apró fogás létezik, ami jól jöhet, ha teljesítményre van szükség.


Üdv,
Felhő
10

köszönom

Szekeres Gergő · 2008. Feb. 23. (Szo), 10.53
elolvasom feltétlenül!