Mai bejegyzésünkben beszéljünk a HBase architektúráról. Tisztítsuk meg a HBase alapjait, mielőtt elmélyülnénk a HBase architektúrájában.
HBase - Az alapok:
A HBase egy nyílt forráskódú, NoSQL elosztott, nem relációs, változatos, többdimenziós, oszloporientált áruház, amelyet a HDFS tetején futó Google BigTable után modelleztek. '' A NoSQL 'egy tág kifejezés, amely azt jelenti, hogy az adatbázis nem RDBMS, amely elsődleges hozzáférési nyelvként támogatja az SQL-t. De sokféle NoSQL adatbázis létezik, és a Berkeley DB jó példa egy helyi NoSQL adatbázisra, míg a HBase nagyon elosztott adatbázis.
A HBase biztosítja a Google BigTable összes funkcióját. A Powerset projektje hatalmas mennyiségű adat feldolgozására indult a természetes nyelv keresésére. Az Apache Hadoop projektjének részeként fejlesztették ki, és a HDFS (Hadoop Distributed File System) tetején fut. Hibatűrő módszereket kínál nagy mennyiségű ritka adat tárolására. A HBase valójában inkább „Data Store”, mint „Data Base”, mert hiányzik belőle az RDBMS-ben elérhető számos funkció, például gépelt oszlopok, másodlagos indexek, triggerek és speciális lekérdezési nyelvek stb.
Az oszloporientált adatbázisokban az adattáblázat az adatok oszlopainak szakaszaként, nem pedig adatsorokként kerül tárolásra. Az oszloporientált adatbázis adatmodellje a táblázat nevéből, a sor kulcsából, az oszlopcsaládból, az oszlopokból és az időbélyegből áll. A HBase-ben táblázatok készítése közben a sorok egyedileg azonosíthatók lesznek a sorkulcsok és az időbélyegző segítségével. Ebben az adatmodellben az oszlopcsalád statikus, míg az oszlopok dinamikusak. Most nézzük meg a HBase architektúrát.
Mikor kell a HBase-hez menni?
A HBase csak akkor jó lehetőség, ha több száz millió vagy milliárd sor van. A HBase helyeken is használható, amikor az RDBMS-ről HBase-re való áttérést tervez teljes átalakításként, szemben a porttal. Más szavakkal, a HBase nincs optimalizálva klasszikus tranzakciós alkalmazásokhoz vagy akár relációs elemzésekhez. Nagy kötegelt MapReduce készítésekor sem helyettesítheti a HDFS-t. Akkor miért érdemes a HBase-re menni ?? Ha az alkalmazásnak van egy változó sémája, ahol az egyes sorok kissé eltérnek, akkor a HBase-t kell megnéznie.
mély tanulás vs gépi tanulás vs mintafelismerés
HBase architektúra:
A következő ábra világosan elmagyarázza a HBase architektúrát.
A HBase-ben három fő összetevő van: Mester, Region kiszolgáló és állatkert őrző . A többi alkatrész Memstore, HFile és WAL.
Mivel a HBase a HDFS tetején fut, a Master-Slave architektúrát használja, amelyben a HMaster lesz a fő csomópont, a Region Servers pedig a slave csomópont. Amikor az ügyfél írási kérelmet küld, a HMaster megkapja ezt a kérést, és továbbítja azt a megfelelő Region Server-nek.
Region Server:
Ez egy olyan rendszer, amely hasonlóan működik, mint egy adatcsomópont. Amikor a Region Server (RS) megkapja az írási kérelmet, a kérést egy adott régióra irányítja. Minden régió sorokat tárol. A sorok adatait több oszlopcsaládban (CF) lehet elválasztani. Az adott CF adatait a HStore tárolja, amely Memstore-ból és egy HFile-készletből áll.
Mit csinál a Memstore?
A Memstore nyomon követi az olvasási és írási műveletek összes naplóját, amelyet az adott régiókiszolgálón végrehajtottak. Ebből azt mondhatjuk, hogy hasonlóan működik, mint egy névcsomópont a Hadoop-ban. A Memstore egy memóriában lévő tároló, ezért a Memstore az egyes adatcsomópontok memóriájában lévő tárolóit használja a naplók tárolására. Bizonyos küszöbértékek teljesülése esetén a Memstore adatai a HFile fájlba kerülnek.
A Memstore használatának fő célja az, hogy adatokat kell tárolni az DFS-en, sorok szerint rendezve. Mivel a HDFS-t szekvenciális olvasásokhoz és írásokhoz tervezték, fájlmódosítások nélkül visszakeresés. A probléma megoldása érdekében a HBase pufferek a memóriában utoljára befogadott adatokat (Memstore-ban), öblítés előtt „rendezik”, majd gyors szekvenciális írásokkal írnak a HDFS-be. Ezért a HFile tartalmazza a rendezett sorok listáját.
Minden alkalommal, amikor a Memstore flush történik, minden CF-hez egy HFile készül, és a gyakori öblítések rengeteg HFile-t hozhatnak létre. Mivel az olvasás során a HBase-nek sok HF fájlt kell megnéznie, az olvasási sebesség szenvedhet. A túl sok HFile megnyitásának megakadályozása és az olvasási teljesítmény romlásának elkerülése érdekében a HFiles tömörítési eljárást alkalmazzuk. A HBase rendszeresen (amikor bizonyos konfigurálható küszöbértékek teljesülnek) több kisebb HF fájlt tömörít egy nagyba. Nyilvánvaló, hogy minél több Memstore által létrehozott fájl mossa el, annál több munka (extra terhelés) lesz a rendszer számára. Ehhez hozzáadjuk, hogy míg a tömörítési folyamat általában más kérések kiszolgálásával párhuzamosan zajlik, és amikor a HBase nem képes lépést tartani a HFile-ek tömörítésével (igen, vannak erre konfigurált küszöbértékek is), akkor ismét blokkolja az RS-n történő írásokat. Mint fentebb tárgyaltuk, ez nagyon nem kívánatos.
hogyan kell használni a tostring módszert a java-ban
Nem lehetünk biztosak abban, hogy az adatok a Memstore-ban végig állandóak lesznek. Tegyük fel, hogy egy adott adatcsomópont nem működik. Ekkor az adatcsomópont memóriájában található adatok elvesznek.
Ennek a problémának a kiküszöbölésére, amikor a kérés a mester részéről érkezik, a WAL-nak is írta. A WAL nem más, mint Írja előre a naplókat amely a HDFS-en található, egy állandó tároló. Most megbizonyosodhatunk arról, hogy akkor is, ha az adatcsomópont nincs, az adatok nem vesznek el. megvan az összes olyan művelet másolata, amelyet állítólag meg kell tennie a WAL-ban. Amikor az adatcsomópont fent van, az összes tevékenységet újra elvégzi. Miután a művelet befejeződött, minden kiürül a Memstore-ból és a WAL-ból, és HFile-be van írva annak biztosítására, hogy ne fogyjon a memória.
Vegyünk egy egyszerű példát, hogy hozzá akarom adni a 10. sort, amikor bejön az írási kérelem, azt mondja, hogy az összes metaadatot átadja a Memstore-nak és a WAL-nak. Miután az adott sort beírta a HFile-be, a Memstore-ban mindent töröl, és a WAL kiürül.
Állatgondozó:
A HBase integrálva van az állatkert-őrzővel. Amikor elindítom a HBase-t, elindul az állatkert-őr példánya is. Ennek oka az, hogy az állatkert-őr segít nekünk nyomon követni az összes régióbeli szervert, amely a HBase számára rendelkezésre áll. Az állatkert őrzője nyomon követi, hogy hány régiószerver van, melyik régiószerver melyik adatcsomópontból melyik adatcsomópontba tart. Nyomon követi azokat a kisebb adathalmazokat, amelyekből Hadoop hiányzik. Csökkenti a Hadoop tetején lévő rezsit, amely nyomon követi a legtöbb metaadatát. Ezért a HMaster megkapja a régió szervereinek részleteit, ha valóban felveszi a kapcsolatot az állatkert őrével.
Van egy kérdésünk? Említse meg őket a megjegyzések részben, és mi kapcsolatba lépünk Önnel.
A php létrehoz egy tömböt a stringből
Kapcsolódó hozzászólások: