Video: Iarna a lovit cu asprime regiuni întinse din SUA. Sute de zboruri au fost anulate 2024
RegionServers este un lucru, dar trebuie să aruncați o privire asupra modului în care funcționează regiunile individuale. În HBase, un tabel este răspândit în mai multe regiuni și este alcătuit din regiuni individuale. Pe măsură ce tabelele sunt împărțite, divizările devin regiuni. Regiunile stochează o serie de perechi cheie-valoare și fiecare regiune gestionează un număr configurabil de regiuni.
Dar cum arata regiunile individuale? HBase este un magazin de date orientat pe coloane și familii, deci cum regiuni individuale stochează perechi cheie-valoare pe baza familiilor din coloane din care fac parte? Următoarea figură începe să răspundă la aceste întrebări și vă ajută să găsiți mai multe informații vitale despre arhitectura HBase.
HBase este scris în Java - ca majoritatea tehnologiilor Hadoop. Java este un limbaj de programare orientat obiect și o tehnologie elegantă pentru calculul distribuit. Deci, pe măsură ce veți afla mai multe despre HBase, amintiți-vă că toate componentele din arhitectură sunt în cele din urmă obiecte Java.
În primul rând, figura precedentă oferă o idee destul de bună despre cum arată obiectele regiunii, în general. De asemenea, clarifică faptul că regiunile separă datele în familii de coloane și stochează datele în HDFS utilizând obiecte HFile.
Când clienții pun perechi cheie-valoare în sistem, cheile sunt procesate astfel încât datele să fie stocate pe baza familiei de coloane din care face parte perechea. După cum se arată în figură, fiecare obiect de stocare a familiei coloane are o cache de citire numită BlockCache și o memorie cache numită MemStore. BlockCache ajută la performanța citită aleatoriu.
Datele sunt citite în blocuri din HDFS și stocate în BlockCache. Citirea ulterioară a datelor - sau a datelor stocate în imediata vecinătate - va fi citită din memoria RAM în loc de disc, îmbunătățind performanța generală. Jurnalul de scriere în aval (WAL, scurt) asigură faptul că înregistrările dvs. HBase sunt fiabile. Există un WAL pe Regiune.
Respectați întotdeauna Legea fierului de calcul distribuit: Un eșec nu este excepția - este norma, mai ales când se clusteriază sute sau chiar mii de servere. Google a urmat Legea fierului în proiectarea BigTable, iar HBase a urmat exemplul.
Când scrieți sau modificați date în HBase, datele sunt mai întâi persistente la WAL, care este stocată în HDFS și apoi datele sunt scrise în cache MemStore. La intervale configurabile, perechile cheie-valoare stocate în MemStore sunt scrise în HFiles în HDFS și apoi intrările WAL sunt șterse.
Dacă un defect apare după WAL scrie inițial, dar înainte de MemStore-ul final scrie pe disc, WAL poate fi replayat pentru a evita pierderea de date.
Trei obiecte HFile sunt într-o singură familie de coloane și două în cealaltă. Designul HBase este de a șterge datele familiei de coloane stocate în MemStore la un HFile per culoare. Apoi, la intervale configurabile, HFiles sunt combinate în HFiles mai mari. Această strategie cade în întâmpinarea operației critice de compactare în HBase.
