HBase dan foydalanish nazariyasi va amaliyoti

Hayrli kun! Mening ismim Danil Lipovoy, Sbertechdagi jamoamiz HBase-dan operatsion ma'lumotlarni saqlash sifatida foydalanishni boshladi. Uni o'rganish jarayonida men tizimlashtirish va tavsiflashni xohlagan tajriba to'plandi (ko'pchilik uchun foydali bo'ladi deb umid qilamiz). Quyidagi barcha tajribalar HBase 1.2.0-cdh5.14.2 va 2.0.0-cdh6.0.0-beta1 versiyalari bilan amalga oshirildi.

1. Umumiy arxitektura
2. HBASE-ga ma'lumotlarni yozish
3. HBASE ma'lumotlarini o'qish
4. Ma'lumotlarni keshlash
5. MultiGet/MultiPut ma'lumotlarini ommaviy qayta ishlash
6. Jadvallarni hududlarga bo'lish strategiyasi (bo'lish)
7. Xatolarga chidamlilik, ixchamlashtirish va ma'lumotlarning joylashishi
8. Sozlamalar va ishlash
9. Stress testi
10. topilmalar

1. Umumiy arxitektura

Zaxira ustasi ZooKeeper tugunidagi faolning yurak urishini tinglaydi va agar yo'qolsa, master funktsiyalarini o'z zimmasiga oladi.

2. HBASE ga ma'lumotlarni yozing

Birinchidan, eng oddiy holatni ko'rib chiqamiz - put(rowkey) yordamida jadvalga kalit-qiymat ob'ektini yozish. Mijoz avval hbase:meta jadvalini saqlaydigan Root Region Server (RRS) qayerda joylashganligini aniqlashi kerak. U bu ma'lumotni ZooKeeper'dan oladi. Shundan so'ng u RRS ga kiradi va hbase:meta jadvalini o'qiydi, undan qaysi RegionServer (RS) qiziqtirgan jadvalda berilgan qator uchun ma'lumotlarni saqlash uchun mas'ul ekanligi haqidagi ma'lumotlarni chiqaradi. Kelajakda foydalanish uchun meta-jadval mijoz tomonidan keshlanadi va shuning uchun keyingi qo'ng'iroqlar tezroq, to'g'ridan-to'g'ri RS ga o'tadi.

Keyinchalik, RS so'rovni qabul qilib, birinchi navbatda uni WriteAheadLog (WAL) ga yozadi, bu avariya holatida tiklash uchun zarurdir. Keyin ma'lumotlarni MemStore-ga saqlaydi. Bu ma'lum bir hudud uchun tartiblangan kalitlar to'plamini o'z ichiga olgan xotiradagi bufer. Jadvalni hududlarga (bo'limlarga) bo'lish mumkin, ularning har birida alohida kalitlar to'plami mavjud. Bu sizga yuqori ishlashga erishish uchun hududlarni turli serverlarga joylashtirish imkonini beradi. Biroq, bu bayonotning ravshanligiga qaramay, bu hamma hollarda ham ish bermasligini keyinroq ko'ramiz.

Yozuvni MemStore-ga joylashtirgandan so'ng, mijozga yozuv muvaffaqiyatli saqlanganligi haqida javob qaytariladi. Biroq, aslida u faqat buferda saqlanadi va diskka ma'lum vaqt o'tgandan keyin yoki yangi ma'lumotlar bilan to'ldirilgandan keyingina tushadi.

"O'chirish" operatsiyasini bajarishda ma'lumotlar jismonan o'chirilmaydi. Ular shunchaki o'chirilgan deb belgilanadi va yo'q qilishning o'zi 7-bandda batafsil tavsiflangan asosiy ixcham funktsiyani chaqirish paytida sodir bo'ladi.

HFile formatidagi fayllar HDFS-da to'planadi va vaqti-vaqti bilan kichik ixcham jarayon ishga tushiriladi, bu esa kichik fayllarni hech narsani o'chirmasdan kattaroq fayllarga birlashtiradi. Vaqt o'tishi bilan bu faqat ma'lumotlarni o'qiyotganda paydo bo'ladigan muammoga aylanadi (bu haqda biroz keyinroq qaytamiz).

Yuqorida tavsiflangan yuklash jarayoniga qo'shimcha ravishda, bu ma'lumotlar bazasining eng kuchli tomoni - BulkLoad bo'lgan ancha samarali protsedura mavjud. Bu biz HFiles-ni mustaqil ravishda shakllantirishimiz va ularni diskka qo'yishimiz bilan bog'liq, bu bizga mukammal o'lchash va juda yaxshi tezlikka erishish imkonini beradi. Aslida, bu erda cheklov HBase emas, balki apparatning imkoniyatlari. Quyida 16 RegionServer va 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 ip), HBase 1.2.0-cdh5.14.2 versiyasidan iborat klasterda yuklash natijalari keltirilgan.

Bu erda jadvaldagi bo'limlar (mintaqalar) sonini, shuningdek, Spark ijrochilarni ko'paytirish orqali biz yuklab olish tezligining oshishini ko'rishingiz mumkin. Bundan tashqari, tezlik yozish hajmiga bog'liq. Katta bloklar MB/sek tezlikni oshiradi, kichik bloklar esa vaqt birligiga kiritilgan yozuvlar sonini oshiradi, qolgan barcha narsalar tengdir.

Bundan tashqari, siz bir vaqtning o'zida ikkita jadvalga yuklashni boshlashingiz va ikki barobar tezlikni olishingiz mumkin. Quyida ikkita jadvalga bir vaqtning o'zida 10 KB bloklarni yozish har birida taxminan 600 MB/sek tezlikda (jami 1275 MB/sek) sodir bo'lishini ko'rishingiz mumkin, bu bitta jadvalga yozish tezligi 623 MB/sek.ga to'g'ri keladi (qarang. Yuqoridagi № 11)

Ammo 50 KB yozuvlar bilan ikkinchi ishga tushirish yuklab olish tezligi biroz o'sib borayotganini ko'rsatadi, bu uning chegara qiymatlariga yaqinlashayotganini ko'rsatadi. Shu bilan birga, shuni yodda tutish kerakki, HBASE-ning o'zida deyarli hech qanday yuk yaratilmaydi, undan talab qilinadigan narsa birinchi navbatda hbase:meta-dan ma'lumotlarni berish va HFiles-ni qo'ygandan so'ng, BlockCache ma'lumotlarini qayta o'rnatish va saqlash. Diskdagi MemStore buferi, agar u bo'sh bo'lmasa.

3. HBASE dan ma'lumotlarni o'qish

Agar mijozda hbase:meta dan barcha ma'lumotlar mavjud deb hisoblasak (2-bandga qarang), so'rov to'g'ridan-to'g'ri kerakli kalit saqlanadigan RS ga o'tadi. Birinchidan, qidiruv MemCache-da amalga oshiriladi. Ma'lumotlar bor yoki yo'qligidan qat'i nazar, qidiruv BlockCache buferida va kerak bo'lganda HFiles-da ham amalga oshiriladi. Agar ma'lumotlar faylda topilgan bo'lsa, u BlockCache-ga joylashtiriladi va keyingi so'rovda tezroq qaytariladi. Bloom filtridan foydalanish tufayli HFile-da qidirish nisbatan tez, ya'ni. oz miqdordagi ma'lumotlarni o'qib chiqib, u darhol ushbu faylda kerakli kalit mavjudligini aniqlaydi va agar bo'lmasa, keyingisiga o'tadi.

Ushbu uchta manbadan ma'lumotlarni olgan RS javob beradi. Xususan, agar mijoz versiyani talab qilgan bo'lsa, u bir vaqtning o'zida ob'ektning bir nechta topilgan versiyasini uzatishi mumkin.

4. Ma'lumotlarni keshlash

MemStore va BlockCache buferlari ajratilgan yig'ma RS xotirasining 80% ni egallaydi (qolganlari RS xizmat vazifalari uchun ajratilgan). Agar odatiy foydalanish rejimi shunday bo'lsa, jarayonlar bir xil ma'lumotlarni yozadi va darhol o'qiydi, unda BlockCache-ni qisqartirish va MemStore-ni ko'paytirish mantiqan to'g'ri keladi, chunki Ma'lumotlarni yozish keshga o'qish uchun tushmasa, BlockCache kamroq ishlatiladi. BlockCache buferi ikki qismdan iborat: LruBlockCache (har doim to'plangan) va BucketCache (odatda to'pdan tashqarida yoki SSDda). BucketCache-dan o'qish so'rovlari ko'p bo'lganda va ular LruBlockCache-ga mos kelmasa ishlatilishi kerak, bu esa Garbage Collector-ning faol ishlashiga olib keladi. Shu bilan birga, siz o'qish keshini ishlatishdan unumdorlikning tubdan oshishini kutmasligingiz kerak, ammo biz bunga 8-bandda qaytamiz.

Butun RS uchun bitta BlockCache mavjud va har bir jadval uchun bitta MemStore mavjud (har bir ustun oilasi uchun bittadan).

qanday tasvirlangan nazariy jihatdan, yozishda ma'lumotlar keshga tushmaydi va haqiqatan ham jadval uchun CACHE_DATA_ON_WRITE va RS uchun "Write ma'lumotlarini keshlash" parametrlari yolg'onga o'rnatiladi. Biroq, amalda, agar biz MemStore-ga ma'lumot yozsak, keyin uni diskka tozalasak (shunday qilib uni tozalaymiz), keyin olingan faylni o'chirib tashlasak, keyin olish so'rovini bajarish orqali biz ma'lumotlarni muvaffaqiyatli qabul qilamiz. Bundan tashqari, agar siz BlockCache-ni butunlay o'chirib qo'ysangiz va jadvalni yangi ma'lumotlar bilan to'ldirsangiz ham, keyin MemStore-ni diskka qayta o'rnatsangiz, ularni o'chirib tashlasangiz va boshqa seansdan so'rasangiz ham, ular biron bir joydan olinadi. Shunday qilib, HBase nafaqat ma'lumotlarni, balki sirli sirlarni ham saqlaydi.

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" parametri noto'g'ri o'rnatilgan. Agar sizda biron bir fikr bo'lsa, sharhlarda muhokama qilishga xush kelibsiz.

5. MultiGet/MultiPut ma'lumotlarini ommaviy qayta ishlash

Yagona so'rovlarni qayta ishlash (Get/Put/Delete) juda qimmat operatsiya, shuning uchun iloji bo'lsa, ularni Ro'yxat yoki Ro'yxatga birlashtirishingiz kerak, bu esa unumdorlikni sezilarli darajada oshirish imkonini beradi. Bu, ayniqsa, yozish operatsiyasi uchun to'g'ri keladi, lekin o'qish paytida quyidagi tuzoq mavjud. Quyidagi grafikda MemStore’dan 50 000 ta yozuvni o‘qish vaqti ko‘rsatilgan. O'qish bir ipda amalga oshirildi va gorizontal o'q so'rovdagi kalitlar sonini ko'rsatadi. Bu erda siz bitta so'rovda mingta kalitga ko'payganda, bajarilish vaqti pasayganini ko'rishingiz mumkin, ya'ni. tezligi ortadi. Biroq, sukut bo'yicha MSLAB rejimi yoqilgan bo'lsa, ushbu chegaradan keyin ishlashning tubdan pasayishi boshlanadi va yozuvdagi ma'lumotlar miqdori qanchalik katta bo'lsa, ish vaqti shunchalik uzoqroq bo'ladi.

Sinovlar virtual mashinada, 8 yadroli, HBase 2.0.0-cdh6.0.0-beta1 versiyasida o'tkazildi.

MSLAB rejimi yangi va eski avlod ma'lumotlarini aralashtirish natijasida yuzaga keladigan yig'ma parchalanishni kamaytirish uchun mo'ljallangan. Vaqtinchalik yechim sifatida, MSLAB yoqilganda, ma'lumotlar nisbatan kichik hujayralarga (bo'laklarga) joylashtiriladi va bo'laklarga bo'linadi. Natijada, so'ralgan ma'lumotlar paketidagi hajm ajratilgan hajmdan oshib ketganda, unumdorlik keskin pasayadi. Boshqa tomondan, ushbu rejimni o'chirish ham tavsiya etilmaydi, chunki bu intensiv ma'lumotlarni qayta ishlash paytida GC tufayli to'xtashlarga olib keladi. Yaxshi yechim o'qish bilan bir vaqtda qo'yish orqali faol yozishda hujayra hajmini oshirishdir. Shuni ta'kidlash kerakki, agar siz yozib olgandan so'ng, MemStore-ni diskka qayta o'rnatadigan flush buyrug'ini bajarsangiz yoki BulkLoad yordamida yuklasangiz, muammo yuzaga kelmaydi. Quyidagi jadvalda MemStore’dan kattaroq (va bir xil miqdorda) ma’lumotlar so‘rovlari sekinlashuvga olib kelishi ko‘rsatilgan. Biroq, bo'lak hajmini oshirish orqali biz ishlov berish vaqtini normal holatga qaytaramiz.

Bo'lak hajmini oshirishdan tashqari, ma'lumotlarni mintaqalar bo'yicha ajratish yordam beradi, ya'ni. stol bo'linishi. Bu har bir mintaqaga kamroq so'rovlar kelishiga olib keladi va agar ular hujayra ichiga sig'sa, javob yaxshi bo'lib qoladi.

6. Jadvallarni hududlarga bo'lish strategiyasi (bo'lish)

HBase kalit-qiymatni saqlash vositasi bo'lganligi sababli va bo'linish kalit orqali amalga oshiriladi, shuning uchun ma'lumotlarni barcha mintaqalar bo'ylab teng ravishda taqsimlash juda muhimdir. Misol uchun, bunday jadvalni uch qismga bo'lish ma'lumotlarning uchta mintaqaga bo'linishiga olib keladi:

Keyinchalik yuklangan ma'lumotlar, masalan, uzoq qiymatlarga o'xshasa, bu keskin sekinlashuvga olib keladi, ularning aksariyati bir xil raqamdan boshlanadi, masalan:

1000001
1000002
...
1100003

Kalitlar bayt massivi sifatida saqlanganligi sababli, ularning barchasi bir xil boshlanadi va ushbu kalitlar oralig'ini saqlaydigan bir xil №1 mintaqaga tegishli. Bir nechta bo'linish strategiyalari mavjud:

HexStringSplit - kalitni "00000000" => "FFFFFFFF" oralig'ida o'n oltilik kodlangan qatorga aylantiradi va chap tomonda nol bilan to'ldiradi.

UniformSplit - Kalitni "00" => "FF" oralig'ida o'n oltilik kodlash va o'ng tomonda nol bilan to'ldirish bilan bayt massiviga aylantiradi.

Bundan tashqari, siz bo'lish uchun har qanday diapazonni yoki tugmalar to'plamini belgilashingiz va avtomatik bo'linishni sozlashingiz mumkin. Biroq, eng oddiy va eng samarali usullardan biri bu UniformSplit va xeshni birlashtirishdan foydalanish, masalan, kalitni CRC32(rowkey) funksiyasi va qator tugmachasi orqali ishga tushirishning eng muhim bayt juftligi:

hash + qator tugmasi

Keyin barcha ma'lumotlar mintaqalar bo'ylab teng taqsimlanadi. O'qish paytida dastlabki ikki bayt shunchaki o'chiriladi va asl kalit qoladi. RS, shuningdek, mintaqadagi ma'lumotlar va kalitlar miqdorini nazorat qiladi va agar chegaralar oshib ketgan bo'lsa, uni avtomatik ravishda qismlarga ajratadi.

7. Xatolarga chidamlilik va ma'lumotlarning joylashishi

Har bir kalit to'plami uchun faqat bitta mintaqa mas'ul bo'lganligi sababli, RS ishdan chiqishi yoki o'chirish bilan bog'liq muammolarni hal qilish HDFSda barcha kerakli ma'lumotlarni saqlashdir. RS tushganda, usta buni ZooKeeper tugunida yurak urishi yo'qligi orqali aniqlaydi. Keyin u xizmat ko'rsatilgan hududni boshqa RS ga tayinlaydi va HFiles tarqatilgan fayl tizimida saqlanganligi sababli, yangi egasi ularni o'qiydi va ma'lumotlarga xizmat ko'rsatishni davom ettiradi. Biroq, ba'zi ma'lumotlar MemStore-da bo'lishi mumkinligi va HFiles-ga kirishga ulgurmaganligi sababli, operatsiyalar tarixini tiklash uchun HDFS-da ham saqlanadigan WAL ishlatiladi. O'zgarishlar qo'llanilgandan so'ng, RS so'rovlarga javob bera oladi, ammo harakat ba'zi ma'lumotlar va ularga xizmat ko'rsatadigan jarayonlar turli tugunlarda tugashiga olib keladi, ya'ni. joylashuvi kamayib bormoqda.

Muammoni hal qilish katta siqilishdir - bu protsedura fayllarni ular uchun mas'ul bo'lgan tugunlarga (ularning hududlari joylashgan) o'tkazadi, buning natijasida ushbu protsedura davomida tarmoq va disklardagi yuk keskin ortadi. Biroq, kelajakda ma'lumotlarga kirish sezilarli darajada tezlashadi. Bundan tashqari, major_compaction barcha HFilelarni mintaqadagi bitta faylga birlashtirishni amalga oshiradi va jadval sozlamalariga qarab ma'lumotlarni tozalaydi. Misol uchun, siz saqlanishi kerak bo'lgan ob'ekt versiyalari sonini yoki ob'ekt jismoniy o'chirilgandan keyin ishlash muddatini belgilashingiz mumkin.

Ushbu protsedura HBase ning ishlashiga juda ijobiy ta'sir ko'rsatishi mumkin. Quyidagi rasmda faol ma'lumotlarni yozib olish natijasida unumdorlik qanday pasayganligi ko'rsatilgan. Bu yerda siz 40 ta mavzu bir jadvalga qanday yozganini va 40 ta ip bir vaqtning o'zida ma'lumotlarni o'qiganini ko'rishingiz mumkin. Yozuvchi iplar ko'proq va ko'proq HFiles hosil qiladi, ularni boshqa mavzular o'qiydi. Natijada, ko'proq va ko'proq ma'lumotlarni xotiradan olib tashlash kerak va oxir-oqibat GC ishlay boshlaydi, bu amalda barcha ishlarni falaj qiladi. Katta siqishni ishga tushirish natijasida hosil bo'lgan qoldiqlarni tozalash va hosildorlikni tiklashga olib keldi.

Sinov 3 DataNode va 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 ip) da amalga oshirildi. HBase versiyasi 1.2.0-cdh5.14.2

Shuni ta'kidlash kerakki, asosiy siqilish "jonli" jadvalda ishga tushirildi, unda ma'lumotlar faol ravishda yoziladi va o'qiladi. Internetda bu ma'lumotlarni o'qishda noto'g'ri javobga olib kelishi mumkinligi haqida bayonot bor edi. Tekshirish uchun yangi ma'lumotlarni yaratadigan va ularni jadvalga yozadigan jarayon ishga tushirildi. Shundan so'ng men darhol o'qib chiqdim va natijada olingan qiymat yozilgan narsaga to'g'ri keladimi yoki yo'qligini tekshirdim. Ushbu jarayon davom etayotganda, katta siqilish taxminan 200 marta bajarilgan va bitta nosozlik qayd etilmagan. Ehtimol, muammo kamdan-kam hollarda va faqat yuqori yuklanish paytida paydo bo'ladi, shuning uchun yozish va o'qish jarayonlarini rejalashtirilgan tarzda to'xtatish va bunday GC kamchiliklarini oldini olish uchun tozalashni amalga oshirish xavfsizroqdir.

Bundan tashqari, katta siqilish MemStore holatiga ta'sir qilmaydi, uni diskga o'chirish va ixchamlashtirish uchun siz flush (connection.getAdmin().flush(TableName.valueOf(tblName))) dan foydalanishingiz kerak.

8. Sozlamalar va ishlash

Yuqorida aytib o'tilganidek, HBase o'zining eng katta muvaffaqiyatini BulkLoadni bajarishda hech narsa qilish kerak bo'lmagan joyda ko'rsatadi. Biroq, bu ko'pchilik tizimlar va odamlar uchun amal qiladi. Biroq, bu vosita ma'lumotlarni katta bloklarda ommaviy saqlash uchun ko'proq mos keladi, agar jarayon bir nechta raqobatdosh o'qish va yozish so'rovlarini talab qilsa, yuqorida tavsiflangan Get va Put buyruqlaridan foydalaniladi. Optimal parametrlarni aniqlash uchun jadval parametrlari va sozlamalarining turli kombinatsiyalari bilan ishga tushirish amalga oshirildi:

• 10 ta ip bir vaqtning o'zida 3 marta ketma-ket ishga tushirildi (keling, buni iplar bloki deb ataymiz).
• Blokdagi barcha iplarning ishlash vaqti o'rtacha hisoblangan va blokning ishlashining yakuniy natijasi edi.
• Barcha mavzular bir xil jadval bilan ishlagan.
• Ip blokining har bir boshlanishidan oldin, katta siqilish amalga oshirildi.
• Har bir blok quyidagi operatsiyalardan faqat bittasini bajardi:

- Qo'ying
— Oling
—Olish+qo‘yish

• Har bir blok o'z ishining 50 000 iteratsiyasini amalga oshirdi.
• Yozuv blokining hajmi 100 bayt, 1000 bayt yoki 10000 bayt (tasodifiy).
• Bloklar turli xil miqdordagi so'ralgan kalitlar bilan ishga tushirildi (bitta kalit yoki 10).
• Bloklar turli xil stol sozlamalari ostida ishladi. O'zgartirilgan parametrlar:

— BlockCache = yoqilgan yoki o'chirilgan
- BlockSize = 65 KB yoki 16 KB
- Bo'limlar = 1, 5 yoki 30
— MSLAB = yoqilgan yoki o'chirilgan

Shunday qilib, blok quyidagicha ko'rinadi:

a. MSLAB rejimi yoqilgan/o'chirilgan.
b. Quyidagi parametrlar o'rnatilgan jadval yaratildi: BlockCache = true/none, BlockSize = 65/16 Kb, Partition = 1/5/30.
c. Siqish GZ ga o'rnatildi.
d. Ushbu jadvalga 10/1/10 baytlik yozuvlar bilan 100/1000 put/get/get+put operatsiyalarini bajarib, ketma-ket 10000 50 so'rovni (tasodifiy kalitlar) bajaradigan 000 ta ip bir vaqtning o'zida ishga tushirildi.
e. d nuqtasi uch marta takrorlandi.
f. Barcha iplarning ishlash muddati o'rtacha hisoblangan.

Barcha mumkin bo'lgan kombinatsiyalar sinovdan o'tkazildi. Rekord hajmi kattalashgan sari tezlik pasayib ketishi yoki keshlashni o'chirib qo'yish sekinlashuvga olib kelishini taxmin qilish mumkin. Biroq, maqsad har bir parametrning ta'siri darajasi va ahamiyatini tushunish edi, shuning uchun to'plangan ma'lumotlar chiziqli regressiya funktsiyasining kiritilishiga kiritildi, bu esa t-statistika yordamida ahamiyatni baholash imkonini beradi. Quyida Put operatsiyalarini bajaruvchi bloklarning natijalari keltirilgan. 2*2*3*2*3 kombinatsiyalarning to'liq to'plami = 144 variant + 72 tk. ba'zilari ikki marta qilingan. Shunday qilib, jami 216 ta yugurish mavjud:

Sinov 3 ta DataNode va 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 ip) dan iborat mini-klasterda oʻtkazildi. HBase versiyasi 1.2.0-cdh5.14.2.

3.7 sekundlik eng yuqori kiritish tezligi MSLAB rejimi o'chirilgan holda, bitta bo'limli stolda, BlockCache yoqilgan, BlockSize = 16, 100 baytlik yozuvlar, har bir paketga 10 dona bilan erishildi.
82.8 soniyalik eng past kiritish tezligi MSLAB rejimi yoqilgan, bitta bo'limli jadvalda, BlockCache yoqilgan, BlockSize = 16, har biri 10000 1 baytdan iborat yozuvlar bilan olingan.

Endi modelni ko'rib chiqaylik. Biz R2 ga asoslangan modelning yaxshi sifatini ko'ramiz, ammo bu erda ekstrapolyatsiya kontrendikedir ekanligi aniq. Parametrlar o'zgarganda tizimning haqiqiy harakati chiziqli bo'lmaydi, bu model bashorat qilish uchun emas, balki berilgan parametrlar doirasida nima sodir bo'lganligini tushunish uchun kerak. Misol uchun, bu erda biz Talaba mezonidan BlockSize va BlockCache parametrlari Put operatsiyasi uchun muhim emasligini ko'ramiz (bu odatda oldindan taxmin qilinadigan):

Ammo bo'limlar sonini ko'paytirish unumdorlikning pasayishiga olib kelishi biroz kutilmagan (biz BulkLoad bilan bo'limlar sonini ko'paytirishning ijobiy ta'sirini allaqachon ko'rganmiz), ammo tushunarli. Birinchidan, qayta ishlash uchun siz bitta emas, balki 30 ta hududga so'rovlar yaratishingiz kerak va ma'lumotlar hajmi unchalik katta emaski, bu daromad keltiradi. Ikkinchidan, umumiy ish vaqti eng sekin RS bilan belgilanadi va DataNodlar soni RS sonidan kamroq bo'lganligi sababli, ba'zi hududlar nol joylashuvga ega. Keling, eng yaxshi beshlikka qaraylik:

Endi Get bloklarini bajarish natijalarini baholaymiz:

Bo'limlar soni ahamiyatini yo'qotdi, bu, ehtimol, ma'lumotlarning yaxshi keshlanganligi va o'qish keshi eng muhim (statistik) parametr ekanligi bilan izohlanadi. Tabiiyki, so'rovdagi xabarlar sonini ko'paytirish ham ishlash uchun juda foydali. Eng yuqori ball:

Va nihoyat, avval olish va keyin qo'yishni amalga oshirgan blokning modelini ko'rib chiqaylik:

Bu erda barcha parametrlar muhim ahamiyatga ega. Va rahbarlarning natijalari:

9. Yuklash sinovi

Va nihoyat, biz ko'proq yoki kamroq munosib yukni ishga tushiramiz, lekin sizda solishtirish uchun biror narsa bo'lsa, har doim qiziqroq bo'ladi. Cassandra-ning asosiy ishlab chiqaruvchisi DataStax veb-saytida mavjud Natijalar HBase 0.98.6-1 versiyasini o'z ichiga olgan bir qator NoSQL xotiralarining NT. Yuklash 40 ta ip, ma'lumotlar hajmi 100 bayt, SSD disklar tomonidan amalga oshirildi. O'qish-O'zgartirish-Yozish amallarini sinovdan o'tkazish natijasi quyidagi natijalarni ko'rsatdi.

Men tushunganimdek, o'qish 100 ta yozuv bloklarida amalga oshirildi va 16 HBase tugunlari uchun DataStax testi soniyada 10 ming operatsiyani ko'rsatdi.

Bizning klasterimiz ham 16 ta tugunga ega ekani baxtiyor, lekin har birida 64 ta yadro (iplar) borligi unchalik "baxtli" emas, DataStax testida esa atigi 4 ta. Boshqa tomondan, ularda SSD disklari bor, bizda esa HDDlar mavjud. yoki undan ko'p HBase ning yangi versiyasi va protsessordan foydalanish yuk paytida deyarli sezilarli darajada oshmadi (vizual ravishda 5-10 foizga). Biroq, keling, ushbu konfiguratsiyadan foydalanishni boshlashga harakat qilaylik. Standart jadval sozlamalari, o'qish 0 dan 50 milliongacha bo'lgan kalit diapazonida tasodifiy ravishda amalga oshiriladi (ya'ni, har safar yangi). Jadvalda 50 ta bo'limga bo'lingan 64 million yozuv mavjud. Kalitlar crc32 yordamida xeshlangan. Jadval sozlamalari standart, MSLAB yoqilgan. 40 ta ipni ishga tushirgandan so'ng, har bir ip 100 ta tasodifiy kalitlar to'plamini o'qiydi va yaratilgan 100 baytni darhol ushbu kalitlarga yozadi.

Stend: 16 DataNode va 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 ip). HBase versiyasi 1.2.0-cdh5.14.2.

O'rtacha natija sekundiga 40 ming operatsiyaga yaqinroq, bu DataStax testiga qaraganda ancha yaxshi. Biroq, eksperimental maqsadlar uchun siz shartlarni biroz o'zgartirishingiz mumkin. Barcha ishlar faqat bitta stolda, shuningdek, faqat noyob kalitlarda amalga oshirilishi dargumon. Faraz qilaylik, asosiy yukni yaratadigan ma'lum bir "issiq" kalitlar to'plami mavjud. Shuning uchun, keling, kattaroq yozuvlar (10 KB) bilan yuk yaratishga harakat qilaylik, shuningdek, 100 ta to'plamda, 4 xil jadvalda va so'ralgan kalitlar oralig'ini 50 minggacha cheklab qo'ying.Quyidagi grafikda 40 ta ipning ishga tushirilishi ko'rsatilgan, har bir mavzu o'qiydi. 100 ta tugmalar to'plami va darhol ushbu tugmachalarga tasodifiy 10 KB yozadi.

Stend: 16 DataNode va 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 ip). HBase versiyasi 1.2.0-cdh5.14.2.

Yuklash paytida, yuqorida ko'rsatilgandek, katta siqilish bir necha marta ishga tushirildi, bu protsedurasiz ishlash asta-sekin pasayadi, ammo bajarish paytida qo'shimcha yuk ham paydo bo'ladi. Kamchiliklar turli sabablarga ko'ra yuzaga keladi. Ba'zan iplar ishlashni tugatdi va ular qayta ishga tushirilganda pauza bo'ldi, ba'zida uchinchi tomon ilovalari klasterda yuk yaratdi.

O'qish va darhol yozish HBase uchun eng qiyin ish stsenariylaridan biridir. Agar siz faqat kichik qo'yish so'rovlarini qilsangiz, masalan, 100 bayt, ularni 10-50 ming dona paketlarga birlashtirsangiz, soniyada yuz minglab operatsiyalarni bajarishingiz mumkin va vaziyat faqat o'qish uchun so'rovlar bilan o'xshashdir. Shuni ta'kidlash kerakki, natijalar DataStax tomonidan olingan natijalardan tubdan yaxshiroq, eng muhimi, 50 ming blokdagi so'rovlar tufayli.

Stend: 16 DataNode va 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 ip). HBase versiyasi 1.2.0-cdh5.14.2.

10. Xulosalar

Ushbu tizim juda moslashuvchan tarzda tuzilgan, ammo ko'p sonli parametrlarning ta'siri hali ham noma'lum bo'lib qolmoqda. Ulardan ba'zilari sinovdan o'tkazildi, ammo natijada olingan test to'plamiga kiritilmadi. Masalan, dastlabki tajribalar tasodifiy yaratilgan ma'lumotlar uchun tushunarli bo'lgan qo'shni hujayralardagi qiymatlar yordamida ma'lumotlarni kodlaydigan DATA_BLOCK_ENCODING kabi parametrning ahamiyatsizligini ko'rsatdi. Agar siz ko'p sonli takroriy ob'ektlardan foydalansangiz, daromad sezilarli bo'lishi mumkin. Umuman olganda, HBase juda jiddiy va puxta o'ylangan ma'lumotlar bazasi haqida taassurot qoldiradi, deb aytishimiz mumkin, bu katta ma'lumotlar bloklari bilan operatsiyalarni bajarishda juda samarali bo'lishi mumkin. Ayniqsa, o'qish va yozish jarayonlarini vaqtida ajratish mumkin bo'lsa.

Agar sizning fikringizcha, etarlicha oshkor etilmagan biror narsa bo'lsa, men sizga batafsilroq aytib berishga tayyorman. Biz sizni tajribangizni baham ko'rishga yoki biror narsaga rozi bo'lmasangiz, muhokama qilishga taklif qilamiz.

Manba: www.habr.com