Добры дзень! Мяне клічуць Даніл Ліпавай, наша каманда ў Сбертэху пачала выкарыстоўваць HBase у якасці сховішчы аператыўных дадзеных. Падчас яго вывучэння назапасіўся досвед, які захацелася сістэматызаваць і апісаць (спадзяемся, што шматлікім будзе карысна). Усе прыведзеныя ніжэй эксперыменты праводзіліся з версіямі HBase 1.2.0-cdh5.14.2 і 2.0.0-cdh6.0.0-beta1.
- Агульная архітэктура
- Запіс дадзеных у HBASE
- Чытанне дадзеных з HBASE
- Кэшаванне дадзеных
- Пакетная апрацоўка даных MultiGet/MultiPut
- Стратэгія разбіўкі табліц на рэгіёны (спілітынг)
- Адмаўстойлівасць, кампактыфікацыя і лаккальнасць дадзеных
- Наладкі і прадукцыйнасць
- Нагрузачнае тэсціраванне
- Высновы
1. Агульная архітэктура
Рэзервовы Master слухае heartbeat актыўнага на вузле ZooKeeper і ў выпадку знікнення бярэ функцыі майстра на сябе.
2. Запіс дадзеных у HBASE
Спачатку разгледзім самы просты выпадак - запіс аб'екта ключ-значэнне ў нейкую табліцу пры дапамозе put(rowkey). Кліент спачатку павінен высветліць, дзе размешчаны каранёвы рэгіён сервер (Root Region Server - RRS), які захоўвае табліцу hbase:meta. Гэтую інфармацыю ён атрымлівае ад ZooKeeper. Пасля чаго ён звяртаецца да RRS і чытае табліцу hbase:meta, з якой здабывае інфармацыю, які RegionServer (RS) адказвае за захоўванне дадзеных па зададзеным ключы rowkey у якая цікавіць яго табліцы. У мэтах далейшага выкарыстання мета-табліца кэшуецца кліентам і таму наступныя звароты ідуць хутчэй, напрамую да RS.
Далей RS, атрымаўшы запыт, перш за ўсё піша яго ў WriteAheadLog (WAL), што неабходна для аднаўлення ў выпадку падзення. Затым захоўвае дадзеныя ў MemStore. Гэта буфер у памяці, які змяшчае адсартаваны набор ключоў дадзенага рэгіёна. Табліца можа быць разбіта на рэгіёны (партыцыі), кожны з якіх утрымоўвае неперасякальны набор ключоў. Гэта дазваляе, размясціўшы рэгіёны на розных серверах, атрымліваць больш высокую прадукцыйнасць. Аднак, нягледзячы на відавочнасць гэтага сцвярджэння, далей мы ўбачым, што гэта працуе не ва ўсіх выпадках.
Пасля размяшчэння запісы ў MemStore кліенту вяртаецца адказ, што запіс захавана паспяхова. Пры гэтым рэальна яна захоўваецца толькі ў буферы і патрапіць на дыск толькі пасля таго, як мінуе некаторы інтэрвал часу ці пры напаўненні яго новымі дадзенымі.
Пры выкананні аперацыі "Delete" фізічнага выдалення дадзеных не адбываецца. Яны проста адзначаюцца як выдаленыя, а само знішчэнне адбываецца ў момант выкліку функцыі major compact, пра якую падрабязней напісана ў п.7.
Файлы ў фармаце HFile збіраюцца ў HDFS і час ад часу запускаецца працэс minor compact, які проста склейвае маленькія файлы ў буйнейшыя, нічога не выдаляючы. З часам гэта ператвараецца праблему, якая выяўляецца толькі пры чытанні дадзеных (да гэтага вернемся крыху пазней).
Акрамя апісанага вышэй працэсу загрузкі ёсць значна больш эфектыўная працэдура, у якой складаецца мабыць наймацнейшы бок гэтай БД – BulkLoad. Яна складаецца ў тым, што мы самастойна фармуем HFiles і падкладаем на дыск, што дазваляе выдатна маштабавацца і дасягаць вельмі прыстойных хуткасцяў. Па сутнасці, абмежаваннем тут з'яўляецца не HBase, а магчымасці жалеза. Ніжэй прыведзены вынікі загрузкі на кластары, якія складаюцца з 16 RegionServers і 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 патоку), версія HBase 1.2.0-cdh5.14.2.
Тут відаць, што павялічваючы кол-ць партыцый (рэгіёнаў) у табліцы, а таксама экзекутараў Spark, атрымліваем прырашчэнне хуткасці загрузкі. Таксама хуткасць залежыць ад аб'ёму запісу. Буйныя блокі даюць прырост у вымярэнні МБ/сек, дробныя ў колькасці ўстаўленых запісаў у адзінку часу, пры іншых роўных.
Таксама можна запусціць загрузку ў дзве табліцы адначасова і атрымаць падваенне хуткасці. Ніжэй відаць, што запіс блокаў 10 КБ адразу ў дзве табліцы ідзе са хуткасцю каля 600 Мб/сек у кожную (сумарна 1275 Мб/сек), што супадае са хуткасцю запісу ў адну табліцу 623 МБ/сек (гл. №11 вышэй)
А вось другі запуск з запісамі ў 50 КБ паказвае, што хуткасць загрузкі расце ўжо малаважна, што кажа аб набліжэнні да лімітавых значэнняў. Пры гэтым трэба мець на ўвазе, што на сам HBASE тут нагрузкі практычна не ствараецца, усё, што ад яго патрабуецца, гэта спачатку аддаць дадзеныя з hbase:meta, а пасля падшэўкі HFiles, скінуць дадзеныя BlockCache і захаваць буфер MemStore на дыск, калі ён не пусты.
3. Чытанне дадзеных з HBASE
Калі лічыць, што ўся інфармацыя з hbase:meta ужо ў ёсць кліента (гл. п.2), то запыт сыходзіць адразу на той RS, дзе захоўваецца патрэбны ключ. Спачатку пошук ажыццяўляецца ў MemCache. Незалежна ад таго, ёсць там дадзеныя ці не, пошук ажыццяўляецца таксама ў буферы BlockCache і пры неабходнасці ў HFiles. Калі дадзеныя былі знойдзеныя ў файле, то яны змяшчаюцца ў BlockCache і пры наступным запыце будуць вернутыя хутчэй. Пошук у HFile адбываецца адносна хутка дзякуючы выкарыстанню фільтра Блюма, г.зн. лічыўшы невялікі аб'ём дадзеных ён адразу вызначае, ці ўтрымоўвае гэты файл патрэбны ключ і калі няма, тое пераходзіць да наступнага.
Атрымаўшы дадзеныя з гэтых трох крыніц RS фармуе адказ. У прыватнасці, ён можа перадаць адразу некалькі знойдзеных версій аб'екта, калі кліент запытаў версійнасць.
4. Кэшаванне дадзеных
Буферы MemStore і BlockCache займаюць да 80% выдзеленай on-heap памяці RS (астатняе зарэзервавана для сэрвісных задач RS). Калі тыповы рэжым выкарыстання такі, што працэсы пішуць і адразу чытаюць гэтыя ж дадзеныя, тое мае сэнс паменшыць BlockCache і павялічыць MemStore, т.к. пры запісе дадзеныя ў кэш на чытанне не пападаюць, то выкарыстанне BlockCache будзе адбывацца радзей. Буфер BlockCache складаецца з двух частак: LruBlockCache (заўсёды on-heap) і BucketCache (як правіла off-heap ці на SSD). BucketCache варта выкарыстоўваць, калі запытаў чытанне вельмі шмат і яны не змяшчаюцца ў LruBlockCache, што прыводзіць да актыўнай працы Garbage Collector. Пры гэтым радыкальнага росту прадукцыйнасці ад выкарыстання кэша на чытанне чакаць не варта, аднак да гэтага мы яшчэ вернемся ў п. 8
BlockCache адзін на ўвесь RS, а MemStore для кожнай табліцы свой (па адным на кожны Column Family).
Як у тэорыі, пры запісе дадзеныя ў кэш не пападаюць і сапраўды, такія параметры CACHE_DATA_ON_WRITE для табліцы і "Cache DATA on Write" для RS усталяваныя ў false. Аднак на практыцы, калі запісаць дадзеныя ў MemStore, потым скінуць яго на дыск (ачысціўшы такім чынам), затым выдаліць атрыманы файл, то выканаўшы get запыт мы паспяхова атрымаем дадзеныя. Прычым нават калі зусім адключыць BlockCache і забіць табліцу новымі дадзенымі, затым дамагчыся скіду MemStore на дыск, выдаліць іх і запытаць з іншай сесіі, то яны ўсё роўна аднекуль дастаюцца. Так што HBase захоўвае ў сабе не толькі дадзеныя, але і таямнічыя загадкі.
hbase(main):001:0> create 'ns:magic', 'cf'
Created table ns:magic
Took 1.1533 seconds
hbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me'
Took 0.2610 seconds
hbase(main):003:0> flush 'ns:magic'
Took 0.6161 seconds
hdfs dfs -mv /data/hbase/data/ns/magic/* /tmp/trash
hbase(main):002:0> get 'ns:magic', 'key1'
cf:c timestamp=1534440690218, value=try_to_delete_me
Параметр "Cache DATA on Read" усталяваны false. Калі ёсць ідэі, сардэчна запрашаем абмеркаваць гэта ў каментарах.
5. Пакетная апрацоўка дадзеных MultiGet/MultiPut
Апрацоўка адзіночных запытаў (Get/Put/Delete) даволі дарагая аперацыя, таму варта аб'ядноўваць па магчымасці іх у List ці List, што дазваляе атрымліваць значны прырост прадукцыйнасці. Асабліва гэта дакранаецца аперацыі запісу, а вось пры чытанні ёсць наступны падводны камень. На графіцы ніжэй паказаны час чытання 50 000 запісаў з MemStore. Чытанне праводзілася ў адзін паток і па гарызантальнай восі паказана колькасць ключоў у запыце. Тут бачна, што пры павелічэнні да тысячы ключоў у адным запыце час выканання падае, г.зн. хуткасць павялічваецца. Аднак пры ўключаным па змаўчанні рэжыме MSLAB пасля гэтага парога пачынаецца радыкальнае падзенне прадукцыйнасці, прычым чым большы аб'ём дадзеных у запісе, тым большы час працы.
Тэсты выконваліся на віртуалцы, 8 ядраў, версія HBase 2.0.0-cdh6.0.0-beta1.
Рэжым MSLAB закліканы паменшыць фрагментацыю heap, якая ўзнікае з-за мяшанні дадзеных новага і старога пакаленняў. У якасці рашэння праблемы пры ўключэнні MSLAB дадзеныя змяшчаюцца ў адносна невялікія вочкі (chunk) і апрацоўваюцца порцыямі. У выніку, калі аб'ём у запытаным пакеце дадзеных перавышае выдзелены памер, то прадукцыйнасць рэзка падае. З іншага боку выключэнне дадзенага рэжыму таксама не пажадана, бо прывядзе да прыпынкаў з прычыны GC у моманты інтэнсіўнай працы з дадзенымі. Добрым выйсцем з'яўляецца павелічэнне аб'ёмаў вочка, у выпадку актыўнага запісу праз put адначасова з чытаннем. Варта адзначыць, што праблема не ўзнікае калі пасля запісу выконваць каманду flush якая скідае MemStore на дыск ці калі ажыццяўляецца загрузка пры дапамозе BulkLoad. У табліцы ніжэй паказана, што запыты з MemStore дадзеных большага аб'ёму (і аднолькавай колькасці) прыводзяць да запаволення. Аднак павялічваючы chunksize вяртаем час апрацоўкі да нормы.
Акрамя павелічэння chunksize дапамагае драбненне дадзеных па рэгіёнах, г.зн. сплітынг табліц. Гэта прыводзіць да таго, што на кожны рэгіён прыходзіць меншая колькасць запытаў і калі яны змяшчаюцца ў ячэйку, водгук застаецца добрым.
6. Стратэгія разбіцця табліц на рэгіёны (спілітынг)
Бо HBase з'яўляецца key-value сховішчам і партыцыянаванне ажыццяўляецца па ключы, то вельмі важна падзяляць дадзеныя раўнамерна па ўсіх рэгіёнах. Напрыклад партыцыянаванне такой табліцы на тры часткі прывядзе таму, што дадзеныя будуць разбітыя на тры рэгіёны:
Бывае, што гэта прыводзіць да рэзкага запаволення, калі загружаныя ў далейшым дадзеныя будуць мець выгляд да прыкладу long значэнняў у большасці сваёй якія пачынаюцца з адной і той жа лічбы, напрыклад:
1000001
1000002
...
1100003
Паколькі ключы захоўваюцца ў выглядзе масіва байт, усе яны будуць пачынацца аднолькава і ставіцца да аднаго рэгіёна #1 які захоўвае гэты дыяпазон ключоў. Ёсць некалькі стратэгій разбіцця:
HexStringSplit - Ператварае ключ у радок з шаснаццатковым кадаваннем у дыяпазоне "00000000" => "FFFFFFFF" і запаўняючы злева нулямі.
UniformSplit - Ператварае ключ у масіў байт з шаснаццатковым кадаваннем у дыяпазоне "00" => "FF" і запаўняючы справа нулямі.
Акрамя таго можна пазначыць любы дыяпазон ці набор ключоў для разбіцця і наладзіць аўтасплітынг. Аднак адным з найболей простых і эфектыўных падыходаў з'яўляецца UniformSplit і выкарыстанне канкатэнацыі хэша, напрыклад старэйшай пары байт ад прагону ключа праз функцыю CRC32(rowkey) і ўласна rowkey:
hash + rowkey
Тады ўсе дадзеныя будуць размеркаваны раўнамерна па рэгіёнах. Пры чытанні першыя два байта проста адкідаюцца і застаецца зыходны ключ. Таксама RS кантралюе колькасць дадзеных і ключоў у рэгіёне і пры перавышэнні лімітаў аўтаматычна разбівае яго на часткі.
7. Адмоўаўстойлівасць і лаккальнасць дадзеных
Бо за кожны набор ключоў адказвае толькі адзін рэгіён, рашэннем праблем злучанымі з падзеннямі RS ці высновай з эксплуатацыі з'яўляецца захоўванне ўсіх неабходных дадзеных у HDFS. Пры падзенні RS майстар выяўляе гэта праз адсутнасць heartbeat на вузле ZooKeeper. Тады ён прызначае абслугоўваны рэгіён іншаму RS і бо HFiles захоўваюцца ў размеркаванай файлавай сістэме, то новы гаспадар вычытвае іх і працягвае абслугоўваць дадзеныя. Аднак, бо частка дадзеных можа быць у MemStore і не паспела патрапіць у HFiles, для аднаўлення гісторыі аперацый выкарыстоўваецца WAL, якія таксама захоўваюцца ў HDFS. Пасля накату змен, RS здольны адказваць на запыты, аднак пераезд прыводзіць да таго, што частка дадзеных і працэсы іх абслуговыя апыняюцца на розных нодах, г.зн. зніжаецца locality.
Рашэннем праблемы з'яўляецца major compaction - гэтая працэдура перамяшчае файлы на тыя ноды, якія за іх адказваюць (туды дзе размешчаны іх рэгіёны), у выніку чаго падчас гэтай працэдуры рэзка ўзрастае нагрузка на сетку і дыскі. Аднак у далейшым доступ да дадзеных прыкметна паскараецца. Акрамя таго, major_compaction выконвае аб'яднанне ўсіх HFiles у адзін файл у рамках рэгіёна, а таксама чысціць дадзеныя ў залежнасці ад налад табліцы. Напрыклад, можна задаць колькасць версій аб'екта, якую неабходна захоўваць або час яго жыцця, пасля заканчэння якога аб'ект фізічна выдаляецца.
Гэтая працэдура можа аказаць вельмі пазітыўны ўплыў на працу HBase. На малюнку ніжэй відаць, як дэградавала прадукцыйнасць у выніку актыўнага запісу дадзеных. Тут бачна як у адну табліцу 40 патокаў пісалі і 40 патокаў адначасова чыталі дадзеныя. Якія пішуць струмені фармуюць усё больш і больш HFiles, якія вычытваюцца іншымі струменямі. У выніку ўсё больш дадзеных трэба выдаляць з памяці і ў рэшце рэшт пачынае працаваць GC, які практычна паралізуе ўсю працу. Запуск major compaction прывёў да чысткі завал, якія ўтварыліся, і аднаўленню прадукцыйнасці.
Тэст выконваўся на 3-х DataNode і 4-х RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 патоку). Версія HBase 1.2.0-cdh5.14.2
Варта адзначыць, што запуск major compaction выконваўся на "жывы" табліцы, у якую актыўна пісалі і чыталі дадзеныя. У сетцы сустракалася сцвярджэнне, што гэта можа прывесці да некарэктнага адказу пры чытанні дадзеных. Для праверкі быў запушчаны працэс, які генераваў новыя дадзеныя і пісаў іх у табліцу. Пасля чаго адразу ж чытаў і звяраў ці супадае атрыманае значэнне з тым што было запісана. Падчас працы гэтага працэсу каля 200 разоў запускаўся major compaction і ніводнага збою не зафіксавана. Магчыма праблема выяўляецца рэдка і толькі падчас высокай загрузкі, таму больш бяспечна ўсё ж такі планава спыняць працэсы запісу і чытанні і выконваць ачыстку не дапушчаючы такіх прасадак GC.
Таксама major compaction не ўплывае на стан MemStore, для скіду яго на дыск і кампафікацыі трэба выкарыстоўваць flush (connection.getAdmin().flush(TableName.valueOf(tblName))).
8. Налады і прадукцыйнасць
Як ужо было сказанае, найбольшы поспех HBase паказвае там, дзе яму нічога не трэба рабіць, пры выкананні BulkLoad. Зрэшты, гэта датычыцца большасці сістэм і людзей. Аднак гэтая прылада падыходзіць хутчэй для масавай кладкі дадзеных вялікімі блокамі, тады як калі працэс патрабуе выканання мноства канкуруючых запытаў на чытанне і запіс, выкарыстоўваюцца апісаныя вышэй каманды Get і Put. Для вызначэння аптымальных параметраў былі зроблены запускі пры розных камбінацыях параметраў табліц і налад:
- Запускалася 10 патокаў адначасова 3 разы запар (назавем гэта блокам патокаў).
- Час працы ўсіх струменяў у блоку ўсярэднівалі і з'яўлялася выніковым вынікам працы блока.
- Усе плыні працавалі з адной і той жа табліцай.
- Перад кожным запускам блока патокаў выконваўся major compaction.
- Кожны блок выконваў толькі адну з наступных аперацый:
- Put
- Get
- Get + Put
- Кожны блок выконваў 50 паўтораў сваёй аперацыі.
- Памер запісу ў блоку 100 байт, 1000 байт ці 10000 байт (random).
- Блокі запускаліся з рознай колькасцю запытаных ключоў (або адзін ключ ці 10).
- Блокі запускаліся пры розных настройках табліцы. Змяняліся параметры:
— BlockCache = уключаўся ці выключаўся
- BlockSize = 65 Кб або 16 Кб
- Партыцый = 1, 5 або 30
- MSLAB = уключаны або выключаны
Такім чынам блок выглядае так:
a. Уключаўся/выключаўся рэжым MSLAB.
b. Стваралася табліца, для якой усталёўваліся наступныя параметры: BlockCache = true/none, BlockSize = 65/16 Kb, Партыцый = 1/5/30.
c. Усталёўваўся сціск GZ.
d. Запускалася 10 струменяў адначасова якія робяць 1/10 аперацый put/get/get+put у гэтую табліцу запісамі па 100/1000/10000 байт, выконваючы 50 000 запытаў запар (ключы рандомныя).
e. Пункт d паўтараўся тры разы.
f. Час працы ўсіх патокаў ўсярэдніваецца.
Былі правераны ўсе магчымыя камбінацыі. Прадказальна, што пры павелічэнні памеру запісу хуткасць будзе падаць ці што адключэнне кэшаванне прывядзе да запаволення. Аднак мэта была зразумець ступень і значнасць уплыву кожнага параметра, таму сабраныя дадзеныя былі пададзены на ўваход функцыі лінейнай рэгрэсіі, што дае магчымасць ацаніць дакладнасць пры дапамозе t-статыстыкі. Ніжэй прыведзены вынікі працы блокаў якія выконваюць аперацыі Put. Поўны набор камбінацый 2*2*3*2*3 = 144 варыянты + 72 т.я. некаторыя былі выкананы двойчы. Таму ў суме 216 запускаў:
Тэставанне праводзілася на міні-кластары якія складаюцца з 3-х DataNode і 4-х RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 патоку). Версія HBase 1.2.0-cdh5.14.2.
Найбольш высокая хуткасць устаўкі 3.7/16 сек была атрымана пры выключаным рэжыме MSLAB, на табліцы з адной партыцыяй, з уключаным BlockCache, BlockSize = 100, запісамі па 10 байт па XNUMX штук у пачку.
Найбольш нізкая хуткасць устаўкі 82.8 сек была атрымана пры ўключаным рэжыме MSLAB, на табліцы з адной партыцыяй, з уключаным BlockCache, BlockSize = 16, запісамі па 10000 байт па 1 штуцы.
Цяпер паглядзім на мадэль. Мы бачым добрую якасць мадэлі па R2, але цалкам зразумела, што экстрапаляцыя тут проціпаказаная. Рэальныя паводзіны сістэмы пры змене параметраў будуць не лінейнымі, гэтая мадэль патрэбная не для прагнозаў, а для разумення, што адбылося ў межах зададзеных параметраў. Напрыклад тут мы бачым па крытэры Ст'юдэнту, што для аперацыі Put не маюць значэння параметры BlockSize і BlockCache (што ўвогуле суцэль прадказальна):
А вось тое, што павелічэнне колькасці партыцый вядзе да зніжэння прадукцыйнасці некалькі нечакана (мы ўжо бачылі пазітыўны ўплыў павелічэння колькасці партыцый пры BulkLoad), хоць і вытлумачальна. У першых для апрацоўкі даводзіцца фармаваць запыты да 30 рэгіёнаў замест аднаго, а аб'ём дадзеных не такі, каб гэта дало выйгрыш. У другіх агульны час працы вызначаецца самым павольным RS, а бо колькасць DataNode менш колькасці RS частка рэгіёнаў маюць нулявую лакальнасць. Ну і паглядзім на пяцёрку лідэраў:
Цяпер ацэнім вынікі выканання блокаў Get:
Колькасць партыцый страціла значнасць, што верагодна тлумачыцца тым, што дадзеныя добра кэшуюцца і кэш для чытання найболей значны (статыстычна) параметр. Натуральна, што павелічэнне кол-ва паведамленняў у запыце - таксама вельмі карысна для прадукцыйнасці. Лепшыя вынікі:
Ну і нарэшце паглядзім на мадэль блока які выконваў спачатку get, а потым put:
Тут усе параметры значныя. І вынікі лідэраў:
9. Нагрузачнае тэсціраванне
Ну і нарэшце запусцім больш-менш прыстойную нагрузку, але заўсёды цікавейшае калі ёсць з чым параўноўваць. На сайце DataStax - ключавога распрацоўніка Cassandra ёсць НТ шэрагу NoSQL сховішчаў, у тым ліку HBase версіі 0.98.6-1. Загрузка ажыццяўлялася 40 патокамі, памер даных 100 байт, дыскі SSD. Вынік тэсціравання аперацый Read-Modify-Write паказаў такія вынікі.
Наколькі я зразумеў, чытанне ажыццяўлялася блокамі па 100 запісаў і для 16 нод HBase тэст DataStax паказаў прадукцыйнасць 10 тыс. аперацый у секунду.
Удала, што ў нашым кластары таксама 16 нод, але не вельмі "ўдала", што на кожным па 64 ядры (струменю), тады як у цесцю DataStax толькі па 4. З іншага боку ў іх кружэлкі SSD, а ў нас HDD і больш новая версія HBase і ўтылізацыя CPU падчас нагрузкі практычна павялічвалася не значна (візуальна на 5-10 адсоткаў). Аднак, тым не менш, паспрабуем запусціцца на гэтай канфігурацыі. Налады табліц па змаўчанні, чытанне вырабляецца ў дыяпазоне ключоў ад 0 да 50 млн. выпадковым чынам (г.зн. па сутнасці кожны раз новы). У табліцы 50 мільёнаў запісаў, разбіта на 64 партыцыі. Ключы захешаваны па crc32. Настройкі табліц дэфолтныя, MSLAB уключаны. Запуск 40 патокаў, кожны паток чытае набор з 100 выпадковых ключоў і тут жа піша згенераваныя 100 байт па гэтых ключах назад.
Стэнд: 16 DataNode і 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 патоку). Версія HBase 1.2.0-cdh5.14.2.
Сярэдні вынік бліжэй да 40 тыс. аперацый у секунду, што істотна лепш, чым у тэсце DataStax. Аднак у мэтах эксперыменту можна некалькі змяніць умовы. Даволі малаверагодна, што ўся праца будзе весціся выключна з адной табліцай, а таксама толькі з унікальнымі ключамі. Выкажам здагадку што ёсць нейкі гарачы набор ключоў які генеруе асноўную нагрузку. Таму паспрабуем стварыць нагрузку буйнейшымі запісамі (10 КБ), таксама пачкамі па 100, у 4 розных табліцы і абмежаваўшы дыяпазон запытаных ключоў 50 тыс. На графіцы ніжэй паказаны запуск 40 струменяў, кожны струмень чытае набор з 100 ключоў і тут жа піша выпадковыя 10 КБ па гэтых ключах таму.
Стэнд: 16 DataNode і 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 патоку). Версія HBase 1.2.0-cdh5.14.2.
Падчас нагрузак некалькі разоў запускаўся major compaction, як было паказана вышэй без гэтай працэдуры прадукцыйнасць будзе паступова дэградаваць, аднак падчас выканання таксама ўзнікае дадатковая нагрузка. Прасадкі выкліканы рознымі прычынамі. Часам патокі заканчвалі працу і пакуль яны перазапускаліся ўзнікала паўза, часам іншыя прыкладанні стваралі нагрузку на кластар.
Чытанне і адразу ж запіс - адзін з найбольш цяжкіх сцэнарыяў працы для HBase. Калі рабіць толькі put запыты невялікага памеру, напрыклад па 100 байт, аб'яднаўшы іх у пачкі па 10-50 тыс штук, можна атрымаць сотні тысяч аперацый у секунду і аналагічна справы ідуць з запытамі толькі на чытанне. Варта адзначыць, што вынікі радыкальна лепшыя за тыя, што атрымаліся ў DataStax больш за ўсё за кошт запытаў блокамі па 50 тыс.
Стэнд: 16 DataNode і 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 патоку). Версія HBase 1.2.0-cdh5.14.2.
10. высновы
Дадзеная сістэма досыць гнутка наладжваецца, аднак уплыў вялікай колькасці параметраў усё яшчэ застаецца невядомым. Частка з іх была пратэставаная, але не ўвайшла ў выніковы набор тэстаў. Напрыклад, папярэднія эксперыменты паказалі малаважную значнасць такога параметру як DATA_BLOCK_ENCODING, які кадуе інфармацыю, выкарыстоўваючы значэнні з суседніх ячэек, што цалкам вытлумачальна для дадзеных згенераваных выпадковым чынам. У выпадку выкарыстання вялікай колькасці паўтаральных аб'ектаў выйгрыш можа быць значным. У цэлым можна сказаць, што HBase вырабляе ўражанне дастаткова сур'ёзнай і прадуманай БД, якая пры аперацыях з вялікімі блокамі дадзеных можа быць дастаткова прадукцыйнай. Асабліва калі ёсць магчымасць разнесці ў часе працэсы чытання і запісы.
Калі нешта на ваш погляд недастаткова раскрыта, гатовы расказаць падрабязней. Прапануем дзяліцца сваім досведам ці падыскутаваць калі з чымсьці не згодныя.
Крыніца: habr.com