|
Detalii Tehnice > Baze de date |
|
||||||||||||||||||
|
||||||||||||||||||
|
||||
|
Baze de Date
Unul dintre principale scopuri pe care am incercat sa le atingem a fost acela de a creea o aplicatie care sa nu necesite costuri pentru licente suplimentare. Serverul de baze de date este cea mai importanta componenta din arhitectura aleasa, avand cel mai mare impact asupra performantelor obtinute. Pe piata exista destul de multe solutii, unele dintre ele veniind de la companii de renume, altele din comunitatea Open-Source. De aceea in alegerea facuta a trebuit sa luam in considerare mai multe servere si sa vedem cum fac fata cerintelor noastre. Solutiile cele mai populare de pe piata ar fi Oracle9i Standard Edition sau Entreprise edition si Microsoft SQL Server 2000 Standard Edition sau Entreprise edition. Desi ambele produse sunt de o calitate foarte buna si reprezinta practic standarde de performanta spre care tind si alte companii singura problema care ne-a dus la evitarea alegerii lor in prima faza a fost costul. Desi preturile de pe piata romaneasca difera probabil se poate observa ca pentru a putea beneficia de unul dintre aceste servere trebuie platit un pret foarte mare (mai mare chiar decat pretul aplicatiei in sine). Intentia noastra era realizarea unui produs care sa fie accesibil unui numar cat mai mare de firme. Cum tinta principala este piata romaneasca am considerat ca aplictia ar trebui sa nu se bazeze pe produse care costa peste 5000 USD. De asemenea trebuia avuta in vedere si posibilitate de a putea face upgrade-uri la hardware fara a fi nevoie sa achizitionam noi licente. De exemplu pentru trecerea la o configuratie cu 2 procesoare era necesara o licenta de 10000 - 30000 USD. Se mai punea problema daca o investitie in niste aplicatii atat de scumpe este justificata de facilitatile si performantele acestora. Din aceste motive am decis sa ne indreptam atentia catre produsele Open-Souce (licente de tip GPL).
Prima si cea mai cunoscuta varianta ar fi MySQL. MySQL Standard include motorul de stocare standard MySQL si motorul InnoDB. InnoDB este un motor de baze de date tanzactional, conform cu ACID, suportand commit, rollback, crash recovery si capabilitati de lock-ing la nivel de rand. MySQL Standard foloseste o licenta standard GPL. Suport pentru tranzactii: Serverul permite alegerea motor-ului care va fi folosit la creearea tabelelor in functie de necesitati. Daca este nevoie de lock la nivel de rand sau de suport pentru tranzactii se alege motorul InnoDB. Daca aplicatia este mai simpluta si nu necesita suport pentru tranzactii se poate alege mai vechiul motor MyISAM pentru a obtine performante mai bune. Datorita complexitatii si concurentei mari aplicatia noastra necesita suportul pentru tranzactii. Prin folosirea motorului InnoDB (Berkeley DB) serverul MySQL suporta de asemenea si key straine (supports foreign key constraints). Suport pentru subinterogari: Subinterogarile permit folosirea rezultatului unei interogari in interiorul altei interogari mai mari. MySQL server suporta deja anumite forme ale acestei tehnici. (de exemplu: INSERT INTO ... SELECT ...). Din pacate suportul pentru subinterogari de tipul "nested" (o interogare SELECT in interiorul altei interogari SELECT) va fi disponibil doar de la versiune 4.1 . Acesta este unul dintre cele mai mari dezavantaje ale server-ului MySQL. Suport pentru proceduri stocate si trigger-i: Procedurile stocate pe server permit creearea de functii si subrutine care ruleaza chiar pe serverul de baze de date.Trigger-i reprezinta tot proceduri ce pot fi setate sa se execute la aparitia unor evenimente (INSERT, UPDATE). In acest moment serverul MySQL nu suporta aceste facilitati.De la versiunea 5.0 vor fi suportate procedurile (conform standardului ANSI SQL-99) in mai multe limbaje, iar de la versiunea 5.1 vor fi implementati si trigger-i. Aplicatia noastra incearca sa mute cat mai multe dintre operatiile efectuate spre serverul de baze de date. Astfel se reduce numarul de comunicari intre PHP si baza de date, lucru ce duce evident la o crestere a vitezei semnificativa. Din aceasta cauza se bazeaza intens pe folosirea procedurilor stocate pe serverul de baze de date. Multe dintre operatiile executate pot fi automatizate prin folosirea trigger-ilor. Complexitatea ridicata duce si la necesitatea de a folosi in multe cazuri subinterogari. Astfel alegerea MySQL-ului devine imposibila datorita suportului incomplet pentru subinterogari si lipsa totala a procedurilor stocate pe server.
PostgreSQL este un sistem de management a bazelor de date (object-relational database management system ORDBMS) bazat pe POSTGRES, Versiunea 4.2, dezvoltat la Universitatea Berkeley din California , departamentul de Computer Science. POSTGRES a pionerat multe concepte ce au fost folosite mult mai tarziu in produse comerciale. PostgreSQL este un descendent open-source al codului Berkeley. Suporta SQL92 si SQL99 oferind multe facilitati moderne : - interogari complexe - key straine (foreign keys) - trigger-i - views - integritatea tranzactiilor De asemenea PostgreSQL poate fi extins de catre utilizator in multe feluri, de exemplu prin creearea de noi : - tipuri de date - functii - operatori - functii agregate - metode de indexare - limbaje procedurale Si datorita licentei sale foarte liberale PostgreSQL poate fi folosit, modificat, si distribuit fara nici un cost pentru orice scop. (privat, academic sau chiar comercial). PostgreSQL indeplineste cerintele ACID. ACID (un acronim ce vine de la Atomicity Consistency Isolation Durability) este un cuvant cheie dupa care un motor de baze de date ar trebui evaluat. Iata o descriere rapida a ceea ce inseamna ACID: Atomicitatea - totul sau nimic. Sa presupunem ca avem o tranzactie ce contine un UPDATE, un INSERT si un SELECT. Cu atomicitate, aceste interogari sunt tratate ca o singura unitate, si datorita consistentei (C-ul din ACID) nu exista decat doua rezultate posibile : or toate interogarile reusesc si baza de date este modificata or nici una nu reuseste si baza de date ramane intacta. Acest lucru este foarte important in situatiile in care o aplicatie transfera diverse obiecte intre doua locatii si apare o problema su server-ul dupa executarea unei interogari DELETE si inainte de a se executa INSERT-ul corespunzator. Consistenta - garanteaza ca o tranzactie nu lasa niciodata baza de date intr-o stare "pe jumatate terminata". Daca o parte a unei tranzactii esueaza toate schimbarile facute sunt anulate lasand baza de date ca inainte de inceputul tranzactiei. De exemplu cand se sterge o companie din baza de date ar trebui sterse si locatiile asociate acesteia. O baza de date bine construita nu ar trebui sa permita doar stergerea companiei lasand obiectele asociate acesteia nesterse si fara vreo legatura cu restul datelor. Izolarea - tine tranzactiile separate una de alta pana cand acestea se termina. Izolarea tranzactiilor este tn general configurabila in diverse moduri. De exemplu o tranzactie se poate bloca pana la terminarea alteia. In alt mod o tranzactie vede datele din baza de date cum erau inainte de inceperea celei de a doua tranzactii. Sa presupunem ca un utilizator vrea sa stearga o companie din baza de date si inainte ca tranzactia sa termine de sters si facturile asociate acestei companii un alt utilizator vrea sa faca modificari asupra unei facturi. Daca se foloseste primul model descris mai sus, al doilea utilizator ar trebui sa astepte pana la terminarea operatiunilor de stergere inainte de a incerca sa faca UPDATE pe o factura. Al doilea utilizator ar vedea atunci ca a fost stearsa compania de care apartinea acea factura, ceea ce e mult mai bine decat pierderea schimbarilor fara sa stie de acest lucru. Durabilitate - garanteaza ca baza de date va tine cont de toate schimbarile in asteptare astfel incat server-ul sa poata reveni in urma apariiiei unor erori. De aceea, chiar daca server-ul este scos din priza in mijlocul unei tranzactii, el va reveni la o stare consistenta la repornire. Aceste situatii sunt gestionate tinand un log (transaction log) cu toate tranzactiile care nu au facut inca COMMIT. Datorita consistentei explicate mai sus o tranzactie partial terminata nu va fi scrisa in baza de date in cazul aparitiei unor erori. Cu toate acestea la revenirea dintr-o astfel de eroare, log-ul de tranzactii este examinat si sunt aplicate tranzactiile care au facut COMMIT dar nu au fost inca aplicate. Datorita acestor caracteristici PostgreSQL a indeplinit majoritatea necesitatiilor aplicatiei noastre si a fost ales pentru a sustine baza de date. |
|
|