Dobar dan Moje ime je Danil Lipovoy, naš tim u Sbertechu počeo je koristiti HBase kao skladište za operativne podatke. U toku njegovog proučavanja nakupilo se iskustvo koje sam želio sistematizovati i opisati (nadamo se da će mnogima biti od koristi). Svi eksperimenti u nastavku su izvedeni sa HBase verzijama 1.2.0-cdh5.14.2 i 2.0.0-cdh6.0.0-beta1.
- Opća arhitektura
- Zapisivanje podataka u HBASE
- Čitanje podataka iz HBASE-a
- Keširanje podataka
- Batch obrada podataka MultiGet/MultiPut
- Strategija za podjelu tabela na regije (splitting)
- Tolerancija grešaka, kompaktifikacija i lokacija podataka
- Postavke i performanse
- Testiranje na stres
- nalazi
1. Opća arhitektura
Backup Master sluša otkucaje srca aktivnog na ZooKeeper čvoru i, u slučaju nestanka, preuzima funkcije mastera.
2. Upišite podatke u HBASE
Prvo, pogledajmo najjednostavniji slučaj - pisanje objekta ključ/vrijednost u tablicu koristeći put(rowkey). Klijent prvo mora saznati gdje se nalazi server korijenske regije (RRS), koji pohranjuje tablicu hbase:meta. Ovu informaciju prima od ZooKeeper-a. Nakon toga pristupa RRS-u i čita hbase:meta tabelu, iz koje izdvaja informacije o tome koji je RegionServer (RS) odgovoran za pohranjivanje podataka za dati rowkey u tabeli od interesa. Za buduću upotrebu, meta tabelu kešira klijent i stoga naredni pozivi idu brže, direktno u RS.
Zatim RS, nakon što je primio zahtjev, prije svega ga upisuje u WriteAheadLog (WAL), što je neophodno za oporavak u slučaju pada. Zatim sprema podatke u MemStore. Ovo je bafer u memoriji koji sadrži sortirani skup ključeva za dati region. Tabela se može podijeliti na regije (particije), od kojih svaka sadrži disjunktni skup ključeva. Ovo vam omogućava da postavite regije na različite servere kako biste postigli veće performanse. Međutim, uprkos očiglednosti ove izjave, kasnije ćemo vidjeti da to ne funkcionira u svim slučajevima.
Nakon postavljanja unosa u MemStore, klijentu se vraća odgovor da je unos uspješno sačuvan. Međutim, u stvarnosti se pohranjuje samo u bafer i dolazi na disk tek nakon određenog vremenskog perioda ili kada se napuni novim podacima.
Prilikom izvođenja operacije “Delete” podaci se fizički ne brišu. Oni su jednostavno označeni kao izbrisani, a samo uništavanje se događa u trenutku pozivanja glavne kompaktne funkcije, što je detaljnije opisano u paragrafu 7.
Fajlovi u HFile formatu se akumuliraju u HDFS i s vremena na vrijeme se pokreće manji proces kompaktiranja, koji jednostavno spaja male datoteke u veće bez brisanja bilo čega. Vremenom se to pretvara u problem koji se pojavljuje samo pri čitanju podataka (na to ćemo se vratiti malo kasnije).
Pored gore opisanog procesa učitavanja, postoji mnogo efikasnija procedura, koja je možda i najjača strana ove baze podataka - BulkLoad. Leži u činjenici da samostalno formiramo HFiles i stavljamo ih na disk, što nam omogućava da savršeno skaliramo i postignemo vrlo pristojne brzine. Zapravo, ograničenje ovdje nije HBase, već mogućnosti hardvera. Ispod su rezultati pokretanja na klasteru koji se sastoji od 16 RegionServera i 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 niti), HBase verzija 1.2.0-cdh5.14.2.
Ovdje možete vidjeti da povećanjem broja particija (regija) u tabeli, kao i Spark izvršitelja, dobijamo povećanje brzine preuzimanja. Također, brzina ovisi o jačini snimanja. Veliki blokovi daju povećanje MB/sec, mali blokovi u broju umetnutih zapisa po jedinici vremena, pod uslovom da su sve ostale jednake.
Također možete početi učitavati u dvije tablice u isto vrijeme i dobiti dvostruku brzinu. U nastavku možete vidjeti da se upisivanje blokova od 10 KB u dvije tablice odjednom odvija brzinom od oko 600 MB/sec u svakoj (ukupno 1275 MB/sec), što se poklapa sa brzinom upisivanja u jednu tablicu od 623 MB/sec (vidi br. 11 iznad)
Ali druga serija sa rekordima od 50 KB pokazuje da brzina preuzimanja blago raste, što ukazuje da se približava graničnim vrijednostima. Istovremeno, morate imati na umu da se na samom HBASE-u praktički ne stvara nikakvo opterećenje, sve što se od njega traži je da prvo da podatke sa hbase:meta, a nakon oblaganja HFiles-a, resetirajte BlockCache podatke i sačuvate MemStore bafer na disk, ako nije prazan.
3. Čitanje podataka iz HBASE-a
Ako pretpostavimo da klijent već ima sve informacije sa hbase:meta (vidi tačku 2), onda zahtjev ide direktno u RS gdje je pohranjen traženi ključ. Prvo, pretraga se vrši u MemCache-u. Bez obzira na to postoje li podaci ili ne, pretraga se također vrši u BlockCache baferu i, ako je potrebno, u HFiles. Ako su podaci pronađeni u datoteci, oni se stavljaju u BlockCache i bit će vraćeni brže na sljedeći zahtjev. Pretraživanje u HFile-u je relativno brzo zahvaljujući korištenju Bloom filtera, tj. nakon čitanja male količine podataka, odmah utvrđuje da li ova datoteka sadrži traženi ključ, a ako ne, onda prelazi na sljedeći.
Dobivši podatke iz ova tri izvora, RS generiše odgovor. Konkretno, može prenijeti nekoliko pronađenih verzija objekta odjednom ako je klijent zatražio verzioniranje.
4. Keširanje podataka
MemStore i BlockCache baferi zauzimaju do 80% dodijeljene na hrpi RS memorije (ostatak je rezerviran za RS servisne zadatke). Ako je tipičan način upotrebe takav da procesi pišu i odmah čitaju iste podatke, onda ima smisla smanjiti BlockCache i povećati MemStore, jer Kada upisani podaci ne dođu u keš memoriju radi čitanja, BlockCache će se rjeđe koristiti. BlockCache bafer se sastoji od dva dijela: LruBlockCache (uvijek na hrpi) i BucketCache (obično off-heap ili na SSD). BucketCache treba koristiti kada ima puno zahtjeva za čitanje i oni se ne uklapaju u LruBlockCache, što dovodi do aktivnog rada Garbage Collector-a. U isto vrijeme, ne biste trebali očekivati radikalno povećanje performansi od korištenja predmemorije za čitanje, ali na to ćemo se vratiti u paragrafu 8
Postoji jedan BlockCache za cijeli RS i jedan MemStore za svaku tabelu (po jedan za svaku familiju kolona).
Kako u teoriji, prilikom pisanja, podaci ne idu u keš memoriju i zaista, takvi parametri CACHE_DATA_ON_WRITE za tabelu i “Cache DATA on Write” za RS su postavljeni na false. Međutim, u praksi, ako zapišemo podatke u MemStore, zatim ih ispraznimo na disk (na taj način izbrišemo), a zatim izbrišemo rezultirajući fajl, onda ćemo izvršavanjem zahteva za dobijanje podataka uspešno primiti podatke. Štoviše, čak i ako potpuno onemogućite BlockCache i popunite tablicu novim podacima, a zatim resetujete MemStore na disk, izbrišete ih i zatražite ih iz druge sesije, oni će i dalje biti odnekud preuzeti. Dakle, HBase pohranjuje ne samo podatke, već i misteriozne misterije.
hbase(main):001:0> create 'ns:magic', 'cf'
Created table ns:magic
Took 1.1533 seconds
hbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me'
Took 0.2610 seconds
hbase(main):003:0> flush 'ns:magic'
Took 0.6161 seconds
hdfs dfs -mv /data/hbase/data/ns/magic/* /tmp/trash
hbase(main):002:0> get 'ns:magic', 'key1'
cf:c timestamp=1534440690218, value=try_to_delete_me
Parametar "Cache DATA on Read" je postavljen na false. Ako imate bilo kakvu ideju, dobrodošli da o tome razgovarate u komentarima.
5. Batch obrada podataka MultiGet/MultiPut
Obrada pojedinačnih zahtjeva (Get/Put/Delete) je prilično skupa operacija, pa ako je moguće, trebali biste ih kombinirati u Listu ili Listu, što vam omogućava da dobijete značajno povećanje performansi. Ovo posebno važi za operaciju pisanja, ali pri čitanju postoji sljedeća zamka. Grafikon ispod prikazuje vrijeme za čitanje 50 zapisa iz MemStore-a. Očitavanje je obavljeno u jednoj niti, a horizontalna os prikazuje broj ključeva u zahtjevu. Ovdje možete vidjeti da pri povećanju na hiljadu ključeva u jednom zahtjevu vrijeme izvršenja pada, tj. brzina se povećava. Međutim, sa MSLAB režimom koji je podrazumevano omogućen, nakon ovog praga počinje radikalan pad performansi, a što je veća količina podataka u zapisu, to je duže vreme rada.
Testovi su obavljeni na virtuelnoj mašini, 8 jezgara, verzija HBase 2.0.0-cdh6.0.0-beta1.
MSLAB režim je dizajniran da smanji fragmentaciju hrpe, koja nastaje zbog miješanja podataka nove i stare generacije. Kao zaobilazno rešenje, kada je MSLAB omogućen, podaci se stavljaju u relativno male ćelije (komadije) i obrađuju u delovima. Kao rezultat toga, kada volumen u traženom paketu podataka premaši dodijeljenu veličinu, performanse naglo opadaju. S druge strane, isključivanje ovog načina rada također nije preporučljivo, jer će dovesti do zaustavljanja zbog GC-a u trenucima intenzivne obrade podataka. Dobro rješenje je povećanje volumena ćelije u slučaju aktivnog pisanja putem put-a istovremeno s čitanjem. Vrijedi napomenuti da se problem ne javlja ako nakon snimanja pokrenete naredbu flush, koja resetuje MemStore na disk, ili ako učitate pomoću BulkLoad-a. Tabela ispod pokazuje da upiti iz MemStore-a za veću (i istu količinu) podataka rezultiraju usporavanjem. Međutim, povećanjem veličine komada vraćamo vrijeme obrade u normalu.
Osim povećanja veličine komada, podjela podataka po regijama pomaže, tj. dijeljenje stola. Ovo rezultira manjim brojem zahtjeva koji dolaze u svaku regiju i ako se uklapaju u ćeliju, odgovor ostaje dobar.
6. Strategija podjele tabela na regije (splitting)
Pošto je HBase skladište ključ/vrijednost i particioniranje se vrši po ključu, izuzetno je važno ravnomjerno podijeliti podatke na sve regije. Na primjer, particioniranje takve tablice na tri dijela rezultirat će podjelom podataka u tri regije:
Dešava se da to dovodi do naglog usporavanja ako kasnije učitani podaci izgledaju kao, na primjer, duge vrijednosti, od kojih većina počinje istom cifrom, na primjer:
1000001
1000002
...
1100003
Pošto su ključevi pohranjeni kao niz bajtova, svi će početi isto i pripadati istoj regiji #1 koja pohranjuje ovaj raspon ključeva. Postoji nekoliko strategija podjele:
HexStringSplit – Pretvara ključ u heksadecimalni kodirani niz u rasponu "00000000" => "FFFFFFFF" i dopuna na lijevoj strani nulama.
UniformSplit – Pretvara ključ u niz bajtova sa heksadecimalnim kodiranjem u rasponu "00" => "FF" i dopunom na desnoj strani nulama.
Osim toga, možete odrediti bilo koji raspon ili skup tipki za razdvajanje i konfigurirati automatsko razdvajanje. Međutim, jedan od najjednostavnijih i najefikasnijih pristupa je UniformSplit i korištenje hash konkatenacije, na primjer najznačajniji par bajtova od pokretanja ključa kroz funkciju CRC32(rowkey) i samog rowkey:
hash + rowkey
Tada će svi podaci biti ravnomjerno raspoređeni po regijama. Prilikom čitanja, prva dva bajta se jednostavno odbacuju i originalni ključ ostaje. RS također kontrolira količinu podataka i ključeva u regiji i, ako se prekorače granice, automatski ih razbija na dijelove.
7. Tolerancija grešaka i lokacija podataka
Budući da je samo jedna regija odgovorna za svaki set ključeva, rješenje za probleme povezane s rušenjem RS ili gašenjem je pohranjivanje svih potrebnih podataka u HDFS. Kada RS padne, master detektuje to kroz odsustvo otkucaja srca na ZooKeeper čvoru. Zatim dodjeljuje opsluživanu regiju drugom RS i pošto su HFiles pohranjeni u distribuiranom sistemu datoteka, novi vlasnik ih čita i nastavlja opsluživati podatke. Međutim, pošto se neki od podataka možda nalaze u MemStore-u i nisu imali vremena da uđu u HFiles, WAL, koji je takođe pohranjen u HDFS, koristi se za vraćanje istorije operacija. Nakon primjene izmjena, RS je u mogućnosti da odgovori na zahtjeve, ali taj potez dovodi do toga da dio podataka i procesa koji ih servisiraju završavaju na različitim čvorovima, tj. lokalitet se smanjuje.
Rješenje problema je veliko zbijanje - ova procedura premješta datoteke na one čvorove koji su za njih odgovorni (gdje se nalaze njihove regije), zbog čega se tokom ove procedure opterećenje mreže i diskova naglo povećava. Međutim, u budućnosti se pristup podacima značajno ubrzava. Osim toga, major_compaction vrši spajanje svih HFiles u jednu datoteku unutar regije, a također čisti podatke ovisno o postavkama tablice. Na primjer, možete odrediti broj verzija objekta koji se moraju zadržati ili životni vijek nakon kojeg se objekt fizički briše.
Ovaj postupak može imati vrlo pozitivan učinak na rad HBase-a. Slika ispod pokazuje kako su performanse smanjene kao rezultat aktivnog snimanja podataka. Ovdje možete vidjeti kako 40 niti piše u jednu tabelu i 40 niti istovremeno čita podatke. Niti pisanja generiraju sve više i više HFiles, koje čitaju druge niti. Kao rezultat toga, sve više podataka mora biti uklonjeno iz memorije i na kraju GC počinje raditi, što praktički paralizira sav rad. Pokretanje velikog zbijanja dovelo je do raščišćavanja nastalog otpada i obnavljanja produktivnosti.
Test je izveden na 3 DataNode i 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 niti). HBase verzija 1.2.0-cdh5.14.2
Vrijedi napomenuti da je veliko zbijanje pokrenuto na „živoj“ tablici, u koju su podaci aktivno upisani i čitani. Na internetu se pojavila izjava da bi to moglo dovesti do pogrešnog odgovora pri čitanju podataka. Za provjeru, pokrenut je proces koji je generirao nove podatke i zapisao ih u tabelu. Nakon čega sam odmah pročitao i provjerio da li se dobijena vrijednost poklapa sa zapisanim. Dok je ovaj proces tekao, veliko zbijanje je izvedeno oko 200 puta i nije zabilježen niti jedan kvar. Možda se problem pojavljuje rijetko i samo pri velikom opterećenju, pa je sigurnije zaustaviti procese pisanja i čitanja kako je planirano i izvršiti čišćenje kako bi se spriječila takva GC povlačenja.
Takođe, veliko sažimanje ne utiče na stanje MemStore-a; da biste ga izbacili na disk i zbili, potrebno je da koristite flush (connection.getAdmin().flush(TableName.valueOf(tblName))).
8. Postavke i performanse
Kao što je već pomenuto, HBase svoj najveći uspeh pokazuje tamo gde ne treba ništa da radi, kada izvršava BulkLoad. Međutim, ovo se odnosi na većinu sistema i ljudi. Međutim, ovaj alat je prikladniji za masovno pohranjivanje podataka u velikim blokovima, dok ako proces zahtijeva više konkurentnih zahtjeva za čitanje i pisanje, koriste se gore opisane naredbe Get i Put. Kako bi se odredili optimalni parametri, lansiranja su provedena s različitim kombinacijama parametara i postavki tablice:
- 10 niti je pokrenuto istovremeno 3 puta zaredom (nazovimo ovo blok niti).
- Vrijeme rada svih niti u bloku je prosječno i bilo je konačni rezultat rada bloka.
- Sve niti su radile sa istom tabelom.
- Prije svakog pokretanja bloka navoja, izvršeno je veliko sabijanje.
- Svaki blok izvodi samo jednu od sljedećih operacija:
-Staviti
— Uzmi
—Get+Put
- Svaki blok je izvršio 50 iteracija svoje operacije.
- Veličina bloka zapisa je 100 bajtova, 1000 bajtova ili 10000 bajtova (nasumično).
- Blokovi su pokretani s različitim brojem traženih ključeva (bilo jedan ključ ili 10).
- Blokovi su vođeni pod različitim postavkama stola. Promijenjeni parametri:
— BlockCache = uključeno ili isključeno
— Veličina bloka = 65 KB ili 16 KB
— Particije = 1, 5 ili 30
— MSLAB = omogućeno ili onemogućeno
Dakle, blok izgleda ovako:
a. MSLAB način rada je uključen/isključen.
b. Kreirana je tabela za koju su postavljeni sljedeći parametri: BlockCache = true/none, BlockSize = 65/16 Kb, Partition = 1/5/30.
c. Kompresija je postavljena na GZ.
d. 10 niti je pokrenuto istovremeno radeći 1/10 put/get/get+put operacija u ovoj tabeli sa zapisima od 100/1000/10000 bajtova, izvodeći 50 upita u nizu (slučajni ključevi).
e. Tačka d je ponovljena tri puta.
f. Vrijeme rada svih niti je prosječno.
Testirane su sve moguće kombinacije. Predvidljivo je da će brzina pasti kako se veličina zapisa povećava, ili da će onemogućavanje keširanja uzrokovati usporavanje. Međutim, cilj je bio da se razume stepen i značaj uticaja svakog parametra, pa su prikupljeni podaci uneti u ulaz funkcije linearne regresije, što omogućava procenu značaja pomoću t-statistike. Ispod su rezultati blokova koji izvode Put operacije. Kompletan set kombinacija 2*2*3*2*3 = 144 opcije + 72 tk. neki su urađeni dva puta. Dakle, ima ukupno 216 vožnji:
Testiranje je obavljeno na mini klasteru koji se sastoji od 3 DataNode i 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 niti). HBase verzija 1.2.0-cdh5.14.2.
Najveća brzina umetanja od 3.7 sekundi je postignuta sa isključenim MSLAB režimom, na tabeli sa jednom particijom, sa uključenim BlockCacheom, BlockSize = 16, zapisi od 100 bajtova, 10 komada po paketu.
Najniža brzina umetanja od 82.8 sek je postignuta sa omogućenim MSLAB režimom, na tabeli sa jednom particijom, sa omogućenim BlockCacheom, BlockSize = 16, zapisi od 10000 bajtova, po 1.
Pogledajmo sada model. Vidimo dobar kvalitet modela baziranog na R2, ali je apsolutno jasno da je ekstrapolacija ovdje kontraindikovana. Stvarno ponašanje sistema pri promjeni parametara neće biti linearno, ovaj model nije potreban za predviđanja, već za razumijevanje onoga što se dogodilo unutar datih parametara. Na primjer, ovdje vidimo iz studentovog kriterija da parametri BlockSize i BlockCache nisu bitni za operaciju Put (koja je općenito prilično predvidljiva):
Ali činjenica da povećanje broja particija dovodi do smanjenja performansi je pomalo neočekivana (već smo vidjeli pozitivan utjecaj povećanja broja particija sa BulkLoad-om), iako je razumljiva. Prvo, za obradu morate generirati zahtjeve za 30 regija umjesto za jednu, a obim podataka nije toliki da bi to donelo dobit. Drugo, ukupno radno vrijeme je određeno najsporijim RS, a pošto je broj DataNode manji od broja RS-ova, neki regioni imaju nulti lokalitet. Pa, pogledajmo prvih pet:
Sada procijenimo rezultate izvršavanja blokova Get:
Broj particija je izgubio na značaju, što se vjerovatno objašnjava činjenicom da se podaci dobro keširaju i da je keš za čitanje najznačajniji (statistički) parametar. Naravno, povećanje broja poruka u zahtjevu je također vrlo korisno za performanse. Najbolji rezultati:
Pa, konačno, pogledajmo model bloka koji je prvo izveo get, a zatim stavi:
Ovdje su svi parametri značajni. I rezultati lidera:
9. Testiranje opterećenja
Pa, konačno ćemo pokrenuti manje-više pristojno opterećenje, ali uvijek je zanimljivije kada imate s čime uporediti. Na web stranici DataStaxa, ključnog programera Cassandre, nalazi se NT brojnih NoSQL skladišta, uključujući HBase verziju 0.98.6-1. Učitavanje je obavljeno sa 40 niti, veličina podataka 100 bajtova, SSD diskovi. Rezultat testiranja operacija Read-Modify-Write pokazao je sljedeće rezultate.
Koliko sam shvatio, čitanje je obavljeno u blokovima od 100 zapisa i za 16 HBase čvorova, DataStax test je pokazao performanse od 10 hiljada operacija u sekundi.
Sreća je što i naš klaster ima 16 čvorova, ali nije baš "sreća" što svaki ima 64 jezgra (thread-a), dok ih u DataStax testu ima samo 4. S druge strane, oni imaju SSD diskove, dok mi imamo HDD ili više, nova verzija HBase-a i iskorišćenost CPU-a tokom opterećenja se praktično nije značajno povećala (vizuelno za 5-10 procenata). Međutim, pokušajmo početi koristiti ovu konfiguraciju. Podrazumevane postavke tabele, čitanje se vrši u rasponu ključeva od 0 do 50 miliona nasumično (tj. svaki put suštinski novo). Tabela sadrži 50 miliona zapisa, podijeljenih u 64 particije. Ključevi se heširaju pomoću crc32. Postavke tabele su podrazumevane, MSLAB je omogućen. Pokrećući 40 niti, svaka nit čita skup od 100 nasumičnih ključeva i odmah upisuje generiranih 100 bajtova natrag u ove ključeve.
Postolje: 16 DataNode i 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 niti). HBase verzija 1.2.0-cdh5.14.2.
Prosječan rezultat je bliži 40 hiljada operacija u sekundi, što je znatno bolje nego na DataStax testu. Međutim, u eksperimentalne svrhe, možete malo promijeniti uvjete. Malo je vjerovatno da će se sav posao obavljati isključivo na jednom stolu, a također samo na jedinstvenim ključevima. Pretpostavimo da postoji određeni „vrući“ skup tastera koji generiše glavno opterećenje. Stoga, hajde da pokušamo da kreiramo opterećenje sa većim zapisima (10 KB), takođe u grupama od 100, u 4 različite tabele i ograničavajući opseg traženih ključeva na 50 hiljada. Grafikon ispod prikazuje pokretanje od 40 niti, svaka nit glasi set od 100 ključeva i odmah upisuje nasumično 10 KB na ove ključeve nazad.
Postolje: 16 DataNode i 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 niti). HBase verzija 1.2.0-cdh5.14.2.
Tokom opterećenja, više puta je pokrenuto veliko zbijanje, kao što je gore prikazano, bez ove procedure, performanse će se postupno pogoršavati, međutim, dodatno opterećenje nastaje i tokom izvođenja. Povlačenja su uzrokovana različitim razlozima. Ponekad su niti završile s radom i došlo je do pauze dok su ponovo pokrenute, ponekad su aplikacije trećih strana stvorile opterećenje na klasteru.
Čitanje i neposredno pisanje jedan je od najtežih radnih scenarija za HBase. Ako napravite samo male put zahtjeve, na primjer 100 bajtova, kombinujući ih u pakete od 10-50 hiljada komada, možete dobiti stotine hiljada operacija u sekundi, a slična je situacija i sa zahtjevima samo za čitanje. Vrijedi napomenuti da su rezultati radikalno bolji od onih koje je dobio DataStax, prije svega zbog zahtjeva u blokovima od 50 hiljada.
Postolje: 16 DataNode i 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 niti). HBase verzija 1.2.0-cdh5.14.2.
10. Zaključci
Ovaj sistem je prilično fleksibilno konfigurisan, ali uticaj velikog broja parametara i dalje ostaje nepoznat. Neki od njih su testirani, ali nisu uključeni u rezultujući skup testova. Na primjer, preliminarni eksperimenti su pokazali beznačajan značaj parametra kao što je DATA_BLOCK_ENCODING, koji kodira informacije koristeći vrijednosti iz susjednih ćelija, što je razumljivo za nasumično generirane podatke. Ako koristite veliki broj dupliranih objekata, dobitak može biti značajan. Općenito, možemo reći da HBase ostavlja utisak prilično ozbiljne i dobro osmišljene baze podataka, koja može biti prilično produktivna kada se obavljaju operacije s velikim blokovima podataka. Pogotovo ako je moguće na vrijeme razdvojiti procese čitanja i pisanja.
Ako postoji nešto po vašem mišljenju što nije dovoljno objavljeno, spreman sam da vam kažem detaljnije. Pozivamo vas da podijelite svoje iskustvo ili razgovarate ako se s nečim ne slažete.
izvor: www.habr.com