В днешния пост нека да обсъдим за архитектурата HBase. Нека изчистим нашите основи на HBase, преди да се задълбочим в HBase архитектурата.
HBase - Основите:
HBase е с отворен код, NoSQL, разпределен, нерелационен, версионен, многоизмерен, ориентиран към колони магазин, който е моделиран след Google BigTable, който работи върху HDFS. „NoSQL“ е широк термин, който означава, че базата данни не е RDBMS, която поддържа SQL като основен език за достъп. Но има много видове бази данни NoSQL и Berkeley DB е добър пример за локална база данни NoSQL, докато HBase е много разпределена база данни.
HBase предоставя всички функции на Google BigTable. Започна като проект на Powerset за обработка на огромни количества данни за търсене на естествен език. Той е разработен като част от проекта Hadoop на Apache и работи върху HDFS (Hadoop Distributed File System). Предоставя толерантни начини за съхраняване на големи количества оскъдни данни. HBase наистина е по-скоро „Съхранение на данни“, отколкото „База данни“, тъй като му липсват много от функциите, налични в RDBMS, като въведени колони, вторични индекси, тригери и разширени езици за заявки и т.н.
В базирани на колони бази данни таблицата с данни се съхранява като раздели на колони с данни, а не като редове с данни. Моделът на данни на база данни, ориентирана към колона, се състои от име на таблица, ключ на ред, семейство колони, колони, времеви печат. Докато създавате таблици в HBase, редовете ще бъдат уникално идентифицирани с помощта на ключове на редове и времеви печат. В този модел на данни семейството колони са статични, докато колоните са динамични. Сега нека разгледаме архитектурата HBase.
Кога да отида за HBase?
HBase е добър вариант само когато има стотици милиони или милиарди редове. HBase също може да се използва на места, когато се обмисля да се премине от RDBMS към HBase като цялостен редизайн, за разлика от порт. С други думи, HBase не е оптимизиран за класически транзакционни приложения или дори релационен анализ. Също така не е пълен заместител на HDFS, когато правите големи партиди MapReduce. Тогава защо трябва да отидете за HBase ?? Ако вашето приложение има променлива схема, където всеки ред е малко по-различен, тогава трябва да погледнете HBase.
дълбоко обучение срещу машинно обучение срещу разпознаване на модели
HBase архитектура:
Следващата фигура ясно обяснява архитектурата HBase.
В HBase има три основни компонента: Капитан, регионален сървър и пазител на зоопарка . Другите компоненти са Memstore, HFile и WAL.
Тъй като HBase работи върху HDFS, той използва архитектурата Master-Slave, в която HMaster ще бъде главният възел, а регионалните сървъри са подчинени възли. Когато клиентът изпрати заявка за запис, HMaster получава тази заявка и я препраща към съответния регионален сървър.
Регионален сървър:
Това е система, която действа подобно на възел за данни. Когато регионалният сървър (RS) получи заявка за запис, той насочва заявката към конкретен регион. Всеки регион съхранява набор от редове. Данните за редове могат да бъдат разделени в множество семейства колони (CF). Данните за определен CF се съхраняват в HStore, който се състои от Memstore и набор от HFiles.
Какво прави Memstore?
Memstore проследява всички регистрационни файлове за операциите за четене и запис, извършени в рамките на този конкретен регионален сървър. От това можем да кажем, че действа подобно на възел с име в Hadoop. Memstore е съхранение в паметта, поради което Memstore използва съхранението в паметта на всеки възел за данни, за да съхранява дневниците. Когато се достигнат определени прагове, данните на Memstore се изхвърлят в HFile.
Основната цел за използване на Memstore е необходимостта от съхраняване на данни в DFS, подредени по ключ на реда. Тъй като HDFS е предназначен за последователно четене / запис, без разрешени модификации на файлове, HBase не може ефективно да записва данни на диск, тъй като се получава: записаните данни няма да бъдат сортирани (когато входът не е сортиран), което означава, че не е оптимизиран за бъдеще извличане. За да разреши този проблем, HBase буферите последно получават данни в паметта (в Memstore), „сортират“ ги преди промиване и след това записват в HDFS, използвайки бързи последователни записи. Следователно, HFile съдържа списък от сортирани редове.
Всеки път, когато се случи флъш в Memstore, един HFile, създаден за всеки CF, и честите флъшове могат да създадат тонове HFiles. Тъй като по време на четене HBase ще трябва да разгледа много HFiles, скоростта на четене може да пострада. За да се предотврати отварянето на твърде много HFiles и да се избегне влошаване на производителността на четене, се използва процесът на уплътняване на HFiles. HBase периодично (когато са изпълнени определени конфигурируеми прагове) уплътнява множество по-малки HFi файлове в голям. Очевидно е, че колкото повече файлове се създават от Memstore, толкова повече работа (допълнително натоварване) за системата. В допълнение към това, докато процесът на уплътняване обикновено се извършва паралелно с обслужването на други заявки и когато HBase не може да се справи с уплътняването на HFiles (да, има конфигурирани прагове и за това), той отново ще блокира записването на RS. Както обсъждахме по-горе, това е крайно нежелателно.
как да отпечатате масив php
Не можем да бъдем сигурни, че данните ще бъдат постоянни в Memstore. Да приемем, че даден възел с данни не работи. Тогава данните, които се намират в паметта на този възел за данни, ще бъдат загубени.
За да се преодолее този проблем, когато заявката идва от главния, тя също е написана на WAL. WAL не е нищо друго освен Напишете дневници напред който се намира на HDFS, постоянно хранилище. Сега можем да се уверим, че дори когато възелът за данни не работи, данните няма да бъдат загубени, т.е. ние имаме копието на всички действия, които трябва да извършите в WAL. Когато възелът за данни е нагоре, той ще извърши всички дейности отново. След като операцията приключи, всичко се изтрива от Memstore и WAL и се записва в HFile, за да се уверим, че паметта ни не свършва.
Нека вземем прост пример, че искам да добавя ред 10, след което идва заявката за запис, в която се казва, че дава всички метаданни в Memstore и WAL. След като този конкретен ред бъде записан в HFile, всичко в Memstore и WAL се изчиства.
Пазител на зоопарка:
HBase е интегриран със Zoo пазител. Когато стартирам HBase, стартира се и екземпляр на Zoo хранител. Причината е, че пазачът на зоопарка ни помага да следим всички регионални сървъри, които са там за HBase. Пазителят на зоопарка следи колко регионални сървъри има, кои регионални сървъри държат от кой възел за данни към кой възел за данни. Той проследява по-малки набори от данни, където Hadoop липсва. Това намалява режийните разходи на върха на Hadoop, които проследяват повечето от вашите Meta данни. Следователно HMaster получава подробности за регионалните сървъри, като действително се свързва със Zoo хранителя.
Имате въпрос към нас? Споменете ги в раздела за коментари и ние ще се свържем с вас.
какви са жетоните в java
Подобни публикации: