Переваги, недоліки та вузьке місце HBase

Що таке HBase?

HBase — це розподілена база даних NoSQL з відкритим кодом, орієнтована на колонки, яка працює поверх розподіленої файлової системи Hadoop (HDFS). Заснована на... Google Bigtable зберігає дані в таблицях, що складаються з рядків і сімейств стовпців, і розроблений для розріджених наборів даних, які можуть зростати до мільярдів рядків і мільйонів стовпців.

На відміну від реляційної бази даних, HBase не використовує фіксовану схему та не пропонує оптимізатора запитів. Натомість кожне значення адресується ключем рядка, сімейством стовпців, кваліфікатором стовпців та міткою часу, що робить випадкові операції читання та запису в режимі реального часу швидкими навіть у великих масштабах.

Кластер HBase спирається на кілька основних компонентів. HMaster координує кластер і призначає регіони, сервери регіонів зберігають і обслуговують фактичні дані, а Apache... ZooKeeper tracks визначає, які сервери активні, та допомагає з відновленням після збоїв. Оскільки HBase знаходиться в екосистемі Hadoop, він працює з такими інструментами, як MapReduce, Вулик, а Pig — для пакетної аналітики. Щоб глибше ознайомитися з внутрішніми механізмами, див. Архітектура HBase.

Переваги HBase

Ось основні переваги використання HBase:

• Зберігає дуже великі набори даних поверх HDFS та може агрегувати й аналізувати мільярди рядків, що зберігаються в таблицях HBase.
• База даних може бути спільною для багатьох клієнтів у розподіленому середовищі.
• Зчитування та обробка даних займають менше часу порівняно з традиційними реляційними моделями.
• Підтримує швидкі операції випадкового читання та запису.
• HBase широко використовується для онлайн-аналітичних операцій.
• У банківських програмах, таких як оновлення балансу в режимі реального часу для банкоматів, HBase надійно обробляє великі обсяги зчитування та запису.

Недоліки HBase

Ось важливі обмеження HBase:

• HBase не є повною заміною традиційних реляційних моделей; деякі реляційні функції не підтримуються.
• HBase не може виконувати такі функції, як SQLВін не підтримує структуру SQL, тому не має оптимізатора запитів.
• HBase вимагає інтенсивного використання процесора та пам'яті з великим послідовним доступом до вводу або виводу, тоді як завдання MapReduce здебільшого пов'язані з вводом/виводом та фіксованою пам'яттю. Інтеграція HBase із завданнями MapReduce може призвести до непередбачуваних затримок.
• Інтеграція HBase із завданнями Pig та Hive іноді може спричиняти проблеми з пам'яттю в кластері.
• У середовищі спільного кластера для налаштування потрібно виділити менше слотів завдань на вузол для вимог процесора HBase.

Вузькі місця продуктивності в HBase

HBase забезпечує масштабованість, але кілька архітектурних рішень створюють вузькі місця в продуктивності, які команди повинні обійти:

У великому робочому середовищі кластер HBase може працювати на тисячах вузлів, проте лише HMaster виступає головним сервером для всіх підлеглих регіональних серверів. Якщо HMaster вийде з ладу, відновлення може зайняти багато часу, навіть якщо клієнти все ще можуть зв'язатися з регіональним сервером. Запуск резервного головного сервера можливий, але одночасно активний лише один HMaster, а підвищення статусу другого HMaster після збою не відбувається миттєво. Як результат, HMaster є визнаним вузьким місцем продуктивності.

HBase не підтримує операції міжтаблицевого з'єднання або об'єднання безпосередньо. Об'єднання можна реалізувати за допомогою MapReduce, але це значно збільшує час проектування та розробки, а деякі об'єднання таблиць фактично непрактичні в HBase.

Міграція даних із зовнішньої СУБД до 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, коли обсяг даних та пропускна здатність запису перевищують те, що може комфортно обробляти реляційна база даних.

Поширені запитання