Oivalluksia HBase-arkkitehtuurista

Tämä viesti käsittelee HBasea ja oivalluksia HBase-arkkitehtuurista. Siinä keskustellaan myös Hbase-komponenteista, kuten Master, Region-palvelin ja Zoo-ylläpitäjä, ja niiden käytöstä.

Keskustelemme tämän päivän viestissä HBase-arkkitehtuurista. Harjoitellaan HBasen perusteita, ennen kuin syvennämme HBase-arkkitehtuuria.





HBase - perusteet:

HBase on avoimen lähdekoodin NoSQL-hajautettu, ei-relaatioon perustuva, versioitu, moniulotteinen, sarakekohtainen myymälä, joka on mallinnettu HDFS: n päällä olevan Google BigTable -työkalun mukaan. '' NoSQL 'on laaja termi, joka tarkoittaa, että tietokanta ei ole RDBMS, joka tukee SQL: ää sen ensisijaisena käyttökielenä, mutta NoSQL-tietokantoja on monenlaisia ​​ja Berkeley DB on hyvä esimerkki paikallisesta NoSQL-tietokannasta, kun taas HBase on hyvin hajautettu tietokanta.

java valettu kaksinkertaiseksi int

HBase tarjoaa kaikki Google BigTable -ominaisuudet. Se alkoi Powersetin projektina käsitellä valtavia määriä tietoa luonnollisen kielen hakua varten. Se on kehitetty osana Apachen Hadoop-projektia ja toimii HDFS: n (Hadoop Distributed File System) päällä. Se tarjoaa vikasietoisia tapoja tallentaa suuria määriä harvoja tietoja. HBase on oikeastaan ​​pikemminkin 'tietokanta' kuin 'tietokanta', koska sillä ei ole monia RDBMS: ssä käytettävissä olevia ominaisuuksia, kuten kirjoitetut sarakkeet, toissijaiset indeksit, laukaisimet ja edistyneet kyselykielet jne.



Sarakekohtaisissa tietokannoissa tietotaulukko tallennetaan tietosarakkeiden osina eikä tietoriveinä. Sarakekohtaisen tietokannan tietomalli koostuu Taulukon nimi, riviavain, sarakeperhe, sarakkeet, aikaleima. Kun luodaan taulukoita HBasessa, rivit tunnistetaan yksilöllisesti rivinäppäinten ja aikaleiman avulla. Tässä tietomallissa sarakeperhe on staattinen, kun taas sarakkeet ovat dynaamisia. Katsokaamme nyt HBase-arkkitehtuuria.

Milloin mennä HBaseen?

HBase on hyvä vaihtoehto vain, kun rivejä on satoja miljoonia tai miljardeja. HBasea voidaan käyttää myös paikoissa harkittaessa siirtymistä RDBMS: stä HBase: een täydellisenä uudelleensuunnitteluna portin sijaan, toisin sanoen, HBasea ei ole optimoitu klassisille transaktiosovelluksille tai edes relaatioanalytiikalle. Se ei myöskään ole täydellinen korvike HDFS: lle, kun tehdään isoa MapReduce-erää. Miksi sinun pitäisi sitten mennä HBaseen? Jos sovelluksessasi on muuttujakaava, jossa kukin rivi on hieman erilainen, kannattaa tarkastella HBasea.

HBase-arkkitehtuuri:

Seuraava kuva selittää selvästi HBase-arkkitehtuurin.



Oivalluksia HBase-arkkitehtuurista

HBasessa on kolme pääkomponenttia: Päällikkö, alueen palvelin ja eläintarhan pitäjä . Muut komponentit ovat Memstore, HFile ja WAL.

qlikview-opetusohjelma askel askeleelta

Kun HBase toimii HDFS: n päällä, se käyttää Master-Slave-arkkitehtuuria, jossa HMaster on pääsolmu ja aluepalvelimet ovat orjasolmut. Kun asiakas lähettää kirjoituspyynnön, HMaster saa pyynnön ja välittää sen vastaavalle aluepalvelimelle.

Aluepalvelin:

Se on järjestelmä, joka toimii samalla tavalla kuin datasolmu. Kun Region Server (RS) vastaanottaa kirjoituspyynnön, se ohjaa pyynnön tietylle alueelle. Jokainen alue tallentaa joukon rivejä. Rivitiedot voidaan erottaa useissa sarakeperheissä (CF). Tietyn CF: n tiedot tallennetaan HStoreen, joka koostuu Memstoresta ja joukosta HFilejä.

Mitä Memstore tekee?

Memstore seuraa kaikkia lukuja ja kirjoitusoperaatioita, jotka on suoritettu tietyllä aluepalvelimella. Tästä voimme sanoa, että se toimii samanlaisena kuin nimisolmu Hadoopissa. Memstore on muistin sisäinen tallennustila, joten Memstore käyttää lokien tallentamiseen kunkin datasolmun sisäistä muistia. Kun tietyt kynnysarvot saavutetaan, Memstore-tiedot huuhdellaan HFile-tiedostoon.

Memstoren käytön päätarkoitus on tarve tallentaa tietoja rivinäppäimillä järjestettyihin DFS: iin. Koska HDFS on suunniteltu peräkkäisille lukemisille / kirjoittamisille ilman tiedostomuutoksia, HBase ei voi kirjoittaa tietoja levylle tehokkaasti vastaanotettaessa: kirjoitettuja tietoja ei lajitella (kun syötettä ei ole lajiteltu), mikä tarkoittaa, ettei niitä ole optimoitu tulevaisuutta varten haku. Tämän ongelman ratkaisemiseksi HBase-puskurit viimeksi vastaanotetut tiedot muistissa (Memstoressa), 'lajittelevat' ne ennen huuhtelua ja kirjoittavat sitten HDFS: ään käyttäen nopeita peräkkäisiä kirjoituksia. Siksi HFile sisältää luettelon lajiteltuista riveistä.

Joka kerta, kun Memstore-huuhtelu tapahtuu, yksi HF-tiedosto luodaan kullekin CF: lle ja usein huuhtelut voivat luoda tonnia HF-tiedostoja. Koska lukemisen aikana HBase joutuu tarkastelemaan monia H-tiedostoja, lukunopeus voi kärsiä. Liiallisen HF-tiedostojen avaamisen estämiseksi ja lukutehon heikkenemisen estämiseksi käytetään HFiles-tiivistysprosessia. HBase tiivistää säännöllisesti (kun tietyt konfiguroitavat kynnysarvot saavutetaan) useita pienempiä H-tiedostoja isoksi. On selvää, että mitä enemmän Memstoren luomia tiedostoja huuhdellaan, sitä enemmän työtä (ylimääräistä kuormitusta) järjestelmälle aiheutuu. Lisätään siihen, että vaikka tiivistysprosessi suoritetaan yleensä samanaikaisesti muiden pyyntöjen palvelemisen kanssa ja kun HBase ei pysty pysymään mukana HF-tiedostojen tiivistämisessä (kyllä, myös sille on määritetty kynnysarvot), se estää kirjoittamisen uudestaan ​​RS: llä. Kuten edellä keskustelimme, tämä on erittäin epätoivottavaa.

Emme voi olla varmoja siitä, että tiedot pysyvät jatkuvasti Memstoressa. Oletetaan, että tietty datanode on alhaalla. Sitten kyseisen solmun muistissa olevat tiedot menetetään.

Tämän ongelman ratkaisemiseksi, kun pyyntö tulee päälliköltä, se kirjoitti myös WAL: lle. WAL on vain Kirjoita eteenpäin lokit joka sijaitsee HDFS: ssä, pysyvässä tallennustilassa. Nyt voimme varmistaa, että vaikka datasolmu olisi alhaalla, tietoja ei menetetä, ts. meillä on kopio kaikista toimista, jotka sinun pitäisi tehdä WAL: ssa. Kun tietosolmu on ylöspäin, se suorittaa kaikki toiminnot uudelleen. Kun toiminto on valmis, kaikki huuhdellaan Memstoresta ja WAL: sta ja kirjoitetaan HFile-tiedostoon varmistaaksemme, että muistimme ei ole loppumassa.

Otetaan yksinkertainen esimerkki siitä, että haluan lisätä rivin 10 sitten kirjoituspyyntö tulee, se sanoo, että se antaa kaikki metatiedot Memstorelle ja WAL: lle. Kun kyseinen rivi on kirjoitettu HFileen, kaikki Memstore ja WAL tyhjennetään.

Eläintarhan pitäjä:

HBase on integroitu eläintarhan pitäjän kanssa. Kun käynnistän HBasen, myös eläintarhan pitäjän instanssi käynnistyy. Syynä on se, että eläintarhan pitäjä auttaa meitä pitämään kirjaa kaikista alueen palvelimista, jotka ovat siellä HBasea varten. Eläintarhan pitäjä seuraa kuinka monta aluepalvelinta on, mitkä alueen palvelimet pitävät mistä tietosolmusta mihin tietosolmuun. Se seuraa pienempiä tietojoukkoja, joista Hadoop puuttuu. Se vähentää yleiskustannuksia Hadoopin päällä, joka seuraa suurinta osaa metatiedoistasi. Siksi HMaster saa tiedot alueen palvelimista ottamalla yhteyttä eläintarhan pitäjään.

Onko sinulla kysymys meille? Mainitse ne kommenttiosassa ja palaamme sinuun.

mitä semaforia on java

Aiheeseen liittyvät julkaisut:

Hyödyllisiä pesäkomentoja