Mga Pananaw sa HBase Architecture



Tinalakay sa post na ito ang HBase at mga pananaw sa HBase Architecture. Tinalakay din dito ang mga bahagi ng Hbase tulad ng Master, Region server at tagabantay ng Zoo at kung paano ito gamitin.

Sa post ngayon talakayin natin ang tungkol sa HBase Architecture. Sikatin natin ang ating mga pangunahing kaalaman sa HBase bago natin malalim ang pagtuklas sa arkitektura ng HBase.





HBase - Ang Mga Pangunahing Kaalaman:

Ang HBase ay isang open-source, NoSQL, ipinamamahagi, hindi kaugnay, nai-bersyon, multi-dimensional, na naka-orient sa tindahan na na-modelo pagkatapos ng Google BigTable na tumatakbo sa tuktok ng HDFS. Ang '' NoSQL ”ay isang malawak na term na nangangahulugang ang database ay hindi isang RDBMS na sumusuporta sa SQL bilang pangunahing wika ng pag-access nito. Ngunit maraming uri ng mga database ng NoSQL at ang Berkeley DB ay isang magandang halimbawa ng isang lokal na database ng NoSQL, samantalang ang HBase ay napaka isang ibinahaging database.

Nagbibigay ang HBase ng lahat ng mga tampok ng Google BigTable. Nagsimula ito bilang proyekto ng Powerset upang maproseso ang napakalaking data para sa paghahanap ng natural na wika. Ito ay binuo bilang bahagi ng proyekto ng Apado's Hadoop at tumatakbo sa tuktok ng HDFS (Hadoop Distraced File System). Nagbibigay ito ng mga paraan na mapagparaya sa pagkakamali ng pag-iimbak ng maraming dami ng kalat-kalat na data. Ang HBase ay talagang isang 'Tindahan ng Data' kaysa sa 'Data Base' dahil wala ito sa maraming mga tampok na magagamit sa RDBMS, tulad ng mga na-type na haligi, pangalawang index, pag-trigger, at mga advanced na wika ng query, atbp.



Sa mga database na oriented sa Column, ang talahanayan ng data ay nakaimbak bilang mga seksyon ng mga haligi ng data sa halip na bilang mga hilera ng data. Ang modelo ng Data ng database na nakatuon sa haligi ay binubuo ng Pangalan ng talahanayan, key key, pamilya ng haligi, mga haligi, time stamp. Habang lumilikha ng mga talahanayan sa HBase, ang mga hilera ay kakaibang makikilala sa tulong ng mga key ng row at time stamp. Sa modelong ito ng data ang pamilya ng haligi ay static samantalang ang mga haligi ay pabago-bago. Ngayon tingnan natin ang HBase Architecture.

Kailan pupunta para sa HBase?

Ang HBase ay isang mahusay na pagpipilian lamang kapag may daan-daang milyon o bilyun-bilyong mga hilera. Maaari ding magamit ang HBase sa mga lugar kung isasaalang-alang na lumipat mula sa isang RDBMS patungong HBase bilang isang kumpletong muling pagdisenyo na taliwas sa isang port. Sa madaling salita, ang HBase ay hindi na-optimize para sa mga klasikong aplikasyon ng transactional o kahit na pamamagitang analytics. Hindi rin ito kumpletong kapalit ng HDFS kapag gumagawa ng malalaking batch MapReduce. Kung gayon bakit ka dapat pumunta para sa HBase ?? Kung ang iyong aplikasyon ay may isang variable na iskema kung saan ang bawat hilera ay bahagyang naiiba, pagkatapos ay dapat mong tingnan ang HBase.

pagkakaiba sa pagitan ng nagpapatupad at nagpapalawak ng java

Arkitektura ng HBase:

Ang sumusunod na pigura ay malinaw na nagpapaliwanag ng HBase Architecture.



Mga Pananaw sa HBase Architecture

Sa HBase, mayroong tatlong pangunahing mga sangkap: Master, Rehiyon ng server at tagabantay ng Zoo . Ang iba pang mga bahagi ay Memstore, HFile at WAL.

Habang tumatakbo ang HBase sa tuktok ng HDFS, gumagamit ito ng arkitekturang Master-Slave kung saan ang HMaster ay magiging master node at ang Mga Servers ng Rehiyon ay ang mga node ng alipin. Kapag nagpadala ang kliyente ng isang kahilingan sa pagsulat, makakakuha ang kahilingan na iyon ng HMaster at ipasa ito sa kani-kanilang Region Server.

Server ng Rehiyon:

Ito ay isang sistema na kumikilos na katulad sa isang data node. Kapag nakatanggap ang Region Server (RS) ng kahilingan sa pagsusulat, ididirekta nito ang kahilingan sa tiyak na Rehiyon. Ang bawat Rehiyon ay nag-iimbak ng hanay ng mga hilera. Ang data ng mga hilera ay maaaring paghiwalayin sa maraming mga pamilya ng haligi (CFs). Ang data ng partikular na CF ay nakaimbak sa HStore na binubuo ng Memstore at isang hanay ng HFiles.

Ano ang ginagawa ng Memstore?

Sinusubaybayan ng Memstore ang lahat ng mga tala para sa pagbabasa at pagsulat ng mga pagpapatakbo na isinagawa sa loob ng partikular na server ng rehiyon. Mula dito masasabi natin na kumikilos ito katulad ng isang node ng pangalan sa Hadoop. Ang Memstore ay isang imbakan na nasa memorya, samakatuwid ang Memstore ay gumagamit ng in-memory na imbakan ng bawat data node upang maiimbak ang mga log. Kapag natutugunan ang ilang mga threshold, ang data ng Memstore ay mapula sa HFile.

Ang pangunahing layunin para sa paggamit ng Memstore ay ang pangangailangan na mag-imbak ng data sa DFS na iniutos ng row key. Tulad ng idinisenyo ang HDFS para sa sunud-sunod na pagbasa / pagsulat, nang walang pinahihintulutang mga pagbabago sa file, hindi mahusay na maisulat ng HBase ang data sa disk habang natatanggap ito: ang nakasulat na data ay hindi maaayos (kapag ang pag-input ay hindi naiayos) na nangangahulugang hindi na-optimize para sa hinaharap pagkuha. Upang malutas ang problemang ito, huling natanggap ng mga buffer ng HBase ang data sa memorya (sa Memstore), 'pinag-uuri' ito bago i-flush, at pagkatapos ay sumulat sa HDFS gamit ang mabilis na sunud-sunod na pagsulat. Samakatuwid, naglalaman ang HFile ng isang listahan ng mga pinagsunod-sunod na mga hilera.

Sa tuwing nangyayari ang Memstore flush isang HFile na nilikha para sa bawat CF at ang mga madalas na flushes ay maaaring lumikha ng toneladang HFiles. Dahil sa panahon ng pagbabasa ng HBase ay kailangang tumingin sa maraming mga HFile, ang bilis ng pagbabasa ay maaaring magdusa. Upang maiwasan ang pagbubukas ng masyadong maraming HFiles at maiwasan ang pagbasa ng pagkasira ng pagganap, ginagamit ang proseso ng pag-compaction ng HFiles. Ang HBase ay pana-panahong (kapag natutugunan ang ilang mga configure na threshold) naka-compact ang maraming mas maliit na HFiles sa isang malaki. Malinaw na, mas maraming mga file na nilikha ng Memstore flushes, mas maraming trabaho (labis na pag-load) para sa system. Naidagdag sa na, habang ang proseso ng pag-compaction ay karaniwang ginagawa nang kahanay sa paghahatid ng iba pang mga kahilingan at kapag ang HBase ay hindi makakasabay sa pag-compact ng HFiles (oo, may mga naka-configure ding mga threshold para doon), hahadlangan nito ang muling pagsulat sa RS. Tulad ng tinalakay sa itaas, ito ay lubos na hindi kanais-nais.

ano ang hashset sa java

Hindi namin matiyak na ang data ay magpapatuloy sa buong Memstore. Ipagpalagay na ang isang partikular na datanode ay wala. Pagkatapos ang data na naninirahan sa memorya ng data node ay mawawala.

Upang mapagtagumpayan ang problemang ito, kapag ang kahilingan ay nagmula sa master na isinulat din nito sa WAL. Ang WAL ay walang anuman kundi Sumulat sa Unahan ng Mga Log na naninirahan sa HDFS, isang permanenteng imbakan. Ngayon ay maaari nating siguraduhin na kahit na kung ang data node ay down ang data ay hindi mawawala I.e. mayroon kaming kopya ng lahat ng mga pagkilos na dapat mong gawin sa WAL. Kapag natapos ang data node ay isasagawa nito muli ang lahat ng mga aktibidad. Kapag nakumpleto ang operasyon, ang lahat ay mai-flush mula sa Memstore at WAL at nakasulat sa HFile upang matiyak na hindi kami nauubusan ng memorya.

Gumawa kami ng isang simpleng halimbawa na nais kong idagdag ang hilera 10 pagkatapos ay pumasok ang kahilingan sa pagsulat, binibigyan nito ang lahat ng data ng meta sa Memstore at WAL. Kapag ang partikular na hilera ay nakasulat sa HFile lahat sa Memstore at WAL ay na-flush out.

Zoo Keeper:

Ang HBase ay isinama sa tagabantay ng Zoo. Kapag sinimulan ko ang HBase, nagsimula din ang halimbawa ng tagabantay ng Zoo. Ang dahilan dito ay tinutulungan kami ng tagapag-alaga ng Zoo sa pagsunod ng isang track ng lahat ng mga server ng rehiyon na naroon para sa HBase. Sinusubaybayan ng tagabantay ng zoo kung gaano karaming mga server ng rehiyon ang naroroon, aling mga server ng rehiyon ang humahawak mula sa aling data node kung aling data node. Sinusubaybayan nito ang mas maliit na mga hanay ng data kung saan nawawala ang Hadoop. Binabawasan nito ang overhead sa tuktok ng Hadoop na sinusubaybayan ang karamihan ng iyong data sa Meta. Samakatuwid ang HMaster ay nakakakuha ng mga detalye ng mga server ng rehiyon sa pamamagitan ng aktwal na pakikipag-ugnay sa tagapag-alaga ng Zoo.

May tanong ba sa amin? Nabanggit ang mga ito sa seksyon ng mga komento at babalikan ka namin.

parehas ba ang git at github

Mga Kaugnay na Post:

Mga Makatutulong na Utos ng Pugad