Grandistabulaphobia

Sau frica de tabele mari în bazele de date 🙂

Am tot auzit de separarea în sute sau mii de tabele a informatiilor dintr-o bază de date, în special pe mysql.

Am facut un mic experiment pe o bază de date (de producţie) pentru că am fost curios cât de reală este frica asta 🙂

Tabela are 20 de milioane de înregistrări şi ocupa 2Gb. Serverul este o maşină virtuală amărâtă cu 1 Gb de memorie alocată, 2 procesoare cu 650MHz alocat, load mediu de 0.6 la momentul testului.

Am făcut două queryuri pe un câmp cu cardinalitate 290 de mii (aproximativ 1.5%) iar rezultatele au fost aşa:

Pentru primul query, cu 6 rezultate, timpul a fost de 62ms.

Pentru al doilea, care a avut 38 de rezultate, timpul a fost de 52ms.

E departe de a fi super rapid, dar ţinând cont de maşina amărâtă, şi utilizarea foarte rară, e de bun simţ. Poate satisface 15-20 de cereri pe secundă.

Pentru un câmp cu cardinalitate 6 milioane, am obţinut timpi mai buni, pe undeva pe la 10-15 ms.

Pe tabelul respectiv, din păcate nu am primary key, deci nu am putut să fac un test pe o cheie unică.

Pe alt tabel, de 200 de mii de inregistrări, deci de 100 de ori mai mic, timpii pentru selecţia pe primary key a fost de la 10ms pana la 30 ms, deci tot pe acolo. O fi mare diferenţa daca tabela ar fi de 1000 de ori mai mare?

Dacă interesează pe cineva chestia asta, am să fac mai multe teste 😉

Anunțuri

~ de printfluke pe Septembrie 18, 2009.

4 răspunsuri to “Grandistabulaphobia”

  1. Presupunerea mea e ca timpul pt tabele mai mari creste exponential. 20mil/2Gb parcurs liniar are sens in <100ms. Dar un query join pe 5 tabele din astea nu va fi 500ms ci 5minute 🙂 I guess la fel si pt o tabela cu 1k mil/100Gb.
    Cred – habar n-am sincer. I'ts been 10 years since I did play this game.

  2. ce (R)DBMS? Ce OS? Primary Key-ul avea atasat un clustered index?

  3. Ideea e aceaşi pentru un join sau o singură tabelă: Cât de repede ajungi la randul care te interesează. Dacă să zicem separi tabela în 2, alegi tu din cod pe care să o foloseşti, în funcţie de cat de bine e scris codul, faci una sau mai multe operaţii, ei, dacă laşi informaţiile în acelaşi tabel, la grămadă, e posibil să meargă mai repede, ţinânđ cont că pe b-tree apar în plus doar două operaţii (comparare pe int) de făcut.

    Sunt într-adevăr nişte avantaje dacă separi datele, dar doar în cazul mysql cu tabele myisam: un update nu iţi blochează intreaga tabelă, ci doar aia pe care se face update. Alt avantaj (teoretic) ar fi dacă ai tabelele respective fiecare pe alt hard disk, scade timpul de acces pt. queryuri paralele. În practica asta se face cu tablespace (dar nu la mysql).

    Aici evident, banuiesc ca toti indecsii sunt încărcaţi complet în memorie, dar, în fine, chiar daca sunt separate tabelele, e fix acelaşi lucru.

  4. […] After 2 years, Hutchinson-Essar a joint venture between Hutchinson Whampoa and Essar group is following similar model by outsourcing their network Click https://twitter.com/moooker1

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

 
%d blogeri au apreciat asta: