Insights on HBase Architecture



Această postare discută despre HBase și informații despre arhitectura HBase. De asemenea, se discută despre componentele Hbase, cum ar fi Master, serverul de regiune și Zoo Keeper și cum să le utilizați.

În postarea de astăzi, să discutăm despre Arhitectura HBase. Să analizăm elementele de bază ale HBase înainte de a aprofunda arhitectura HBase.





HBase - Noțiuni de bază:

HBase este un magazin open-source, NoSQL, distribuit, non-relațional, versionat, multidimensional, orientat pe coloane, care a fost modelat după Google BigTable care rulează pe HDFS. '' NoSQL 'este un termen larg care înseamnă că baza de date nu este un RDBMS care acceptă SQL ca limbaj de acces principal. Dar există multe tipuri de baze de date NoSQL și Berkeley DB este un bun exemplu de bază de date NoSQL locală, în timp ce HBase este foarte mult o bază de date distribuită.

HBase oferă toate caracteristicile Google BigTable. A început ca proiect al Powerset de a procesa cantități masive de date pentru căutarea în limbaj natural. A fost dezvoltat ca parte a proiectului Hadoop al lui Apache și rulează pe partea superioară a HDFS (Hadoop Distributed File System). Oferă modalități tolerante la erori de stocare a unor cantități mari de date rare. HBase este într-adevăr mai mult un „Magazin de date” decât „Baza de date”, deoarece îi lipsesc multe dintre caracteristicile disponibile în RDBMS, cum ar fi coloanele tastate, indexurile secundare, declanșatoarele și limbile de interogare avansate etc.



la ce folosește serializarea în java

În bazele de date orientate pe coloane, tabelul de date este stocat ca secțiuni de coloane de date mai degrabă decât ca rânduri de date. Modelul de date al bazei de date orientate pe coloane constă din numele tabelului, cheia rândului, familia coloanelor, coloanele, ștampila de timp. În timp ce creați tabele în HBase, rândurile vor fi identificate în mod unic cu ajutorul cheilor de rând și a ștampilei de timp. În acest model de date, familia de coloane este statică, în timp ce coloanele sunt dinamice. Acum să analizăm Arhitectura HBase.

Când să mergi pentru HBase?

HBase este o opțiune bună numai atunci când există sute de milioane sau miliarde de rânduri. HBase poate fi, de asemenea, utilizat în anumite locuri atunci când vă gândiți să treceți de la un RDBMS la HBase ca o reproiectare completă, spre deosebire de un port, cu alte cuvinte, HBase nu este optimizat pentru aplicații tranzacționale clasice sau chiar analize relaționale. De asemenea, nu este un substitut complet pentru HDFS atunci când faceți MapReduce în loturi mari. Atunci de ce ar trebui să mergi pentru HBase ?? Dacă aplicația dvs. are o schemă variabilă în care fiecare rând este ușor diferit, atunci ar trebui să vă uitați la HBase.

Arhitectura HBase:

Următoarea figură explică în mod clar Arhitectura HBase.



Insights on HBase Architecture

În HBase, există trei componente principale: Maestru, server de regiune și păstrător de grădină zoologică . Celelalte componente sunt Memstore, HFile și WAL.

Pe măsură ce HBase rulează pe partea superioară a HDFS, folosește arhitectura Master-Slave în care HMaster va fi nodul master și serverele de regiune sunt nodurile slave. Când clientul trimite o cerere de scriere, HMaster primește acea solicitare și o trimite la respectivul server de regiune.

Server regiune:

Este un sistem care acționează similar cu un nod de date. Când serverul de regiune (RS) primește o cerere de scriere, acesta direcționează cererea către o anumită regiune. Fiecare regiune stochează un set de rânduri. Datele pe rânduri pot fi separate în mai multe familii de coloane (CF). Datele anumitor CF sunt stocate în HStore, care constă din Memstore și un set de fișiere HFile.

Ce face Memstore?

Memstore ține evidența tuturor jurnalelor pentru operațiile de citire și scriere care au fost efectuate pe acel server de regiune special. Din aceasta putem spune că acționează similar cu un nod de nume din Hadoop. Memstore este o stocare în memorie, prin urmare Memstore utilizează stocarea în memorie a fiecărui nod de date pentru a stoca jurnalele. Când anumite praguri sunt îndeplinite, datele Memstore sunt transferate în HFile.

Scopul cheie pentru utilizarea Memstore este necesitatea de a stoca date pe DFS ordonate după cheia de rând. Deoarece HDFS este proiectat pentru citiri / scrieri secvențiale, fără a permite modificări de fișiere, HBase nu poate scrie în mod eficient date pe disc pe măsură ce sunt recepționate: datele scrise nu vor fi sortate (când intrarea nu este sortată) ceea ce înseamnă că nu este optimizat pentru viitor regăsire. Pentru a rezolva această problemă, bufferele HBase au primit ultima dată datele în memorie (în Memstore), le „sortează” înainte de spălare și apoi scrie pe HDFS folosind scrieri secvențiale rapide. Prin urmare, HFile conține o listă de rânduri sortate.

c c # c ++

De fiecare dată când Memstore flush are loc un fișier HF creat pentru fiecare CF și frecvente flushes pot crea tone de HFiles. Deoarece în timpul lecturii HBase va trebui să se uite la multe fișiere HF, viteza de citire poate suferi. Pentru a preveni deschiderea prea multor fișiere HF și pentru a evita deteriorarea citirii performanței, se utilizează procesul de compactare HFiles. HBase va periodic (atunci când anumite praguri configurabile sunt îndeplinite) compactează mai multe fișiere HF mai mici într-unul mare. Evident, cu cât sunt mai multe fișiere create de Memstore, cu atât mai multă muncă (încărcare suplimentară) pentru sistem. În plus, în timp ce procesul de compactare se efectuează de obicei în paralel cu servirea altor cereri și când HBase nu poate ține pasul cu compactarea HFile (da, există și praguri configurate pentru asta), va bloca din nou scrierile pe RS. Așa cum am discutat mai sus, acest lucru este extrem de nedorit.

Nu putem fi siguri că datele vor fi persistente pe tot parcursul Memstore. Să presupunem că un anumit datanod este defect. Apoi, datele care se află pe memoria acelui nod de date se vor pierde.

Pentru a depăși această problemă, atunci când cererea vine de la comandant, aceasta a fost scrisă și către WAL. WAL nu este altceva decât Scrieți jurnale înainte care se află pe HDFS, un spațiu de stocare permanent. Acum ne putem asigura că, chiar dacă nodul de date este în jos, datele nu se vor pierde, adică. avem copia tuturor acțiunilor pe care ar trebui să le faceți în WAL. Când nodul de date este activ, acesta va efectua din nou toate activitățile. Odată ce operațiunea este finalizată, totul este eliminat din Memstore și WAL și este scris în HFile pentru a ne asigura că nu rămânem fără memorie.

Să luăm un exemplu simplu că vreau să adaug rândul 10, apoi intră cererea de scriere, spune că oferă toate datele meta Memstore și WAL. Odată ce acel rând special este scris în HFile, totul în Memstore și WAL sunt eliminate.

Ingrijitor zoo:

HBase vine integrat cu Zoo Keeper. Când pornesc HBase, este pornită și instanța Zoo Keeper. Motivul este că păstrătorul de grădină zoologică ne ajută să păstrăm o evidență a tuturor serverelor regionale care sunt acolo pentru HBase. Zoo Keeper ține evidența numărului de servere de regiune care există, ce servere de regiune dețin de la ce nod de date la ce nod de date. Ține evidența seturilor de date mai mici în care Hadoop lipsește. Scade cheltuielile generale de pe partea de sus a Hadoop, care ține evidența majorității datelor dvs. Meta. Prin urmare, HMaster primește detaliile serverelor regionale contactând efectiv deținătorul Zoo.

Ai o întrebare pentru noi? Menționați-le în secțiunea de comentarii și vă vom răspunde.

ce sunt jetoanele în java

Postări asemănatoare:

Comenzi utile de stup