V današnjem prispevku se pogovorimo o arhitekturi HBase. Očiščimo osnove HBase, preden se poglobimo v arhitekturo HBase.
pretvori niz v datum v
HBase - osnove:
HBase je odprtokodna, NoSQL, distribuirana, nerelacijska, različna, večdimenzionalna, stolpčno usmerjena trgovina, ki je bila oblikovana po vzoru Googlove velike tabele, ki deluje na vrhu HDFS. 'NoSQL' je širok izraz, ki pomeni, da baza podatkov ni RDBMS, ki podpira SQL kot primarni jezik dostopa. Vendar obstaja veliko vrst baz podatkov NoSQL in Berkeley DB je dober primer lokalne baze podatkov NoSQL, medtem ko je HBase zelo porazdeljena baza podatkov.
HBase ponuja vse funkcije Google BigTable. Začel se je kot projekt podjetja Powerset za obdelavo ogromnih količin podatkov za iskanje v naravnem jeziku. Razvit je bil v okviru Apachejevega projekta Hadoop in deluje na vrhu HDFS (Hadoop Distributed File System). Zagotavlja odporne načine shranjevanja velikih količin redkih podatkov. HBase je res bolj »shramba podatkov« kot »baza podatkov«, ker mu manjka veliko funkcij, ki so na voljo v RDBMS, kot so tipkani stolpci, sekundarni indeksi, sprožilci in napredni jeziki za poizvedbe itd.
V stolpcih usmerjenih zbirkah podatkov je tabela shranjena kot odseki stolpcev podatkov in ne kot vrstice podatkov. Podatkovni model zbirke podatkov usmerjene baze podatkov sestavljajo ime tabele, ključ vrstice, družina stolpcev, stolpci, časovni žig. Med ustvarjanjem tabel v HBase bodo vrstice enolično identificirane s pomočjo tipk vrstic in časovnega žiga. V tem podatkovnem modelu so družine stolpcev statične, stolpci pa dinamični. Zdaj pa poglejmo v arhitekturo HBase.
Kdaj se odločiti za HBase?
HBase je dobra možnost le, če je na stotine milijonov ali milijard vrstic. HBase je mogoče uporabiti tudi mestoma, ko razmišljate o prehodu z RDBMS na HBase kot popolno prenovo v nasprotju z vrati. Z drugimi besedami, HBase ni optimiziran za klasične transakcijske aplikacije ali celo relacijsko analitiko. Prav tako ni popoln nadomestek za HDFS pri izvajanju velikih serij MapReduce. Zakaj bi potem uporabljali HBase ?? Če ima vaša aplikacija spremenljivo shemo, kjer se vsaka vrstica nekoliko razlikuje, si oglejte HBase.
Arhitektura HBase:
Naslednja slika jasno razlaga arhitekturo HBase.
V HBase so tri glavne komponente: Poveljnik, strežnik regije in skrbnik živalskega vrta . Druge komponente so Memstore, HFile in WAL.
ec2 ustvari primerek iz posnetka
Ko HBase deluje na vrhu HDFS, uporablja arhitekturo Master-Slave, v kateri bo HMaster glavno vozlišče, Regijski strežniki pa podrejena vozlišča. Ko odjemalec pošlje zahtevo za pisanje, HMaster dobi to zahtevo in jo posreduje ustreznemu strežniku regije.
Regijski strežnik:
Gre za sistem, ki deluje podobno kot podatkovno vozlišče. Ko regijski strežnik (RS) prejme zahtevo za pisanje, jo usmeri v določeno regijo. Vsaka regija shrani niz vrstic. Podatke o vrsticah je mogoče ločiti v več družin stolpcev (CF). Podatki določenega CF so shranjeni v HStore, ki ga sestavljajo Memstore in nabor datotek HFiles.
Kaj počne Memstore?
Memstore beleži vse dnevnike za operacije branja in pisanja, ki so bile izvedene znotraj tega določenega strežnika regije. Iz tega lahko rečemo, da deluje podobno kot imensko vozlišče v Hadoopu. Memstore je pomnilnik v pomnilniku, zato Memstore uporablja pomnilnik vsakega podatkovnega vozlišča za shranjevanje dnevnikov. Ko so določeni pragovi doseženi, se podatki Memstorea odstranijo v HFile.
Ključni namen uporabe Memstorea je potreba po shranjevanju podatkov v DFS, razvrščenih po ključu vrstice. Ker je HDFS zasnovan za zaporedno branje / pisanje, brez dovoljenih sprememb datotek, HBase ne more učinkovito zapisovati podatkov na disk, ko so prejeti: zapisani podatki ne bodo razvrščeni (če vhod ni razvrščen), kar pomeni, da ni optimiziran za prihodnost iskanje. Da bi rešili to težavo, vmesni pomnilnik HBase nazadnje prejme podatke v pomnilnik (v Memstoreju), jih razvrsti pred izpiranjem in nato s hitrim zaporednim zapisovanjem zapiše v HDFS. Zato HFile vsebuje seznam razvrščenih vrstic.
Vsakič, ko pride do izpiranja Memstoreja, se za vsak CF ustvari HFile in pogosti izpiri lahko ustvarijo tone datotek HFiles. Ker bo med branjem HBase moral gledati številne datoteke HFi, lahko hitrost branja trpi. Da bi preprečili odpiranje preveč datotek HFiles in se izognili poslabšanju učinkovitosti branja, se uporablja postopek stiskanja HFiles. HBase bo občasno (ko bodo izpolnjeni določeni nastavljivi pragovi) več manjših datotek HFi strnil v velikega. Očitno je, da več datotek, kot jih ustvari Memstore, več dela (več obremenitve) za sistem. Če k temu dodamo, da se postopek stiskanja običajno izvaja vzporedno z vročanjem drugih zahtev in če HBase ne more slediti stiskanju datotek HFiles (da, tudi za to obstajajo nastavljeni pragovi), bo znova blokiral zapisovanje na RS. Kot smo že omenili, je to zelo nezaželeno.
Ne moremo biti prepričani, da bodo podatki v Memstoreju trajni. Predpostavimo, da določeno podatkovno vozlišče ne deluje. Potem se bodo podatki, ki se nahajajo v pomnilniku tega vozlišča, izgubili.
Če želite odpraviti to težavo, jo zahteva, ko jo pošlje glavni, tudi napiše v WAL. WAL ni nič drugega kot Zapišite dnevnike naprej ki je nameščen na HDFS, stalno skladišče. Zdaj lahko zagotovimo, da tudi če podatkovno vozlišče ne deluje, se podatki ne bodo izgubili, tj. imamo kopijo vseh dejanj, ki bi jih morali storiti v WAL-u. Ko je podatkovno vozlišče gor, bo znova izvedlo vse dejavnosti. Ko je operacija končana, se vse izbriše iz Memstorea in WAL-a in je zapisano v HFile, da zagotovimo, da nam ne zmanjka pomnilnika.
Vzemimo preprost primer, da želim dodati vrstico 10, potem ko pride zahteva za pisanje, pravi, da daje vse meta podatke v Memstore in WAL. Ko je ta vrstica zapisana v HFile, se vse v Memstoreju in WAL izbriše.
Oskrbnik živalskega vrta:
HBase je integriran z Zoo čuvajem. Ko zaženem HBase, se zažene tudi primerek skrbnika živalskega vrta. Razlog je v tem, da nam skrbnik živalskega vrta pomaga pri sledenju vseh regijskih strežnikov, ki so na voljo za HBase. Izobraževalec živalskega vrta beleži, koliko regijskih strežnikov je, katere regijske strežnike imajo od katerega podatkovnega vozlišča do katerega vozlišča podatkov. Spremlja manjše nabore podatkov, kjer Hadoop manjka. Zmanjša režijske stroške na vrhu Hadoopa, ki spremlja večino vaših meta podatkov. Zato HMaster dobi podatke o regionalnih strežnikih, tako da se dejansko obrne na skrbnika živalskega vrta.
Imate vprašanje za nas? Omenite jih v oddelku za komentarje in javili se vam bomo.
struktura podatkov čakalne vrste v javi
Sorodne objave: