MySql használhatósága
2003-09-04T11:53:15+02:00
2003-09-22T11:53:55+02:00
2022-06-29T08:25:31+02:00
  • Bocs, de eltévesztetted a házszámot.

    Az állítások nem az én állításaim, hanem ebben a topicban találtam őket, és épp hogy cáfolom.

    A 2. témánál (cache) én NEM kliens hanem szerver oldali cache-ről írtam, az rdbms-be beépítve. (statement cache, library cache).

    Legközelebb olvass figyelmesebben!

    Egyébként amit írtál, azzal egyetértek,csak nem jó emberkének címezted.

    Üdv:

    Okarika
    Mutasd a teljes hozzászólást!
  • Egyetértek...

    Amin most dolgozom, ott is használok vagy 150 TADOStoredProc komponenst. TADOQuery-t egyet sem :)
    Mutasd a teljes hozzászólást!
  • Ha az ember egyébként igazán profi adatbázist csinál, akkor úgysem engedi meg a klienseknek, hogy azok tábla- és rekordszinten manipulálják az adatokat, hanem kizárólag szigorúan ellenőrzött utakon, tárolj eljárásokon keresztül teszi lehetővé a hozzáférést (természetesen az alkalmazási logika egy részét is bevonva így az adatbázisba).


    Azt hiszem ennel jobban ezt meg sem lehet fogalmazni. Amig egyetlen select is bent figyel a programkodban, addig azt a megoldast nem lehet komolyan venni (persze nem pityuka vendegkonyve szintu alkalmazasokrol beszelek).

    netchan
    Mutasd a teljes hozzászólást!
  • 1. "Join a kliensen"
    Állítás: Nem lasabb, mint a szerveren, és egy gigabites háló esetén a sávszélesség se gond. Csak akkor O.K. a szerver használata, ha az lényegesen erősebb mint a kliens.

    Ez így általánosságban nem igaz, sőt, az esetek többségében sem.

    Ha az eredményhalmazban a join-olt mezők összes - az adatbázisban tárolt - értéke megjelenik akkor talán gyorsabb is lehet a kliens oldalról a táblák külön-külön felolvasasása és utólagos összefésülése, hiszen ilyenkor általában jelentős sávszélesség spórolható meg azzal, hogy elég csak a kulcsértékeket beolvasni minden rekordban, és az ismétlődő, és általában hosszabb join-olt mezőket nem kell a hálózaton újra és újra átpaszírozni.

    Az esetek legnagyobb részében azonban komoly rendszerekben ezek a feltételek nem igazak. Akkor meg egyértelműen gyorsabb a szerveroldali join. És akkor még ráadásul csak right/left joinokról beszéltünk, mert pl. inner join kliens oldalon csakis egy csomó "felesleges" adat áthozatala, azaz jelentős overhead mellett szimulálható.

    Ha nem a teljes eredményhalmazt kérdezi le az ember akkor ez még inkább igaz, és pl. egy joinolt mező alapján történő rendezéssel kombinálva (mármint azt, hogy pl. csak a 100-200. sorokra vagyok kíváncsi az eredményhalmazból) ez hatványozottan igaz.

    A fentiektől függetlenül is minden leválogatás, szűrés, feldolgozás az alkalmazási logikába átemelése rontja az adatbáziskezelő esélyét arra, hogy statisztikai vagy optimalizációs alapokon nyugvó beépített gyorsítási technikáit alkalmazza. Modern SQL rendszerek esetén pedig bizony már nagyon pengén működnek az optimalizálók.

    2: ha ugyanazt kérdezik a kliensek (és ez bizony a terhelés meglepően magas százaléka.) a második kiszolgálása gyorsabb cache-ből. (mármint a kérdést és eredményét tartalmazó cache-ből)

    Nagyon kevés életszerű feladat van ahol megengedhető az, hogy a kliensek saját cache-ből dolgozzanak, és ne a szerveren lévő "élő" adatokat kérjék le. Minden ilyen technológia súlyosan sérti az adatbázis integritását, hiszen annak egy részét kihelyezi az ezt biztosító adatbáziskezelő rendszer felügyelete alól. Ez pedig komoly adatvesztésekhez és sérülésekhez vezethet.


    Ha az ember egyébként igazán profi adatbázist csinál, akkor úgysem engedi meg a klienseknek, hogy azok tábla- és rekordszinten manipulálják az adatokat, hanem kizárólag szigorúan ellenőrzött utakon, tárolj eljárásokon keresztül teszi lehetővé a hozzáférést (természetesen az alkalmazási logika egy részét is bevonva így az adatbázisba).

    Erre azért van szükség, hogy a kliens akár szándékos akár véletlen hiba következtében ne állíthasson elő az alkalmazási logika szintjén inkonzisztens/ellentmondásos adatállapotokat. (Pl. ne tehesse meg, hogy egy számlarekordot eltárol, de közben nem csökkenti a készlet táblában a megfelelő mezőértékeket - amit ugye tábla-/rekordszintű elérés esetén bármikor megtehetne.) Persze ennek a megoldásnak az alkalmazás rétegezettségére, és így portábilitására is pozitív hatása van - bár általában nem ez a cél.

    Ezek esetében azonban értelemszerűen fel sem merülhet semmilyen kliensoldali helyettesítő válogatás lehetősége, hiszen már eleve nem bír a szóban forgó oldal közvetlen hozzáféréssel a legyűjtés alapjául szolgáló halmazokhoz, táblákhoz.

    Na, pl. ezért sem alkalmas a MySQL adatbáziskezelésre (mert nem lehet benne tárolt eljárásokat definiálni).
    Mutasd a teljes hozzászólást!
  • Gyerekek, valaki nézte már, hogy mikor írt ide utoljára a kérdés feltevője?

    Pár érdekes dologra azért én is reflektálnék, hadd legyen több betű itten.

    1. "Join a kliensen"
    Állítás: Nem lasabb, mint a szerveren, és egy gigabites háló esetén a sávszélesség se gond. Csak akkor O.K. a szerver használata, ha az lényegesen erősebb mint a kliens.

    Válaszom: 2 esetben van gond. 1: Ha 1000 kliens terheli 100 megabittel a szervert, akkor az már összesen hány gigabit?
    2: ha ugyanazt kérdezik a kliensek (és ez bizony a terhelés meglepően magas százaléka.) a második kiszolgálása gyorsabb cache-ből. (mármint a kérdést és eredményét tartalmazó cache-ből)

    2: x adatbáziskezelő jobb mint y

    válaszom: Ez nem ilyen egyszerű. nagyon sok kérdést kell ahhoz megvizsgálni, hogy eldönthesd, melyik a neked való adatbáziskezelő. ilyen kérdések pl:

    Hány kliens lesz?

    Mekkora lesz az adatbázis?

    Milyen jellegű lesz az adatbázis:
    (OLTP <-> Data mining)

    Milyen bonyolultságú lesz az adatbázis.?
    egy bonyolultság felett az adatbázisba építhető üzleti logika (triggerek, constraint-ek, tárolt fv-ek, job-ok, "élő" view-k) hihetetlenül fontossá válhat.

    Mit ismersz?

    Mennyi időd van?

    Mit támogat (jobban) a fejlesztőeszközöd?

    Mennyi pénzed van?

    Kell-e támogatás?

    Van-e hozzá szakember, aki üzemeltesse?



    Másik teljesítmény szempontjából fontos dolog: Ma Magyarországon azt tanítják kivétel nélkül minden iskolában, hogy te írjál minél furmányosabb sql-t, hogy ne a programodban kelljen join-okkal, sort-okkal szórakoznod, hiszen annál gyorsabban fogsz haladni, ha ezeket a dbms csinálja meg helyetted. Ez alapvető és nagy hiba. Igenis tudnod kell, hogy mi fog történni a selecteddel az adatbázisban. Ha nem tudod, bonyolult, szép selecteket fogsz írni, és aztán csodálkozol, hogy milyen lassan futnak le.
    Én adatbázis hangolással foglalkozom, és látom hogy egy adatbázis teljesítmény gondjai 20-30 százalékban fakadnak a rossz beállításokból. A többi rész a hihetetlenül amatőr módon megírt selectekből fakad. A legnagyobb, és irdatlanul profinak számító cégeknél is bűn rossz selecteket írnak a programozók. Nem azért mert hülyék, hanem mert fogalmuk sincs, hogy mi fog a selectjükkel történni.

    Na többévi mérgemet kiírtam magamból. :)
    Mutasd a teljes hozzászólást!
  • A kedvencemre. A SapDB-re
    Mutasd a teljes hozzászólást!
  • Itt konkrétan mire gondolsz?
    Mutasd a teljes hozzászólást!
  • Sőt! Még néhány fizetősnél is van jobb az ingyen kategóriában....
    Mutasd a teljes hozzászólást!
  • Hát a leírásod alapján azért ez elég messze van egy fürtözött MSSQL-től :)


    A lényeg az, hogy több gépen fut az adatbázis, ezek gyakorlatilag szinkronban vannak. Megy közöttük a terheléseloszlás, és nincs probléma ha lehúzod az egyik szervert a hálóról...


    Meg aztán vannak többfázisú tranzakciók is :)


    Ettől függetlenül: használható dolog az a MySQL, de véleményem szerint túl van favorizálva egy picit. Vannak nála sokkal jobb adatbáziskezelők még az ingyenes kategóriában is. A fizetősökről nem is beszélve...
    Mutasd a teljes hozzászólást!
  • Vegigolvastam az egeszet. Allitasod szerint ha korlatlan savszelesseget feltetelezunk, akkor gyorsabb lesz, ha programbol csinalsz join-t/szurest -azaz letoltod a tablakat tombokbe, es ciklussal vegzed el a muveleteket -, mintha ezt az SQL szerver csinalna, es ebbol a szempontbol "Tök mindegy hány táblát kell összekapcsolni".

    Ha jol ertelmeztem a dolgot, akkor tovabbra is fenntartom az allitasom (es ez eleg egyszeruen ellenorizheto), ha felreertettem (es ugy latom nem egyedul), akkor sorry, kifejthetned bovebben.

    Fikazasrol szo nem volt, egyszeruen az a velemenyem, hogy minimalis adatbazisos fejlesztes utan egy ilyen kijelentes legalabbis fura.

    netchan
    Mutasd a teljes hozzászólást!
  • Ne kapd föl a vizet. Nem érdemes. Mindannyian tanulunk. Itt is..

    Mutasd a teljes hozzászólást!
  • Elolvastad részletesen amit irtam? Vagy csak kiragadtál egy részt a szöveg környezetből és arra mutogatsz, hogy nem ért hozzá, nem ért hozzá. Ez ujság iró mentalitás.

    Ilyen formán én is tudok kötekedni.
    CSak nem ez a szándékom. Nem kötekedni jöttem, hanem kérdezősködni esetleg tanulni nem a másikat fikázni.
    (Minden ember holtig tanul.)
    Én a tapasztalataimat irom, nem azt amit elméletben nyomnak, hogy ez minden esetben igaz, mert ezt nagy okosok igy találták ki. Persze van ahol igaz, de van ahol nem. Ha nem hiszed akkor sajnálom.
    Mutasd a teljes hozzászólást!

  • Ez csak elméleti megközelités, a gyakorlatban ez közel sincs igy. Nem a sebesség a probléma, hanem a hállózati forgalom. Sebességben talán még gyorsabb is ha a kliens válogat.


    Kezdem azt hinni, hogy Te meg nem irtal adatbazisos programot.

    netchan
    Mutasd a teljes hozzászólást!
  • Nem a sebesség a probléma, hanem a hállózati forgalom.

    Én sem másról beszéltem. A sebesség alatt nyilvánvalóan a teljes rendszer működési sebessége értendő. Ebben pedig a merevlemeztől kezdve a hálózaton át a megjelenítésig minden benne van.
    Mutasd a teljes hozzászólást!
  • "lehetőség van van hotstandby adatbázisok létrehozására is. (nem MySQL-el természetesen)"

    Azt hiszem Mysql-en is lehetőség van rá. Master slave-nek hívják, a driverbe be van építve, hogy magától átkapcsoljon. Valamit ügyködtek, hogy hot is legyen a master-slave átváltás, de ezeket csak a changelogokból tudom.

    Egyébként a FAT is két példányban van a vinyón, nekem mégis elment. Igaz előző nap backupoltam.
    Mutasd a teljes hozzászólást!
  • Csak már látnám. Sír a szivem, hogy itt egy tuti adatbáziskezelő, amit mindenki használhatna (GPL) és nem...és nem...

    pedig nálunk van néhány produktív rendszer alatta. Némelyik 100 GB-nál is kicsinkét nagyobb és több mint 20000 adatbázisobjektum van benne...

    Kaptok még egy kis infót.
    Szóval a jelenlegi weblap: 416 Requested Range Not Satisfiable Innen le is lehet tölteni. A jövőben a http://www.maysql.com/maxdb alatt lesz található. 2004 Május 1 ig, nini ekkor leszünk EU , szóval eddig letölthető marad a mysql lapjáról a 7.3 és a 7.4-es SapDB utána csak a MaxDB. Persze nem kell félni, mert én kiteszem az akkori archivot majd. Megkérdeztem, nincs ellene kifogása a Sap-nak.
    Mutasd a teljes hozzászólást!
  • Megnéztem nektek, mert látom, hogy mindenkit feszít a kérdés erősen, hogy hogyan is fogják hívni a SapDB-t MySql-ül.

    Tehát a "rebranding" után MySQL MaxDB lesz az neve.

    Mutasd a teljes hozzászólást!
  • No majd kipróbáljuk kritikus szemmel is.
    Mutasd a teljes hozzászólást!
  • Bocsi, de a "ha elmegy a filerendszer"-hez bárotkodtam megjegyzést fűzni. Az online log minden esetben külön disken tárolandó és általában (default) legalább két példányban. Tehát ebben az esetben a gond akkor kezdődik, ha lehal a filesystem, ahol az adatfile-ok vannak, plusz ahol az első onlinelogok, plusz ahol a másolt onlinelogok.... Ez azért nagyon valószínűtlen. De ha ez a helyzet és az alkalmazás valóban kritikus, lehetőség van hotstandby adatbázisok létrehozására is. (nem MySQL-el természetesen ) ami kompletten másik gép, akár a föld túloldalán, mégis az utolsó online-logfile ig (ami már archiválva lett természetesen, tehát nem az aktuálisan nyitott) meglesznek az adataid. Mitöbb kvázi azonnal.

    Mindez megy a SapDB-vel is. És ingyenes, és letölthető, és nemsokára MySQL-nek fogják hívni, mint azt már számtalanszor említettem
    Mutasd a teljes hozzászólást!
  • ezt meg tudom erősíteni, jópár éve volt, (ma már) kisgépen a ms access, ami hálózaton keresztül éri el a adatbázisfájlt, magyarul mindent a kilens csinál, minden tekintetben sokkal gyorsabb volt mint a ms sql szerver (és nem azért mert az sql szerver önmagában ne fért volna a memóriába).

    Ma már ez persze túlzás, egy mai kis pc is rengeted adatot memóriában tud tartani. De az is abszolút túlzás, hogy a mysql-nél a kilensnek kellene szűrni.
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • Direkt csillagok közé raktam, hogy NEMTRANZAKCIÓS táblák. Mi kell még, bold italic h1?
    Mutasd a teljes hozzászólást!
  • Elméletben ez megint csak igaz, de a szerver nem 1 embert szolgál ki, és PC alapú szerverek esetén a szerver nem sokkal erősebb mint a kliens PC. Sok esetben még jóval gyengébb is. Ilyenkor gyorsulás lesz a végeredmény

    A Jon nem befolyásolja. Tök mindegy hány táblát kell összekapcsolni. Ez a hállózati forgalmat növeli meg inkább.
    De gigabites hállón ez nem gond
    100-as hállón már érdekesebb, de ott sem jelentős a dolog.

    De kérlek olvasd el ujra mit irtam, mert felületesen értelmezted.
    Senki nem mondta hogy butaság lenne a Kliens- server architektúra. Többek között én sem irtam. De ez igazán nagy szerverek esetén jótékony. Elég sok nagy szerverrel dolgoztam, és ott gyorsabb, de kis PC alapúaknál egy egy komolyabb lekérdezés megfekteti a szervert, a többi júzer meg malmozik.
    Mert a gépen homokóra látszik
    Mutasd a teljes hozzászólást!
  • Tisztességes adatbáziskezelő pedig veszi az online logokat és szépen előregörget az utolsó logolt tranzakcióig, majd fisszavonja (rollback) a nem commitoltakat és készenvan. Amiket vesztettél azok a nem commitolt tranzakciók, de az érintett táblák is logikailag konzisztensek maradnak a rollback miatt. Na ez az, ami ha nincs meg egy adatbáziskeresőben, akkor kritikus alkalmazásokban szerintem nem alkalmazható.
    Mutasd a teljes hozzászólást!
  • Nemáááá....

    mondjuk, ha két bazinagy táblát kell joint-olnod úgy, hogy a végeredmény néhány sor lesz. Képzeld csak el mekkora forgalmat csinál, ha a teljes táblákat le kell tölteni a kliensedre, ott beletuszakolni a memóriába, és kiszedni azt a néhány használható sort. Nem gyorsabb, ha a lokális diskről a lokális memóriába megy a zacc és te csak az eredményt kapod??? És ha még megspékeled azzal, hogy neaggggyisten egy konkurens lúzer ugyanezt a melót akarja elvégeztetni. Nem gyorsabb, ha az adatbázis cahce-ében benne vagyon már és nem is kell mégegy full tablescan??? Szóval a kliens-szerver architektúra nem butaság....
    Mutasd a teljes hozzászólást!
  • nem forszírozom a mysql-t, már csak azért se, mert semmi tapasztalatom nincs a mysql tranzakciós tábláival.

    Áramszünetnél a *nemtranzakciós* táblákban meg szokott sérülni az a rekord, amelyiket éppen ír, ez nálunk is van, mondjuk évente egyszer. De olyan hogy az egész tábla elveszne gyakrolatilag kizárt. (Ha elmegy a fájlrendszer akkor nyilván nincs mit tennie, de ez bármilyen adatbáziskezelőre igaz.) Ilyenkor nálunk eddig két dolog történt, vagy az egész táblát nem lehetett olvasni, vagy csak azt az egy rekordot. Van egy repair utility a mysql-ben, ami megjavítja, azt kell áramszünet után használni.
    Mutasd a teljes hozzászólást!
  • " -összetett lekérdezése, legyűjtések esetén a válogatási feladat legnagyobb része a kliens oldalra hárul, ami akár nagyságrendekkel lassabb működést eredményezhet a szerveroldali válogatásnál."

    Ez csak elméleti megközelités, a gyakorlatban ez közel sincs igy. Nem a sebesség a probléma, hanem a hállózati forgalom. Sebességben talán még gyorsabb is ha a kliens válogat.
    Ezeket nem mértem, de ilyen esetben soha nem csökent az alkalmazások sebessége.
    Igaz ez Progress

    Ez aKliens szerver el van miszifikálva. Semmi bajom vele, de attól hogy valamit aszerver csinál, közel sem biztos hogy gyorsabb lesz. Pláne ahol a Szerver egy PC, megtámogatva szerver feeeelingel.
    Értem ezalatt az 1 procis gépeket.
    Ezesetben nekem van igazam.
    Ha viszont a szerver komolyab gép, akkor már nincs igazam.
    Mutasd a teljes hozzászólást!
  • Ha te mondod
    Én nem ismertem, és most sem ismerem, de adatvesztést nem engedhetek meg semmilyen körülmények között.
    pl lehal a szerver.
    Itt az irodában az egyik kollégámnak valakik alkotak egy JAVA -s progit. MySQL adatbázisra. CSak épp lehalt a gép amin futott a progi. Csak annyi bibi volt, hogy az adatbázisa megsérült, és többet az életben nem sikerült kinyerni semilyen adatot. Pedig egy norml áram szünet volt, még csak a programot tesztelték egy normál pc -n. De ha már a teszt alatt elhalt alólla a DB az elég gáz.
    Mutasd a teljes hozzászólást!
  • A 3-as MySQL-ben is volt tranzakciókezelés, már jónéhány éve.
    Mutasd a teljes hozzászólást!
  • Az új 4.x-es MySQL-ben már van tranzakciókezelés (bár kérdés, hogy a gyakorlatban milyen hatása van a teljesítményre), szóval nem ez a legnagyobb hátránya. A tárolt eljárások és a triggerek, a hivatkozási integritás (bár utóbbi a 3.x-es széria utolsó darabjaiban már megjelent), valamint az összetett SQL szerkezetek, mint pl. view-k, és hasonlók támogatása nélkül viszont ettől még egy fapados rekordmenedszer. A szóban forgó paradigmák nélkül ugyanis
    - nem garantálható az adatok integritása az adatbázis szintjén
    - nem garantálható az adatok biztonsága/integritása az alkalmazási logika szitjén
    - nem szervezhető át az adatbázis belső működése az alkalmazások módosítása nélkül
    - összetett lekérdezése, legyűjtések esetén a válogatási feladat legnagyobb része a kliens oldalra hárul, ami akár nagyságrendekkel lassabb működést eredményezhet a szerveroldali válogatásnál.

    Ezért mondják, hogy a soros olvasásnál és rekordszintű visszakeresésénél a MySQL valóban gyors, de ha már valóban adatbázist kell kezelni, akkor mind összsebesség, mind megbízhatóság, mind karbantarthatóság szempontjából egyértelműen hátrányban van gyakorlatilag minden más adatbáziskezelő rendszerrel szemben.
    Mutasd a teljes hozzászólást!
abcd