InnoDB vs MyISAM - gyakorlatban
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...
■ 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...
tranzakció
InnoDB.
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.
nem kell..
okos tervezés megvan.. :)
"tranzakció kódból"
Üdv,
Felhő
Re: Tranzakció kódból
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?
feltétel az spben
Tárolt eljárá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 ...
Tárolt eljárások
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.
Saját szerver
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.
Pont nem
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.
nyilván
esélyek
fordítsd meg a gondolatot
Üdv,
Felhő
nem feltétlenül
Megéri?
írás olvasás aránya
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ő
és keverve?
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?
ennél azért bonyolultabb
Üdv,
Felhő
köszönom