Adrenalin\’s Blog

Martie 3, 2010

Despre MySQL, ce mi-aș zice dacă m-aș întoarce în timp vreo 5 ani în urmă

Filed under: experience, mysql, Unix — Adrenalin @ 15:19

Dînd cu nasu în același perete de multe ori, îți dai seama că dacă de la început făceai alt fel, îți ușurai cu mult viața.
Dar norocul vostru că ați dat de blogul meu, și cu mic succes veți avea mai mult timp pentru băut bere și nopțile vor fi dormite la călduț !

Așa deci:

  • Evitați triggerele, da ele sună bine în teorie, dar nici nu vă imaginați cît e de simplu de pierdut unul. Exemplu cînd faceți rename la un tabel, sau cînd recreați același tablou cu partiții, de fiecare dată trebuie să fiți atenți ca triggerele să fie și ele. Și dacă îl uitați, atunci va trebui de resincronizat totul. Plus la replicare, triggerele pot complica logica.
    Mult mai simplu de realizat triggerele la nivel de aplicație, plus că ele vor intra în funcție îndată ce faceți update la aplicație.
  • Evitați tabelele federate, iarăși sună bine în teorie cînd începeți să aveți mai mult de 1 bază de date, dar tabelele federate îs extrem de proaste și lente. Dacă serverul de la distanță cade, toate cererile spre tabelele federate vor bloca db-ul pînă la momentul cînd tot site-ul se va opri. Iar dacă faceți inserturi în tabele federate (nu dă domnul), foarte repede veți găsi incoerențe.
    Dacă vă trebuiește acces la datele de la distanță, utilizați replicarea datelor (nu uitați să monitorizați replicarea).
    De asemenea în mod normal, dacă de exemplu doriți să modificați date, trimiteți cererea de modificare la master, astfel și slave-ul vostru va avea datele.
  • Utilizați innodb, pentru tabele din care se face permanent read și write, asta trebuie să folosiți, uitați de myisam. Alocați mai mult ram la buffere și totul va zbura.
    În tinerețe utilizam myisam, și a trebuit niște timp pînă se îmi dau seama că e frînat, la modificări, myisam face table lock, astfel cererile concurente merg ca găina printr-o hudiță, pînă nu trece într-o direcție în direcția opusă nimeni nu se duce În innodb, citiți despre cheile primare clusterizate.
  • Replicarea master – master, iarăși sună bine în teorie, dar cel mai probabil simpla replicare master slave va fi suficientă. De asemenea învățați-vă aplicația să trimită update-urile la master și select-urile la slave.
  • Urmați principiul KISS, dacă se complică cel mai probabil nu faceți corect, cu cît e mai complicat, cu atît mai multe greble, cu cît mai multe greble, cu atît mai mare probabilitatea să dați în vreo una. Poate chiar în unele cazuri ceva va lucra puțin mai greu, dar dacă asta e simplu și intuitiv, atunci e calea corectă.
  • Nu utilizați versiuni beta în prod chiar dacă pare că are mega facilități. Softul complex cu reviziuni majore ieșit mai puțin de un an în urmă cel mai probabil încă e cu buguri și nu a fost bine testat. Defapt mie îmi place să utilizez cel mai recent soft și chiar să raportez bugurile (am raportate pentru mysql5.1), dar trebui de avut infrastructura bine pusă la punct pentru ați permite jocurile, alt fel jocul se transformă într-un coșmar ;)

Iată dacă știam din start despre aceste chestii, probabil mi-ar fi salvat tone de timp și energie.
Cînd mi-am început aventura cu bazele de date, aveam un singur server care avea totul pe el, și așa cum site-ul era în creștere permanentă, bani de server mai puternic nu era (la moment și cela care era îmi părea scump), pasiunea și dorința era enormă, de aceea tot ce-mi trăsnea prin cap încercam, prioritatea era viteza cu orice preț.

La moment dacă aș începe de la 0 posibil în genere aș încerca ceva care necesită mai puțin maintenance în cazurile cînd are loc căderi de electricitate (posibil chiar și ceva nosql ca Cassandra care singur scalează și e redundantă în caz de cade vreun node), probabil înafară de viteză asta ar fi unul din primii factori de decizie. Softurile care le pui și nu mai cer atenție, sau ft mică, autorilor lor trebuie de pus monumente, dar bazele de date îs extrem de fragile dacă compar cu alte genuri de softuri..
Nici nu vă imaginați de cîte ori am avut tabele corupte, replicare care trebuie reinițializată pe slave-uri.

Aceste au fost niște sfaturi generale care mai greu veți găsi în primele pagini de cărți,docuri,bloguri de mysql, învățați pe greșelile mele :)

Anunțuri

3 comentarii »

  1. La primul punct as putea spune ca problema nu e in trigger si in logica gestionarii acestuia.

    Ce nu-i permite autorului SGBD’ului sa treaca prin lista de triggere de fiecare data cind se redenumeste un tabel, si sa-i arate omului un warning in care se spune ca „don’t forget to review your triggers”, sau – sa actualizeze instructiunile din trigger automat?

    Ultimele 2 puncte le sustin, restul sunt in afara competentei mele- niciodata nu m-am ciocnit cu situatii in care MySQL cu ‘out of the box settings’ sa-mi strice toate planurile :-)

    Comentariu de Alex — Iulie 15, 2010 @ 22:19

  2. si in logica -> ci in logica
    :-)

    Comentariu de Alex — Iulie 15, 2010 @ 22:22

  3. Hei thanks p/u comment ;-)
    Totusi cu triggerele, eu as prefera sa pastrez toata logica in aplicatie, db-ul sa fie numai p/u stocare/selectare ;-)
    Eu utilizam triggerele ex p/u counterul nr de mesaje a unui utilizator. Citeodata cind faceam ceva mahinatii (ceva joc cu datele), counterele puteau sa-si iasa din minti ;-) Si plus in mysql nu-i nici un mod usor de stins triggerele.
    Deah eu am avut niste epopei ft serioase cu mysql-ul ;-)

    Comentariu de Adrenalin — Iulie 15, 2010 @ 23:13


RSS feed for comments on this post. TrackBack URI

Lasă un răspuns

Completează mai jos detaliile tale sau dă clic pe un icon pentru a te autentifica:

Logo WordPress.com

Comentezi folosind contul tău WordPress.com. Dezautentificare / Schimbă )

Poză Twitter

Comentezi folosind contul tău Twitter. Dezautentificare / Schimbă )

Fotografie Facebook

Comentezi folosind contul tău Facebook. Dezautentificare / Schimbă )

Fotografie Google+

Comentezi folosind contul tău Google+. Dezautentificare / Schimbă )

Conectare la %s

Creează un sit web gratuit sau un blog la WordPress.com.

%d blogeri au apreciat asta: