{"id":55302,"date":"2020-01-17T00:00:00","date_gmt":"2020-01-16T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/teoriya-i-praktika-ispolzovaniya-hbase"},"modified":"2020-02-18T14:03:24","modified_gmt":"2020-02-18T11:03:24","slug":"teoriya-i-praktika-ispolzovaniya-hbase","status":"publish","type":"post","link":"https:\/\/prohoster.info\/hu\/blog\/administrirovanie\/teoriya-i-praktika-ispolzovaniya-hbase","title":{"rendered":"Az HBase haszn\u00e1lat\u00e1nak elm\u00e9lete \u00e9s gyakorlata","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

J\u00f3 napot! A nevem Danil Lipovoy, a csapatunk a Szbertechn\u00e9l elkezdte haszn\u00e1lni az HBase-t, mint val\u00f3s idej\u0171 adatrakt\u00e1rat. Az al\u00e1bbiakban \u00f6sszegy\u0171jt\u00f6tt tapasztalatainkat szeretn\u00e9nk rendszerezni \u00e9s le\u00edrni (rem\u00e9lj\u00fck, sokak sz\u00e1m\u00e1ra hasznos lesz). Az al\u00e1bb felsorolt k\u00eds\u00e9rletek az HBase 1.2.0-cdh5.14.2 \u00e9s 2.0.0-cdh6.0.0-beta1 verzi\u00f3ival t\u00f6rt\u00e9ntek. <\/p>\n

    \n
  1. \u00c1ltal\u00e1nos architekt\u00fara <\/li>\n
  2. Adatok \u00edr\u00e1sa HBASE-be<\/li>\n
  3. Adatok olvas\u00e1sa HBASE-b\u0151l<\/li>\n
  4. Adatok gyors\u00edt\u00f3t\u00e1raz\u00e1sa<\/li>\n
  5. T\u00f6meges adatfeldolgoz\u00e1s MultiGet\/MultiPut<\/li>\n
  6. A t\u00e1bl\u00e1k r\u00e9gi\u00f3kra bont\u00e1s\u00e1nak strat\u00e9gi\u00e1ja (sharding)<\/li>\n
  7. Hibat\u0171r\u00e9s, t\u00f6m\u00f6r\u00edt\u00e9s \u00e9s az adatok lok\u00e1ci\u00f3ja<\/li>\n
  8. Be\u00e1ll\u00edt\u00e1sok \u00e9s teljes\u00edtm\u00e9ny<\/li>\n
  9. Terhel\u00e9ses tesztel\u00e9s<\/li>\n
  10. K\u00f6vetkeztet\u00e9sek<\/li>\n<\/ol>\n

    <\/a><\/noindex><\/p>\n

    1. \u00c1ltal\u00e1nos architekt\u00fara<\/h2>\n

    \n\"Az
    \nA tartal\u00e9k Master a ZooKeeper csom\u00f3ponton hallgatja a f\u0151 akt\u00edv csom\u00f3pont heartbeat-j\u00e9t, \u00e9s a kies\u00e9s eset\u00e9n \u00e1tveszi a Master feladatait. <\/p>\n

    2. Adatok \u00edr\u00e1sa HBASE-be<\/h2>\n

    \nEl\u0151sz\u00f6r vizsg\u00e1ljuk meg a legegyszer\u0171bb esetet \u2013 egy kulcs-\u00e9rt\u00e9k p\u00e1r \u00edr\u00e1s\u00e1t egy t\u00e1bl\u00e1ba put(rowkey) haszn\u00e1lat\u00e1val. A kliensnek el\u0151sz\u00f6r is meg kell tudnia, hol tal\u00e1lhat\u00f3 a gy\u00f6k\u00e9r r\u00e9gi\u00f3szerver (Root Region Server - RRS), amely a hbase:meta t\u00e1bl\u00e1t t\u00e1rolja. Ezt az inform\u00e1ci\u00f3t a ZooKeeper-t\u0151l kapja. Ezut\u00e1n a RRS-hez fordul, \u00e9s elolvassa a hbase:meta t\u00e1bl\u00e1t, amelyb\u0151l kinyeri, hogy melyik RegionServer (RS) felel\u0151s az adott rowkey kulcshoz tartoz\u00f3 adatok t\u00e1rol\u00e1s\u00e1\u00e9rt a v\u00e1lasztott t\u00e1bl\u00e1ban. A j\u00f6v\u0151beli felhaszn\u00e1l\u00e1s \u00e9rdek\u00e9ben a meta-t\u00e1bl\u00e1t a kliens gyors\u00edt\u00f3t\u00e1razza, \u00edgy a tov\u00e1bbi k\u00e9r\u00e9sek gyorsabban, k\u00f6zvetlen\u00fcl az RS-hez \u00e9rkeznek.<\/p>\n

    Ezut\u00e1n az RS, miut\u00e1n megkapta a k\u00e9r\u00e9st, el\u0151sz\u00f6r is be\u00edrja azt a WriteAheadLog (WAL) napl\u00f3ba, ami a vissza\u00e1ll\u00edt\u00e1shoz sz\u00fcks\u00e9ges, ha a rendszer le\u00e1ll. Ezt k\u00f6vet\u0151en elmenti az adatokat a MemStore-ba. Ez egy mem\u00f3riaalap\u00fa puffer, amely a r\u00e9gi\u00f3hoz tartoz\u00f3 rendezett kulcsk\u00e9szletet tartalmazza. A t\u00e1bla r\u00e9gi\u00f3kra (part\u00edci\u00f3kra) bonthat\u00f3, amelyeket minden egyes r\u00e9gi\u00f3 nem \u00e1tfed\u0151 kulcsk\u00e9szletek t\u00e1rol\u00e1s\u00e1ra haszn\u00e1l. Ez lehet\u0151v\u00e9 teszi, hogy a r\u00e9gi\u00f3kat k\u00fcl\u00f6nb\u00f6z\u0151 szervereken elhelyezve magasabb teljes\u00edtm\u00e9nyt \u00e9rjenek el. Azonban, annak ellen\u00e9re, hogy ez a kijelent\u00e9s nyilv\u00e1nval\u00f3nak t\u0171nik, hamarosan l\u00e1tni fogjuk, hogy nem minden esetben m\u0171k\u00f6dik.<\/p>\n

    A MemStore-ba t\u00f6rt\u00e9n\u0151 \u00edr\u00e1st k\u00f6vet\u0151en a kliens v\u00e1laszt kap arr\u00f3l, hogy az adatokat sikeresen elmentett\u00e9k. Val\u00f3j\u00e1ban azonban az adatok csak a pufferben t\u00e1rol\u00f3dnak, \u00e9s csak egy megfelel\u0151 id\u0151intervallum ut\u00e1n, vagy \u00faj adatok felv\u00e9tel\u00e9nek eset\u00e9n ker\u00fclnek a lemezre. <\/p>\n

    \"Az
    \nA \"Delete\" operation does not physically remove data. It is merely marked as deleted, with actual deletion occurring at the time of calling the major compact function, which is explained in detail in section 7.<\/p>\n

    Files in HFile format accumulate in HDFS, and from time to time, a minor compact process is initiated, which simply merges small files into larger ones without deleting anything. Over time, this becomes a problem that manifests only when reading data (we will return to this later). <\/p>\n

    In addition to the loading process described above, there is a much more efficient procedure, which is perhaps the strongest point of this database \u2013 BulkLoad. This involves creating HFiles ourselves and placing them on the disk, allowing for excellent scalability and reaching quite respectable speeds. Essentially, the limitation here is not HBase, but the capabilities of the hardware. Below are the loading results on a cluster consisting of 16 RegionServers and 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads), HBase version 1.2.0-cdh5.14.2. <\/p>\n

    \"Az
    \n
    \nIt can be seen that by increasing the number of partitions (regions) in the table, as well as Spark executors, we achieve an increase in loading speed. Speed also depends on the volume of records. Large blocks yield an increase in measurement in MB\/sec, while smaller ones increase the number of inserted records per unit time, all else being equal. <\/p>\n

    You can also initiate loading into two tables simultaneously and achieve a doubling of speed. It can be seen below that writing 10 KB blocks straight into two tables runs at about 600 Mb\/sec for each (totaling 1275 Mb\/sec), matching the speed of writing into one table at 623 MB\/sec (see #11 above).<\/p>\n

    \"Az
    \nHowever, the second run with 50 KB records shows that the loading speed is growing only slightly, indicating a nearing of the limit values. It should be noted that HBASE itself is not significantly stressed here; all that is required from it is to initially hand over data from hbase:meta, and after placing the HFiles, flush the BlockCache data and save the MemStore buffer to disk, if it is not empty.<\/p>\n

    3. Reading data from HBASE<\/h2>\n

    \nHa felt\u00e9telezz\u00fck, hogy az \u00f6sszes inform\u00e1ci\u00f3 a hbase:meta m\u00e1r rendelkez\u00e9sre \u00e1ll a kliensn\u00e9l (l\u00e1sd 2. pont), akkor a k\u00e9r\u00e9s azonnal arra a RS-re \u00e9rkezik, ahol a sz\u00fcks\u00e9ges kulcsot t\u00e1rolj\u00e1k. El\u0151sz\u00f6r a MemCache-ben t\u00f6rt\u00e9nik a keres\u00e9s. F\u00fcggetlen\u00fcl att\u00f3l, hogy vannak-e ott adatok vagy sem, a keres\u00e9s a BlockCache pufferben is zajlik, sz\u00fcks\u00e9g eset\u00e9n pedig az HFiles-ban. Ha az adatokat megtal\u00e1lj\u00e1k a f\u00e1jlban, akkor a BlockCache-be helyezik, \u00e9s a k\u00f6vetkez\u0151 k\u00e9r\u00e9skor gyorsabban visszaadj\u00e1k. A HFile-ban t\u00f6rt\u00e9n\u0151 keres\u00e9s viszonylag gyorsan zajlik a Bloom sz\u0171r\u0151 haszn\u00e1lat\u00e1nak k\u00f6sz\u00f6nhet\u0151en, azaz egy kis mennyis\u00e9g\u0171 adat beolvas\u00e1s\u00e1val azonnal meghat\u00e1rozza, hogy ez a f\u00e1jl tartalmazza-e a sz\u00fcks\u00e9ges kulcsot, \u00e9s ha nem, akkor \u00e1tt\u00e9r a k\u00f6vetkez\u0151re.<\/p>\n

    \"Az
    \nA h\u00e1rom forr\u00e1sb\u00f3l kapott adatok alapj\u00e1n az RS v\u00e1laszt form\u00e1l. K\u00fcl\u00f6n\u00f6sen, ha a kliens verzi\u00f3z\u00e1st k\u00e9rt, akkor egyszerre sz\u00e1mos megtal\u00e1lt verzi\u00f3t is tov\u00e1bb\u00edthat.<\/p>\n

    4. Adatok gyors\u00edt\u00f3t\u00e1raz\u00e1sa<\/h2>\n

    \nA MemStore \u00e9s BlockCache puffer 80%-ig terjed\u0151 on-heap mem\u00f3riaig\u00e9nyt k\u00e9pvisel az RS sz\u00e1m\u00e1ra (a t\u00f6bbi a RS szolg\u00e1ltat\u00e1si feladatai sz\u00e1m\u00e1ra van fenntartva). Ha a tipikus haszn\u00e1lati m\u00f3d olyan, hogy a folyamatok \u00edrj\u00e1k \u00e9s azonnal olvass\u00e1k ezeket az adatokat, akkor \u00e9rdemes cs\u00f6kkenteni a BlockCache m\u00e9retet \u00e9s n\u00f6velni a MemStore-t, mivel \u00edr\u00e1skor az adatok nem ker\u00fclnek a gyors\u00edt\u00f3t\u00e1rba olvas\u00e1sra, \u00edgy a BlockCache haszn\u00e1lata ritk\u00e1bban fordul el\u0151. A BlockCache puffer k\u00e9t r\u00e9szb\u0151l \u00e1ll: LruBlockCache (mindig on-heap) \u00e9s BucketCache (\u00e1ltal\u00e1ban off-heap vagy SSD-n). A BucketCache haszn\u00e1lat\u00e1t akkor javaslom, ha az olvas\u00e1si k\u00e9r\u00e9sek sz\u00e1ma nagyon magas, \u00e9s nem f\u00e9rnek el az LruBlockCache-ben, ami akt\u00edv Garbage Collector m\u0171k\u00f6d\u00e9shez vezet. Ekkor azonban radik\u00e1lis teljes\u00edtm\u00e9nyn\u00f6veked\u00e9st ne v\u00e1rjunk az olvas\u00e1si gyors\u00edt\u00f3t\u00e1r haszn\u00e1lat\u00e1t\u00f3l, de erre m\u00e9g visszat\u00e9r\u00fcnk a 8. pontban.<\/p>\n

    \"Az
    \nA BlockCache egy eg\u00e9sz RS-re vonatkozik, m\u00edg a MemStore minden t\u00e1bl\u00e1hoz saj\u00e1t (egy minden Column Family-hez).<\/p>\n

    Mint ami le van \u00edrva<\/a><\/noindex> Elm\u00e9letben, \u00edr\u00e1skor az adatok nem ker\u00fclnek a gyors\u00edt\u00f3t\u00e1rba, \u00e9s val\u00f3ban, ezek a CACHE_DATA_ON_WRITE param\u00e9terek a t\u00e1bl\u00e1ra \u00e9s a \u201eCache DATA on Write\u201d az RS-re false-ra vannak \u00e1ll\u00edtva. Praktikusan azonban, ha adatokat \u00edrunk a MemStore-ba, majd azokat le\u00edrjuk a lemezre (ez\u00e1ltal t\u00f6r\u00f6lve \u0151ket), majd a l\u00e9trej\u00f6tt f\u00e1jlt elt\u00e1vol\u00edtjuk, akkor egy get k\u00e9r\u00e9s v\u00e9grehajt\u00e1sakor sikeresen megkapjuk az adatokat. R\u00e1ad\u00e1sul, m\u00e9g ha teljesen le is \u00e1ll\u00edtjuk a BlockCache-t, \u00e9s \u00faj adatokkal t\u00f6ltj\u00fck fel a t\u00e1bl\u00e1t, majd el\u00e9rj\u00fck a MemStore le\u00edr\u00e1s\u00e1t a lemezre, elt\u00e1vol\u00edtjuk az adatokat, \u00e9s egy m\u00e1sik \u00fcl\u00e9st k\u00e9r\u00fcnk, akkor az adatok valahonnan m\u00e9gis visszanyerhet\u0151k. Teh\u00e1t az HBase nemcsak az adatokat t\u00e1rolja, hanem titokzatos rejt\u00e9lyeket is.<\/p>\n

    hbase(main):001:0> create 'ns:magic', 'cf'\nL\u00e9trehozva a t\u00e1bl\u00e1zat: ns:magic\nEltelt: 1.1533 m\u00e1sodperc\nhbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me'\nEltelt: 0.2610 m\u00e1sodperc\nhbase(main):003:0> flush 'ns:magic'\nEltelt: 0.6161 m\u00e1sodperc\nhdfs dfs -mv \/data\/hbase\/data\/ns\/magic\/* \/tmp\/trash\nhbase(main):002:0> get 'ns:magic', 'key1'\n cf:c      timestamp=1534440690218, \u00e9rt\u00e9k=try_to_delete_me\n<\/code><\/pre>\n
    \nA \u201eCache DATA on Read\u201d param\u00e9ter false \u00e9rt\u00e9kre van \u00e1ll\u00edtva. Ha van \u00f6tletem, sz\u00edvesen v\u00e1rom a megjegyz\u00e9seket.<\/p>\n
    5. MultiGet\/MultiPut k\u00f6tegelt adatfeldolgoz\u00e1s<\/h2>\n
    \nAz egyes lek\u00e9rdez\u00e9sek (Get\/Put\/Delete) kezel\u00e9se meglehet\u0151sen k\u00f6lts\u00e9ges m\u0171velet, ez\u00e9rt \u00e9rdemes ezeket lehet\u0151s\u00e9g szerint List-be vagy List-be csoportos\u00edtani, ami jelent\u0151s teljes\u00edtm\u00e9nyn\u00f6veked\u00e9st eredm\u00e9nyez. K\u00fcl\u00f6n\u00f6sen az \u00edr\u00e1si m\u0171veletek eset\u00e9n, de olvas\u00e1s k\u00f6zben az al\u00e1bbi buktat\u00f3val tal\u00e1lkozhatunk. Az al\u00e1bbi grafikonon 50 000 rekord MemStore-b\u00f3l t\u00f6rt\u00e9n\u0151 olvas\u00e1s\u00e1nak ideje l\u00e1that\u00f3. Az olvas\u00e1s egy sz\u00e1lon zajlott, \u00e9s a v\u00edzszintes tengelyen a lek\u00e9rdez\u00e9sben szerepl\u0151 kulcsok sz\u00e1ma l\u00e1that\u00f3. Itt l\u00e1that\u00f3, hogy ezer kulcsra emelve egy lek\u00e9rdez\u00e9s ideje cs\u00f6kken, azaz a sebess\u00e9g n\u0151. Azonban az alap\u00e9rtelmezett MSLAB m\u00f3d bekapcsol\u00e1sa ut\u00e1n ezen a hat\u00e1ron t\u00fal drasztikusan cs\u00f6kken a teljes\u00edtm\u00e9ny, \u00e9s min\u00e9l nagyobb az adatmennyis\u00e9g a feljegyz\u00e9sben, ann\u00e1l hosszabb a feldolgoz\u00e1si id\u0151. <\/p>\n
    \"Az
    \n
    \nA teszteket virtu\u00e1lis g\u00e9pen v\u00e9gezt\u00e9k, 8 mag, HBase 2.0.0-cdh6.0.0-beta1 verzi\u00f3.<\/p>\n
    Az MSLAB m\u00f3d c\u00e9lja a heap t\u00f6redezetts\u00e9g\u00e9nek cs\u00f6kkent\u00e9se, amely az \u00faj \u00e9s r\u00e9gi gener\u00e1ci\u00f3k adatainak kevered\u00e9se miatt keletkezik. A probl\u00e9ma megold\u00e1sak\u00e9nt, az MSLAB bekapcsol\u00e1sakor az adatok viszonylag kis cell\u00e1kba (chunk) ker\u00fclnek, \u00e9s adagokban dolgozz\u00e1k fel \u0151ket. Ennek eredm\u00e9nyek\u00e9nt, amikor a k\u00e9rt adatmennyis\u00e9g meghaladja a kijel\u00f6lt m\u00e9retet, a teljes\u00edtm\u00e9ny drasztikusan cs\u00f6kken. M\u00e1sr\u00e9szr\u0151l, ennek a m\u00f3dnak a kikapcsol\u00e1sa sem k\u00edv\u00e1natos, mivel a GC miatti le\u00e1ll\u00e1sokhoz vezethet az adatok intenz\u00edv kezel\u00e9sekor. J\u00f3 megold\u00e1s lehet a cellam\u00e9ret n\u00f6vel\u00e9se, akt\u00edv \u00edr\u00e1s k\u00f6zben a put parancs haszn\u00e1lat\u00e1val, egyidej\u0171 olvas\u00e1ssal. \u00c9rdemes megjegyezni, hogy a probl\u00e9ma nem mer\u00fcl fel, ha a feljegyz\u00e9s ut\u00e1n v\u00e9grehajtjuk a flush parancsot, amely a MemStore-t a lemezre \u00edrja, vagy ha BulkLoad seg\u00edts\u00e9g\u00e9vel t\u00f6ltenek be. Az al\u00e1bbi t\u00e1bl\u00e1zatban l\u00e1that\u00f3, hogy a MemStore-b\u00f3l nagyobb mennyis\u00e9g\u0171 adat (\u00e9s azonos sz\u00e1m\u00fa) lek\u00e9rdez\u00e9sek lassul\u00e1shoz vezetnek. Azonban a chunksize n\u00f6vel\u00e9s\u00e9vel az feldolgoz\u00e1si id\u0151 norm\u00e1ra \u00e1ll\u00edthat\u00f3 vissza.<\/p>\n
    \"Az
    \nAz adatok r\u00e9gi\u00f3k szerinti feloszt\u00e1sa, azaz a t\u00e1bl\u00e1k has\u00edt\u00e1sa, seg\u00edt a chunksize n\u00f6vel\u00e9s\u00e9ben. Ez azt eredm\u00e9nyezi, hogy minden r\u00e9gi\u00f3hoz kevesebb k\u00e9r\u00e9s \u00e9rkezik, \u00e9s ha ezek egy cell\u00e1ba ker\u00fclnek, a v\u00e1laszid\u0151 j\u00f3 marad.<\/p>\n
    6. Strat\u00e9gi\u00e1k a t\u00e1bl\u00e1k r\u00e9gi\u00f3kra bont\u00e1s\u00e1ra (has\u00edt\u00e1s)<\/h2>\n
    \nMivel az HBase egy kulcs-\u00e9rt\u00e9k t\u00e1rol\u00f3, ahol a part\u00edcion\u00e1l\u00e1s a kulcs alapj\u00e1n t\u00f6rt\u00e9nik, rendk\u00edv\u00fcl fontos, hogy az adatokat egyenletesen osszuk el a r\u00e9gi\u00f3k k\u00f6z\u00f6tt. P\u00e9ld\u00e1ul egy ilyen t\u00e1bl\u00e1t h\u00e1rom r\u00e9szre osztva az adatok h\u00e1rom r\u00e9gi\u00f3ra bont\u00f3dnak:<\/p>\n
    \"Az
    \nEl\u0151fordulhat, hogy ez dr\u00e1mai lassul\u00e1shoz vezet, ha a k\u00e9s\u0151bb bet\u00f6ltend\u0151 adatok t\u00f6bbs\u00e9ge p\u00e9ld\u00e1ul hossz\u00fa \u00e9rt\u00e9kekb\u0151l \u00e1ll, amelyek legt\u00f6bbje ugyanazzal a sz\u00e1mmal kezd\u0151dik, p\u00e9ld\u00e1ul:<\/p>\n
    1000001
    \n1000002
    \n\u2026
    \n1100003<\/p>\n
    Mivel a kulcsok byte t\u00f6mbk\u00e9nt t\u00e1rol\u00f3dnak, mindegyik ugyanazzal kezd\u0151dik, \u00e9s ugyanahhoz az #1 region\u00e1lhoz tartozik, amely ezt a kulcstartom\u00e1nyt t\u00e1rolja. T\u00f6bb has\u00edt\u00e1si strat\u00e9gia l\u00e9tezik:<\/p>\n
    HexStringSplit \u2013 A kulcsot hexadecim\u00e1lis k\u00f3dol\u00e1s\u00fa karakterl\u00e1ncc\u00e1 alak\u00edtja a tartom\u00e1nyban \u201e00000000\u201d => \u201eFFFFFFFF\u201d, balra null\u00e1kkal kit\u00f6ltve.<\/p>\n
    UniformSplit \u2013 A kulcsot byte t\u00f6mbb\u00e9 alak\u00edtja hexadecim\u00e1lis k\u00f3dol\u00e1sban a tartom\u00e1nyban \u201e00\u201d => \u201eFF\u201d, jobbra null\u00e1kkal kit\u00f6ltve.<\/p>\n
    Ezen k\u00edv\u00fcl megadhatunk b\u00e1rmilyen kulcstartom\u00e1nyt vagy kulcsk\u00e9szletet a has\u00edt\u00e1shoz, \u00e9s be\u00e1ll\u00edthatjuk az automatikus has\u00edt\u00e1st. Azonban az egyik legegyszer\u0171bb \u00e9s leghat\u00e9konyabb megk\u00f6zel\u00edt\u00e9s a UniformSplit \u00e9s a hash konkaten\u00e1ci\u00f3 haszn\u00e1lata, p\u00e9ld\u00e1ul a legmagasabb byte p\u00e1r a kulcs CRC32(rowkey) f\u00fcggv\u00e9nyen val\u00f3 \u00e1tfuttat\u00e1s\u00e1b\u00f3l \u00e9s mag\u00e1b\u00f3l a rowkeyb\u0151l:<\/p>\n
    hash + rowkey<\/p>\n
    Ez\u00e1ltal az \u00f6sszes adat egyenletesen oszlik meg a r\u00e9gi\u00f3k k\u00f6z\u00f6tt. Olvas\u00e1skor az els\u0151 k\u00e9t byte egyszer\u0171en elvet\u00e9sre ker\u00fcl, \u00e9s megmarad az eredeti kulcs. A RS szint\u00e9n ellen\u0151rzi a r\u00e9gi\u00f3ban tal\u00e1lhat\u00f3 adatok \u00e9s kulcsok sz\u00e1m\u00e1t, \u00e9s ha a hat\u00e1r\u00e9rt\u00e9keket t\u00fall\u00e9pi, automatikusan felosztja azokat. <\/p>\n
    7. Hibat\u0171r\u00e9s \u00e9s adatok helyi el\u00e9rhet\u0151s\u00e9ge<\/h2>\n
    \nMivel minden kulcsgarnit\u00far\u00e1\u00e9rt csak egy r\u00e9gi\u00f3 felel, a RS-el val\u00f3 probl\u00e9m\u00e1k megold\u00e1sa \u00e9rdek\u00e9ben minden sz\u00fcks\u00e9ges adatot az HDFS-ben kell t\u00e1rolni. Ha a RS le\u00e1ll, a mester az ezt k\u00f6vet\u0151 heartbeat hi\u00e1ny\u00e1b\u00f3l \u00e9rtes\u00fcl r\u00f3la a ZooKeeper csom\u00f3ponton. Ekkor egy m\u00e1sik RS-nek rendeli hozz\u00e1 a kezelend\u0151 r\u00e9gi\u00f3t, \u00e9s mivel az HFiles a elosztott f\u00e1jlrendszerben t\u00e1rol\u00f3dik, az \u00faj gazda kiolvassa azokat \u00e9s folytatja az adatok kezel\u00e9s\u00e9t. Azonban mivel az adatok egy r\u00e9sze lehet a MemStore-ban van, \u00e9s m\u00e9g nem ker\u00fclt az HFiles-ba, a tranzakci\u00f3s el\u0151zm\u00e9nyek helyre\u00e1ll\u00edt\u00e1s\u00e1hoz a WAL-t haszn\u00e1lj\u00e1k, ami szint\u00e9n az HDFS-ben van t\u00e1rolva. A v\u00e1ltoztat\u00e1sok alkalmaz\u00e1sa ut\u00e1n a RS k\u00e9pes v\u00e1laszolni a k\u00e9r\u00e9sekre, azonban a k\u00f6lt\u00f6z\u00e9s miatt az adatok egy r\u00e9sze \u00e9s azokat kezel\u0151 folyamatok k\u00fcl\u00f6nb\u00f6z\u0151 csom\u00f3pontokon helyezkednek el, ami cs\u00f6kkenti a helyi er\u0151forr\u00e1sok haszn\u00e1lat\u00e1t. <\/p>\n
    A probl\u00e9ma megold\u00e1sa a major compaction - ez a folyamat \u00e1thelyezi a f\u00e1jlokat azokra a csom\u00f3pontokra, amelyek\u00e9rt felel\u0151sek (ahov\u00e1 a r\u00e9gi\u00f3ik is tartoznak), ennek eredm\u00e9nyek\u00e9nt a folyamat alatt nagym\u00e9rt\u00e9kben megn\u00f6vekszik a h\u00e1l\u00f3zati \u00e9s lemez terhel\u00e9s. Azonban a k\u00e9s\u0151bbiekben az adatokhoz val\u00f3 hozz\u00e1f\u00e9r\u00e9s jelent\u0151sen felgyorsul. Ezenk\u00edv\u00fcl a major_compaction egyes\u00edti az \u00f6sszes HFiles-t egy f\u00e1jlba a r\u00e9gi\u00f3 keretein bel\u00fcl, \u00e9s t\u00f6rli az adatokat a t\u00e1bl\u00e1zat be\u00e1ll\u00edt\u00e1sait\u00f3l f\u00fcgg\u0151en. P\u00e9ld\u00e1ul megadhat\u00f3 az objektumok verzi\u00f3inak sz\u00e1ma, amelyet meg kell \u0151rizni, vagy az eltarthat\u00f3s\u00e1gi id\u0151, amely ut\u00e1n az objektum fizikailag elt\u00e1vol\u00edt\u00e1sra ker\u00fcl.<\/p>\n
    Ez a folyamat nagyon pozit\u00edv hat\u00e1ssal lehet az HBase m\u0171k\u00f6d\u00e9s\u00e9re. Az al\u00e1bbi k\u00e9pen l\u00e1that\u00f3, hogyan cs\u00f6kkent a teljes\u00edtm\u00e9ny az akt\u00edv adat\u00edr\u00e1s eredm\u00e9nyek\u00e9nt. L\u00e1that\u00f3, hogy egy t\u00e1bl\u00e1zatba 40 sz\u00e1l \u00edrt \u00e9s 40 sz\u00e1l egyidej\u0171leg olvasott adatokat. Az \u00edr\u00f3 sz\u00e1lak egyre t\u00f6bb HFiles-t k\u00e9peztek, amelyeket a m\u00e1sik sz\u00e1l olvasott. Ennek eredm\u00e9nyek\u00e9ppen egyre t\u00f6bb adatot kellett elt\u00e1vol\u00edtani a mem\u00f3ri\u00e1b\u00f3l, \u00e9s v\u00e9g\u00fcl elindult a GC, amely szinte megb\u00e9n\u00edtotta az eg\u00e9sz m\u0171k\u00f6d\u00e9st. A major compaction elind\u00edt\u00e1sa a felhalmoz\u00f3d\u00e1sok megtiszt\u00edt\u00e1s\u00e1hoz \u00e9s a teljes\u00edtm\u00e9ny helyre\u00e1ll\u00edt\u00e1s\u00e1hoz vezetett.<\/p>\n
    \"Az
    \nA teszt h\u00e1rom DataNode-on \u00e9s n\u00e9gy RS-en futott (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 sz\u00e1l). HBase verzi\u00f3: 1.2.0-cdh5.14.2<\/p>\n
    Fontos megjegyezni, hogy a major compaction egy \"\u00e9letben l\u00e9v\u0151\" t\u00e1bl\u00e1n hajt\u00f3dott v\u00e9gre, amelybe akt\u00edvan \u00edrtak \u00e9s olvastak adatokat. Az interneten olyan \u00e1ll\u00edt\u00e1sok fogalmaz\u00f3dtak meg, hogy ez helytelen v\u00e1laszokat eredm\u00e9nyezhet az adatok olvas\u00e1sakor. A probl\u00e9ma ellen\u0151rz\u00e9s\u00e9re egy folyamatot ind\u00edtottunk, amely \u00faj adatokat gener\u00e1lt \u00e9s \u00edrt a t\u00e1bl\u00e1ba. Ezt k\u00f6vet\u0151en azonnal olvasta \u00e9s ellen\u0151rizte, hogy a kapott \u00e9rt\u00e9k megegyezik-e azzal, ami be volt \u00edrva. Ennek a folyamatnak a m\u0171k\u00f6d\u00e9se alatt k\u00f6r\u00fclbel\u00fcl 200 alkalommal hajtottak v\u00e9gre major compaction-t, \u00e9s egyetlen hiba sem t\u00f6rt\u00e9nt. Lehets\u00e9ges, hogy a probl\u00e9ma ritk\u00e1n l\u00e9p fel, csak magas terhel\u00e9s eset\u00e9n, ez\u00e9rt biztons\u00e1gosabb lenne a \u00edr\u00e1si \u00e9s olvas\u00e1si folyamatokat tervezetten le\u00e1ll\u00edtani, \u00e9s tiszt\u00edt\u00e1st v\u00e9gezni, elker\u00fclve a GC ilyen m\u00e9lyrep\u00fcl\u00e9seit.<\/p>\n
    A major compaction szint\u00e9n nem befoly\u00e1solja a MemStore \u00e1llapot\u00e1t, annak lemezre \u00edr\u00e1s\u00e1hoz \u00e9s t\u00f6m\u00f6r\u00edt\u00e9s\u00e9hez flush-t kell haszn\u00e1lni (connection.getAdmin().flush(TableName.valueOf(tblName))).<\/p>\n
    8. Be\u00e1ll\u00edt\u00e1sok \u00e9s teljes\u00edtm\u00e9ny<\/h2>\n
    \nAhogy m\u00e1r eml\u00edtett\u00fck, az HBase legnagyobb sikert akkor \u00e9ri el, amikor nincs sz\u00fcks\u00e9ge semmire, ha BulkLoad-ot hajt v\u00e9gre. Ez azonban a legt\u00f6bb rendszerre \u00e9s emberre is igaz. Azonban ez az eszk\u00f6z ink\u00e1bb a t\u00f6meges adatok nagy blokkokban t\u00f6rt\u00e9n\u0151 elhelyez\u00e9s\u00e9re alkalmas, m\u00edg ha a folyamat verseng\u0151 olvas\u00e1si \u00e9s \u00edr\u00e1si k\u00e9r\u00e9sek sokas\u00e1g\u00e1t ig\u00e9nyli, az el\u0151z\u0151leg eml\u00edtett Get \u00e9s Put parancsokat haszn\u00e1lj\u00e1k. Az optim\u00e1lis param\u00e9terek meghat\u00e1roz\u00e1s\u00e1ra k\u00fcl\u00f6nf\u00e9le t\u00e1bl\u00e1zati param\u00e9terek \u00e9s be\u00e1ll\u00edt\u00e1skombin\u00e1ci\u00f3k mellett hajtottunk v\u00e9gre teszteket:<\/p>\n