Предимства, недостатъци и затруднения в производителността на HBase

Какво е HBase?

HBase е разпределена, колонно-ориентирана NoSQL база данни с отворен код, която работи върху Hadoop Distributed File System (HDFS). Моделирана по... Google Bigtable съхранява данни в таблици, съставени от семейства редове и колони, и е проектиран за разредени набори от данни, които могат да нараснат до милиарди редове и милиони колони.

За разлика от релационната база данни, HBase не използва фиксирана схема, нито предлага оптимизатор на заявки. Вместо това, всяка стойност се адресира чрез ключ на ред, семейство колони, квалификатор на колони и времева маркировка, което прави произволните четения и записи в реално време бързи дори в голям мащаб.

HBase клъстерът разчита на няколко основни компонента. HMaster координира клъстера и разпределя региони, регионалните сървъри съхраняват и обслужват действителните данни, а Apache... ZooKeeper tracks показва кои сървъри са активни и помага при превключване на сървъри при срив. Тъй като се намира в екосистемата на Hadoop, HBase работи с инструменти като MapReduce, Кошери Pig за пакетен анализ. За по-задълбочен поглед върху вътрешните механизми вижте HBase архитектура.

Предимства на HBase

Ето основните предимства от използването на HBase:

• Съхранява много големи набори от данни върху HDFS и може да агрегира и анализира милиарди редове, съхранявани в HBase таблици.
• Базата данни може да се споделя между много клиенти в разпределена среда.
• Четенето и обработката на данни отнемат по-малко време в сравнение с традиционните релационни модели.
• Поддържа бързи операции за произволно четене и запис.
• HBase се използва широко за онлайн аналитични операции.
• В банкови приложения, като например актуализации на баланса в реално време за банкомати, HBase обработва надеждно големи обеми четения и записи.

Недостатъци на HBase

Ето важните ограничения на HBase:

• HBase не е пълен заместител на традиционните релационни модели; някои релационни функции не се поддържат.
• HBase не може да изпълнява функции като SQLНе поддържа SQL структура, така че няма оптимизатор на заявки.
• HBase изисква голямо натоварване на процесора и паметта с голям последователен достъп до входни или изходни данни, докато MapReduce задачите са предимно I/O, обвързани с фиксирана памет. Интегрирането на HBase със задачи MapReduce може да доведе до непредсказуеми латентности.
• Интегрирането на HBase със задачи Pig и Hive понякога може да причини проблеми с паметта в клъстера.
• В среда на споделен клъстер, настройката изисква по-малко слотове за задачи на възел, които да се разпределят за изискванията на HBase CPU.

Тесни места в производителността в HBase

HBase осигурява мащабируемост, но няколко архитектурни решения създават пречки в производителността, които екипите трябва да планират:

В голяма производствена среда, HBase клъстер може да работи на хиляди възли, но само HMaster действа като master за всички подчинени регионални сървъри. Ако HMaster се повреди, възстановяването може да отнеме много време, въпреки че клиентите все още могат да достигнат до регионален сървър. Възможно е да се използва standby master, но само един HMaster е активен в даден момент и повишаването на втория HMaster след повреда не е мигновено. В резултат на това HMaster е признат проблем с производителността.

HBase не поддържа директно операции за кръстосано свързване или свързване между таблици. Съединенията могат да бъдат реализирани с MapReduce, но това добавя значително време за проектиране и разработка, а някои таблични съединения са практически непрактични в HBase.

Мигрирането на данни от външна RDBMS в HBase обикновено изисква нов дизайн на схемата и този процес на миграция може да отнеме много време. Заявките също са трудни: много екипи добавят SQL слой, като Apache Phoenix, върху HBase, за да могат четене и запис на данни с познати запитвания.

HBase поддържа само един индекс — ключът на реда действа като първичен ключ — така че търсенията във всяко друго поле са бавни. Екипите заобикалят това, като пишат код за MapReduce или като интегрират Apache. Solr и Apache Phoenix за вторично индексиране.

• Контролите за сигурност за достъп до данни от множество потребители са се подобрили само бавно.
• HBase не поддържа напълно частични ключове.
• За всяка таблица е разрешен само един ред на сортиране по подразбиране.
• Съхраняването на големи двоични файлове в HBase е трудно.
• Съхранението в HBase ограничава заявките и сортирането в реално време.
• Търсенията по ключове и диапазони в съдържанието на таблицата могат да ограничат заявките, които трябва да се изпълняват в реално време.
• Индексирането по подразбиране липсва; програмистите трябва да напишат допълнителен код или скриптове, за да добавят индексиране.
• Хардуерните изисквания и разпределението на блоковете памет правят HBase скъп за изпълнение.
• Разпределеният клъстер се нуждае от много сървъри - отделни възли за NameNode, DataNodes, ZooKeeper и Region сървърите.
• За добра производителност са необходими машини с голям обем памет.
• Общите разходи и поддръжка са по-високи от по-простите алтернативи.

HBase срещу RDBMS

Статията многократно сравнява HBase с традиционните релационни бази данни. Таблицата по-долу обобщава основните разлики, за да можете да решите кой модел е подходящ за дадено работно натоварване:

Накратко, HBase предпочита мащабируемостта и достъпа в реално време, докато RDBMS предпочита богатите заявки и силната консистентност. Изберете HBase, когато обемът на данните и пропускателната способност за запис надхвърлят това, което една релационна база данни може удобно да обработи.

Въпроси и Отговори