{"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\/pl\/blog\/administrirovanie\/teoriya-i-praktika-ispolzovaniya-hbase","title":{"rendered":"Teoria i praktyka wykorzystania HBase","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Dzie\u0144 dobry! Nazywam si\u0119 Danil Lipowoj, nasz zesp\u00f3\u0142 w Sbertechu zacz\u0105\u0142 korzysta\u0107 z HBase jako magazyn danych operacyjnych. W trakcie jego badania zgromadzono do\u015bwiadczenia, kt\u00f3re chcia\u0142em usystematyzowa\u0107 i opisa\u0107 (mamy nadziej\u0119, \u017ce b\u0119dzie to przydatne dla wielu os\u00f3b). Wszystkie poni\u017cej przedstawione eksperymenty przeprowadzono na wersjach HBase 1.2.0-cdh5.14.2 i 2.0.0-cdh6.0.0-beta1. <\/p>\n

    \n
  1. Og\u00f3lna architektura <\/li>\n
  2. Zapisywanie danych w HBASE<\/li>\n
  3. Odczytywanie danych z HBASE<\/li>\n
  4. Buforowanie danych<\/li>\n
  5. Przetwarzanie wsadowe danych MultiGet\/MultiPut<\/li>\n
  6. Strategia podzia\u0142u tabel na regiony (sharding)<\/li>\n
  7. Odporno\u015b\u0107 na awarie, kompresja i lokalno\u015b\u0107 danych<\/li>\n
  8. Ustawienia i wydajno\u015b\u0107<\/li>\n
  9. Testowanie obci\u0105\u017cenia<\/li>\n
  10. Wnioski<\/li>\n<\/ol>\n

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

    1. Og\u00f3lna architektura<\/h2>\n

    \n\"Teoria
    \nZapasowy Master nas\u0142uchuje heartbeat aktywnego na w\u0119\u017ale ZooKeeper i w przypadku jego znikni\u0119cia przejmuje funkcje mastera. <\/p>\n

    2. Zapisywanie danych w HBASE<\/h2>\n

    \nNajpierw rozwa\u017cymy najprostszy przypadek \u2013 zapis obiektu klucz-warto\u015b\u0107 w pewnej tabeli przy u\u017cyciu put(rowkey). Klient najpierw musi ustali\u0107, gdzie znajduje si\u0119 serwer g\u0142\u00f3wny regionu (Root Region Server \u2014 RRS), kt\u00f3ry przechowuje tabel\u0119 hbase:meta. Informacje t\u0119 uzyskuje od ZooKeeper. Nast\u0119pnie zwraca si\u0119 do RRS i odczytuje tabel\u0119 hbase:meta, z kt\u00f3rej wyci\u0105ga informacj\u0119, kt\u00f3ry RegionServer (RS) odpowiada za przechowywanie danych dla podanego klucza rowkey w interesuj\u0105cej go tabeli. W celu dalszego wykorzystania tabela meta jest buforowana przez klienta, dlatego kolejne zapytania s\u0105 szybsze, bezpo\u015brednio do RS.<\/p>\n

    Nast\u0119pnie RS, po otrzymaniu zapytania, najpierw zapisuje je w WriteAheadLog (WAL), co jest niezb\u0119dne do odtworzenia w przypadku awarii. Nast\u0119pnie zapisuje dane w MemStore. To bufor w pami\u0119ci, kt\u00f3ry zawiera posortowany zestaw kluczy danego regionu. Tabela mo\u017ce by\u0107 podzielona na regiony (partyacje), z kt\u00f3rych ka\u017cdy zawiera nieprzecinaj\u0105cy si\u0119 zbi\u00f3r kluczy. Pozwala to, umieszczaj\u0105c regiony na r\u00f3\u017cnych serwerach, uzyska\u0107 wy\u017csz\u0105 wydajno\u015b\u0107. Jednak mimo oczywisto\u015bci tego stwierdzenia, p\u00f3\u017aniej zobaczymy, \u017ce to nie dzia\u0142a we wszystkich przypadkach.<\/p>\n

    Po umieszczeniu wpisu w MemStore klient otrzymuje odpowied\u017a, \u017ce wpis zosta\u0142 pomy\u015blnie zapisany. W rzeczywisto\u015bci jest on przechowywany tylko w buforze i trafi na dysk dopiero po up\u0142ywie pewnego czasu lub po zape\u0142nieniu go nowymi danymi. <\/p>\n

    \"Teoria
    \nW trakcie wykonywania operacji \u201eDelete\u201d fizyczne usuni\u0119cie danych nie nast\u0119puje. Zostaj\u0105 one po prostu oznaczone jako usuni\u0119te, a samo zniszczenie ma miejsce w momencie wywo\u0142ania funkcji major compact, o kt\u00f3rej wi\u0119cej napisano w pkt 7.<\/p>\n

    Pliki w formacie HFile gromadz\u0105 si\u0119 w HDFS, a od czasu do czasu uruchamiany jest proces minor compact, kt\u00f3ry po prostu \u0142\u0105czy ma\u0142e pliki w wi\u0119ksze, nie usuwaj\u0105c niczego. Z biegiem czasu przekszta\u0142ca si\u0119 to w problem, kt\u00f3ry objawia si\u0119 tylko przy odczycie danych (do tego wr\u00f3cimy nieco p\u00f3\u017aniej). <\/p>\n

    Opr\u00f3cz opisanego powy\u017cej procesu \u0142adowania istnieje znacznie efektywniejsza procedura, w kt\u00f3rej zawarta jest chyba najsilniejsza strona tej bazy danych \u2013 BulkLoad. Polega ona na tym, \u017ce samodzielnie tworzymy HFiles i umieszczamy je na dysku, co pozwala na doskona\u0142\u0105 skalowalno\u015b\u0107 i osi\u0105ganie ca\u0142kiem przyzwoitych pr\u0119dko\u015bci. W istocie ograniczeniem jest tu nie HBase, lecz mo\u017cliwo\u015bci sprz\u0119towe. Poni\u017cej przedstawione s\u0105 wyniki \u0142adowania na klastrze sk\u0142adaj\u0105cym si\u0119 z 16 RegionServers i 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 w\u0105tki), wersja HBase 1.2.0-cdh5.14.2. <\/p>\n

    \"Teoria
    \n
    \nWida\u0107, \u017ce zwi\u0119kszaj\u0105c liczb\u0119 partycji (region\u00f3w) w tabeli oraz liczby executor\u00f3w Spark, otrzymujemy przyrost pr\u0119dko\u015bci \u0142adowania. Pr\u0119dko\u015b\u0107 zale\u017cy r\u00f3wnie\u017c od obj\u0119to\u015bci zapisu. Du\u017ce bloki daj\u0105 przyrost w miarze MB\/s, ma\u0142e w liczbie wstawionych rekord\u00f3w w jednostce czasu, przy innych r\u00f3wnych warunkach. <\/p>\n

    Mo\u017cna r\u00f3wnie\u017c uruchomi\u0107 \u0142adowanie w dw\u00f3ch tabelach jednocze\u015bnie i uzyska\u0107 podwojone pr\u0119dko\u015bci. Poni\u017cej wida\u0107, \u017ce zapis blok\u00f3w 10 KB od razu do dw\u00f3ch tabel odbywa si\u0119 z pr\u0119dko\u015bci\u0105 oko\u0142o 600 MB\/s w ka\u017cdej (\u0142\u0105cznie 1275 MB\/s), co odpowiada pr\u0119dko\u015bci zapisu do jednej tabeli 623 MB\/s (zob. nr 11 powy\u017cej).<\/p>\n

    \"Teoria
    \nNatomiast drugi uruchomienie z zapisami 50 KB pokazuje, \u017ce pr\u0119dko\u015b\u0107 \u0142adowania ro\u015bnie ju\u017c nieznacznie, co wskazuje na zbli\u017canie si\u0119 do warto\u015bci granicznych. Nale\u017cy przy tym mie\u0107 na uwadze, \u017ce same mu HBASE praktycznie nie stawia si\u0119 obci\u0105\u017ce\u0144, wszystko co od niego wymagane, to najpierw oddanie danych z hbase:meta, a nast\u0119pnie po umieszczeniu HFiles, zrzucenie danych BlockCache i zapisanie bufora MemStore na dysk, je\u015bli nie jest pusty.<\/p>\n

    3. Odczyt danych z HBASE<\/h2>\n

    \nJe\u015bli zak\u0142adamy, \u017ce wszystkie informacje z hbase:meta s\u0105 ju\u017c dost\u0119pne dla klienta (patrz pkt 2), zapytanie jest kierowane bezpo\u015brednio do tego RS, w kt\u00f3rym przechowywany jest poszukiwany klucz. Najpierw wyszukiwanie odbywa si\u0119 w MemCache. Niezale\u017cnie od tego, czy dane tam istniej\u0105, wyszukiwanie odbywa si\u0119 r\u00f3wnie\u017c w buforze BlockCache i w razie potrzeby w HFiles. Je\u015bli dane zosta\u0142y znalezione w pliku, s\u0105 one umieszczane w BlockCache i przy nast\u0119pnym zapytaniu b\u0119d\u0105 zwracane szybciej. Wyszukiwanie w HFile odbywa si\u0119 stosunkowo szybko dzi\u0119ki zastosowaniu filtru Blooma, tzn. po odczytaniu ma\u0142ej ilo\u015bci danych od razu ustala, czy ten plik zawiera poszukiwany klucz, a je\u015bli nie, przechodzi do nast\u0119pnego.<\/p>\n

    \"Teoria
    \nPo uzyskaniu danych z tych trzech \u017ar\u00f3de\u0142 RS formu\u0142uje odpowied\u017a. W szczeg\u00f3lno\u015bci mo\u017ce przekaza\u0107 od razu kilka znalezionych wersji obiektu, je\u015bli klient za\u017c\u0105da\u0142 wersjonowania.<\/p>\n

    4. Cache danych<\/h2>\n

    \nBufory MemStore i BlockCache zajmuj\u0105 do 80% przydzielonej pami\u0119ci on-heap RS (pozosta\u0142e przeznaczone s\u0105 na zadania serwisowe RS). Je\u015bli typowy spos\u00f3b u\u017cytkowania polega na tym, \u017ce procesy zapisuj\u0105 i natychmiast odczytuj\u0105 te same dane, warto zmniejszy\u0107 BlockCache i zwi\u0119kszy\u0107 MemStore, poniewa\u017c przy zapisie dane do pami\u0119ci cache na odczyt nie trafiaj\u0105, co powoduje rzadsze wykorzystanie BlockCache. Bufor BlockCache sk\u0142ada si\u0119 z dw\u00f3ch cz\u0119\u015bci: LruBlockCache (zawsze on-heap) i BucketCache (zwykle off-heap lub na SSD). BucketCache warto zastosowa\u0107, gdy zapyta\u0144 o odczyt jest bardzo du\u017co i nie mieszcz\u0105 si\u0119 one w LruBlockCache, co prowadzi do intensywnej pracy Garbage Collector. Przy tym nie nale\u017cy oczekiwa\u0107 radykalnego wzrostu wydajno\u015bci z wykorzystania cache'u do odczytu, jednak do tego jeszcze wr\u00f3cimy w pkt 8.<\/p>\n

    \"Teoria
    \nBlockCache jest jeden dla ca\u0142ego RS, a MemStore jest osobny dla ka\u017cdej tabeli (po jednym na ka\u017cdy Column Family).<\/p>\n

    Jak opisano<\/a><\/noindex> w teorii, przy zapisie dane do pami\u0119ci cache nie trafiaj\u0105 i rzeczywi\u015bcie, takie parametry CACHE_DATA_ON_WRITE dla tabeli oraz \u201eCache DATA on Write\u201d dla RS s\u0105 ustawione na false. Jednak w praktyce, je\u015bli zapiszesz dane w MemStore, a nast\u0119pnie zrzucisz je na dysk (w ten spos\u00f3b je czyszcz\u0105c), a nast\u0119pnie usuniesz powsta\u0142y plik, to wykonuj\u0105c zapytanie get, pomy\u015blnie uzyskasz dane. Co wi\u0119cej, nawet je\u015bli ca\u0142kowicie wy\u0142\u0105czysz BlockCache i wype\u0142nisz tabel\u0119 nowymi danymi, nast\u0119pnie wymusisz zrzut MemStore na dysk, usuniesz je i zapytasz z innej sesji, to i tak zostan\u0105 one sk\u0105d\u015b wydobyte. Tak wi\u0119c HBase przechowuje w sobie nie tylko dane, ale i tajemnicze zagadki.<\/p>\n

    hbase(main):001:0> create 'ns:magic', 'cf'\nStworzono tabel\u0119 ns:magic\nZaj\u0119\u0142o 1.1533 sekundy\nhbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'spr\u00f3buj_usun\u0105\u0107_mnie'\nZaj\u0119\u0142o 0.2610 sekundy\nhbase(main):003:0> flush 'ns:magic'\nZaj\u0119\u0142o 0.6161 sekundy\nhdfs dfs -mv \/data\/hbase\/data\/ns\/magic\/* \/tmp\/trash\nhbase(main):002:0> get 'ns:magic', 'key1'\n cf:c      znacznik_czasu=1534440690218, warto\u015b\u0107=spr\u00f3buj_usun\u0105\u0107_mnie\n<\/code><\/pre>\n
    \nParametr \u201eCache DATA on Read\u201d jest ustawiony na false. Je\u015bli masz pomys\u0142y, zapraszam do om\u00f3wienia ich w komentarzach.<\/p>\n
    5. Przetwarzanie wsadowe danych MultiGet\/MultiPut<\/h2>\n
    \nPrzetwarzanie pojedynczych \u017c\u0105da\u0144 (Get\/Put\/Delete) jest do\u015b\u0107 kosztown\u0105 operacj\u0105, dlatego zaleca si\u0119 \u0142\u0105czenie ich w List lub List, co pozwala na znaczn\u0105 popraw\u0119 wydajno\u015bci. Dotyczy to w szczeg\u00f3lno\u015bci operacji zapisu, a przy odczycie pojawia si\u0119 kolejna pu\u0142apka. Na poni\u017cszym wykresie pokazano czas odczytu 50 000 zapis\u00f3w z MemStore. Odczyt by\u0142 realizowany w jednym w\u0105tku, a na osi poziomej pokazano liczb\u0119 kluczy w \u017c\u0105daniu. Wida\u0107, \u017ce wraz z zwi\u0119kszeniem liczby kluczy w jednym \u017c\u0105daniu do tysi\u0105ca czas wykonania maleje, tzn. szybko\u015b\u0107 ro\u015bnie. Jednak\u017ce przy w\u0142\u0105czonym domy\u015blnym trybie MSLAB po tym progu zaczyna si\u0119 radykalny spadek wydajno\u015bci, przy czym im wi\u0119ksza obj\u0119to\u015b\u0107 danych w zapisie, tym d\u0142u\u017cszy czas operacji. <\/p>\n
    \"Teoria
    \n
    \nTesty przeprowadzono na wirtualnej maszynie, 8 rdzeni, wersja HBase 2.0.0-cdh6.0.0-beta1.<\/p>\n
    Tryb MSLAB ma na celu zmniejszenie fragmentacji pami\u0119ci heap, kt\u00f3ra powstaje w wyniku mieszania danych m\u0142odszych i starszych pokole\u0144. Jako rozwi\u0105zanie problemu, przy w\u0142\u0105czeniu MSLAB dane s\u0105 umieszczane w stosunkowo ma\u0142ych kom\u00f3rkach (chunk) i przetwarzane partiami. W rezultacie, kiedy obj\u0119to\u015b\u0107 w \u017c\u0105danym pakiecie danych przekracza przydzielony rozmiar, wydajno\u015b\u0107 nagle spada. Z drugiej strony, wy\u0142\u0105czenie tego trybu r\u00f3wnie\u017c nie jest po\u017c\u0105dane, poniewa\u017c prowadzi do zatrzyma\u0144 z powodu GC w momentach intensywnej pracy z danymi. Dobrym rozwi\u0105zaniem jest zwi\u0119kszenie obj\u0119to\u015bci kom\u00f3rki, w przypadku aktywnego zapisu przez put jednocze\u015bnie z odczytem. Warto zauwa\u017cy\u0107, \u017ce problem nie wyst\u0119puje, je\u015bli po zapisaniu wykonasz polecenie flush, kt\u00f3re zrzuca MemStore na dysk, lub je\u015bli nast\u0119puje za\u0142adunek za pomoc\u0105 BulkLoad. W poni\u017cszej tabeli pokazano, \u017ce \u017c\u0105dania z MemStore wi\u0119kszej obj\u0119to\u015bci (i tej samej liczby) prowadz\u0105 do op\u00f3\u017anie\u0144. Jednak zwi\u0119kszaj\u0105c chunksize, przywracamy czas przetwarzania do normy.<\/p>\n
    \"Teoria
    \nOpr\u00f3cz zwi\u0119kszenia chunksize pomocne jest podzia\u0142anie danych wed\u0142ug region\u00f3w, tj. splitowanie tabel. Prowadzi to do tego, \u017ce na ka\u017cdy region przypada mniejsza liczba zapyta\u0144, a je\u015bli mieszcz\u0105 si\u0119 one w kom\u00f3rce, odpowied\u017a pozostaje dobra.<\/p>\n
    6. Strategia podzia\u0142u tabel wed\u0142ug region\u00f3w (splitowanie)<\/h2>\n
    \nPoniewa\u017c HBase jest przechowalni\u0105 key-value, a partycjonowanie odbywa si\u0119 wed\u0142ug klucza, niezwykle wa\u017cne jest, aby r\u00f3wnomiernie rozdziela\u0107 dane w\u015br\u00f3d wszystkich region\u00f3w. Na przyk\u0142ad, partycjonowanie takiej tabeli na trzy cz\u0119\u015bci prowadzi do tego, \u017ce dane b\u0119d\u0105 podzielone na trzy regiony:<\/p>\n
    \"Teoria
    \nCzasami prowadzi to do znacznego spowolnienia, je\u015bli w dalszej kolejno\u015bci wczytywane dane b\u0119d\u0105 mia\u0142y posta\u0107 np. warto\u015bci long, kt\u00f3re w wi\u0119kszo\u015bci zaczynaj\u0105 si\u0119 od tej samej cyfry, na przyk\u0142ad:<\/p>\n
    1000001
    \n1000002
    \n\u2026
    \n1100003<\/p>\n
    Poniewa\u017c klucze s\u0105 przechowywane w postaci tablicy bajt\u00f3w, wszystkie one b\u0119d\u0105 zaczyna\u0142y si\u0119 jednakowo i odnosi\u0142y si\u0119 do jednego regionu #1 przechowuj\u0105cego ten zakres kluczy. Istnieje kilka strategii podzia\u0142u:<\/p>\n
    HexStringSplit \u2013 przekszta\u0142ca klucz w ci\u0105g z szesnastkowym kodowaniem w zakresie \u201e00000000\u201d => \u201eFFFFFFFF\u201d, a na lewo wype\u0142nia zerami.<\/p>\n
    UniformSplit \u2013 przekszta\u0142ca klucz w tablic\u0119 bajt\u00f3w z szesnastkowym kodowaniem w zakresie \u201e00\u201d => \u201eFF\u201d, a na prawo wype\u0142nia zerami.<\/p>\n
    Ponadto mo\u017cna wskaza\u0107 dowolny zakres lub zestaw kluczy do podzia\u0142u oraz skonfigurowa\u0107 automatyczne splitowanie. Jednak jednym z najprostszych i najskuteczniejszych podej\u015b\u0107 jest UniformSplit i wykorzystanie z\u0142\u0105czenia hash, na przyk\u0142ad wy\u017cszej pary bajt\u00f3w uzyskanej z przepuszczenia klucza przez funkcj\u0119 CRC32(rowkey) oraz samego rowkey:<\/p>\n
    hash + rowkey<\/p>\n
    W\u00f3wczas wszystkie dane b\u0119d\u0105 r\u00f3wnomiernie rozprowadzane w\u015br\u00f3d region\u00f3w. Podczas odczytu pierwsze dwa bajty s\u0105 po prostu zrzucane, a pozostaje oryginalny klucz. RS kontroluje r\u00f3wnie\u017c liczb\u0119 danych i kluczy w regionie i w przypadku przekroczenia limit\u00f3w automatycznie dzieli go na cz\u0119\u015bci. <\/p>\n
    7. Odporno\u015b\u0107 na awarie i lokalno\u015b\u0107 danych<\/h2>\n
    \nPoniewa\u017c za ka\u017cdy zestaw kluczy odpowiada tylko jeden region, rozwi\u0105zaniem problem\u00f3w zwi\u0105zanych z awariami RS lub wy\u0142\u0105czeniem z eksploatacji jest przechowywanie wszystkich niezb\u0119dnych danych w HDFS. W przypadku awarii RS, master wykrywa to poprzez brak heartbeat na w\u0119\u017ale ZooKeeper. W\u00f3wczas przypisuje obs\u0142ugiwany region innemu RS, a poniewa\u017c HFiles s\u0105 przechowywane w rozproszonej systemie plik\u00f3w, nowy w\u0142a\u015bciciel odczytuje je i kontynuuje obs\u0142ug\u0119 danych. Jednak\u017ce, poniewa\u017c cz\u0119\u015b\u0107 danych mo\u017ce znajdowa\u0107 si\u0119 w MemStore i nie zosta\u0142a jeszcze zapisana w HFiles, do przywracania historii operacji wykorzystuje si\u0119 WAL, kt\u00f3ry r\u00f3wnie\u017c jest przechowywany w HDFS. Po zatwierdzeniu zmian, RS jest w stanie odpowiada\u0107 na \u017c\u0105dania, jednak przeprowadzka prowadzi do sytuacji, w kt\u00f3rej cz\u0119\u015b\u0107 danych oraz procesy ich obs\u0142ugi znajduj\u0105 si\u0119 na r\u00f3\u017cnych w\u0119z\u0142ach, tj. lokalno\u015b\u0107 ulega zmniejszeniu. <\/p>\n
    Rozwi\u0105zaniem problemu jest major compaction \u2013 ta procedura przenosi pliki na te w\u0119z\u0142y, kt\u00f3re za nie odpowiadaj\u0105 (tam, gdzie znajduj\u0105 si\u0119 ich regiony), w wyniku czego podczas tej procedury gwa\u0142townie wzrasta obci\u0105\u017cenie sieci i dysk\u00f3w. Jednak w dalszej perspektywie dost\u0119p do danych staje si\u0119 zauwa\u017calnie szybszy. Ponadto, major_compaction \u0142\u0105czy wszystkie HFiles w jeden plik w obr\u0119bie regionu, a tak\u017ce oczyszcza dane w zale\u017cno\u015bci od ustawie\u0144 tabeli. Na przyk\u0142ad, mo\u017cna okre\u015bli\u0107 liczb\u0119 wersji obiektu, kt\u00f3re nale\u017cy zachowa\u0107 lub czas jego \u017cycia, po kt\u00f3rego up\u0142ywie obiekt jest fizycznie usuwany.<\/p>\n
    Ta procedura mo\u017ce mie\u0107 bardzo pozytywny wp\u0142yw na dzia\u0142anie HBase. Na poni\u017cszym obrazku wida\u0107, jak degradowa\u0142a si\u0119 wydajno\u015b\u0107 w wyniku intensywnego zapisu danych. Mo\u017cna zauwa\u017cy\u0107, jak do jednej tabeli 40 w\u0105tk\u00f3w zapisywa\u0142o i 40 w\u0105tk\u00f3w r\u00f3wnocze\u015bnie odczytywa\u0142o dane. W\u0105tki zapisuj\u0105ce tworz\u0105 coraz wi\u0119cej HFiles, kt\u00f3re s\u0105 odczytywane przez inne w\u0105tki. W wyniku tego coraz wi\u0119cej danych musi zosta\u0107 usuni\u0119tych z pami\u0119ci, a w ko\u0144cu zaczyna dzia\u0142a\u0107 GC, kt\u00f3ry praktycznie parali\u017cuje ca\u0142\u0105 prac\u0119. Uruchomienie major compaction doprowadzi\u0142o do oczyszczenia powsta\u0142ych zator\u00f3w i przywr\u00f3cenia wydajno\u015bci.<\/p>\n
    \"Teoria
    \nTest przeprowadzono na 3 DataNode i 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 w\u0105tki). Wersja HBase 1.2.0-cdh5.14.2<\/p>\n
    Warto zauwa\u017cy\u0107, \u017ce uruchomienie major compaction odby\u0142o si\u0119 na \u201e\u017cywej\u201d tabeli, do kt\u00f3rej aktywnie zapisywano i odczytywano dane. W sieci pojawia\u0142y si\u0119 twierdzenia, \u017ce mo\u017ce to prowadzi\u0107 do niepoprawnych odpowiedzi przy odczycie danych. W celu sprawdzenia uruchomiono proces, kt\u00f3ry generowa\u0142 nowe dane i zapisywa\u0142 je w tabeli. Nast\u0119pnie od razu je odczytywano i por\u00f3wnywano, czy uzyskana warto\u015b\u0107 zgadza si\u0119 z tym, co zapisano. W trakcie pracy tego procesu major compaction uruchamiano oko\u0142o 200 razy i nie zarejestrowano \u017cadnych awarii. Mo\u017cliwe, \u017ce problem pojawia si\u0119 rzadko i tylko podczas wysokiego obci\u0105\u017cenia, dlatego bezpieczniej jest jednak zaplanowa\u0107 zatrzymanie proces\u00f3w zapisu i odczytu oraz wykona\u0107 czyszczenie, aby nie dopuszcza\u0107 do takich spadk\u00f3w GC.<\/p>\n
    R\u00f3wnie\u017c major compaction nie wp\u0142ywa na stan MemStore, aby zrzuci\u0107 go na dysk i przeprowadzi\u0107 kompaktacj\u0119, nale\u017cy u\u017cy\u0107 flush (connection.getAdmin().flush(TableName.valueOf(tblName))).<\/p>\n
    8. Ustawienia i wydajno\u015b\u0107<\/h2>\n
    \nJak ju\u017c wspomniano, HBase odnosi najwi\u0119kszy sukces tam, gdzie nie wymaga wiele dzia\u0142a\u0144, przy wykonywaniu BulkLoad. To dotyczy jednak wi\u0119kszo\u015bci system\u00f3w i ludzi. Niemniej jednak to narz\u0119dzie nadaje si\u0119 raczej do masowego uk\u0142adania danych du\u017cymi blokami, natomiast je\u015bli proces wymaga wype\u0142nienia wielu konkurencyjnych zapyta\u0144 o odczyt i zapis, u\u017cywane s\u0105 opisane powy\u017cej polecenia Get i Put. Aby okre\u015bli\u0107 optymalne parametry, przeprowadzono uruchomienia przy r\u00f3\u017cnych kombinacjach parametr\u00f3w tabeli i ustawie\u0144:<\/p>\n