Zalety i wady HBase oraz wąskie gardło wydajności

Co to jest HBase?

HBase to rozproszona, zorientowana na kolumny baza danych NoSQL o otwartym kodzie źródłowym, działająca na bazie rozproszonego systemu plików Hadoop (HDFS). Oparta na Google Bigtable przechowuje dane w tabelach składających się z rodzin wierszy i kolumn. Jest przeznaczony do rozproszonych zestawów danych, które mogą rozrastać się do miliardów wierszy i milionów kolumn.

W przeciwieństwie do relacyjnej bazy danych, HBase nie korzysta ze stałego schematu ani nie oferuje optymalizatora zapytań. Zamiast tego, każda wartość jest adresowana za pomocą klucza wiersza, rodziny kolumn, kwalifikatora kolumny i znacznika czasu, co przyspiesza losowe odczyty i zapisy w czasie rzeczywistym, nawet na masową skalę.

Klaster HBase opiera się na kilku podstawowych komponentach. HMaster koordynuje klaster i przypisuje regiony, serwery regionów przechowują i udostępniają rzeczywiste dane, a serwer Apache Opiekun zoo tracks, które serwery są aktywne i pomagają w przełączaniu awaryjnym. Ponieważ HBase jest częścią ekosystemu Hadoop, współpracuje z narzędziami takimi jak MapaReduce, Uli Pig do analizy wsadowej. Aby dokładniej przyjrzeć się mechanizmom wewnętrznym, zobacz Architektura HBase.

Zalety HBase'a

Oto najważniejsze korzyści wynikające z używania HBase:

• Przechowuje bardzo duże zbiory danych w systemie HDFS i potrafi agregować oraz analizować miliardy wierszy przechowywanych w tabelach HBase.
• Bazę danych można udostępniać wielu klientom w rozproszonym środowisku.
• Odczyt i przetwarzanie danych zajmuje mniej czasu w porównaniu z tradycyjnymi modelami relacyjnymi.
• Obsługuje szybkie, losowe operacje odczytu i zapisu.
• Baza danych HBase jest szeroko wykorzystywana do przeprowadzania analiz online.
• W zastosowaniach bankowych, takich jak aktualizacja salda w czasie rzeczywistym w bankomatach, HBase niezawodnie obsługuje dużą liczbę operacji odczytu i zapisu.

Wady HBase

Oto ważne ograniczenia HBase:

• HBase nie zastępuje w pełni tradycyjnych modeli relacyjnych; niektóre funkcje relacyjne nie są obsługiwane.
• HBase nie może wykonywać funkcji takich jak SQL. Nie obsługuje struktury SQL, więc nie posiada optymalizatora zapytań.
• HBase wymaga dużej mocy obliczeniowej i pamięci, z dużą liczbą sekwencyjnych operacji wejścia/wyjścia, podczas gdy zadania MapReduce są w większości ograniczone przez wejście/wyjście i mają stałą pamięć. Integracja HBase z zadaniami MapReduce może powodować nieprzewidywalne opóźnienia.
• Integrowanie HBase z zadaniami Pig i Hive może czasami powodować problemy z pamięcią w klastrze.
• W środowisku klastra współdzielonego konfiguracja wymaga mniejszej liczby slotów zadań na węzeł do przydzielenia na potrzeby procesora HBase.

Wąskie gardła wydajności w HBase

HBase zapewnia skalę, ale kilka rozwiązań architektonicznych stwarza wąskie gardła wydajnościowe, które zespoły powinny uwzględnić przy planowaniu:

W dużym środowisku produkcyjnym klaster HBase może obsługiwać tysiące węzłów, a mimo to tylko HMaster pełni rolę serwera głównego dla wszystkich serwerów podrzędnych Region Servers. Jeśli HMaster ulegnie awarii, odzyskiwanie może zająć dużo czasu, nawet jeśli klienci nadal będą mogli połączyć się z serwerem Region Servers. Uruchomienie zapasowego serwera głównego jest możliwe, ale w danym momencie aktywny jest tylko jeden HMaster, a awansowanie drugiego HMaster po awarii nie jest natychmiastowe. W rezultacie HMaster jest znanym wąskim gardłem wydajności.

HBase nie obsługuje bezpośrednio operacji międzytabelowych ani łączenia. Połączenia można zaimplementować za pomocą MapReduce, ale wiąże się to ze znacznym nakładem czasu na projektowanie i programowanie, a niektóre łączenia tabel są praktycznie niepraktyczne w HBase.

Migracja danych z zewnętrznego systemu RDBMS do HBase zazwyczaj wymaga nowego projektu schematu, a proces migracji może być długotrwały. Zapytania są również trudne: wiele zespołów dodaje warstwę SQL, taką jak Apache Phoenix, na HBase, aby móc… odczyt i zapis danych ze znanymi pytaniami.

HBase obsługuje tylko jeden indeks – klucz wiersza działa jako klucz podstawowy – więc wyszukiwanie w dowolnym innym polu jest powolne. Zespoły radzą sobie z tym, pisząc kod MapReduce lub integrując Apache. Solr i Apache Phoenix do indeksowania wtórnego.

• Kontrola bezpieczeństwa dostępu wielu użytkowników do danych poprawia się powoli.
• HBase nie obsługuje w pełni kluczy częściowych.
• W każdej tabeli dozwolona jest tylko jedna domyślna kolejność sortowania.
• Przechowywanie dużych plików binarnych w HBase jest trudne.
• Ograniczenia pamięci masowej HBase w zakresie zapytań i sortowania w czasie rzeczywistym.
• Wyszukiwanie kluczy i zakresów w zawartości tabeli może ograniczać zapytania, które muszą być wykonywane w czasie rzeczywistym.
• Brak domyślnego indeksowania; programiści muszą napisać dodatkowy kod lub skrypty, aby dodać indeksowanie.
• Wymagania sprzętowe i alokacja bloków pamięci sprawiają, że uruchomienie HBase jest kosztowne.
• Rozproszony klaster wymaga wielu serwerów — osobnych węzłów dla NameNode, DataNodes, ZooKeeper i serwerów Region.
• Do uzyskania dobrej wydajności wymagane są maszyny z dużą ilością pamięci.
• Całkowity koszt i wymagania konserwacyjne są wyższe niż w przypadku prostszych alternatyw.

HBase kontra RDBMS

W artykule wielokrotnie zestawia się HBase z tradycyjnymi relacyjnymi bazami danych. Poniższa tabela podsumowuje główne różnice, aby ułatwić wybór modelu odpowiedniego do obciążenia:

Krótko mówiąc, HBase stawia na skalowalność i dostęp w czasie rzeczywistym, podczas gdy RDBMS preferuje rozbudowane zapytania i wysoką spójność. Wybierz HBase, gdy wolumen danych i przepustowość zapisu przekraczają możliwości relacyjnej bazy danych.

FAQ