U današnjem postu razgovarajmo o arhitekturi HBase. Pročistimo naše osnove HBase prije nego što dublje uđemo u HBase arhitekturu.
HBase - osnove:
HBase je open-source, NoSQL, distribuirana, nerelacijska, verzionirana, višedimenzionalna, orijentirana na stupce trgovina koja je napravljena po uzoru na Google BigTable koji se pokreće na vrhu HDFS-a. '' NoSQL 'je širok pojam koji znači da baza podataka nije RDBMS koji podržava SQL kao primarni jezik pristupa. Ali postoji mnogo vrsta NoSQL baza podataka, a Berkeley DB je dobar primjer lokalne NoSQL baze podataka, dok je HBase distribuirana baza podataka.
HBase pruža sve značajke Google BigTablea. Započeo je kao projekt Powerseta za obradu ogromnih količina podataka za pretraživanje prirodnog jezika. Razvijen je u sklopu Apacheova projekta Hadoop, a radi na vrhu HDFS-a (Hadoop Distributed File System). Pruža načine čuvanja velikih količina rijetkih podataka otpornih na kvarove. HBase je zapravo više 'Spremište podataka' nego 'Baza podataka', jer mu nedostaju mnoge značajke dostupne u RDBMS-u, poput tipkanih stupaca, sekundarnih indeksa, okidača i naprednih jezika upita itd.
U bazama podataka orijentiranim na stup, tablica podataka pohranjuje se kao odjeljci stupaca podataka, a ne kao redovi podataka. Model podataka baze podataka orijentirane na stupce sastoji se od naziva tablice, ključa retka, obitelji stupaca, stupaca, vremenskog žiga. Tijekom stvaranja tablica u HBaseu, retci će se jedinstveno identificirati uz pomoć tipki retka i vremenskog žiga. U ovom podatkovnom modelu porodica stupaca je statična, dok je stupac dinamičan. Pogledajmo sada arhitekturu HBase.
dizajnirati obrasce u php-u s primjerom
Kada odabrati HBase?
HBase je dobra opcija samo ako postoje stotine milijuna ili milijarde redaka. HBase se također može koristiti na mjestima kada se razmišlja o prelasku sa RDBMS-a na HBase kao potpuni redizajn za razliku od porta. Drugim riječima, HBase nije optimiziran za klasične transakcijske aplikacije ili čak relacijsku analitiku. Također nije potpuna zamjena za HDFS kada se radi velika serija MapReduce. Zašto bi onda trebali koristiti HBase ?? Ako vaša aplikacija ima varijabilnu shemu gdje se svaki redak malo razlikuje, tada biste trebali pogledati HBase.
Arhitektura HBase:
Sljedeća slika jasno objašnjava arhitekturu HBase.
U HBaseu postoje tri glavne komponente: Majstor, poslužitelj regije i čuvar zoološkog vrta . Ostale komponente su Memstore, HFile i WAL.
Kako se HBase izvodi na vrhu HDFS-a, koristi arhitekturu Master-Slave u kojoj će HMaster biti glavni čvor, a Regijski poslužitelji podređeni čvorovi. Kada klijent pošalje zahtjev za pisanje, HMaster dobiva taj zahtjev i prosljeđuje ga odgovarajućem regionalnom poslužitelju.
marioneta vs kuhar vs jenkins
Regijski poslužitelj:
To je sustav koji djeluje slično čvoru podataka. Kad regijski poslužitelj (RS) primi zahtjev za upisom, usmjerava zahtjev na određenu regiju. Svaka regija pohranjuje skup redaka. Podaci redaka mogu se razdvojiti u više porodica stupaca (CF). Podaci pojedinih CF pohranjuju se u HStore koji se sastoji od Memstorea i skupa HFiles.
Što Memstore radi?
Memstore vodi evidenciju svih dnevnika za operacije čitanja i pisanja koje su izvedene unutar tog određenog regionskog poslužitelja. Iz ovoga možemo reći da djeluje slično čvoru imena u Hadoopu. Memstore je memorija u memoriji, stoga Memstore koristi memoriju svakog čvora podataka za pohranu dnevnika. Kada se zadovolje određeni pragovi, podaci Memstorea prebacuju se u HFile.
Ključna svrha korištenja Memstorea je potreba za pohranom podataka na DFS poredanih po ključu retka. Kako je HDFS dizajniran za uzastopno čitanje / pisanje, bez dopuštenih izmjena datoteke, HBase ne može učinkovito zapisati podatke na disk dok se primaju: zapisani podaci neće se sortirati (kada se ulaz ne sortira) što znači da nije optimiziran za budućnost dohvaćanje. Da bi riješio ovaj problem, HBase me uspremnici zadnji put primili podatke u memoriju (u Memstoreu), 'sortirali' ih prije ispiranja, a zatim upisali u HDFS pomoću brzog sekvencijalnog upisivanja. Dakle, HFile sadrži popis razvrstanih redaka.
Svaki put kada se dogodi ispiranje Memstorea, jedan HFile stvoren za svaki CF i česta ispiranja mogu stvoriti tone HFilesa. Budući da će tijekom čitanja HBase morati pogledati mnoge datoteke HFi, brzina čitanja može patiti. Kako bi se spriječilo otvaranje previše HFiles datoteka i izbjeglo pogoršanje performansi čitanja, koristi se postupak sabijanja HFiles. HBase će povremeno (kada se zadovolje određeni pragovi koji se mogu konfigurirati) kompaktnirati više manjih HFi datoteka u veliki. Očito je da što se više datoteka stvori u Memstoreu, to više rada (dodatnog opterećenja) za sustav. Uz to, dok se postupak sabijanja obično izvodi paralelno s posluživanjem drugih zahtjeva i kada HBase ne može pratiti sažimanje HFiles-a (da, za to postoje konfigurirani pragovi), ponovno će blokirati upisivanje na RS-u. Kao što smo gore raspravljali, ovo je vrlo nepoželjno.
Ne možemo biti sigurni da će podaci biti trajni tijekom cijelog Memstorea. Pretpostavimo da određeni podatkovni čvor nije u funkciji. Tada će se podaci koji se nalaze u memoriji tog podatkovnog čvora izgubiti.
Da bismo prevladali ovaj problem, kada zahtjev dolazi od glavnog računara, napisao ga je i WAL-u. WAL nije ništa drugo do Napišite naprijed zapisnike koji se nalazi na HDFS-u, trajnom spremištu. Sada možemo biti sigurni da čak i ako je čvor podataka spušten, podaci neće biti izgubljeni, tj. imamo kopiju svih radnji koje biste trebali učiniti u WAL-u. Kada je podatkovni čvor podignut, on će ponovno izvršiti sve aktivnosti. Nakon što je operacija dovršena, sve se uklanja iz Memstorea i WAL-a i zapisuje se u HFile kako bi se osiguralo da nam ne ponestaje memorije.
Uzmimo jednostavan primjer da želim dodati redak 10, a zatim se pojavi zahtjev za pisanjem, koji kaže da daje sve meta podatke u Memstore i WAL. Jednom kada se taj redak upiše u HFile, sve u Memstoreu i WAL-u se isprazni.
Čuvar zoo vrta:
HBase dolazi integriran sa Zoo čuvarom. Kada pokrenem HBase, pokreće se i instanca čuvara zoološkog vrta. Razlog je taj što nam čuvar zoološkog vrta pomaže u praćenju svih regionalnih poslužitelja koji su tu za HBase. Čuvar zoološkog vrta prati koliko ima regionalnih poslužitelja, koje se regionalne poslužitelje drže od kojeg podatkovnog čvora do kojeg čvora podataka. Prati manje skupove podataka gdje Hadoop nedostaje. Smanjuje režijske troškove na vrhu Hadoopa koji prati većinu vaših meta podataka. Stoga HMaster dobiva detalje o regionalnim poslužiteljima zapravo kontaktirajući čuvara Zoološkog vrta.
Imate pitanje za nas? Spomenite ih u odjeljku za komentare i javit ćemo vam se.
što su tokeni u javi
Vezane objave: