xmldeveloper:
Articolul asta e destul de vag, nu prea intra in detalii. Pentru a arata cat de "tare" e SQL Server 2000, Microsoft a realizat o implementare cu servere multiple care la vremea respectiva (2000) era cea mai mare baza de date expusa pe Internet (daca nu ma insel 140TB) si continea o vasta colectie de fotografii realizate de satelitii NASA. Iata cum se face concret o asemenea implementare:
- Se defineste baza de date principala (front-end server) pe SQL Server Enterprise Edition (singurul care suporta Indexed Views), cu un calcul atent de planning astfel incat acest server sa poata gazdui tabelele mici, indecsii tabelei principale si un TEMPDB "generos";
- Se defineste baza de date pe cateva servere secundare (back-end servers), si se implementeaza acolo doar tabela principala, apoi aceste servere se declara ca linked servers in serverul principal; aici Microsoft a folosit tot Enterprise Edition (ca merge mai bine si nu a trebuit sa-si cumpere licente), dar in principiu putem sa folosim si editii mai ieftine;
- Se declara pe serverul front-end un Indexed View care concateneaza datele tabelei principale distribuite pe serverele back-end si care e folosit pe post de tabela principala in aplicatie.
- Se implementeaza un algoritm de hashing prin care sa se decida pe care din serverele back-end trebuie sa stea un anume rand din tabela principala (la n servere valorile hash sunt 0..n-1);
- Se declara pe Indexed View triggere INSTEAD OF INSERT, INSTEAD OF UPDATE si INSTEAD OF DELETE, care folosing algoritmul de hashing de mai sus delega respectiva operatie serverului back-end responsabil cu respectivul rand de date.
Trebuie sa remarcam ca aceasta implementare nu scaleaza orizontal prea grozav: nu putem sa mai adaugam inca un server back-end cand vrem noi, pentru ca asta implica schimbarea algoritmului de hash si ar necesita salvarea si re-incarcarea datelor. Putem totusi dubla numarul de servere si muta jumatate din date pe serverele noi, dar asta implica oricum operatii manuale si script-uri custom.
De asemenea, SQL Server nu e prea "tare" in calcule sau manipulari de string-uri, asa ca calcularea hash-ului pune unele probleme in SQL Server 2000 (Microsoft a folosit o procedura "extinsa", adica scrisa in C++, ca sa evite penalitatile de performanta); aici vestea buna e ca in SQL Server 2005 aceasta problema se poate rezolva elegant implementand algoritmul de hash intr-o functie .NET.
Petru Moldovan, MCSE, MCDBA