A HBase előnyei, hátrányai és a teljesítmény szűk keresztmetszete

Mi az a HBase?

A HBase egy nyílt forráskódú, elosztott, oszloporientált NoSQL adatbázis, amely a Hadoop elosztott fájlrendszeren (HDFS) fut. Modellezése a következőre épül: Google A Bigtable sorokból és oszlopcsaládokból álló táblázatokban tárolja az adatokat, és ritka adathalmazokhoz tervezték, amelyek akár több milliárd sorra és több millió oszlopra is növekedhetnek.

Egy relációs adatbázissal ellentétben a HBase nem használ rögzített sémát, és nem kínál lekérdezésoptimalizálót. Ehelyett minden értéket egy sorkulcs, oszlopcsalád, oszlopminősítő és időbélyeg címez, ami még hatalmas méretekben is gyors véletlenszerű valós idejű olvasásokat és írásokat tesz lehetővé.

Egy HBase klaszter néhány alapvető összetevőre támaszkodik. A HMaster koordinálja a klasztert és hozzárendeli a régiókat, a régiókiszolgálók tárolják és kiszolgálják a tényleges adatokat, az Apache pedig Állatgondozó tracks, amely szerverek aktívak, és segít a feladatátvételben. Mivel a Hadoop ökoszisztémán belül helyezkedik el, a HBase olyan eszközökkel működik, mint a MapReduce, Kaptár, és a Pig a kötegelt elemzéshez. A belső folyamatok részletesebb megismeréséhez lásd a HBase architektúra.

A HBase előnyei

Íme a HBase használatának főbb előnyei:

• Nagyon nagy adathalmazokat tárol a HDFS tetején, és képes összesíteni és elemezni a HBase táblákban tárolt több milliárd sort.
• Az adatbázis megosztható több kliens között egy elosztott környezetben.
• Az adatolvasás és -feldolgozás kevesebb időt vesz igénybe a hagyományos relációs modellekhez képest.
• Támogatja a gyors véletlenszerű olvasási és írási műveleteket.
• A HBase-t széles körben használják online analitikai műveletekhez.
• Banki alkalmazásokban, például ATM-ek valós idejű egyenlegfrissítéseiben, a HBase megbízhatóan kezeli a nagy mennyiségű olvasást és írást.

A HBase hátrányai

Íme a HBase fontos korlátai:

• A HBase nem helyettesíti teljesen a hagyományos relációs modelleket; bizonyos relációs funkciók nem támogatottak.
• A HBase nem tud olyan funkciókat végrehajtani, mint a SQLNem támogatja az SQL struktúrát, így nincs lekérdezésoptimalizálója.
• A HBase CPU- és memóriaigényes, nagyszámú szekvenciális bemeneti vagy kimeneti hozzáféréssel, míg a MapReduce feladatok többnyire I/O-hoz kötöttek, fix memóriával. A HBase és a MapReduce feladatok integrálása kiszámíthatatlan késleltetéseket eredményezhet.
• A HBase Pig és Hive feladatokkal való integrálása időnként memóriaproblémákat okozhat a fürtön.
• Megosztott fürtkörnyezetben a beállításnak kevesebb feladatidőt kell lefoglalnia csomópontonként a HBase CPU-követelmények kielégítésére.

A teljesítmény szűk keresztmetszete a HBase-ben

A HBase méretezhetőséget biztosít, de számos architekturális döntés teljesítménybeli szűk keresztmetszeteket okoz, amelyeket a csapatoknak figyelembe kell venniük:

Egy nagyméretű termelési környezetben egy HBase klaszter több ezer csomóponton futhat, mégis csak a HMaster működik masterként az összes slave regionális kiszolgáló számára. Ha a HMaster leáll, a helyreállítás hosszú időt vehet igénybe, még akkor is, ha a kliensek továbbra is elérhetik a regionális kiszolgálót. Egy készenléti master futtatása lehetséges, de egyszerre csak egy HMaster lehet aktív, és a második HMaster előléptetése hiba után nem történik meg azonnal. Ennek eredményeként a HMaster egy elismert teljesítménybeli szűk keresztmetszet.

A HBase nem támogatja közvetlenül a táblaközi vagy illesztési műveleteket. Az illesztések megvalósíthatók a MapReduce segítségével, de ez jelentős tervezési és fejlesztési időt igényel, és egyes táblaillesztések gyakorlatilag nem praktikusak a HBase-ben.

Egy külső RDBMS-ből a HBase-be történő adatmigrálás általában új sématervét igényli, és ez a migrációs folyamat sokáig tarthat. A lekérdezés is nehézkes: sok csapat egy SQL réteget, például az Apache Phoenixet ad hozzá a HBase-hez, hogy adatok olvasása és írása ismerős kérdésekkel.

A HBase csak egyetlen indexet támogat – a sorkulcs az elsődleges kulcs –, így a keresések bármely más mezőben lassúak. A csapatok ezt MapReduce kód írásával vagy az Apache integrálásával oldják meg. Solr és az Apache Phoenix a másodlagos indexeléshez.

• A többfelhasználós adathozzáférés biztonsági ellenőrzései csak lassan javultak.
• A HBase nem támogatja teljes mértékben a részleges kulcsokat.
• Táblázatonként csak egy alapértelmezett rendezési sorrend engedélyezett.
• A nagy bináris fájlok HBase-ben történő tárolása nehézkes.
• A HBase tároló korlátozza a valós idejű lekérdezéseket és rendezést.
• A tábla tartalmának kulcs- és tartománykeresései korlátozhatják a valós időben futtatandó lekérdezéseket.
• Az alapértelmezett indexelés hiányzik; a programozóknak extra kódot vagy szkripteket kell írniuk az indexelés hozzáadásához.
• A hardverkövetelmények és a memóriablokk-elosztás miatt a HBase futtatása drága.
• Egy elosztott klaszternek sok szerverre van szüksége – külön csomópontokra a NameNode, a DataNode, a ZooKeeper és a Region szerverekhez.
• A jó teljesítményhez nagy memóriájú gépekre van szükség.
• Az összköltség és a karbantartás is magasabb, mint az egyszerűbb alternatíváké.

HBase vs. RDBMS

A cikk ismételten szembeállítja a HBase-t a hagyományos relációs adatbázisokkal. Az alábbi táblázat összefoglalja a főbb különbségeket, így eldöntheti, hogy melyik modell illik egy adott munkaterheléshez:

Röviden, a HBase a skálázhatóságot és a valós idejű hozzáférést részesíti előnyben, míg az RDBMS a gazdag lekérdezést és az erős konzisztenciát részesíti előnyben. Válassza a HBase-t, ha az adatmennyiség és az írási átviteli sebesség meghaladja azt, amit egy relációs adatbázis kényelmesen kezelni tud.

GYIK