Иҷрои баланд яке аз талаботҳои асосӣ ҳангоми кор бо додаҳои калон мебошад. Мо, дар идоракунии боркунии маълумот дар Сбербанк, қариб ҳама транзаксияҳоро ба абри додаҳои Hadoop асосёфтаи худ интиқол медиҳем ва аз ин рӯ мо бо ҷараёни воқеан бузурги иттилоот сарукор дорем. Табиист, ки мо ҳамеша роҳҳои беҳтар кардани корҳоро меҷӯем ва ҳоло мо мехоҳем ба шумо бигӯем, ки чӣ тавр мо тавонистем, ки RegionServer HBase ва муштарии HDFS-ро часпонем, ки ин имкон дод, ки суръати амалиёти хониш ба таври назаррас афзоиш ёбад.
Бо вуҷуди ин, пеш аз гузаштан ба моҳияти беҳбудиҳо, бояд дар бораи маҳдудиятҳое сухан гӯем, ки агар шумо дар HDD нишинед, онҳоро аслан аз байн бурдан мумкин нест.
Чаро HDD ва хондани дастрасии фаврӣ номувофиқанд
Тавре ки шумо медонед, HBase ва бисёр дигар пойгоҳи додаҳо маълумотро дар блокҳои якчанд даҳҳо килобайт нигоҳ медоранд. Бо нобаёнӣ он тақрибан 64 KB аст. Акнун биёед тасаввур кунем, ки мо бояд танҳо 100 байт гирем ва мо аз HBase хоҳиш мекунем, ки ин маълумотро бо истифода аз як калиди муайян ба мо диҳад. Азбаски андозаи блок дар HFiles 64 KB аст, дархост аз зарурӣ 640 маротиба калонтар хоҳад буд (ҳамагӣ як дақиқа!).
Ғайр аз он, зеро дархост тавассути HDFS ва механизми кэшкунии метамаълумоти он мегузарад ShortCircuitCache (ки имкон медиҳад дастрасии мустақим ба файлҳо), пас ин боиси хондани аллакай 1 МБ аз диск мегардад. Аммо, ин метавонад бо параметр танзим карда шавад dfs.client.read.shortcircuit.buffer.size ва дар бисёр мавридҳо кам кардани ин арзиш, масалан, то 126 KB маъно дорад.
Фарз мекунем, ки мо ин корро мекунем, аммо илова бар ин, вақте ки мо ба хондани маълумот тавассути java api оғоз мекунем, бо функсияҳо ба монанди FileChannel.read ва аз системаи оператсионии хондани миқдори муайяни маълумот хоҳиш мекунем, он "ҳар маврид" 2 маротиба зиёдтар хориҷ мекунад. , яъне. дар 256 KB дар ҳолати мо. Сабаб дар он аст, ки дар Java роҳи осони гузоштани парчами FADV_RANDOM барои пешгирии ин рафтор вуҷуд надорад.
Дар натиҷа, барои ба даст овардани 100 байти мо, 2600 маротиба бештар дар зери капот хонда мешавад. Чунин ба назар мерасад, ки роҳи ҳалли он маълум аст, биёед андозаи блокро то як килобайт кам кунем, парчами зикршударо насб кунем ва суръатбахшии равшании бузург ба даст орем. Аммо мушкил дар он аст, ки бо кам кардани андозаи блок 2 маротиба, мо инчунин шумораи байтҳои хондашударо дар як воҳиди вақт 2 маротиба кам мекунем.
Аз гузоштани парчами FADV_RANDOM каме фоида ба даст овардан мумкин аст, аммо танҳо бо мултипликатори баланд ва андозаи блоки 128 КБ, аммо ин ҳадди аксар якчанд даҳҳо фоиз аст:
Санҷишҳо дар 100 файл, андозаи ҳар яки 1 ГБ ва дар 10 HDD ҷойгир карда шуданд.
Биёед ҳисоб кунем, ки мо асосан бо чунин суръат ба он чизе умед бастан мумкин аст:
Фарз мекунем, ки мо аз 10 диск бо суръати 280 МБ/с мехонем, яъне. 3 миллион маротиба 100 байт. Аммо тавре ки мо дар хотир дорем, ба мо маълумоте лозим аст, ки нисбат ба он чизе, ки хонда мешавад 2600 маротиба камтар аст. Ҳамин тариқ, мо 3 миллионро ба 2600 тақсим мекунем ва мегирем 1100 сабт дар як сония.
Ноумедкунанда, ҳамин тавр не? Чунин аст табиат Дастрасии тасодуфӣ дастрасӣ ба маълумот дар HDD - новобаста аз андозаи блок. Ин маҳдудияти физикии дастрасии тасодуфӣ аст ва ҳеҷ як махзани маълумот дар чунин шароит наметавонад бештар аз он фишурда шавад.
Пас чӣ гуна пойгоҳи додаҳо суръати баландтарро ба даст меоранд? Барои ҷавоб додан ба ин савол, биёед бубинем, ки дар расми зерин чӣ рӯй медиҳад:
Дар ин ҷо мо мебинем, ки дар чанд дақиқаи аввал суръат воқеан тақрибан ҳазор рекорд дар як сония аст. Бо вуҷуди ин, минбаъд, аз сабаби он, ки миқдори бештар аз дархостшуда тарҳ карда мешавад, маълумот дар буфф / кэши системаи амалиётӣ (linux) нигоҳ дошта мешавад ва суръат то 60 ҳазор дар як сония ба қадри кофӣ меафзояд.
Ҳамин тариқ, минбаъд мо бо суръатбахшии дастрасӣ танҳо ба маълумоте, ки дар кэши OS ҷойгиранд ё дар дастгоҳҳои нигаҳдории SSD/NVMe бо суръати дастрасии муқоисашаванда ҷойгиранд, сару кор хоҳем кард.
Дар ҳолати мо, мо дар як курсии 4 сервер санҷишҳо мегузаронем, ки ҳар яки онҳо ба таври зерин ситонида мешаванд:
CPU: Xeon E5-2680 v4 @ 2.40 ГГц 64 ришта.
Хотира: 730 ГБ.
Версияи Java: 1.8.0_111
Ва дар ин ҷо нуқтаи асосӣ миқдори маълумот дар ҷадвалҳост, ки бояд хонда шаванд. Гап дар он аст, ки агар шумо маълумотро аз ҷадвале хонед, ки комилан ба кэши HBase мувофиқат мекунад, он гоҳ он ҳатто ба хондан аз буфф / кэши системаи оператсионӣ намеояд. Азбаски HBase ба таври нобаёнӣ 40% хотираро ба сохторе бо номи BlockCache ҷудо мекунад. Дар асл, ин як ConcurrentHashMap аст, ки дар он калид номи файл + ҷуброни блок аст ва арзиш маълумоти воқеӣ дар ин ҷуброн аст.
Хамин тавр, хангоми хондан танхо аз хамин сохтор мо , мисли як миллион дархост дар як сония. Аммо биёед тасаввур кунем, ки мо садҳо гигабайт хотираро танҳо барои эҳтиёҷоти базаи маълумот дода наметавонем, зеро дар ин серверҳо бисёр чизҳои муфиди дигар чарх мезананд.
Масалан, дар ҳолати мо, ҳаҷми BlockCache дар як RS тақрибан 12 ГБ аст. Мо ду RS дар як гиреҳ фуруд омадем, яъне. 96 ГБ барои BlockCache дар ҳама гиреҳҳо ҷудо карда шудааст. Ва дар айни замон, маълумоти хеле бештар вуҷуд дорад, масалан, бигзор он 4 ҷадвал, 130 минтақа бошад, ки дар онҳо файлҳои андозаи 800 МБ, бо FAST_DIFF фишурда шудаанд, яъне. Дар маҷмӯъ 410 ГБ (ин маълумоти холис аст, яъне бе назардошти омили такрорӣ).
Ҳамин тариқ, BlockCache танҳо тақрибан 23% маълумоти умумиро ташкил медиҳад ва ин ба шароити воқеии он чизе ки BigData номида мешавад, хеле наздиктар аст. Ва дар ин ҷо ҷолибтарин оғоз меёбад - дар ниҳоят, маълум аст, ки чӣ қадаре ки кэш камтар бошад, кор ҳамон қадар бадтар мешавад. Охир, дар сурати пазмон шудан, шумо бояд кори зиёдеро анҷом диҳед - яъне. фуромадан пеш аз даъват кардани функсияҳои система. Аммо, аз ин пешгирӣ кардан мумкин нест ва аз ин рӯ биёед як ҷанбаи тамоман дигарро баррасӣ кунем - бо маълумот дар дохили кэш чӣ мешавад?
Биёед вазъиятро содда кунем ва фарз кунем, ки мо кэш дорем, ки дар он танҳо 1 объект ҷойгир шудааст. Ин аст як мисоли он чӣ рӯй медиҳад, вақте ки мо кӯшиш мекунем бо ҳаҷми маълумот аз кэш 3 маротиба калонтар кор кунем, мо бояд:
1. Блоки 1-ро дар кэш ҷойгир кунед
2. Блоки 1-ро аз кэш хориҷ кунед
3. Блоки 2-ро дар кэш ҷойгир кунед
4. Блоки 2-ро аз кэш хориҷ кунед
5. Блоки 3-ро дар кэш ҷойгир кунед
5 амал анҷом ёфт! Аммо, ин вазъиятро муқаррарӣ номидан мумкин нест; дар асл, мо HBase-ро маҷбур мекунем, ки як қатор кори тамоман бефоидаро анҷом диҳад. Он пайваста маълумотро аз кэши OS мехонад, онро дар BlockCache ҷойгир мекунад, танҳо барои он ки онро қариб дарҳол партояд, зеро қисми нави маълумот ворид шудааст. Аниматсия дар аввали пост моҳияти мушкилотро нишон медиҳад - Ҷамъоварии партов аз миқёс берун меравад, атмосфера гарм мешавад, Гретаи хурдсол дар Шветсияи дурдаст ва гарм хафа мешавад. Ва мо одамони IT воқеан вақте ки кӯдакон ғамгинанд, дӯст намедорем, аз ин рӯ мо дар бораи он фикр мекунем, ки дар ин бора чӣ кор карда метавонем.
Аммо чӣ мешавад, агар на ҳама блокҳо дар кэш ҷойгир карда шаванд, балки танҳо фоизи муайяни онҳо, то ки кэш пур нашавад? Биёед танҳо бо илова кардани чанд сатри код ба болои функсияи push BlockCache оғоз кунем:
public void cacheBlock(BlockCacheKey cacheKey, Cacheable buf, boolean inMemory) {
if (cacheDataBlockPercent != 100 && buf.getBlockType().isData()) {
if (cacheKey.getOffset() % 100 >= cacheDataBlockPercent) {
return;
}
}
...
Маънои ин ҷо чунин аст, офсет мавқеи блок дар файл аст ва рақамҳои охирини он аз 00 то 99 ба таври тасодуфӣ ва баробар тақсим карда мешаванд. Аз ин рӯ, мо танҳо онҳоеро, ки ба диапазони ба мо лозиманд, мегузарем.
Масалан, cacheDataBlockPercent = 20 гузоред ва бубинед, ки чӣ мешавад:
Натиҷа дар он аст. Дар графикҳои дар поён овардашуда маълум мешавад, ки чаро ин суръатбахшӣ рух додааст - мо як қатор захираҳои GC-ро бидуни кори Sisyphean барои ҷойгир кардани маълумот дар кэш сарфа мекунем, то онро фавран ба сагҳои Марсиан партоянд:
Ҳамзамон, истифодаи CPU афзоиш меёбад, аммо нисбат ба иҷроиш хеле камтар:
Инчунин бояд қайд кард, ки блокҳое, ки дар BlockCache нигоҳ дошта мешаванд, гуногунанд. Аксарияти он, тақрибан 95%, худи маълумот аст. Ва боқимондаҳо метадата мебошанд, ба монанди филтрҳои Bloom ё LEAF_INDEX ва . Ин маълумот кофӣ нест, аммо хеле муфид аст, зеро пеш аз он ки мустақиман ба маълумот рӯй оваред, HBase ба мета ишора мекунад, то бифаҳмад, ки оё дар ин ҷо ба таври минбаъда дидан лозим аст ва агар ин тавр бошад, блоки таваҷҷӯҳ ба он маҳз дар куҷост.
Аз ин рӯ, дар код мо ҳолати чекро мебинем buf.getBlockType().isData() ва ба шарофати ин мета мо ба ҳар ҳол дар кэш нигоҳ медорем.
Акнун биёед сарбориро зиёд кунем ва дар айни замон хусусиятро каме танзим кунем. Дар санҷиши аввал, мо фоизи буриданро = 20 кардем ва BlockCache каме камбор карда шуд. Акнун биёед онро ба 23% муқаррар кунем ва дар ҳар 100 дақиқа 5 ришта илова кунем, то бубинем, ки кай сершавӣ рух медиҳад:
Дар ин ҷо мо мебинем, ки версияи аслӣ тақрибан дар як сония тақрибан 100 ҳазор дархост ба шифт мезанад. Дар ҳоле ки патч суръатбахшии то 300 ҳазорро медиҳад. Дар айни замон, равшан аст, ки суръатбахшии минбаъда дигар он қадар "озод" нест, дар ҳоле ки истифодаи CPU низ меафзояд.
Аммо, ин як ҳалли хеле шево нест, зеро мо пешакӣ намедонем, ки чанд фоизи блокҳоро кэш кардан лозим аст, он аз профили сарборӣ вобаста аст. Аз ин рӯ, механизми ба таври худкор танзим кардани ин параметр вобаста ба фаъолияти амалиёти хониш ҷорӣ карда шуд.
Барои назорат кардани ин се вариант илова карда шудааст:
hbase.lru.cache.heavy.evction.count.limit - муайян мекунад, ки пеш аз оғози истифодаи оптимизатсия (яъне блокҳоро гузаред) бояд чанд маротиба раванди хориҷ кардани маълумот аз кэш оғоз шавад. Бо нобаёнӣ, он ба MAX_INT = 2147483647 баробар аст ва дар асл маънои онро дорад, ки хусусият ҳеҷ гоҳ бо ин арзиш кор намекунад. Зеро раванди хориҷкунӣ дар ҳар 5 - 10 сония оғоз мешавад (он аз сарборӣ вобаста аст) ва 2147483647 * 10/60/60/24/365 = 680 сол. Аммо, мо метавонем ин параметрро ба 0 муқаррар кунем ва хусусиятро фавран пас аз оғоз кор кунем.
Бо вуҷуди ин, дар ин параметр як бор низ вуҷуд дорад. Агар мо хусусияти сарборӣ дошта бошем, ки хонишҳои кӯтоҳмуддат (биёед дар давоми рӯз бигӯем) ва хонишҳои дарозмӯҳлат (шабо) пайваста ба ҳам мепайвандад, он гоҳ мо метавонем хусусиятро танҳо ҳангоми фаъол кардани амалиёти хониши дарозмуддат ба кор дарорем. дар ҷараён.
Масалан, мо медонем, ки хониши кӯтоҳмуддат одатан тақрибан 1 дақиқа давом мекунад. Зарурати оғоз кардани партофтани блокҳо нест, кэш вақт надорад, ки кӯҳна шавад ва он гоҳ мо метавонем ин параметрро, масалан, 10 муқаррар кунем. Ин ба он оварда мерасонад, ки оптимизатсия танҳо ҳангоми хондани фаъоли тӯлонӣ кор хоҳад кард. оғоз кардааст, и. пас аз 100 сония. Ҳамин тариқ, агар мо хондани кӯтоҳмуддат дошта бошем, он гоҳ ҳама блокҳо ба кэш дохил мешаванд ва дастрас хоҳанд буд (ба истиснои онҳое, ки бо алгоритми стандартӣ хориҷ карда мешаванд). Ва вақте ки мо хондани дарозмуддат мекунем, хусусият фаъол мешавад ва мо иҷрои хеле беҳтар хоҳем дошт.
hbase.lru.cache.heavy.evction.mb.size.limit - муайян мекунад, ки мо дар 10 сония чанд мегабайтро дар кэш ҷойгир кардан мехоҳем (ва табиатан хориҷ кунем). Хусусият кӯшиш мекунад, ки ба ин арзиш бирасад ва онро нигоҳ дорад. Гап дар сари он аст, ки агар мо гигабайтҳоро ба кэш тела диҳем, он гоҳ гигабайтҳо бояд хориҷ карда шаванд ва ин, тавре ки дар боло дидем, хеле гарон аст. Бо вуҷуди ин, шумо набояд кӯшиш кунед, ки онро хеле хурд кунед, зеро ин боиси бармаҳал баромадан аз ҳолати гузариш аз блок мегардад. Барои серверҳои пурқувват (тақрибан 20-40 ядрои физикӣ) муқаррар кардани тақрибан 300-400 МБ оптимал аст. Барои синфи миёна (~ 10 ядро) 200-300 МБ. Барои системаҳои заиф (2-5 ядро) 50-100 МБ метавонад муқаррарӣ бошад (дар чунин системаҳо санҷида нашудааст).
Биёед бубинем, ки он чӣ гуна кор мекунад: биёед бигӯем, ки мо hbase.lru.cache.heavy.eviction.mb.size.limit = 500 муқаррар кардем, як навъ сарборӣ (хондан) вуҷуд дорад ва пас аз ҳар ~ 10 сония мо ҳисоб мекунем, ки чанд байт хориҷ карда шудааст. аз рӯи формула:
Маблағи болоӣ = Маблағи байтҳои озодшуда (МБ) * 100 / Ҳадди (МБ) - 100;
Агар воқеан 2000 МБ хориҷ карда шуда бошад, пас сарборӣ ба ин баробар аст:
2000 * 100 / 500 - 100 = 300%
Алгоритмҳо кӯшиш мекунанд, ки на бештар аз чанд даҳ фоизро дастгирӣ кунанд, бинобар ин хусусият фоизи блокҳои кэшро коҳиш медиҳад ва ба ин васила механизми танзими худкорро амалӣ мекунад.
Аммо, агар сарборӣ кам шуда бошад, биёед бигӯем, ки ҳамагӣ 200 МБ хориҷ карда шуд ва сарборӣ манфӣ мешавад (ба ном аз ҳад зиёд):
200 * 100 / 500 - 100 = -60%
Баръакс, ин хусусият фоизи блокҳои кэшшударо афзоиш медиҳад, то он даме, ки сарбории боло мусбат шавад.
Дар зер намунаи он аст, ки чӣ тавр ин ба маълумоти воқеӣ назар мекунад. Барои расидан ба 0% кӯшиш кардан лозим нест, ин имконнопазир аст. Ин хеле хуб аст, вақте ки он тақрибан 30 - 100% аст, ин барои пешгирӣ кардани бармаҳал аз реҷаи оптимизатсия ҳангоми шиддати кӯтоҳмуддат кӯмак мекунад.
hbase.lru.cache.heavy.evction.overhead.коэффиценти — муайян мекунад, ки мо то чӣ андоза зуд ба натиҷа ноил шудан мехоҳем. Агар мо аниқ донем, ки хондани мо асосан тӯлонӣ аст ва интизор шудан намехоҳем, мо метавонем ин таносубро зиёд кунем ва суръати баландро зудтар ба даст орем.
Масалан, мо ин коэффисиентро = 0.01 муқаррар кардем. Ин маънои онро дорад, ки сарбории изофӣ (ба боло нигаред) аз рӯи натиҷа ба ин рақам зарб карда мешавад ва фоизи блокҳои кэшшуда кам мешавад. Биёед бигӯем, ки сарборӣ = 300% ва коэффисиент = 0.01, пас фоизи блокҳои кэшшуда 3% кам карда мешавад.
Мантиқи шабеҳи "Фашори бозгашт" низ барои арзишҳои манфии сарборӣ (аз ҳад зиёд) амалӣ карда мешавад. Азбаски тағирёбии кӯтоҳмуддати ҳаҷми хондан ва хориҷкунӣ ҳамеша имконпазир аст, ин механизм ба шумо имкон медиҳад, ки аз реҷаи оптимизатсия бармаҳал баромаданро пешгирӣ кунед. Фишори бозгашт мантиқи баръакс дорад: чӣ қадаре, ки аз ҳад зиёд қавитар шавад, блокҳои бештар кэш карда мешаванд.
Рамзи татбиқ
LruBlockCache cache = this.cache.get();
if (cache == null) {
break;
}
freedSumMb += cache.evict()/1024/1024;
/*
* Sometimes we are reading more data than can fit into BlockCache
* and it is the cause a high rate of evictions.
* This in turn leads to heavy Garbage Collector works.
* So a lot of blocks put into BlockCache but never read,
* but spending a lot of CPU resources.
* Here we will analyze how many bytes were freed and decide
* decide whether the time has come to reduce amount of caching blocks.
* It help avoid put too many blocks into BlockCache
* when evict() works very active and save CPU for other jobs.
* More delails: https://issues.apache.org/jira/browse/HBASE-23887
*/
// First of all we have to control how much time
// has passed since previuos evict() was launched
// This is should be almost the same time (+/- 10s)
// because we get comparable volumes of freed bytes each time.
// 10s because this is default period to run evict() (see above this.wait)
long stopTime = System.currentTimeMillis();
if ((stopTime - startTime) > 1000 * 10 - 1) {
// Here we have to calc what situation we have got.
// We have the limit "hbase.lru.cache.heavy.eviction.bytes.size.limit"
// and can calculte overhead on it.
// We will use this information to decide,
// how to change percent of caching blocks.
freedDataOverheadPercent =
(int) (freedSumMb * 100 / cache.heavyEvictionMbSizeLimit) - 100;
if (freedSumMb > cache.heavyEvictionMbSizeLimit) {
// Now we are in the situation when we are above the limit
// But maybe we are going to ignore it because it will end quite soon
heavyEvictionCount++;
if (heavyEvictionCount > cache.heavyEvictionCountLimit) {
// It is going for a long time and we have to reduce of caching
// blocks now. So we calculate here how many blocks we want to skip.
// It depends on:
// 1. Overhead - if overhead is big we could more aggressive
// reducing amount of caching blocks.
// 2. How fast we want to get the result. If we know that our
// heavy reading for a long time, we don't want to wait and can
// increase the coefficient and get good performance quite soon.
// But if we don't sure we can do it slowly and it could prevent
// premature exit from this mode. So, when the coefficient is
// higher we can get better performance when heavy reading is stable.
// But when reading is changing we can adjust to it and set
// the coefficient to lower value.
int change =
(int) (freedDataOverheadPercent * cache.heavyEvictionOverheadCoefficient);
// But practice shows that 15% of reducing is quite enough.
// We are not greedy (it could lead to premature exit).
change = Math.min(15, change);
change = Math.max(0, change); // I think it will never happen but check for sure
// So this is the key point, here we are reducing % of caching blocks
cache.cacheDataBlockPercent -= change;
// If we go down too deep we have to stop here, 1% any way should be.
cache.cacheDataBlockPercent = Math.max(1, cache.cacheDataBlockPercent);
}
} else {
// Well, we have got overshooting.
// Mayby it is just short-term fluctuation and we can stay in this mode.
// It help avoid permature exit during short-term fluctuation.
// If overshooting less than 90%, we will try to increase the percent of
// caching blocks and hope it is enough.
if (freedSumMb >= cache.heavyEvictionMbSizeLimit * 0.1) {
// Simple logic: more overshooting - more caching blocks (backpressure)
int change = (int) (-freedDataOverheadPercent * 0.1 + 1);
cache.cacheDataBlockPercent += change;
// But it can't be more then 100%, so check it.
cache.cacheDataBlockPercent = Math.min(100, cache.cacheDataBlockPercent);
} else {
// Looks like heavy reading is over.
// Just exit form this mode.
heavyEvictionCount = 0;
cache.cacheDataBlockPercent = 100;
}
}
LOG.info("BlockCache evicted (MB): {}, overhead (%): {}, " +
"heavy eviction counter: {}, " +
"current caching DataBlock (%): {}",
freedSumMb, freedDataOverheadPercent,
heavyEvictionCount, cache.cacheDataBlockPercent);
freedSumMb = 0;
startTime = stopTime;
}
Акнун ҳамаи инро дар мисоли воқеӣ баррасӣ кунед. Мо сенарияи санҷиши зерин дорем:
- Биёед кори сканро оғоз кунем (25 ришта, партия = 100)
- Пас аз 5 дақиқа, multi-gets илова кунед (25 ришта, партия = 100)
- Пас аз 5 дақиқа, multi-gets-ро хомӯш кунед (фақат боз сканер боқӣ мемонад)
Мо ду иҷро мекунем, аввал hbase.lru.cache.heavy.eviction.count.limit = 10000 (ки воқеан ин хусусиятро ғайрифаъол мекунад) ва сипас лимити = 0 (фаъол мекунад).
Дар гузоришҳои зер мо мебинем, ки ин хусусият чӣ гуна фаъол мешавад ва Overshooting-ро ба 14-71% аз нав барқарор мекунад. Вақт аз вақт сарборӣ коҳиш меёбад, ки ин Backpressure ва HBase-ро боз блокҳои бештар кэш мекунад.
Сабти сервери минтақавӣ
ихроҷшуда (МБ): 0, таносуби 0.0, сарбории изофӣ (%): -100, ҳисобкунаки эваксионии вазнин: 0, кэшкунии ҷорӣ DataBlock (%): 100
ихроҷшуда (МБ): 0, таносуби 0.0, сарбории изофӣ (%): -100, ҳисобкунаки эваксионии вазнин: 0, кэшкунии ҷорӣ DataBlock (%): 100
ихроҷшуда (МБ): 2170, таносуби 1.09, сарбории болоӣ (%): 985, ҳисобкунаки вазнини ихроҷ: 1, кэшкунии ҷорӣ DataBlock (%): 91 < оғоз
ихроҷшуда (МБ): 3763, таносуби 1.08, хароҷоти изофӣ (%): 1781, ҳисобкунаки вазнини ихроҷ: 2, кэшкунии ҷорӣ DataBlock (%): 76
ихроҷшуда (МБ): 3306, таносуби 1.07, хароҷоти изофӣ (%): 1553, ҳисобкунаки вазнини ихроҷ: 3, кэшкунии ҷорӣ DataBlock (%): 61
ихроҷшуда (МБ): 2508, таносуби 1.06, хароҷоти изофӣ (%): 1154, ҳисобкунаки вазнини ихроҷ: 4, кэшкунии ҷорӣ DataBlock (%): 50
ихроҷшуда (МБ): 1824, таносуби 1.04, хароҷоти изофӣ (%): 812, ҳисобкунаки вазнини ихроҷ: 5, кэшкунии ҷорӣ DataBlock (%): 42
ихроҷшуда (МБ): 1482, таносуби 1.03, хароҷоти изофӣ (%): 641, ҳисобкунаки вазнини ихроҷ: 6, кэшкунии ҷорӣ DataBlock (%): 36
ихроҷшуда (МБ): 1140, таносуби 1.01, хароҷоти изофӣ (%): 470, ҳисобкунаки вазнини ихроҷ: 7, кэшкунии ҷорӣ DataBlock (%): 32
ихроҷшуда (МБ): 913, таносуби 1.0, хароҷоти изофӣ (%): 356, ҳисобкунаки вазнини ихроҷ: 8, кэшкунии ҷорӣ DataBlock (%): 29
ихроҷшуда (МБ): 912, таносуби 0.89, хароҷоти изофӣ (%): 356, ҳисобкунаки вазнини ихроҷ: 9, кэшкунии ҷорӣ DataBlock (%): 26
ихроҷшуда (МБ): 684, таносуби 0.76, хароҷоти изофӣ (%): 242, ҳисобкунаки вазнини ихроҷ: 10, кэшкунии ҷорӣ DataBlock (%): 24
ихроҷшуда (МБ): 684, таносуби 0.61, хароҷоти изофӣ (%): 242, ҳисобкунаки вазнини ихроҷ: 11, кэшкунии ҷорӣ DataBlock (%): 22
ихроҷшуда (МБ): 456, таносуби 0.51, хароҷоти изофӣ (%): 128, ҳисобкунаки вазнини ихроҷ: 12, кэшкунии ҷорӣ DataBlock (%): 21
ихроҷшуда (МБ): 456, таносуби 0.42, хароҷоти изофӣ (%): 128, ҳисобкунаки вазнини ихроҷ: 13, кэшкунии ҷорӣ DataBlock (%): 20
ихроҷшуда (МБ): 456, таносуби 0.33, хароҷоти изофӣ (%): 128, ҳисобкунаки вазнини ихроҷ: 14, кэшкунии ҷорӣ DataBlock (%): 19
ихроҷшуда (МБ): 342, таносуби 0.33, хароҷоти изофӣ (%): 71, ҳисобкунаки вазнини ихроҷ: 15, кэшкунии ҷорӣ DataBlock (%): 19
ихроҷшуда (МБ): 342, таносуби 0.32, хароҷоти изофӣ (%): 71, ҳисобкунаки вазнини ихроҷ: 16, кэшкунии ҷорӣ DataBlock (%): 19
ихроҷшуда (МБ): 342, таносуби 0.31, хароҷоти изофӣ (%): 71, ҳисобкунаки вазнини ихроҷ: 17, кэшкунии ҷорӣ DataBlock (%): 19
ихроҷшуда (МБ): 228, таносуби 0.3, хароҷоти изофӣ (%): 14, ҳисобкунаки вазнини ихроҷ: 18, кэшкунии ҷорӣ DataBlock (%): 19
ихроҷшуда (МБ): 228, таносуби 0.29, хароҷоти изофӣ (%): 14, ҳисобкунаки вазнини ихроҷ: 19, кэшкунии ҷорӣ DataBlock (%): 19
ихроҷшуда (МБ): 228, таносуби 0.27, хароҷоти изофӣ (%): 14, ҳисобкунаки вазнини ихроҷ: 20, кэшкунии ҷорӣ DataBlock (%): 19
ихроҷшуда (МБ): 228, таносуби 0.25, хароҷоти изофӣ (%): 14, ҳисобкунаки вазнини ихроҷ: 21, кэшкунии ҷорӣ DataBlock (%): 19
ихроҷшуда (МБ): 228, таносуби 0.24, хароҷоти изофӣ (%): 14, ҳисобкунаки вазнини ихроҷ: 22, кэшкунии ҷорӣ DataBlock (%): 19
ихроҷшуда (МБ): 228, таносуби 0.22, хароҷоти изофӣ (%): 14, ҳисобкунаки вазнини ихроҷ: 23, кэшкунии ҷорӣ DataBlock (%): 19
ихроҷшуда (МБ): 228, таносуби 0.21, хароҷоти изофӣ (%): 14, ҳисобкунаки вазнини ихроҷ: 24, кэшкунии ҷорӣ DataBlock (%): 19
ихроҷшуда (МБ): 228, таносуби 0.2, хароҷоти изофӣ (%): 14, ҳисобкунаки вазнини ихроҷ: 25, кэшкунии ҷорӣ DataBlock (%): 19
ихроҷшуда (МБ): 228, таносуби 0.17, хароҷоти изофӣ (%): 14, ҳисобкунаки вазнини ихроҷ: 26, кэшкунии ҷорӣ DataBlock (%): 19
ихроҷшуда (МБ): 456, таносуби 0.17, сарбории изофӣ (%): 128, ҳисобкунаки эваксионии вазнин: 27, кэшкунии ҷорӣ DataBlock (%): 18 < илова карда мешавад (аммо ҷадвал ҳамон аст)
ихроҷшуда (МБ): 456, таносуби 0.15, хароҷоти изофӣ (%): 128, ҳисобкунаки вазнини ихроҷ: 28, кэшкунии ҷорӣ DataBlock (%): 17
ихроҷшуда (МБ): 342, таносуби 0.13, хароҷоти изофӣ (%): 71, ҳисобкунаки вазнини ихроҷ: 29, кэшкунии ҷорӣ DataBlock (%): 17
ихроҷшуда (МБ): 342, таносуби 0.11, хароҷоти изофӣ (%): 71, ҳисобкунаки вазнини ихроҷ: 30, кэшкунии ҷорӣ DataBlock (%): 17
ихроҷшуда (МБ): 342, таносуби 0.09, хароҷоти изофӣ (%): 71, ҳисобкунаки вазнини ихроҷ: 31, кэшкунии ҷорӣ DataBlock (%): 17
ихроҷшуда (МБ): 228, таносуби 0.08, хароҷоти изофӣ (%): 14, ҳисобкунаки вазнини ихроҷ: 32, кэшкунии ҷорӣ DataBlock (%): 17
ихроҷшуда (МБ): 228, таносуби 0.07, хароҷоти изофӣ (%): 14, ҳисобкунаки вазнини ихроҷ: 33, кэшкунии ҷорӣ DataBlock (%): 17
ихроҷшуда (МБ): 228, таносуби 0.06, хароҷоти изофӣ (%): 14, ҳисобкунаки вазнини ихроҷ: 34, кэшкунии ҷорӣ DataBlock (%): 17
ихроҷшуда (МБ): 228, таносуби 0.05, хароҷоти изофӣ (%): 14, ҳисобкунаки вазнини ихроҷ: 35, кэшкунии ҷорӣ DataBlock (%): 17
ихроҷшуда (МБ): 228, таносуби 0.05, хароҷоти изофӣ (%): 14, ҳисобкунаки вазнини ихроҷ: 36, кэшкунии ҷорӣ DataBlock (%): 17
ихроҷшуда (МБ): 228, таносуби 0.04, хароҷоти изофӣ (%): 14, ҳисобкунаки вазнини ихроҷ: 37, кэшкунии ҷорӣ DataBlock (%): 17
ихроҷшуда (МБ): 109, таносуби 0.04, сарбории болоӣ (%): -46, ҳисобкунаки эваксионии вазнин: 37, кэшкунии ҷорӣ DataBlock (%): 22 <фишори бозгашт
ихроҷшуда (МБ): 798, таносуби 0.24, хароҷоти изофӣ (%): 299, ҳисобкунаки вазнини ихроҷ: 38, кэшкунии ҷорӣ DataBlock (%): 20
ихроҷшуда (МБ): 798, таносуби 0.29, хароҷоти изофӣ (%): 299, ҳисобкунаки вазнини ихроҷ: 39, кэшкунии ҷорӣ DataBlock (%): 18
ихроҷшуда (МБ): 570, таносуби 0.27, хароҷоти изофӣ (%): 185, ҳисобкунаки вазнини ихроҷ: 40, кэшкунии ҷорӣ DataBlock (%): 17
ихроҷшуда (МБ): 456, таносуби 0.22, хароҷоти изофӣ (%): 128, ҳисобкунаки вазнини ихроҷ: 41, кэшкунии ҷорӣ DataBlock (%): 16
ихроҷшуда (МБ): 342, таносуби 0.16, хароҷоти изофӣ (%): 71, ҳисобкунаки вазнини ихроҷ: 42, кэшкунии ҷорӣ DataBlock (%): 16
ихроҷшуда (МБ): 342, таносуби 0.11, хароҷоти изофӣ (%): 71, ҳисобкунаки вазнини ихроҷ: 43, кэшкунии ҷорӣ DataBlock (%): 16
ихроҷшуда (МБ): 228, таносуби 0.09, хароҷоти изофӣ (%): 14, ҳисобкунаки вазнини ихроҷ: 44, кэшкунии ҷорӣ DataBlock (%): 16
ихроҷшуда (МБ): 228, таносуби 0.07, хароҷоти изофӣ (%): 14, ҳисобкунаки вазнини ихроҷ: 45, кэшкунии ҷорӣ DataBlock (%): 16
ихроҷшуда (МБ): 228, таносуби 0.05, хароҷоти изофӣ (%): 14, ҳисобкунаки вазнини ихроҷ: 46, кэшкунии ҷорӣ DataBlock (%): 16
ихроҷшуда (МБ): 222, таносуби 0.04, хароҷоти изофӣ (%): 11, ҳисобкунаки вазнини ихроҷ: 47, кэшкунии ҷорӣ DataBlock (%): 16
ихроҷшуда (МБ): 104, таносуби 0.03, сарбории болоӣ (%): -48, ҳисобкунакҳои вазнини ихроҷ: 47, кэшкунии ҷорӣ DataBlock (%): 21 < қатъ мешавад
ихроҷшуда (МБ): 684, таносуби 0.2, хароҷоти изофӣ (%): 242, ҳисобкунаки вазнини ихроҷ: 48, кэшкунии ҷорӣ DataBlock (%): 19
ихроҷшуда (МБ): 570, таносуби 0.23, хароҷоти изофӣ (%): 185, ҳисобкунаки вазнини ихроҷ: 49, кэшкунии ҷорӣ DataBlock (%): 18
ихроҷшуда (МБ): 342, таносуби 0.22, хароҷоти изофӣ (%): 71, ҳисобкунаки вазнини ихроҷ: 50, кэшкунии ҷорӣ DataBlock (%): 18
ихроҷшуда (МБ): 228, таносуби 0.21, хароҷоти изофӣ (%): 14, ҳисобкунаки вазнини ихроҷ: 51, кэшкунии ҷорӣ DataBlock (%): 18
ихроҷшуда (МБ): 228, таносуби 0.2, хароҷоти изофӣ (%): 14, ҳисобкунаки вазнини ихроҷ: 52, кэшкунии ҷорӣ DataBlock (%): 18
ихроҷшуда (МБ): 228, таносуби 0.18, хароҷоти изофӣ (%): 14, ҳисобкунаки вазнини ихроҷ: 53, кэшкунии ҷорӣ DataBlock (%): 18
ихроҷшуда (МБ): 228, таносуби 0.16, хароҷоти изофӣ (%): 14, ҳисобкунаки вазнини ихроҷ: 54, кэшкунии ҷорӣ DataBlock (%): 18
ихроҷшуда (МБ): 228, таносуби 0.14, хароҷоти изофӣ (%): 14, ҳисобкунаки вазнини ихроҷ: 55, кэшкунии ҷорӣ DataBlock (%): 18
ихроҷшуда (МБ): 112, таносуби 0.14, сарбории болоӣ (%): -44, ҳисобкунаки эваксионии вазнин: 55, кэшкунии ҷорӣ DataBlock (%): 23 <фишори бозгашт
ихроҷшуда (МБ): 456, таносуби 0.26, хароҷоти изофӣ (%): 128, ҳисобкунаки вазнини ихроҷ: 56, кэшкунии ҷорӣ DataBlock (%): 22
ихроҷшуда (МБ): 342, таносуби 0.31, хароҷоти изофӣ (%): 71, ҳисобкунаки вазнини ихроҷ: 57, кэшкунии ҷорӣ DataBlock (%): 22
ихроҷшуда (МБ): 342, таносуби 0.33, хароҷоти изофӣ (%): 71, ҳисобкунаки вазнини ихроҷ: 58, кэшкунии ҷорӣ DataBlock (%): 22
ихроҷшуда (МБ): 342, таносуби 0.33, хароҷоти изофӣ (%): 71, ҳисобкунаки вазнини ихроҷ: 59, кэшкунии ҷорӣ DataBlock (%): 22
ихроҷшуда (МБ): 342, таносуби 0.33, хароҷоти изофӣ (%): 71, ҳисобкунаки вазнини ихроҷ: 60, кэшкунии ҷорӣ DataBlock (%): 22
ихроҷшуда (МБ): 342, таносуби 0.33, хароҷоти изофӣ (%): 71, ҳисобкунаки вазнини ихроҷ: 61, кэшкунии ҷорӣ DataBlock (%): 22
ихроҷшуда (МБ): 342, таносуби 0.33, хароҷоти изофӣ (%): 71, ҳисобкунаки вазнини ихроҷ: 62, кэшкунии ҷорӣ DataBlock (%): 22
ихроҷшуда (МБ): 342, таносуби 0.33, хароҷоти изофӣ (%): 71, ҳисобкунаки вазнини ихроҷ: 63, кэшкунии ҷорӣ DataBlock (%): 22
ихроҷшуда (МБ): 342, таносуби 0.32, хароҷоти изофӣ (%): 71, ҳисобкунаки вазнини ихроҷ: 64, кэшкунии ҷорӣ DataBlock (%): 22
ихроҷшуда (МБ): 342, таносуби 0.33, хароҷоти изофӣ (%): 71, ҳисобкунаки вазнини ихроҷ: 65, кэшкунии ҷорӣ DataBlock (%): 22
ихроҷшуда (МБ): 342, таносуби 0.33, хароҷоти изофӣ (%): 71, ҳисобкунаки вазнини ихроҷ: 66, кэшкунии ҷорӣ DataBlock (%): 22
ихроҷшуда (МБ): 342, таносуби 0.32, хароҷоти изофӣ (%): 71, ҳисобкунаки вазнини ихроҷ: 67, кэшкунии ҷорӣ DataBlock (%): 22
ихроҷшуда (МБ): 342, таносуби 0.33, хароҷоти изофӣ (%): 71, ҳисобкунаки вазнини ихроҷ: 68, кэшкунии ҷорӣ DataBlock (%): 22
ихроҷшуда (МБ): 342, таносуби 0.32, хароҷоти изофӣ (%): 71, ҳисобкунаки вазнини ихроҷ: 69, кэшкунии ҷорӣ DataBlock (%): 22
ихроҷшуда (МБ): 342, таносуби 0.32, хароҷоти изофӣ (%): 71, ҳисобкунаки вазнини ихроҷ: 70, кэшкунии ҷорӣ DataBlock (%): 22
ихроҷшуда (МБ): 342, таносуби 0.33, хароҷоти изофӣ (%): 71, ҳисобкунаки вазнини ихроҷ: 71, кэшкунии ҷорӣ DataBlock (%): 22
ихроҷшуда (МБ): 342, таносуби 0.33, хароҷоти изофӣ (%): 71, ҳисобкунаки вазнини ихроҷ: 72, кэшкунии ҷорӣ DataBlock (%): 22
ихроҷшуда (МБ): 342, таносуби 0.33, хароҷоти изофӣ (%): 71, ҳисобкунаки вазнини ихроҷ: 73, кэшкунии ҷорӣ DataBlock (%): 22
ихроҷшуда (МБ): 342, таносуби 0.33, хароҷоти изофӣ (%): 71, ҳисобкунаки вазнини ихроҷ: 74, кэшкунии ҷорӣ DataBlock (%): 22
ихроҷшуда (МБ): 342, таносуби 0.33, хароҷоти изофӣ (%): 71, ҳисобкунаки вазнини ихроҷ: 75, кэшкунии ҷорӣ DataBlock (%): 22
ихроҷшуда (МБ): 342, таносуби 0.33, хароҷоти изофӣ (%): 71, ҳисобкунаки вазнини ихроҷ: 76, кэшкунии ҷорӣ DataBlock (%): 22
ихроҷшуда (МБ): 21, таносуби 0.33, сарбории изофӣ (%): -90, ҳисобкунаки эваксионии вазнин: 76, кэшкунии ҷорӣ DataBlock (%): 32
ихроҷшуда (МБ): 0, таносуби 0.0, сарбории изофӣ (%): -100, ҳисобкунаки эваксионии вазнин: 0, кэшкунии ҷорӣ DataBlock (%): 100
ихроҷшуда (МБ): 0, таносуби 0.0, сарбории изофӣ (%): -100, ҳисобкунаки эваксионии вазнин: 0, кэшкунии ҷорӣ DataBlock (%): 100
Сканҳо барои нишон додани як раванд дар шакли графики муносибати байни ду қисмати кэш лозим буданд - ягона (дар он блокҳое, ки то ҳол ҳеҷ кас дархост накардааст) ва бисёр (маълумоти "талабшуда" ҳадди аққал як маротиба). дар ин ҷо нигоҳ дошта мешаванд):
Ва ниҳоят, параметрҳо дар шакли график чӣ гуна кор мекунанд. Барои муқоиса, кэш дар аввал комилан хомӯш карда шуд, баъд ба кор андохтани HBase бо кэш ва таъхири оғози оптимизатсия то 5 дақиқа (30 давраҳои эволютсия) ба амал омад.
Рамзи пурраро дар дархости Pull пайдо кардан мумкин аст дар github.
Аммо, 300 ҳазор хондан дар як сония на ҳама чизест, ки дар ин таҷҳизот дар ин шароит фишурда мешавад. Гап дар он аст, ки вақте ба шумо лозим меояд, ки ба маълумот тавассути HDFS дастрасӣ пайдо кунед, механизми ShortCircuitCache (минбаъд SSC) истифода мешавад, ки ба шумо имкон медиҳад мустақиман ба маълумот дастрасӣ пайдо кунед ва аз ҳамкории шабакавӣ канорагирӣ кунед.
Профилсозӣ нишон дод, ки ҳарчанд ин механизм фоидаи калон медиҳад, аммо дар баъзе мавридҳо он ба монеа низ табдил меёбад, зеро қариб ҳама амалиётҳои вазнин дар дохили қулф ба амал меоянд, ки аксар вақт ба қуфлҳо оварда мерасонанд.
Бо дарки ин, мо фаҳмидем, ки мушкилотро тавассути эҷоди як қатор SSC-ҳои мустақил бартараф кардан мумкин аст:
private final ShortCircuitCache[] shortCircuitCache;
...
shortCircuitCache = new ShortCircuitCache[this.clientShortCircuitNum];
for (int i = 0; i < this.clientShortCircuitNum; i++)
this.shortCircuitCache[i] = new ShortCircuitCache(…);
Ва он гоҳ бо онҳо кор кунед, ба истиснои чорроҳаҳо аз рӯи рақами охирини офсет:
public ShortCircuitCache getShortCircuitCache(long idx) {
return shortCircuitCache[(int) (idx % clientShortCircuitNum)];
}
Акнун шумо метавонед озмоишро оғоз кунед. Барои ин, мо файлҳоро аз HDFS бо як барномаи оддии бисёрсоҳавӣ хонем. Мо параметрҳоро муқаррар мекунем:
conf.set("dfs.client.read.shortcircuit", "true");
conf.set("dfs.client.read.shortcircuit.buffer.size", "65536"); // по дефолту = 1 МБ и это сильно замедляет чтение, поэтому лучше привести в соответствие к реальным нуждам
conf.set("dfs.client.short.circuit.num", num); // от 1 до 10
Ва танҳо файлҳоро хонед:
FSDataInputStream in = fileSystem.open(path);
for (int i = 0; i < count; i++) {
position += 65536;
if (position > 900000000)
position = 0L;
int res = in.read(position, byteBuffer, 0, 65536);
}
Ин код дар риштаҳои алоҳида иҷро карда мешавад ва мо шумораи файлҳои ҳамзамон хондашаванда (аз 10 то 200 - меҳвари уфуқӣ) ва шумораи кэшҳоро (аз 1 то 10 - графика) зиёд мекунем. Меҳвари амудӣ суръатро нишон медиҳад, ки афзоиши SSC нисбат ба ҳолате, ки танҳо як кэш мавҷуд аст, медиҳад.
Чӣ тавр хондани график: 100k хондан дар блокҳои 64K бо як кэш барои анҷом 78 сония лозим аст. Дар ҳоле ки бо 5 кэш он 16 сонияро мегирад. Онхое. ~5 маротиба суръатбахшӣ вуҷуд дорад. Тавре ки шумо аз график мебинед, дар шумораи ками хонданҳои параллелӣ, таъсири он чандон назаррас нест, вақте ки хондани ришта аз 50 зиёд аст, он нақши намоёнро мебозад. Инчунин мушоҳида мешавад, ки шумораи SSCs аз 6 ва боло фоида ба таври назаррас камтар медиҳад.
Эзоҳ 1: Азбаски натиҷаҳои санҷиш хеле ноустуворанд (нигаред ба поён), 3 таҷриба гузаронида шуд ва арзишҳои натиҷавӣ ба ҳисоби миёна гирифта шуданд.
Эзоҳ 2: Афзоиши кор аз танзимоти дастрасии тасодуфӣ яксон аст, гарчанде худи дастрасӣ каме сусттар аст.
Аммо, бояд фаҳмонд, ки бар хилофи парвандаи HBase, ин суръатбахшӣ на ҳамеша ройгон аст. Дар ин ҷо мо қобилияти CPU-ро барои иҷрои кори бештар ба ҷои овезон кардан дар қуфлҳо "кушода" мекунем.
Дар ин ҷо шумо мебинед, ки дар маҷмӯъ, афзоиши шумораи кэшҳо афзоиши мутаносиби истифодаи CPU-ро медиҳад. Бо вуҷуди ин, якчанд комбинатсияи ғолиб бештар вуҷуд дорад.
Масалан, биёед ба танзимоти SSC = 3 назар андозем. Афзоиши иҷроиш дар диапазон тақрибан 3.3 маротиба аст. Дар зер натиҷаҳои ҳар се дави алоҳида оварда шудаанд.
Дар ҳоле ки истеъмоли CPU тақрибан 2.8 маротиба меафзояд. Тафовут чандон калон нест, аммо Гретаи хурдакак аллакай хушбахт аст ва шояд барои рафтан ба мактаб ва дарсҳо вақт пайдо шавад.
Ҳамин тариқ, ин ба ҳама асбобе, ки дастрасии оммавии HDFS-ро истифода мебарад (масалан, Spark ва ғайра) таъсири мусбат мерасонад, ба шарте ки рамзи барнома сабук бошад (яъне васл кардани он дар тарафи муштарии HDFS) ва қувваи ройгони CPU мавҷуд бошад. Барои санҷидани он, биёед бисанҷем, ки истифодаи якҷояи оптимизатсияи BlockCache ва танзими SSC барои хондан аз HBase чӣ натиҷа медиҳад.
Дар ин ҷо шумо мебинед, ки дар чунин шароит эффект он қадар калон нест, ки дар озмоишҳои тозашуда (хондан бе ягон коркард) нест, аммо дар ин ҷо 80K иловагӣ фишурдан мумкин аст. Якҷоя, ҳарду оптимизатсия то 4 маротиба суръатбахшӣ медиҳанд.
Барои ин оптимизатсия PR низ таҳия карда шуд , ки якҷоя карда шудааст ва ин функсия дар нашрҳои оянда дастрас хоҳад буд.
Ва дар ниҳоят, муқоиса кардани кори хониши як пойгоҳи додаи сутуни васеъи шабеҳи Cassandra ва HBase ҷолиб буд.
Барои ин, намунаҳои утилитаи стандартии санҷиши сарбории YCSB аз ду ҳост (дар маҷмӯъ 800 ришта) оғоз карда шуданд. Дар тарафи сервер - 4 мисоли RegionServer ва Cassandra дар 4 ҳост (на дар он ҷое, ки муштариён барои пешгирӣ кардани таъсири онҳо кор мекунанд). Хонишҳо аз ҷадвалҳои андоза гирифта шудаанд:
HBase - 300 ГБ дар HDFS (маълумоти хом 100 ГБ)
Кассандра - 250 ГБ (омили такрорӣ = 3)
Онхое. ҳаҷми тақрибан якхела буд (дар HBase каме бештар).
Имконоти Hbase:
dfs.client.short.circuit.num = 5 (Оптимизатсияи муштарӣ HDFS)
hbase.lru.cache.heavy.eviction.count.limit = 30 - ин маънои онро дорад, ки ямоқи пас аз 30 хориҷшавӣ ба кор шурӯъ мекунад (~5 дақиқа)
hbase.lru.cache.heavy.eviction.mb.size.limit = 300 - ҳаҷми мақсадноки кэш ва хориҷшавӣ
Гузоришҳои YCSB таҳлил ва ба диаграммаҳои Excel тартиб дода шудаанд:
Тавре ки шумо мебинед, маълумоти оптимизатсия имкон медиҳад, ки кори ин пойгоҳи додаҳо дар ин шароит баробар карда шавад ва ба 450 хондан дар як сония ноил шавад.
Мо умедворем, ки ин маълумот метавонад барои касе дар ҷараёни муборизаи ҳаяҷонбахш барои иҷроиш муфид бошад.
Манбаъ: will.com