Sistemul TPC-C de evaluare a performantelor bazelor de date

Daniel Popeanga

 

 

 

Abstract: Testele sunt instrumente vitale in evaluarea performantelor sistemelor de gestiune baze de date relationale.

Fiind un sistem on-line de testare a capacitatii de procesare a tranzactiilor, TPC-C simuleaza un mediu complet, unde un numar de operatori de terminale executa o serie de tranzatii asupra unei baze de date. Testul este centrat in jurul activitatilor centrale (tranzactii) ale unui mediu de introducere a cererilor.

In lucrarea de fata voi prezenta, intr-o prima parte, o analiza efectuata asupra unor elemente de evaluare a performantelor bazelor de date, folosind standardul TPC, descriind, in partea secunda, un numar de rezultate experimentale comentate. Printre sistemele de gestiune a bazelor de date folosite in experimente, vor fi prezentate rezultate obtinute pentru Microsoft SQL Server si Microsoft Access

Cuvinte cheie: TPC-C, evaluarea performantelor bazelor de date, sistem de gestiune a bazelor de date, tranzactie, Oracle, Microsoft Access

 

 

1. Introducere

a. Sisteme de gestiune a bazelor de date

În ultimii ani tehnologiile bazelor de date au devenit tot mai complexe, integrând tot mai multe concepte din alte domenii. Este uşor de înţeles faptul că bazele de date joacă în prezent un rol important în multe domenii în care calculatoarele sunt utilizate.

O bază de date relaţională este o colecţie de date relaţionale. Prin date se înţeleg valori ce pot fi stocate şi care au semnificaţie implicită. Mai mult, o bază de date este o colecţie centralizată de date organizate în scopul optimizării

prelucrării acestora în contextul unui set dat de aplicaţii. Se pot ataşa unei baze de date următoarele proprietăţi implicite:

o bază de date este o colecţie logică coerentă de date ce are cel puţin un înţeles

baza de date este destinată, construită şi populată cu date despre un domeniu bine precizat. Ea are un grup inerent de utilizatori şi se adresează unui anumit grup de solicitanţi

o bază de date reprezintă câteva aspecte ale lumii reale, creând orizontul propriu. Schimbările orizontului sunt reflectate în baza de date

O bază de date poate fi de diverse mărimi şi diverse complexităţi, putând fi generată şi menţinută manual sau cu ajutorul programelor utilitare. Sistemul de gestiune a bazei de date (SGBD), însă, este reprezentat de colecţia programelor ce ajută utilizatorul să creeze şi să întreţină baza de date.

SGBD este, deci, un sistem general de programe, ce facilitează procesul definirii, construcţiei şi manipulării datelor pentru diverse aplicaţii.

Definirea bazei de date presupune specificarea tipurilor de date ce vor fi stocate în baza de date, precum şi descrierea detaliată a fiecărui tip de date. Construcţia bazei de date este procesul stocării datelor însele, pe mediul controlat prin SGBD.

Prin manipulare se întelege o serie de funcţii ce facilitează implementarea cererilor pentru găsirea unei date specificate, adăugarea de noi date ce reflectă modificarea lumii reale, generarea diverselor rapoarte despre date. Se remarcă faptul că nu este imperios necesar un sistem de programe general SGBD, el putând fi înlocuit cu programe specifice, creând astfel un SGBD specific.

Există o serie de caracteristici specifice bazelor de date faţă de alte programe tradiţionale chiar dacă toate opereaza cu fişiere.

În prelucrarea tradiţională a fişierelor fiecare utilizator implementează fişierele necesare propriei aplicaţii. Este posibil ca doi utilizatori să creeze fişiere organizate diferit, chiar dacă manipulează aceleaşi date. În această situaţie utilizatorii folosesc propriile fişiere, fapt ce duce la creşterea redundanţei reprezentării datelor, şi deci la spaţiu de stocare ineficient ocupat. Într-o bază de date o singură structură de date este stocată, dar este folosită de către toţi utilizatorii.

Voi prezenta în cele ce urmează câteva caracteristici ale bazelor de date.

O caracteristică importantă a bazelor de date este aceea că pot conţine pe lângă datele propriu-zise şi definiţii sau descrieri. Definiţiile sunt stocate în catalogul

sistemului şi conţin informaţii despre structura fiecărui fişier, tipul şi formatul de stocare a fiecărei date, diverse restricţii referitoare la date.

Informaţiile stocate în cataloage sunt numite meta-date şi descriu structura bazei de date primare. Catalogul este utilizat de SGBD şi numai în mod ocazional de utilizator, atunci când solicită informaţii despre structura bazei de date.

De asemeni trebuie menţionat şi faptul că într-o bază de date software-ul SGBD nu este scris pentru o aplicaţie specifică, deci, este nevoie de catalog pentru a se cunoaşte structura fişierelor în baza de date specificată, precum şi formatul datelor din aceste fişiere. SGBD trebuie să lucreze şa fel de bine în orice tip de aplicaţii.

În plus, mai trebuie remarcat faptul că SGBD face ca utilizatorul să utilizeze o reprezentare conceptuală a datelor fără să includă nici un detaliu asupra modului în care acestea sunt stocate. Se defineşte modelul datelor ca un mod de abstractizare a datelor ce este utilizat pentru reprezentarea conceptuală. Modelul datelor utilizează concepte logice despre obiecte, proprietăţile lor, relaţiile dintre el. Se poate spune, astfel, că detaliile de reprezentare sunt neesenţiale dacă referirea la date se poate face direct prin numele acestora.

În ultimul deceniu s-a impus necesitatea evidentă a unor SGBD multi-utilizator, unde mai mulţi utilizatori au acces la date în acelaşi moment. Astfel, este esenţial ca datele pentru aplicaţii multiple să fie integrate şi menţinute în aceeaşi bază de date. Evident, apare necesitatea ca SGBD să încorporeze programe ce asigură controlul concurenţei. De asemeni, tot el va trebui să asigure accesul în mod autorizat la datele bazei, numai unii dintre utilizatorii sistemului putând avea acces la toate datele.

Întrucât diferite categorii de utilizatori au cunoştinţe diferite în utilizarea bazelor de date, SGBD facilitează aceasta printr-o varietate de intefeţe utilizator. Aceste tipuri de interfeţe includ interpretoare de cereri, limbaje de programare pentru programele de aplicaţii, interfeţe sub forma de meniuri pentru utilizatorii nespecializaţi, interfeţe de limbaje naturale.

Cele mai multe sisteme informatice cu baze de date asugură restricţii de integritate a datelor, cum ar fi de exemplu numărul de caractere, domeniul de definire al numerelor, şamd…

O altă caracteristică importantă al sistemelor informatice cu baze de date este aceea a asigurarii facilităţii de back-up, adică de refacere la defectările hardware şi software. Dacă sistemul se defectează în timpul operaţiei de reactualizare de date dintr-un fişier, este reţinut fişierul în forma pe care o avea înainte de operaţie, prin creerea copiei acestuia.

În continuare voi prezenta o serie de avantaje ale utilizării sistemelor cu bazelor de date:

facilitarea şi grăbirea standardizării, datorită cooperării largi între diverse departamente, colective de proiectare, utilizatori, şamd… Prin standard se înţelege numele şi formatul datelor, formatul afişării, terminologie, etc…

flexibilitatea marcată prin posibilitatea modificării structurii bazei de date fără a fi necesară modificarea programelor de aplicaţie

reducerea timpului de dezvoltare a aplicaţiilor, deoarece descrierea şi implementarea unei noi baze de date cere mai puţin timp decât cel aferent dezvoltării unor programe particulare, acest timp fiind estimat ca de la ¼ până la 1/6, în principal datorită SGBD şi a interfeţei om-maşină

facilitatea reactualizării ca urmare a adăugării de noi date sau a modificării structurii datelor existente

economia spaţiului de stocare, consecinţă a structurării datelor existente

Deşi, la ora actuală sistemele informatice cu baze de date devin tot mai complexe, fiind în plină expansiune a pieţei (aproape 30% din vânzările mondiale de tehnică de calcul sunt vânzări de sisteme cu baze de date), nu se poate spune că există o maturitate deplină a domeniului.

Există multe probleme nerezolvate, unele dintre ele foarte simple ca concept, dar foarte greu de realizat în practică. Soluţia care s-a conturat în ultimii ani a fost integrarea în acest domeniu a conceptelor importate din alte domenii conexe, cum ar fi inteligenţa artificială, reţele neurale, tehnici orientate obiect, internet, şi exemplele ar putea continua.

Acest lucru demonstrează faptul că domeniul sistemelor cu baze de date este unul deosebit de complex, intr-o plină expansiune, şi în curând s-ar putea să asistăm la noi modificări ale conceptelor fundamentale ale bazelor de date, tocmai pentru a veni în sprijinul cerinţelor tot mai complexe ale pieţei.

Pe plan modial, se pune tot mai mult problema accelerarii, creării sau perfectionarii sistemelor de gestiune de baze de date, cat si a bazelor de date insesi. Astfel se cauta noi metode de evaluare a performantelor bazelor de date, de interpretare a rezultatelor obtinute, de gasire a unor tehnici tot mai performante de optimizare a timpului de raspuns – problema capitala pentru toti beneficiarii care folosesc informatiile acumulate. Scopul final este acela al maximizarii profiturilor, a utilizarii eficiente a resurselor, serviciilor, a cresterii productivitatii, ... samd.

În orice sistem de baze de date relaţional, ca de altfel în oricare sistem complex, criteriul de performanţă este esenţial. Performanţa este o proprietate care trebuie urmărită pe toată durata de viaţă a sistemului, începând cu planificarea, continuând cu proiectarea, programarea, testarea şi utilizarea de zi cu zi. În

acest fel responsabilitatea în ceea ce priveşte asigurarea performanţei sistemului nu scade niciodată.

Monitorizarea continua a performanţelor împreună cu optimizarea acestora constituie o activitate cotidiană, pentru orice sistem complex dat în funcţiune.

Desi la ora actuală există diverse abordări de modele de proiectare şi utilizare a bazelor de date, conceptul de orientare obiect ajungand chiar şi în acest domeniu în ultimii ani, totusi, principalul model de bază rămâne cel relaţional, eventual extins cu aşa numitul "object-relational", concept ce caută să aduca o ordine obiectuală într-un tipar relaţional. Toate aceste modele stau la baza crearii unui model corect din punct de vedere functional al sistemului, model ce redă fidel sistemul real, cu toate funcţionalităţile sale.

Este dificil, dacă nu chiar imposibil de modelat o aplicaţie fără o analiza teoretică a problemei, fără studiul proprietăţilor logice, separat si prioritar faţă de aspectele fizice ale sistemului. Numai în acest fel se poate aborda si extinde optimizarea aplicaţiilor de la metoda clasică a costului minim (aplicat la număr de tuple şi atribute, fişiere index, etc), la toate proprietăţile care definesc sistemul.

Evaluarea performanţelor in domeniul bazelor de date este un aspect fundamental in desfăşurarea unei activităţi profitabile. Ea aduce importante informaţii si detalii referitoare la punctele slabe ale aplicatiei, la ceea ce poate fi imbunătăţit, precum si la modalităţile de optimizare a sistemului în tot ansamblul său. Iar prin optimizarea sistemelor de baze de date de cele mai multe ori se tinde spre obtinerea unor avantaje financiare, cum ar fi: evitarea achizitionarii de echipamente noi si costisitoare, reducerea costului intretinerii echipamentelor precum si al upgrade-urilor, scaderea timpului de raspuns, impreuna cu toate avantajele ce decurg de aici, scaderea stressului operatorilor si clientilor, care trebuie sa astepte prelucrarea sau generarea unor situatii sau rapoarte, si nu in ultimul rand, evitarea pierderii unor clienti prin scaderea timpului de asteptare a unor servicii.

 

a. Teste de evaluare a performantelor bazelor de date

Performantele unui sistem de gestiune a bazelor de date stau la baza masurii eficacitatii modului in care resursele oferite de mediul unei baze de date sunt utilizate, in scopul atingerii obiectivelor sistemelor de gestiune a bazelor de date. Sistemele de testare sunt instrumente vitale in masurarea si evaluarea performantelor sistemelor de baze de date

In ultimul deceniu, sistemele de testare a bazelor de date au evoluat intr-un ritm extrem de rapid, devenind o paradigma mult mai importanta si matura in domeniul analizarii si compararii diverselor software-uri de baze de date. Teste

standard, precum Wisconsin, AS3AP, TP1, TPC-A, TPC-B, TPC-C, TPC-D, OO1 si OO7 sunt extrem utilizate, in prezent, in scopul dezvoltarii modelului de performanta dorit, al compararii deverselor forme de proiectare, al identificarii punctelor de gatuire ale sistemelor, precum si in selectarea diverselor software-uri si in prezicerea comportamentelor sistemelor. Ele constituie, astfel, instrumente indispensabile in asistarea academicienilor, programatorilor, procticienilor, tester-ilor si chiar managerilor, in procesul de imbunatatire a prototipurilor software, si pentru aprobarea selectiilor de sisteme si a procesului de achizitionare a acestora.

A devenit, in acelasi timp, extrem de importanta si benefica, cunoasterea relevantei, conceptelor si complexitatii modelelor de testare, proiectare si implementare a sistemelor de testare, in scopul surprinderii esentei procesului de imbunatatire si progres al tehnologiilor bazelor de date

Un test efectuat asupra unui sistem de gestiune a bazelor de date este definit ca un set de instructiuni executabile, care sunt folosite pentru masurarea si compararea performantele relative si comparabile ale mai multor sisteme de baze de date, de-a lungul executiei experimentelor controlate. Testarea este, astfel, un proces de evaluare a diverselor sisteme software pe o aceeasi platforma hardware, sau pe platforme diferite.

Fiecare experiment este compus din doua tipuri de variabile. Primul tip este compus dintr-un set de variabile independente care vor afecta performantele sistemelor de baze de date. Acest variabile sunt denumite factori experimentali. Putem aminti in aceasta categorie dimensiunea bazei de date, complexitatea cererilor si configuratia sistemului.

Al doilea tip este un set de variabile dependente, care reprezinta masuratorile cantitative colectate in timpul procesului de testare. Ele sunt denumite indicatori ai performantei. Printre indicatorii de performanta putem aminti rata de trecere, care reprezinta intervalul principal de timp, precum si indicatorul timpului de raspuns, care este definit ca fiind timpul necesar unui anumit volum de munca, bine stabilit.

Rezultatele testelor depinde de volumul de lucru, de necesitatile specifice ale aplicatiei, de proiectarea sistemului, precum si de implementarea lor. Un volum de lucru este cantitatea de lucru atribuita sau efectuata de o entitate lucratoare, sau de un grup de entitati lucratoare, intr-un interval de timp. Volumul de lucru al unui sistem de testare al bazelor de date, este, astfel, cantitatea de lucru pe care trebuie sa o efectueze un sistem de baze de date in intervalul de timp specificat.

In esenta, un sistem de gestiune a bazelor de date este un mecanism folosit pentru stocarea, obtinerea si utilizarea datelor. Mecanismul este relativ simplu, si, din acest punct de vedere, construirea unui sistem de gestiune a bazelor de date nu constituie un proces prea dificil. Atunci cand apare necesitatea

manevrarii cererilor concurente intr-un mod consistent, din punctul de vedere al datelor, insa, logica devine mai complicata, considerandu-se cantitati considerabile de date, si cautandu-se obtinerea unor timpi de raspuns rezonabili.

In prezent, exista un mare numar de sisteme de gestiune a bazelor de date, fiecare dintre ele avand, in particular, performantele sale. In domeniul vast al sistemelor de gestiune a bazelor de date, trebuie sa existe, dupa cum am amintit mai sus, anumite concepte pentru compararea si alegerea celui mai bun sistem pentru o problema anume.

TPC (Transaction Processing Council – Consiliul Procesarii Transzatiilor) este o corporatie nonprofit infiintata in 1988 avand misiunea de a defini procesarea tranzactiilor (TP) si concepe teste specifice bazelor de date in scopul de a furniza repere obiective, date verificabile de catre industrie, referitoare la produse software si configuratii hardware utilizate ca servere de baze de date.

In spatele acestei organizatii se afla astazi 34 de membrii din lumea intreaga, in special producatori de software de baze de date, producatori de hardware, firme de cercetare/consultanta, integratori de sistem etc. Orice companie poate deveni membra a acestei organizatii contra unei taxe de 9500 USD/an.

In 12 ani de existenta TPC a conceput si rafinat mai multe teste de baza pentru masurarea performantelor bazelor de date - mai exact a eficientei tranzactiilor ce pot fi procesate on-line de aplicatii OLTP sau DS (suport decizie) pe o anumita configuratie hard si/sau soft.

TPC a dezvoltat o serie de teste de evaloare a performantelor bazelor de date in diferite situatii. Aceste teste au devenit o referinta comuna, folosita in compararea principalelor sisteme de gestiune a bazelor de date.

In istoria relativ scurta a TPC vor ramane incercarile concretizate in benchmark-urile TPC-A, TPC-B, TPC-C si TPC-D. Desi TPC-A a fost gandit pentru a testa eficienta depozitarii datelor (simple banking) in conditii de stres cu emularea de sesiuni terminal si cu monitorizarea accesului la disc, astazi el este considerat invechit nemaifiind promovat de TPC. Aceeasi soarta a avut si TPC-B, varianta fara emulare de terminal a benchmark-ului TPC-A, un simplu test de stres pentru BD.

Gandit initial ca test pentru interogarea bazelor de date, TPC-D a avut si el perioada sa de glorie urmata de critici, contestatii si rafinari. Asa se face ca astazi el exista doar prin urmasii sai, TPC-H(Ad-Hoc, DS) si TPC-R(Business Reporting, DS), ambele benchmark-uri fiind gandite pentru masurarea performantelor aplicatiilor de asistare a deciziilor de business pe baza datelor stocate intr-o baza de date (sau depozit de date). Diferenta dintre cele doua teste, ce poate fi sesizata si din numele acestora, consta in caracterul aleator al generarii interogarilor in cazul TPC-H (similar cu generarea acestora pe baza

selectiilor intr-o interfata GUI point&click), in timp ce in cazul TPC-R este rulat un set de interogari predefinite avand drept scop explicit obtinerea unor rapoarte de business standard.

TPC-C, testul ce simuleaza incarcari standard pentru aplicatii OLTP (procesare tranzactii on-line) a avut o soarta mai fericita. El continua sa-si pastreze numele chiar daca a evoluat continuu, ajungand astazi la versiunea 4.0.

Cel mai recent test finalizat, TPC-W a presupus un efort conjugat si sustinut a 23 de companii membre ale TPC. Gandit ca benchmark de tranzactii web pentru e-commerce, e-business, comert si business-to-buisness (B2B) pe web, TPC-W a fost lansat oficial in iulie 2000. Faptul ca intr-un timp record specificatiile finale au fost adoptate de intreg consiliul TPC, demonstreaza o data in plus cererea sa pe piata. Cu riscul ca specificatiile TPC-W vor evolua periodic si continuu, data fiind dinamica din acest domeniu, voi prezenta in continuare cateva aspecte legate de acest nou benchmark avand drept sursa principala de informatie versiunea 1.2 a specificatiilor oficiale.

Scopul testelor TPC este de a defini un set de cerinte functionale care se pot aplica pe orice sistem de procesare a tranzatiilor, indiferente de hardware sau de sistemul de operare. Depinde, astfel, de cel care efectueaza testul pentru ca aceste cerinte sa fie indeplinite. Aceasta metodologie permite oricarui producator de soft sa implementeze testul TPC si sa garanteze utilizatorilor finali faptul ca pot vedea situatii comparative usor de interpretat.

Testele TPC difera de alte teste prin faptul ca sunt modelate mai ales dupa directiile si mediile actuale de producere a aplicatiilor, spre diferenta de testele pentru calculatoarele individuale, care pot sa nu evalueze factori cheie de performanta, cum ar fi interfata cu utilizatorul, comunicatia din sistem, intrarile si iesirile la periferice, stocarea datelor si mecanismele de realizare a backup-ului si a refacerii bazelor de date.

Dificultatea proiectarii testelor TPC consta in reducerea diversitatii operatiilor gasite intr-o aplicatie industriala, insotita, insa, de o pastrare sa caracteristicilor esentiale de performanta, cum ar fi nivelul de utilizare a sistemului sau complexitatea operatiilor.

Un mare numar de operatii trebuie sa fie efectuate pentru a manevra un sistem de productie. Majoritatea acestor operatii, insa, sunt aproximativ reduse, din punctul de vedere al utilizarii resurselor sistemului, sau al frecventei de executie. Din aceasta cauza ele nu prezinta un interes real pentru analiza performantelor. Desi aceste functiii sunt vitale sistemului de productie, in contextul testelor standard, ele ar crea o prea mare diversitate si, implicit, cost, fiind astfel, omise.

Dupa cum se apreciaza, in prezent, TPC se afla intr-o faza de tranzitie. Liniile generale de implementare au fost dezvoltate intre directii, in scopul luarii in consideratie a preocuparilor legate de elementele speciale de testare.

Astfel, testele TPC-A si TPC-B se afla in prima faza a etapei de iesire din circulatie. Se spera ca testul TPC-C va umple acest gol lasat de ele, dar primele indicii in acest sens au fost sub cele asteptate. Urmatorul teste TPC, TPC-D se afla in etapa finala de studiu, inainte de consacrarea ca standard, fiind asteptat cu interes de intreaga comunitate stiintifica din domeniu.

Se pot extrage cateva motive pentru care testele TPC au ajuns sa fie folosite in intreaga lume:

furnizeaza o comparatie intre diversele platforme ofera informatii relevante despre raportul cost/performante ofera informatii relevante despre raportul putere de procesare/performante echilibreaza cererile de marketing ale producatorilor de soft de testare furnizeaza date reale care permit evaluarea scalabilitatii sistemelor,

precum si o comparatie intre diversele sisteme ajuta la compararea tehnologiilor ajuta la compartarea diverselor implementari software furnizeaza informatii utile in evaluarea costului software-ului este un pas inainte in domeniul testarii sistemelor de gestiune a bazelor

de date si nu numai

Testele TPC, insa, nu pot inlocui testele individuale de aplicatie, mai ales atunci cand performantele sunt un criteriu de decizie. Daca sunt folosite corect, insa, ele pot deveni un instrument necostisitor in furnizarea informatiilor preliminare independente despre situatia si pozitia producatorilor de sisteme de gestiune a bazelor de date pe piata de referinta. Si aceste lucru este relevant nu doar din punctul de vedere al performantelor, cat si din cel al pretului sau suportului tehnologic, in egala masura.

In lucrarea de fata voi prezenta in sestiunea 2, in amanunt testul TPC-C, devenit standard de testare a sistemelor de gestiune a bazelor de date, urmand ca apoi, in sectiunea 3 sa prezint o implementare a acestui test, impreuna ca o discutie o rezultatelor obtinute. In sectiunea 4 voi prezenta consideratii si concluzii finale, pe marginea celor discutate, incercand sa extrag elementele principale ale domeniului evaluarii performantelor sistemelor de gestiune a bazelor de date.

 

2. Modelul testului TPC-C

a. Prezentare generala

Testul TPC-C se bazeaza pe un volum de lucru care se desfasoara in timp real, volum caracterizat printr-un anumit numar de tranzactii ce se efectueaza. El este format dintr-un amestec de tranzactii ce efectueaza modificari intensive si de tranzactii de tip read-only., simuland activitatile existente in mediul general al unei aplicatii de procesare on-line a tranzactiilor. Acest lucru este efectuat prin includerea in cadrul testarii a unei multimi de componente de sistem asociate cu anumite medii, caracterizate prin:

executia simultana a tipurilor de tranzactii multiple, fapt ce cauzeaza o crestere a complexitatii

moduri de executie a tranzactiilor on-line si off-line sesiuni on-line de terminal multiple timp moderat de executie pentru aplicatie operatiuni semnificative de intrari si iesiri cu discul integritate a tranzactiilor (proprietatile ACID) distributie neuniforma a accesului la date prin intermediul cheilor primare

si secundare baze de date care constau in multe tabele cu multiple dimesiuni, atribute

si relatii concurenta pentru acces la date si modificari

Parametrul de performanta raportat de TPC-C este “rata de trecere a afacerii”, care masoara numarul de cereri procesate intr-un minut. Tranzactii multiple sunt folosite pentru a simula activitatea afacerii in procesarea unei cereri, si fiecare tranzactie este supusa unor constrangeri privitoare la timpul de raspuns.

Parametrul de performanta al acestui test este exprimat in tranzatii/minut (tpmC).

Pentru a fi conform cu standardul TPC-C, toate referintele la rezultatele tpmC trebuie sa includa rata tpmC, valoarea asociata cu aceasta pret/tpmC, precum si data de disponibilitate a pretului configuratiei.

Desi aceste specificatii exprima implementarea in termenii modelului de date relational, cu scheme de blocare conventionale, baza de date poate fi implementata folosind orice sistem conventional de gestiune a bazelor de date, servere de baze de date, sistem de fisiere sau alt tip de depozit de date care furnizeaza o implementare functionala echivalenta. Termenii “tabela”, “linie” si “coloana” sunt folositi in acest document doar pentru o exemplificare a structurile de date logice.

TPC-C foloseste o terminologie si o metrica ce este similara cu alte teste, dezvoltate de TPC sau de alti producatori. Aceasta similaritate in terminologie, insa, nu implica in nici un fel faptul ca rezultatele TPC-C sunt comparabile cu cele obtinute cu alte teste. Singurele rezulate obtinute in urma testarilor, care

sunt comparabile cu TPC-C sunt alte rezultate TPC-C, obtinute cu acceasi versiune TPC-C.

In ciuda faptului ca testul ofera un mediu bogat care emuleaza aplicatiile de procesare a tranzactiilor intr-un mod on-line, acest test nu reflecta intreaga gama de cerinte pentru aceasta procesare on-line. In plus, masura in care un client poate atinge rezultatele raportate de un producator al testului, este dependenta de modul in care TPC-C aprocimeaza aplicatia clientului. Performanta relativa a sistemelor derivata din acest test nu este in mod necesar valabila si pentru alte volume de lucru sau alte medii. Extrapolarile la alte medii nu sunt recomandate.

Rezultatele testelor sunt extrem de dependente de volumul de lucru, de cerintele specifice ale aplicatiei, precum si de proiectare si de implementare. Performantele relative ale sistemelor vor varia in functie de acesti factori, dar si de multi altii.

Astfel, TPC-C nu trebuie sa fie utilizat pentru a inclocui testele specifice ale aplicatiilor clientilor, atunci cand se urmareste o planificare a capacitatii critice si/sau decizii de evaluare a produselor.

Initiatorii testelor pot alege dintr- o multime de proiectari ale sistemlor de testare, cu conditia, insa, ca acest lucru sa fie specificat si ilustrat in Raportul Complet de Descriere a detaliilor de implementare, care trebuie sa insoteasca rezultatele raportate.

Scopul testelor TPC este de a furniza utilizatorilor industriali date relevante si obiective relative la performante. Pentru a realiza acest scop, specificatiile testelor TPC cer ca testele sa fie implementate pe sisteme, produse, tehnologii si preturi care:

sunt in general disponibile utilizatorilor sunt relevante segmentului de piata pe care testul TPC il modeleaza sau il

reprezinta (de exemplu TPC-A modeleaza si reprezinta medii de mari dimensiuni dar simple de procesare on-line a tranzactiilor

un numar semnificativ de utilizatori in modelele si reprezentarile segmentului de piata ar putea fi implementati

 

b. Elemente de testare speciale interzise

Utilizarea de noi sisteme, tehnologii (hardware sau software) si preturi este incurajata atat timp cat aceste elemente intrunesc cerintele specificate mai sus. Sunt interzise in mod special sistemele de testare, produsele, tehnologiile si preturile (referite in acest document ca “implementari”) al caror principal scop este optimizarea performantelor testelor TPC, fara a avea corespondenta intr-o

aplicabilitate in aplicatia reala sau in mediul real. Aceste elemente vor fi denumite “elemente speciale de testare”, fiind deci interzise.

Urmatoarele caracteristici ar trebui sa fie folosite pentru a judeca daca o implementare anume este un element special de testare. Nu este necesar ca fiecare punct de mai jos sa fie indeplinit, ci o pondere cumulativa a dovezilor trebuie sa fie luata in considerare, pentru a identifica o implementare neacceptabila.

Nu este necesara o certitudine absoluta pentru a se decide in aceasta privinta. Intrebarea la care trebuie dat un raspuns este: bazata pe elementele disponibile, ponderea evidentelor indica sau nu faptul ca o implementare este un element special de testare.

Urmatoarele caracteristici ar trebui sa fie folosite pentru a judeca daca o anumita implementare este un element special de testare:

daca implementarea este in general disponibila, documentata si sustinuta conceptual

daca implementarea are restrictii semnificative in utilizarea ei sau aplicabilitati care ii limiteaza utilizarea, peste testele TPC

daca intreaga implementare sau o parte a ei este integrata slab intr-un produs mai complex

daca implementarea dispunde de avantaje speciale ale naturii limitate ale testelor TPC (profile de tranzactii, amestecuri de tranzactii, tranzactii concurente si/sau continute una in alta, izolari ale tranzactiilor) intr-o maniera care nu este aplicabila in general in mediul pe care testul il reprezinta

daca utilizarea implementarii este descurata de comerciant (aici sunt incluse elemente care duc la nepromovarea implementarii intr-o maniera similara cu cea a altor produse sau tehnologii)

daca implementarea necesita elemente de complexitate neobisnuite din partea utilizatorilor, programatorilor sau administratorilor de retea

daca pretul este neobisnuit pentru comerciantul respectiv, sau neobisnuit pentru practica normala a afacerii. Urmatoarele practici de stabilire a preturilor sunt suspecte:

disponibilitatea unui discount pentru un mic set de clienti dicounturi documentate intr-un mod neobisnuit sau intr-o maniera

deosebita preturi de tip oferte speciale sau lichidare de stoc discount-uri care depasesc 25% pentru cantitati reduse, sau 50% pentru

cantitati mari

c. Modelul aplicatiei si al mediului real

Testul TPC-C este compus dintr-un set de operatii elementare, proiectate sa utilizeze functionalitati de sistem intr-o maniera reprezentativa pentru un mediu de aplicatie de procesare on-line a tranzatiilor. Aceste operatii au fost concepute pentru a avea un context ce modeleaza mediile reale ale problematicilor industriale, descriind activitatea unui furnizor de produse, pentru a ajuta utilizatorii sa faca legatura dintre componentele testului si cele ale propriei afacei intr-un mod intuitiv.

Volumul de lucru este central in jurul activitatii de procesare a cererilor, furnizand o proiectare logica a bazei de date, si putand fi distribuit fara a fi necesare modificari structurale ale tranzactiilor.

TPC-C nu reprezinta activitatea unui segment particular de afacere, modeland, insa, o industrie generica, industrie ce trebuie sa conduca procese de vanzari si distribuiri de produse sau servicii (de exemplu: vanzarea de masini, distribuirea produse alimentare, furnizarea componentelor diverselor echipamente).

TPC-C nu incearca sa reprezinte un model pentru modul in care trebuie construita o aplicatie.

Scopul testului este de a reduce diversitatea operatiilor ce se gasesc intr-o aplicatie de productie. Aceste fapt trebuie insotit de o mentinere a caracteristicilor esentiale de performanta, cum ar fi, de exemplu: nivelul utilizarii sistemului sau complexitatea operatiilor.

Un numar mare de functii trebuiesc aplicate pentru a conduce un sistem de acceptare a cererilor din productie. Multe din aceste funtii nu sunt de un interes major in analiza performantei, intrucat ele sunt reduse proportional din punctul de vedere al utilizarii resurselor sistemului sau al frecventei executiei.

Desi aceste functii sunt vitale pentru un sistem de productie, ele nu creaza o mare diversitate in contextul testului standard si voi fi, dupa cum am mai amintit, omise din testele TPC-C.

Testul este exemplificat in specificatii, utilizand un model al unei companii specializata pe comercializarea unor produse, avand un numar de filiale in teritoriu, precum si un numar de depozite. S-a incercat in acest mod o cat mai buna reprezentare pentru organizarea unei companii oarecare, reprezentare care sa fie sugestiva in cat mai multe cazuri.

Bineinteles, o idee importanta ar fi aceea de a permite ca respectiva companie sa se extinda in viitor cu noi reprezentante in teritoriu, precum si cu noi depozite.

Diagrama urmatoare ilustreaza, intr-un prim nivel, schema companiei descrise mai sus:

Clientii companiei apeleaza la compania respectiva cu scopul de a aduce o noua comanda sau de a verifica starea curenta a unei comenzi efectuată anterior. Comenzile sunt formate dintr-un număr de 10 obiecte în caz mediu.

Sistemul conceput ca model de prezentare mai este folosit, de asemeni si în scopul de a introduce plati catre clienti, de a procesa comenzi pentru livrare, si a examina nivelul stocului pentru a identifica eventualele necesitati de aprovizionare.

Schema bazei de date concepută de autorii testului, suprinzând şi cardinalitatea tabelelor, este următoarea

Trebuie specificate următoarele:

toate numerele ilustrate specifică cerinţele de populare a bazei de date

numerele din cadrul blocurilor entitate reprezintă cardinalitatea tabelelor (număr de linii). Aceste numere sunt înmulţite cu D ( D – număr de depozite), pentru a ilustra mai fidel dimensiunea bazei de date

numerele din dreptul săgeţilor de relaţii reprezintă cardinalitatea lor (numărul mediu de descendenţi ai părintelui)

semnul (+) este folosit după o cardinalitate a unei relaţii sau a unei tabele pentru a ilustra că numărul respectiv poate avea mici variaţii faţă de popularea iniţială a bazei de date, de-a lungul intervalului de măsurare.

Deci, dupa cum se poate observa, proiectarea logica a bazei de date este compusa din 9 relatii:

 

Numele

relatiei

(tabelei)

Cardinalitate

(numar de inregistrari)

Dimensiunea unui

tuplu

Numar tuple

intr-o pagina de 4K

warehouse W 89 bytes 46

district W * 10 95 bytes 43

customer W * 30K 655 bytes 6

stock W * 100K 306 bytes 13

item 100K 82 bytes 49

order 

24 bytes 170

new-order 

8 bytes 512

order-line 

54 bytes 75

history 

46 bytes 89

In tabelul de mai sus se poate observa ca W reprezinta numarul de depozite. Se presupune faptul ca doar unitatile intregi incap intr-o pagina de 4000 de bytes. Cardinalitatile tabelelor Warehouse, District, Customer si Stock sunt scalate in functie de numarul de depozite. De asemeni, dupa cum se poate observa, relatia Item nu se scaleaza in functie de numarul depozitelor, in timp ce relatiile Order, Order-Line si History cresc in volum intr-un mod nedefinit, pe masura ce cererile sunt procesate.

Exista 5 tipuri de tranzactii, descrise de tabelul urmator:

 

TranzactiaMin

[%]

Setat

[%]Select Update Insert Delete Join

New-Order

(cerere noua)

* 43 23 11 12 0 0

Payment

(plata)43 44 4.2 3 1 0 0

Order Status

(stare cerere)

4 4 11.4 0 0 0 0

Delivery

(livrare)4 5 130 120 0 10 0

Stock Level

(nivel stoc)4 4 0 0 0 0 1

Tranzactia New-Order plaseaza o cerere compusa in medie din 10 elemente dintr-un depozit, adauga cererea, si pentru fiecare element, modifica in mod corespunzator stocul.

Tranzactia Payment proceseaza o plata de la un client si modifica balantele, precum si alte date din tabelele Warehouse, District si Customer. Clientul poate fi specificat prin doua moduri:

printr-un identificator unic al clientului prin numele clientului

In ultimul caz, exista in medie trei posibilitati de alegere a clientului, dintre care doar unul este ales.

Tranzactia Order Status intoarce starea ultimei comenzi a clientului. Ca si in cazul tranzactiei Payment, clientul poate fi specificat prin identificatorul unic de client sau prin numele personal.

Tranzactia Delivery proceseaza cererile corespunzatoare pentru 10 cereri ce sunt in asteptare, cate una pentru fiecare district, cu 10 elemente pentru fiecare cerere. Intrarea corepsunzatoare din tabela New-Order este stearsa.

In cele din urma, tranzactia Stock Level examineaza cantitatea stocului pentru elementele solicitate de ultimele 20 de cereri intr-un district.

Dupa cum se poate vedea din tabelul de mai sus, se prezinta o sumarizare a tranzactiilor in functie de procentul volumului de lucru pe care il ocupa fiecare tranzactie, precum si numarul de operatii de selectare, modificare, inserare, stergere si jonctiuni pentru modelul relational.

Exista in tabel o coloana cu procentul minim de volum de lucru, precum si o coloana cu volumul de munca presupus a fi atins intr-un caz mediu. Testul specifica un procent minim pentru toate tipurile de tranzactii, cu exceptia celei New-Order.

Dupa cum am amintit in sectiunile precedente, indicatorul de performanta reprezinta numarul de tranzactii de tip New Order procesate intr-un minut, astfel incat este de dorit sa se obtina un numar cat mai mare de astfel de tranzactii (catre 45%), avand in vedere ca dimensiunea relatiei New-Order va creste fara nici o limitare, in cazul in care procentul de tranzactii Delivery nu va fi suficient pentru a sterge intrari din New-Order intr-un ritm comparativ.

A treia coloana din tabelul prezentat este procentul amestecului care va fi propus in studiul care urmeaza.

Trebuie remarcat faptul ca procentul New-Order trebuie manevrat cu foarte mare atentie, in contrapartida cu procentul Delivery, pentru a obtine numarul maxim de tranzactii New-Order intr-un minut.

c. Sabloane de acces ale tranzactiilor

In aceasta sectiune voi prezenta sabloanele de acces la baza de date a fiecarei tranzactii. Pentru fiecare tranzactie, vor fi prezentate operatiunile cu baza de date efectuate de acea tranzactie, intr-un pseudocod simplificat. Desi pseudocodul nu este in SQL, prezinta intr-un mod succint functiile din care este formata fiecare trabzactie. In cadrul proiectului realizat aceste tranzactii au fost implementate folosind Visual Studio 6.0, conexiunea realizandu-se prin driverele ODBC.

Tranzactia New Order

1. Select(whouse-id) from Warehouse 2. Select(dist-id, whouse-id) from District 3. Update(dist-id, whouse-id) in District 4. Select(customer-id, dist-id, whouse-id) from Customer 5. Insert into Order 6. Insert into New-Order 7. Pentru fiecare element (10 elemente):

a. Select(item-id) from Item b. Select(item-id, whouse-id) from Stock c. Update(item-id, whouse-id) in Stock d. Insert into Order-Line

8. Commit

Tranzactia Payment

Exista doua cazuri. In 40% din situatii, clientul este selectat prin intermediul identificatorului sau. In celelalte 60% dintre cazuri, clientul este selectat prin numele sau. In aceasta situatie vor fi in medie trei clienti ce vor purta numele selctat, clientul selectat fiind determinat prin selectarea tuturor clientilor cu acest nume, sortarea lor dupa prenume si selectarea clientului din pozitia mediana.

1. Select(whose-id) from Warehouse 2. Select(dist_id, whouse-id) from District 3. (a) Cazul 1: Select(customer-id, dist-id, whouse-id) from Customer

(b) Cazul 2: Select ne-unic(customer-name, dist-id, whouse-id) from Customer

4. Update(whose-id) in Warehouse 5. Update(dist-id, whouse-id) in District 6. Update(customer-id, dist-id, whouse-id) in Customer 7. Insert into History 8. Commit

Tranzactia Order Status

1. (a) Cazul 1: Select(customer-id, dist-id, whose-id) from Customer

(b) Cazul 2: Select ne-unic(customer-name, dist-id, whouse-id) from Customer

2. Select(Max(order-id), customer-id) from Order 3. Pentru fiecare element din cerere

a. Select(order-id) from Order-Line

1. Commit

Apelul “Select(Max(order-id), customer-id) from Order” efectuat asupra bazei de date selecteaza tuplul din relatia Order care este corespunzator celei mai recente cereri de la client.

Acest apel ar putea fi implementat ca o functie agregat. Deoarece, insa, relatia Order isi continua cresterea in dimensiuni, aceasta abordare ar fi extrem de scumpa. Acest lucru ar putea fi implementat folosind un index ordonat multi-cheie, astfel incat tuplul corect sa poata fi selectat doar printr-o parcurgere a indexului. In studiul de fata se presupune un overhead format dintr-o singura operatie de select.

Tranzactia Delivery

1. Pentru fiecare district din depozit (de exemplu de 10 ori)

a. Select(Min(order-id), whouse-id, dist-id) from New-Order b. Delete(order-id) from New-Order c. Select(order-id) from Order d. Update(order-id) Order e. Pentru fiecare element al cererii (se exemplu de 10 ori)

i. Select(order-id) from Order-Line ii. Update(order-id) from Order-Line

a. Select(customer-id) from Customer b. Update(customer-id) Customer

2. Commit

Similar operatiei “Max” din cadrul tranzactiei Order-Status, se presupune ca selectul “Min” este realizat intr-un singur apel.

Tranzactia Stock Level

Voi prezenta mai jos un exemplu de cod SQL, preluat direct din specificatiile TPC-C, intrucat se prezinta intr-o forma optimala:

SELECT d_nxt_o_id INTO :o_id

FROM District

WHERE d_w_id = :w_id AND d_id = :d_id;

SELECT COUNT(DISTINCT(s_i_id)) INTO :stock_count

FROM Order-Line, Stock

WHERE

ol_w_id = :w_id AND

ol_d_id = :d_id AND

ol_o_id < :o_id AND

ol_o_id >= (:o_id – 20)

AND

s_w_id = :w_id AND

s_i_id = ol_i_id AND

s_quantity < :threshold;

 

Presupunand ca avem un index pe campul order_id al relatiei Order-Line, impreuna ca un index de cheie dubla pe whouse-id si item-id din relatia Stock, interogarea bazei de date rezultata este formata in medie din 200 de tuple Order-Line si Stock, fiecare fiind prelucrata in parte.

Pentru a sintetiza sabloanele de acces ale celor 5 tranzactii, mai intai trebuie extrase numerele de accese ale tranzactiilor la fiecare relatie, precum si numarul mediu de accese la baza de date ale fiecarei tranzactii in parte. In continuare voi prezenta un tabel care aduce in discutie aceste elemente:

 

 

 

 

RelatiaNew

OrderPayment

Order

StatusDelivery

Stock

LevelMedie

warehouse U(1) U(1)     

0.87

district U(1) U(1)   

P(1) 0.93

customer NU(1) NU(2,2) NU(2,2) P(10) 

1.524

stock NU(10)     

P(200) 12.4

item NU(10)       

4.4

order A(1) 

P(1) P(10) 

0.53

new-order A(1)   

P(10) 

0.49

order-line A(10) 

P(10) P(100) P(200) 13.3

history 

A(1)     

0.43

In cadrul tabelulul avem urmatoarele notatii:

U(x) semnifica faptul ca sunt alese x tuple intr-un mod uniform dintr-o relatie

NU(x) semnifica faptul ca se efectueaza o selectie neuniforma a x tuple din relatia respectiva

A(x) specifica faptul ca x tuple sunt adaugate relatiei P(x) specifica faptul ca x tuple sunt alese, cu conditia ca aceste tuple sa

fie alese in functie de un comportament anterior bine determinat (este, de fapt o forma de localitate temporara)

Trebuie mentionat faptul ca tuplele accesate de tranzactiile Order-Status, Delivery si Stock-Level este foarte posibil sa fie stocate in buffere in momentul accesarii, intrucat fac parte din multimea tuplelor accesate recent de tranzactia New-Order, fiind astfel extrem de posibil ca ele sa se gaseasca in buffer.

Multe dintre identificatorii tuplelor sunt generati de functia NU(). Aceasta functie este definita si simulata in cele ce urmeaza.

c. Analiza accesului imprastiat la date in cazul TPC-C

Testul TPC-C presupune ca accesul la tuplele bazei de date este imprastiat cu alte cuvinte intr-o relatie anumite tuple sunt accesate mai frecvente decat altele. In aceasta sectiune voi defini si simula functia aleatoare neuniforma numerica, specificata de documentatia TPC-C, folosita pentru generarea identificatoarelor de tuple. Procesul de generare neuniforma si aleatoare a numerelor, notat prin functia NU(), este definit prin :

NU(A, x, y) = (((rand(0, A) | rand(x, y) + C)%(y – x)) + x [1]

unde :

rand(x, y) desemneaza un numar intreg uniform distribuit in intervalul inchis [x..y]

C este o constanta intre [0..A] A este o constanta aleasa in functie cu dimensiunea intervalului [x..y] (N % M) semnifica N modulo M (N | M) semnifica operatiunea de “sau” logic la nivel de bit pentru

operatorii M si N

Mentionand ca in cadrul sectiunii de fata C se presupune a fi nul (standardul TPC-C permite alegerea arbitrara a lui C in interiorul plajei de valori [0..A]). De asemeni, se alege A si y in concordanta cu specificatiile tuplului care este generat.

In primul rand se considera accesul la relatiie Stock si Item. Toti identificatorii tuplelor acestor relatii sunt desemnati in interiorul plajei de valori distribuite de functia NU(8191,1,1000000).

In bazele de date clasice datele sunt stocate in pagini, de aici apare nesitatea determinarii nivelului de incrucisare la nivelul fiecarei pagini. Se presupune ca tuplele sunt impachetate intr-o pagina intr-o ordine secventiala, intr-o asezare care presupune numarul maxim de tuple care incap in pagina. Se mai presupune ca spatiul ramas din fiecare pagina este ignorat.

Pentru relatia Stock intr-o pagina de 4k (8K) incap 13 (16) tuple. Se sorteaza paginile in functie de frecventa de acces, si se obtin urmatoarele rezultate:

Pentru o pagina de 4Kbytes

25% dintre operatiuni acceseaza 80% dintre date, sau, dintr-un punct de vedere opus, peste 80% dintre accese acceseaza 20% din date. Acesta este, de fapt, principiul denumit “regula 80-20”

peste 59% dintre accese ating in jur de 10% dintre pagini 2% dintre pagini sunt atinse de aproximativ 28% dintre accese

Cu cat pagina este mai mica, cu atat aceasta imprastiere este mai mare, intrucat exista o si mai mica sansa ca tuplele cel mai des accesate sa se afle in paginile din bufferele memoriei.

c. Modelul sistemului si estimari ale performantei

In aceasta sectiune se descrie modelul ratei de trecere. Valorile parametrului folosit in acest model nu reflecta nici un sistem particular, incercand sa fie, insa, reprezentative.

Obiectivul este de a identifica directiile principale, si nu de a furniza estimari specifice ale ratei de trecere, sau ale raportului pret/performanta.

Modelul prezentat aici incorporeaza atat unitatea centrala de procesare, cat si discurile de date. Se presupune ca sistemul este configurat cu un numar suficient de discuri astfel incat gradul de utilizarea al acestora sa fie sub 50% iar singura cale de aparitie a fenomenului de gatuire fiind prin unitatea centrala de procesare (CPU).

Pentru a calcula gradul de utilizare, modelul insumeaza cererea medie de CPU pe tranzactie, impartind, apoi aceasta valoare cu cu frecventa procesorului, inmultind apoi cu rata de trecere.

Un prim indicator al modelului este rata maxima de trecere, obtinuta prin fixarea gradului de utilizare CPU, si calculand rata de trecere.

Pentru a calcula utilizarea discului, se insumeaza cererea medie pe fiecare disc intr-o tranzactie (in milisecunde), impartind prin numarul de discuri, multiplicand, apoi prin rata de trecere a discului.

Trebuie mentionat faptul ca se presupune cate un log separat pentru fiecare disc. In tabelele urmatoare voi prezenta valorile parametrilor presupusi, precum si numarul de vizitari pentru fiecare tranzactie, in fiecare nod al sistemului.

Trebuie mentionat faptul ca n reprezinta indicele parametrilor. In ecuatiile de mai jos, se va folosi on pentru a nota intarzierea care apare pentru un apel de parametru pe nivelul n.

Se defineste notiunea de numar de vizitari ca fiind numarul de situatii in care o tranzactie necesita o anumita operatie, in functie de tipul tranzactiei.

Numarul de vizitari este memorat in coloanele V1 ... V5. Se defineste Vi, j ca fiind numarul de vizitari pentru tranzactia i la operatia j.

Majoritatea parametrilor din tabel sunt evident, ca semnificatie. Exista anumite exceptii, pe care le voi prezenta

resursa parametru n intarziereNew Order

V1

Payment

V2

Status

V3

Delivery

V4

CPU select 1 20K 23 4.2 13.2 130 1

CPU update 2 20K 11 3 0 120 0

CPU insert 3 20K 12 1 0 0 0

CPU delete 4 20K 0 0 0 10 0

CPU commit 5 40K1 1 1 1 1 1

CPUinitiere

intrari

iesiri

6 5K 1 + mc + 10(mi + ms)

1 + 2.2(mc)

2.2(mc) + mo + 10(ml)

1 +10(mc + mo +mn) +130(ml)

200(ms+ml)

CPU aplicatie 7 0.1K 47 8 13 261 3

CPUtrimitere –

receptie8 15K 0 0 0 0 0

CPUpregatire

commit9 40K 0 0 0 0 0

CPUinitiere

tranzactie10 50K 1 1 1 1 1

CPUridicarea

inchiderilor11 35K 1 1 1 1 1

CPUselect

neunic12 50K 0 0.6 0.6 0 0

CPU join 13 2000K 0 0 0 0 1

diskintrari

iesiri14 25ms mc + 10(mi

+ ms)2.2(mc) 2.2(mc) +

mo +10(ml)10(mc + mo + mn) +130(ml)

200(ms + ml)

unde:

aplicatie este folosit desemnand codul aplicatiei dintre apelurile SQL transmiteri – receptii este folosit pentru intarzierea CPU la un nod, aparuta

pentru a trimite sau receptiona un mesaj prin retea. ridicarea inchiderilor este aferent portiunii din faza commit-ului destinata

ridicarii inchiderilor (blocarilor, zavoarelor) pregatire Commit desemneaza procesul de pregatire a operatiunii de

commit-ere a modifiucarilor efectuate asupra bazei de date. Operatiunea Commit este compusa din 2 faze, in aceste caz

initiere intrai-iesiri reprezinta intarzierea CPU necesara initierii unei intrari sau a unei iesiri

Intarzierea ridicarii inchiderilor este obtinuta prin insumarea timpilor de ridicare a zavoarelor pentru citire si a zavoarelor pentru scriere, numarul de inchideri tinute de fiecare tip de tranzactie find stabilit procentual de volumul de munca atasat fiecarui tip de tranzactie. Se presupune, in acest caz o intarziere de 1K instructiuni pentru ridicarea fiecarei inchideri.

Parametrii mc, mi, ms, mo si ml, gasiti in formulele coloanelor Vi..6 si Vi, 14, unde i este luat din intervalul 1...5, reprezinta numarul de ratari pentru relatiile Customer, Item, Stock, Order si OrderLine

Aceste numere de ratari sunt obtinute din modelul bufferului. Trebuie mentionat, insa, faptul ca pentru o completare, se puteau introduce numerele de ratari si

pentru tabelele Warehouse, District si New-Order, in estimarile performantelor, dar acestea au valori neglijabile si pot fi omise din tabel.

Intarzierea unui select ne-unic este bazata pentru faptul ca in cazul mediu, se returneaza trei valori care apoi trebuiesc sortate. Intarzierea pentru join (jonctiune) este estimata astfel:

In medie exista 200 de elemente ordonate in ultimile 20 de tranzactii aferente ultimilor cereri, si astfel, o scanare care sa intoarca aproximativ 200 de elemente este necesara pentru a crea o tablea temporara pentru jonctiunea externa.

Fiecare dintre aceste tuple vor efectua jonctiunea cu exact un tuplu din jonctiunea interna. Presupunand ca exista indecsi corespunzatori pe jonctiunea interna, fiecare tuplu al jonctiunii externe necesita un select indexat.

In fine, rezultatul trebuie sa fie sortat pentru a elimina elementele duplicate. Se presupune ca intarzierea pentru scanare este de 5K pentru fiecare tuplu, intarzierea pentru selectul indexat este de 5K instructiuni pentru fiecare tuplu, iar intarzierea pentru sortarea finala este de 40K, rezultand intr-o intarziere totala CPU de 2040 instructiuni.

 

3. Implementarea testului TPC-C

a. Prezentare preliminara

Aprobat în 1992, devenit standard, testul TPC-C35 reprezintă unul dintre cele mai complexe teste de evaluare a performanţelor din punctul de vedere al prelucrării tranzacţiilor on-line. Acest lucru se datoreaza, printre altele, si urmatoarelor cauze:

multiplelor tipuri de tranzacţii ce se efectuează. Există cinci tipuri diferite de tranzacţii, cu complexităţi diferite, care se execută într-un mod concurent, "amestecat". Execuţia lor se poate face direct sau în mod întârziat.

bazei de date foarte complexe. Baza de date este compusă din 9 tipuri de înregistrări, cu diferite dimensiuni ale înregistrărilor, şi populate diferit. Trebuie menţionat şi faptul că specificaţiile standardului precizează clar tipurile atributelor şi gradul de populare a tabelelor.

structură de execuţie extrem de complicată, dar bine definită. Testul se execută algoritmic, într-o secvenţă bine precizată de paşi, simulându-se mai mulţi utilizatori diferiţi.

Testul este format dintr-o succesiune ciclică de operaţii ce trebuiesc efectuate într-o ordine strictă. Se fac, la fiecare etapă a succesiunii (algoritmului) diverse măsurători, ce vor evidenţia parametrii de performanţă căutaţi.

Figura urmatoare ilustreaza secventa ciclica de operatii executate de fiecare utilizator simulat. Partea activa a ecranului este reprezentată prin caractere bold-ate:

Astfel, fiecare utilizator simulat executa o succesiune ciclica de sesiuni de lucru cu terminalul, asteptari, timpi de raspuns ( TR ), dupa cum urmează:

selecteaza un tip de tranzactie de pe meniu, dupa o anumita distributie de complexitate bine stabilita;

asteapta ca ecranul de intrare/iesire sa apara; masoara timpul de raspuns; introduce informatii pentru numarul necesar de campuri, cu un timp de

tastare minim, specificat; asteapta pana apar rezultatele in campurile de iesire, pe ecranul de

intrare/iesire; asteapta un timp bine definit (timp de gandire - standard), in timp ce

ecranul de intrare - iesire ramane activat.

La sfarsitul timpului de gandire utilizatorul simulat sare din nou la primul pas al alegerii tranzactiei din meniu.

Fiecare tip de tranzactie este disponibila fiecarui terminal prin intermediul meniului. Pe perioada intervalului de masurare, emulatorul de terminal aflat la distanţă trebuie să menţină un procentaj minim de amestec al tranzacţiilor (mix), pentru fiecare tip de tranzactie. Astfel, valorile acestui procentaj minim sunt definite dupa cum urmeaza:

Tip tranzactie Valoare minima pentru amestec [%]

Comandă nouă nu se specifica

Plata 43.0

Stare a comenzii 4.0

Livrare 4.0

Nivel de stoc 4.0

Etapa corespunzatoare meniului este independenta de tranzactii. Cel putin 90% din toate selectiile de meniu trebuie sa aiba un timp de raspuns pentru meniu (response time menu) mai putin de 2 secunde.

Pentru fiecare tip de tranzactie, timpul destinat selectarii cheii este constant si trebuie sa fie minim:

18 secunde pentru tranzactie de tip comandă nouă; 3 secunde pentru tranzactie de tip plata; 2 secunde pentru tranzactii de tip stare a comenzii, livrare si nivel stoc.

Sintetizând, parametrii discutaţi mai sus, precum şi alte completări, pot fi ilustraţi în următorul tabel:

Tip

tranzacţieAmestec

minim [%]Timp de tastare

minimTimp de răspuns

minimTimp min. de

gândire

New-Order nespecificat 18 secunde 5 secunde 12 secunde

Payment 43.0 3 secunde 5 secunde 12 secunde

Order Status 4.0 2 secunde 5 secunde 10 secunde

Delivery 4.0 2 secunde 5 secunde 5 secunde

Stock Level 4.0 2 secunde 20 secunde 5 secunde

După cum am mai specificat, fiecare sistem are particularităţile sale, cu dimensiunile sale. Totuşi, marele merit al testelor TPC-C35 este acela că permite comparaţia între diferitele sisteme, aducând, în plus, informaţii consistente despre performanţele fiecăruia. Singura menţiune este aceea că datele pot fi comparate în cadrul aceluiaşi standard, şi anume TPC-C35. În sectiunile viitoare voi descrie implementarea testelor TPC-C35 realizata, impreuna cu o discutie a rezultatelor obtinute.

 

a. Implementarea testului TPC-C35

In aceasta sectiune voi prezenta rezultatele unui studiu efectuat asupra a doua sisteme de gestiune a bazelor de date:

Microsoft SQL Sever 7.0, intrucat am considerat ca este reprezentativ pentru serverele dedicate de baze de date, obtinand pe scara larga bune apricieri asupra modului de utilizare, si a facilitatilor obtinute

Microsoft Acces, intrucat am dorit o analiza a unui sistem de gestiune a bazelor de date orientat pe sistemul de fisiere fizice. Acest sistem, prin lipsa elementelor de manevrabilitate a concurentei, care ii pot complica executia

Am considerat ca cele doua sisteme de gestiune a bazelor de date sunt reprezentative pentru categoriile din care fac parte, obtinand astefl, o imagine mai clara asupra comportamentului real a SGBD-urilor fata de testul TPC-C.

Fiecare sistem de gestiune a bazelor de date a fost masurat utilizand acceasi interfata a apelurilor asupra bazei de date (ODBC), iar interogarile sunt efectuate de aceeasi aplicatie, fara a efectua modificari care sa faciliteze obtinerea unor rezultate mai bune, la schimbarea SGBD-ului.

Mediul testului a urmat indeaproape conditiile descrise de standardul TPC-C. Baza de date, prcum si aplicatia sunt proiectate, simuland comportamentul unui utilizator normal, in conformitate specificatiile standarului cu TPC-C.

Proiectarea bazei de date standard TPC-C a fost realizata cu o cat mai mare acuratete pentru fiecare sistem de gestiune a bazelor de date.

Aplicatia a fost implementata folosind o interfata Microsoft Visual C++, iar ca interfata cu baza de date, pentru o aplicabilitate pe toate sistemele de gestiune a

bazelor de date importante, am folosit driverele ODBC (un alt motiv a fost cautarea unui timp optim de raspuns).

Testul este proiectat sa ruleze pe mai multe statii de lucru, si simuleaza mai multi utilizatori simultani ai bazei de date.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Aplicatia porneste mai multe terminale simultane, si se comporta in conformitate cu standardul TPC-C. Testele sunt pornite simultan, in scopul asigurarii unei incarcari deterministe in regim de concurenta a bazei de date.

De asemeni, trebuie mentionat ca fiecare terminal virtual afiseaza interfata cu utilizatorul ca si cum un utilizator real ar fi prezent in fata consolei. Actiunile utilizatorului sunt generate aleator, respectand functiile de distributie specificate in standard.

De exemplu, in meniul principal, utilizatorul poate selecta una din cele cinci tranzactii posibile. Standardul necesita ca intr-un interval fixat de masurare, terminalele sa pastreze un procentaj minim de amestec al tipurilor de tranzactii, procentaj descris mai amplu in sectiunea precedenta.

a. Rezultatele testelor

Dimensiunea bazei de date obtinuta in urma testelor a repsectat standardele normale (aproximativ 100 MB), constand in inregistrari aferente la peste 100.000 de elemente, distribuite in 10 districte, fiecare avand 3.000 de clienti.

Primul element studiat a fost procesul de populare a bazei de date initiale, avand scopul de a evolua viteza de inserare. Pentru acest scop, am creat cate o baza de date pentru fiecare sistem de gestiune a bazelor de date studiat, folosind aceleasi fisiere script DML (Data Modeling Language – Limbaj de modelare a datelor), eventual cu schimbari minore, pentru o conformitate cu fiecare sistem de baze de date in parte.

Acest fapt a asigurat ca ambele colectii de date au continut aceleasi constrangeri si au avut aproximativ aceleasi dimensiuni pentru inregistrari.

Ca o prima concluzie, SQL Sever s-a comportat bine, avand un timp mediu de rapuns de 1300 de secunde. Access a inregistrat timpi comparabili, de asemeni, situandu-se in jur de 1670 de secunde.

Dimnesiunile bazelor de date rezultate la sfarsitul procesului de populare au fost, si ele, comparabile.

DBMS SQL Server Access

dimensiune 100 MB 120 MB

Dimensiunea bazei de date standard este de 88 MB, folosind campuri de lungime standard. Diferenta dintre aceasta dimensiune si cele obtinute se datoreaza reprezentarii interne a paginilor de date si a indecsilor. Astfel, se poat observa un mecanism de stocare ineficient in cazul bazei de date Access.

Dupa etapa premergatoare a popularii bazelor de date, s-a trecut la rularea efectiva a testelor constand in interogari si modificari ale datelor.

Principalele teste au studiat distributia timpului de raspuns. Trebuie mentionat ca in cadrul testelor nu s-a luat in considerare nici o optimizare.

Bazele de date nu au fost testate pe sisteme dedicate, nefiind incarcate in mod aditional, si nici neimplementandu-se configuratii speciale.

In continuare voi prezenta rezultatele obtinute, detaliand pentru fiecare tranzactie in parte.

Tranzactia New-Order

i. Microsoft Access

Pentru o singura conexiune la baza de date la un moment de timp, Microsoft Access a inregistrat timpi de raspuns distribuiti intre 10 si 55 secunde pe tranzactie. Rata de trece a fost, insa extrem de dependenta de incarcarea sistemului de intrare/iesire – discul fix.

Atunci cand nivelul concurentei creste la doua conexiuni simultane, timpii de raspuns au fost separati in doua grupuri distincte: 30-50 secunde si 125-155 de secunde pe tranzactie. Se poate observa cu usurinta ca prima regiune este similara cu timpii de acces obtinuti in cazul accesului singular, prezentati anterior. In acest caz, insa, banda inferioara are valori mai ridicate, datorita intarzierii introduse de implementarea mecanismelor de blocare.

A doua arie poate fi folosita pentru a prezenta operatiile introduse de baza de date atunci cand tabelele sunt deja blocate de alte tranzactii: verificari

ale zavoarelor, in cazul in care resursa dorita este blocata de alta tranzactie, urmate apoi de asteptari pana cand zavoarele sunt ridicate, de primirea mesajului ce confirma ridicarea blocarii, crearea zavoarelor la nevel de inregistrari, executarea tranzatiei, ridicarea zavoarelor.

 

 

 

 

 

 

 

 

 

 

 

 

Atunci cand concurenta este crescuta mai mult (4 conexiuni concurente) aceleasi arii de raspuns pot fi identificate: la 444, 822, 944 si 1388 de secunde in medie.

Se poate inregistra o crestere importanta a timpilor de raspuns, care sunt imprastiati intr-un interval de 1000 de secunde. De asemeni, o serie de tranzactii pornite au esuat (aproximativ 18% din totalul tranzactiilor lansate).

Procentajul tranzactiilor esuate a crescut in mod semnificativ, direct proportional cu factorul de concurenta. De exemplu, atunci cand au fost lansate 10 accese concurente la baza de date, procentajul conexiunilor esuate a crescut la peste 60%.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ii. Microsoft SQLServer

Pentru o singura conexiune la baza de date, timpii de raspuns obtinuti in cazul SQL Server s-au situat intre 100 si 500 de secunde, grupati catre inceputul intervalului. Dimensiunile insemnate ale acestui interval pot fi explicate prin lispa memoriei la unele sisteme testate. Atunci cand cantitatea memoriilor RAM a crescut, timpii de raspuns s-au incadrat in intervalul 100 – 200 de secunde.

Atunci cand nivelul concurentei a fost crescut la doua conexiuni simultane, timpii de raspuns s-au mentinut aproximativ aceiasi ca in cazul unei singure conexiuni. Aceleasi arii de grupare se pot observa si in acest caz, inregistrandu-se intre 140 si 555 de secunde pe tranzactie (timpi medii)

Mai multe tranzactii, insa, s-au terminat mai tarziu datorita insuficientei unor resurse.

Marind concurenta, SQL Server a inregistrat timpi de raspuns care s-au incadrat in aceleasi sabloane ca in cazurile anterioare. Multe dintre tranzactii s-au terminat intre 55 si 600 secunde. Din nou trebuie mentionat rolul extrem de important al resurselor sistemului in distributia timpilor de raspuns.

 

 

Tranzactia Payment

i. Microsoft Acces

Pentru o singura conexiune la baza de date, timpii de raspuns ai tranzactiilor s-au situat in mod constant intre 5 si 15 secunde.

 

Dupa cum era de asteptat, atunci cand nivelul concurentei a crescut, timpii de raspuns s-au modificat si ei in mod corespunzator. Astfel ei au atins valori situate intre 305 si 360 de secunde pentru o tranzactie de tip Payment executata.

ii. Microsoft SQLServer

Pentru o singura conexiune la baza de date, timpii de raspuns s-au incadrat intre 15 si 25 de secunde.

Aceeasi distributie a timpilor de raspuns se observa si atunci cand se ridica nivelul concurentei la 2 sau patru conexiuni simultane, si acest fapt se poate observa in diagramele de mai jos.

Trebuie mentionat faptul ca se observa cu usurinta faptul ca SQL Server prezinta o acceasi forma a distributiei in cele doua cazuri mentionate. Desi cazul celor 4 conexiuni simultane dispune de mai multe rezultate (de aici datorandu-se forma graficului cu mai multe “asperitati”), se poate vedea ca forma distributiei este aceeasi, singurele care difera fiind valorile timpilor de raspuns.

a. Comentarii pe marginea rezultatelor

Primul rand de teste au fost executate intr-un mediu neconcurent. Am observat ca atat SQLServer cat si Access au fost extrem de dependente de arhitectura sistemului, dar si de puterea de calcul. Am inregistrat diferente semnificative intre rezultatele obtinute pe un Pentium III 800 Mhz, fata de un Pentium II cu 450 Mhz.

Un alt aspect important, care trebuie mentionat, este faptul ca Access a inregistrat un comportament mai bun decat SQLServer in aceste caz, asa cum era de asteptat, insa. Este un rezultat normal, si una dintre explicatii este aceea ca Access dispune de o cantitate redusa de operatii suplimentare.

De asemeni, am studiat doua tipuri de acces: folosind TCP/IP si folosind accesul local. SQL Server a inregistrat o diferenta semnificativa intre cele doua cazuri, in timp ce Access a fost relativ constant.

Al doilea tip de teste au fost efectuate intr-un mediu concurent. Am observat faptul ca Microsoft Access a inregistrat un bun comportament si in acest caz, iar performantele au fost comparabile cu cele obtinute de SQL Server.

Rezultatele au confirmate, si in aceste caz, concluziile noastre privitoare la dependenta rezultatelor obtinute de SQL Server si Access de tipul de acces.

Studiind, insa, rezultatele obtinute intr-un mediu de mare concurenta, am observat, mai intai, faptul ca Microsoft Access a avut timpi foarte mari de raspuns, si un mare numar de tranzactii nereusite. Este, din nou, un fapt normal, intrucat Microsoft Access nu este proiectat si destinat utilizarii in regim de concurenta ridicata, avand o evidenta lipsa a facilitatilor pentru accesul concurent.

Un alt aspect important care trebuie mentionat este faptul ca SQL Server a inregistrat pe toata durata testelor, un comportament aproximativ constant si un numar redus de rollback-uri (datorate tranzactiilor esuate), iar rezultatele au fost doar intr-o masura mai redusa dependente de puterea de calcul.

 

 

 

 

 

 

 

 

4. Consideratii finale

 

O primă concluzie ce se poate trage este aceea că pe plan mondial se pune tot mai mult problema accelerării, creării şi perfecţionării sistemelor de gestiune de baze de date, precum şi a perfecţionării sistemelor informatice.

Un element fundamental în aprecierea acestor sisteme este timpul de răspuns, căutându-se tehnici tot mai eficiente pentru minimizarea acestuia, scopul principal fiind maximizarea profiturilor, utilizarea eficientă a resurselor, a serviciilor, creşterea producţiei, un cât mai mare confort al clientului, şi implicit, aprecierea cât mai bună a sistemului propriu. Toate acestea se pot obţine prin o optimizare a performanţelor sistemelor informatice, optimizare care devine posibilă prin studiul direct al parametrilor indicatori de performanţă.

În consecinţă, evaluarea performanţelor sistemelor cu baze de date, deşi nu este spectaculoasă, este deosebit de necesară, relevând informaţii extrem de importante pentru o bună desfăşurarea a activităţii sistemului.

Mai trebuie specificat faptul că performanţele unui sistem informatic cu baze de date pot fi privite din foarte multe puncte de vedere, complexitatea acestora fiind dată de multitudinea elementelor ce compun un sistem informatic, a etapelor lui de construire, precum şi a elementelor software ce fac posibilă rularea unei aplicaţii cu baze de date. Fiecare parametru indicator al performanţei este

important, şi determină, într-o măsură mai mare sau mai mică, comportamentul întregului sistem.

In lucrarea de fata am prezentat modelul testului TPC-C35, incercand efectuarea unei analize cat mai detaliate si usor de inteles asupra modului de acces la inregistrarile din bazele de date.

Este un aspect care trebuie luat in calcul in mod serios, intrucat influenteaza foarte mult timpii de incheiere a tranzactiilor, si implicit parametri indicatori ai performantei. Chiar daca studiul nu este si nici nu poate fi complet (cercetarile in domeniu fiind abia la inceput), el ofera informatii relevante referitoare la compunerea unui timp de raspuns al bazei de date la o anumita tranzactie.

Intr-un mediu real, relatiile elementelor vor fi modificate fara o frecventa bine definita si controlata, astfel incat trebuiesc luate anumite precautii. Cunoasterea cat mai amanuntita a elementelor ce compun comportamentul unui sistem de gestiune a bazelor de date este absolut necesara si duce intotdeauna la crearea cat mai rapida a unei situatii controlabile, favorabila exploatarii aplicatiilor in bune conditii. Ceea ce inseamna, in final, o buna apreciere din partea utilizatorilor finali.

Relativ la partea a doua a lucrarii, destinata testelor efectuate cu ajutorul TPC-C35, trebuie remarcat comportamentul constant al serverului de baze de date SQL Server, chiar si atunci cand au fost introduce tranzactii complexe, cu cereri imbricate, cu inserari si modificari multiple. Un exemplu ar putea fi numarul de tranzactii New-Order executate intr-un minut.

De asemeni, trebuie mentionat faptul ca Microsoft Access a inregistrat, in multe cazuri, timpi superiori lui SQL Server. Explicatia este simpla: nu include facilitati de jurnalizare a tranzactiilor, si nici alte operatiuni suplimentare (de background). Acest lucru este tradus intr-un timp mai scurt de procesare a tranzactiilor, dar acest avantaj este platit printr-un numar redus de facilitati.

 

5. Cuprins

 

 

[pag]

1. Introducere ............................................................................ 3

a. Sisteme de gestiune a bazelor de date ....................... 3

b. Teste de evaluare a performantelor bazelor de date ... 7

2. Modelul testului TPC-C35 ...................................................... 13

a. Prezentare generala .................................................... 13

b. Elemente de testare speciale interzise ....................... 15

c. Modelul aplicatiei si al mediului real ............................ 16

d. Sabloane de acces pentru tranzactii ............................ 21

Tranzactia New-Order ............................................ 21

Tranzactia Payment ............................................... 21

Tranzactia Order Status ......................................... 22

Tranzactia Delivery ................................................ 22

Tranzactia Stock Level ........................................... 23

e. Analiza accesului imprastiat la date in cazul TPC-C ..... 24

f. Modelul sistemului si estimari ale performantei ............. 26

3. Implementarea testului TPC-C35 ........................................... 31

a. Prezentare preliminara ................................................. 31

b. Implementarea testului TPC-C35 ................................. 34

c. Rezultatele testelor ....................................................... 35

Tranzactia New-Order ............................................ 36

Tranzactia Payment ............................................... 40

d. Comentarii pe marginea rezultatelor ............................ 42

4. Consideratii finale ................................................................... 44

5. Cuprins .................................................................................... 46

6. Bibliografie .............................................................................. 47

 

6. Bibliografie

 

 

 

[1] prof. dr. ing. Petrescu, M, “Baze de date”, note de curs

[2] prof. dr. ing. Petrescu, M., “Proiectarea bazelor de date”, note de

curs

[3] prof. dr. ing. Petrescu, M., Popeanga, ., Vasilescu, R., “The TPC-C Database Performance Benchmarking System. Analysis and Experiments”, Conferinta Bucuresti, Universitatea Politehnica Bucresti, mai 2001

[4] prof. dr. ing. Petrescu, M, Popeanga, D., Vasilescu, R., “Performance Evaluation in Databases. Analysis and Experiments”, Transactions on Automatic Control and Computer Science, pg. 153-158, special issue of “Buletinul stiintific al Universitatii Politehnica Timisoara”, vol 45(59), No. 4, 2000

[5] TPC-C35 Benchmark Specification, www.tpc.org

[6] Ullman, J., D., “Principles of Databases Systems”, Comp. Science Press, 1983

[7] Leutenegger, Scott, “A Modeling Study of the TPC-C Benchmark”, Institute for Computer Applications in Science and Engineering

[8] Doppelhammer, J., Hoppler, T., Kemper, T., “Database Performance in the Real World”, Passau University

[9] Burgess, G., “What is the TPC good for? The Top Ten Reasons in Favor of TPC Benchmarks”, Ideas International