Concepte baze de date distribuite 513
Fig. 29.2. Servere distribuite
În mod ideal, clienții nu știu dacă sistemul este distribuit sau nu. Ei își trimit doar cererile și sistemul returnează rezultatele acestor cereri clienților. Cum o face, clienții nu sunt interesați. În practică, bazele de date distribuite prezintă transparență diferită. În cazuri extreme, RDB-ul este stocat pe mai multe servere independente, iar aplicația client trebuie să aleagă serverul, în funcție de ce informații trebuie să obțină. Aceasta implică faptul că tabelele de pe diferite servere nu au conexiuni interne. Bineînțeles, o astfel de organizare a RDB este doar ocazional utilă.
Sistemul de gestionare a bazelor de date distribuite, sau RDBMS, oferă clienților o interfață unificată de acces la date, prin care apare iluzia unui singur server. Dacă datele se află în diferite locuri, RDBMS trimite interogări și actualizări către depozitele corespunzătoare. În funcție de spațiul de stocare utilizat, performanța sistemului poate fi diferită, dar cel puțin clienții nu trebuie să aleagă serverul în sine.
Dacă datele sunt reproduse între mai multe servere, clientul poate prefera, în general, un anumit server. Într-o schemă similară, toate serverele stochează aceleași date. Un modul special poate ajuta clienții să selecteze serverele, realizând echilibrarea încărcării. RDBMS este responsabil pentru efectuarea tranzacțiilor într-un mediu multi-server, dar în orice moment două servere nu pot fi sincronizate între ele.
RDB utilizează mai multe scheme de distribuire a datelor. În cazul replicării, fiecare server stochează întreaga cantitate de date. Acest lucru necesită ca RDBMS să copieze tranzacțiile, permițând tuturor clienților să vadă o imagine consistentă a bazei de date. În cazul separării de date neechilibrate, se selectează nivelul de segmentare. La cel mai înalt nivel, bazele de date individuale sunt supuse divizării, dar nu și tabelelor. Fiecare masă este în întregime într-un singur loc. La un nivel inferior, tabelele sunt împărțite în rânduri sau coloane. De exemplu, cu divizare orizontală, subseturile individuale de înregistrări sunt plasate în diferite depozite, iar cu divizarea verticală se formează subseturi pe baza coloanelor.
Este destul de ușor să creați o copie exactă a bazei de date MySQL. Metodele de fundamentare a bazelor de date au fost descrise în capitolul 25, Eliminarea consecințelor dezastrelor. În ceea ce privește recuperarea datelor, se poate face pe orice server. Cu astfel de instrumente, este ușor să implementați o bază de date distribuită, care este sincronizată la intervale suficient de mari, de exemplu o dată pe zi.
Luați în considerare problema actualizării datelor. Dacă actualizările apar pe două servere simultan, acestea trebuie să fie coordonate. Pentru a evita situațiile insolubile, trebuie să permiteți efectuarea unor modificări pe un singur server. Apoi sincronizarea va consta în duplicarea conținutului serverului disponibil pentru scriere la toate celelalte servere. Utilitatea lor depinde de cât de importantă este relevanța datelor. În multe cazuri, o bază de date care conține toate înregistrările, altele decât cele create în ultimele 24 de ore, este destul de acceptabilă.
Tehnica de sincronizare întârziată este ideală pentru bazele de date care conțin rezultatele rapoartelor de noapte. De exemplu, un site Web care oferă acces poate înregistra numele cântecelor solicitate și poate compila ratinguri de popularitate. O dată pe zi, toate serverele trimit jurnalele lor la serverul principal, care actualizează evaluările conform noilor statistici. Schema unei astfel de baze de date este prezentată în listă
Listing 29.1. ISiXBMiijajfn / ieiViw
/ * Director de fișiere MP3. * / CREATE TABLE cântec (
ID INT NOT NULL INCREMENT AUTO,
Nume CHAR (4 0) NU NULL,
Artistul CHAR (16) NU NULL,
Numele de fișier CHAR (80) NOT NULL,
/ * Jurnalul fișierelor solicitate, * / CREATE TABLE log (
Serverul TINYINT UNSIGNED NOT NULL,
Song INT NOT NULL,
DownloadTime DATETIME NOT NULL
Fiecare server stochează informații despre melodiile disponibile în tabelul de melodii. Jurnalul este înregistrat de fiecare dată când cineva descarcă următorul. Acest tabel nu are o cheie primară, deoarece în modul normal este folosit numai pentru inserarea înregistrărilor. Prezența indexului va încetini doar lucrul cu masa.
O dată pe zi, tabelele de jurnal ale tuturor serverelor sunt combinate în conformitate cu următorul scenariu. Unul dintre servere nu mai servește cererilor de aplicații web. Celelalte servere creează copii ale tabelei de jurnal, extrag ultimele înregistrări din ele și le trimit
serverul lor care generează raportul. Pentru durata acestei proceduri, fiecare server trebuie să-și închidă tabelul de jurnal. Pentru a împiedica blocarea prea multor solicitări de utilizatori, este recomandat să efectuați procedura în timpul perioadei minime de activitate a serverului.
CREAȚI INDEX piesa ON log (Song);
/ * Determinați evaluarea tuturor melodiilor. * / DROP TABLE DACĂ EXISTĂ populare tot timpul; CREATE TABLE populare alitime (
Clasa INT NOT NULL, Song INT NOT NULL, Hits INT NOT NULL
INTRODUCEȚI ÎN TOATE populare
ALTER TABLE popular alItime ADD PRIMARY KEY (clasare);
/ * Definiția ratingului melodiilor în ultimele 24 de ore. * / DROP TABLE IF EXISTĂ popular last24; CREATE TABLE popular last24 (
Poziția INT NOT NULL, Song INT NOT NULL,
Hits INT NOT NULL
INSCRIERE IN popular last24
SELECT (@id: = @ id + l), Song, COUNT (*) FROM Jurnal
WHERE DownloadTime> DATA SUB (ACUM (), INTERVAL 2 4 ORE)
ORDER CU 3 DESC; ALTER TABLE popular last24 ADAUGATI KEY PRIMARY (rang);
/ * Eliminarea Kca. * / DROP INDEX melodie ON log;
Articole similare
Trimiteți-le prietenilor: