kirish
"O'rningizda qolish uchun imkon qadar tez yugurishingiz kerak,
biror joyga borish uchun esa kamida ikki baravar tez yugurish kerak!”
(c) Alisa ajoyibotlar mamlakatida
Biroz vaqt oldin mendan ma'ruza o'qishni so'rashdi tahlilchilar bizning kompaniyamiz ma'lumotlar modellarini loyihalash mavzusida, chunki loyihalarda uzoq vaqt (ba'zan bir necha yil) o'tirib, biz IT texnologiyalari dunyosida atrofimizda sodir bo'layotgan voqealarni ko'zdan kechiramiz. Bizning kompaniyamizda (bu shunday bo'ladi) ko'pgina loyihalar NoSQL ma'lumotlar bazalaridan foydalanmaydi (hech bo'lmaganda hozircha), shuning uchun men o'z ma'ruzamda HBase misolidan foydalanib, ularga alohida e'tibor qaratdim va material taqdimotini o'shalarga yo'naltirishga harakat qildim. ularni hech qachon ishlatmaganlar ishlagan. Xususan, men bir necha yil oldin o'qigan misolimdan foydalanib, ma'lumotlar modeli dizaynining ba'zi xususiyatlarini tasvirlab berdim . Misollarni tahlil qilishda men asosiy g'oyalarni tinglovchilarga yaxshiroq etkazish uchun bir xil muammoni hal qilishning bir nechta variantlarini taqqosladim.
Yaqinda "hech narsadan" o'zimga savol berdim (ayniqsa, may oyining karantindagi uzoq dam olish kunlari bunga yordam beradi), nazariy hisob-kitoblar amaliyotga qanchalik mos keladi? Aslida, ushbu maqolaning g'oyasi shunday tug'ilgan. Bir necha kun davomida NoSQL bilan ishlagan dasturchi undan yangi hech narsa o'rganmasligi mumkin (shuning uchun maqolaning yarmini darhol o'tkazib yuborishi mumkin). Lekin uchun tahlilchilarNoSQL bilan hali yaqindan ishlamaganlar uchun HBase uchun ma'lumotlar modellarini loyihalash xususiyatlari haqida asosiy tushunchaga ega bo'lish uchun foydali bo'lishiga ishonaman.
Misol tahlili
Menimcha, NoSQL ma'lumotlar bazalaridan foydalanishni boshlashdan oldin yaxshilab o'ylab, ijobiy va salbiy tomonlarini tortish kerak. Ko'pincha muammoni an'anaviy relyatsion DBMSlar yordamida hal qilish mumkin. Shuning uchun muhim sabablarsiz NoSQL dan foydalanmaslik yaxshiroqdir. Agar siz hali ham NoSQL ma'lumotlar bazasidan foydalanishga qaror qilsangiz, bu erda dizayn yondashuvlari biroz boshqacha ekanligini hisobga olishingiz kerak. Ayniqsa, ularning ba'zilari ilgari faqat relyatsion DBMSlar bilan shug'ullanganlar uchun g'ayrioddiy bo'lishi mumkin (mening kuzatishlarimga ko'ra). Shunday qilib, "munosabat" dunyosida biz odatda muammoli sohani modellashtirishdan boshlaymiz va shundan keyingina, agar kerak bo'lsa, modelni normalizatsiya qilamiz. NoSQL da biz ma'lumotlar bilan ishlash uchun kutilgan stsenariylarni darhol hisobga olish kerak va dastlab ma'lumotlarni normalizatsiya qilish. Bundan tashqari, bir qator boshqa farqlar mavjud, ular quyida muhokama qilinadi.
Keling, biz ishlashni davom ettiradigan quyidagi "sintetik" muammoni ko'rib chiqaylik:
Ba'zi mavhum ijtimoiy tarmoq foydalanuvchilarining do'stlari ro'yxati uchun saqlash tuzilmasini loyihalash kerak. Soddalashtirish uchun biz barcha ulanishlarimiz yo'naltirilgan deb hisoblaymiz (Linkedin emas, balki Instagramda bo'lgani kabi). Tuzilish sizga samarali tarzda imkon berishi kerak:
- A foydalanuvchi B foydalanuvchisini o'qiydimi degan savolga javob bering (o'qish namunasi)
- A foydalanuvchisi B foydalanuvchisidan obuna bo'lgan/obunani bekor qilgan taqdirda ulanishlarni qo'shish/o'chirishga ruxsat berish (ma'lumotlarni o'zgartirish shabloni)
Albatta, muammoni hal qilishning ko'plab variantlari mavjud. Muntazam relyatsion ma'lumotlar bazasida biz shunchaki munosabatlar jadvalini tuzamiz (agar biz, masalan, foydalanuvchi guruhini saqlashimiz kerak bo'lsa: oila, ish va h.k., shu "do'st" ni o'z ichiga olgan holda xarakterlanadi) va optimallashtirish uchun kirish tezligi indekslarni/bo'limlarni qo'shadi. Ehtimol, yakuniy jadval quyidagicha ko'rinadi:
user_id
friend_id
Vasya
Akbar
Vasya
Olya
bundan keyin aniqlik va yaxshiroq tushunish uchun identifikatorlar o'rniga ismlarni ko'rsataman
HBase holatida biz buni bilamiz:
- to'liq jadvalni skanerlashga olib kelmaydigan samarali qidiruv mumkin faqat kalit bilan
- aslida, shuning uchun bunday ma'lumotlar bazalariga ko'pchilik uchun tanish bo'lgan SQL so'rovlarini yozish yomon fikrdir; texnik jihatdan, albatta, siz bir xil Impala-dan HBase-ga qo'shilish va boshqa mantiq bilan SQL so'rovini yuborishingiz mumkin, ammo bu qanchalik samarali bo'ladi ...
Shuning uchun biz foydalanuvchi identifikatoridan kalit sifatida foydalanishga majburmiz. Va "do'stlar identifikatorlarini qayerda va qanday saqlash kerak?" mavzusidagi birinchi fikrim. ehtimol ularni ustunlarda saqlash g'oyasi. Ushbu eng aniq va "sodda" variant shunga o'xshash ko'rinadi (keling, uni chaqiraylik Variant 1 (standart)qo'shimcha ma'lumot uchun):
RowKey
Ustunlar
Vasya
1: Petya
2: Olya
3: Dasha
Akbar
1: Masha
2: Vasya
Bu erda har bir satr bitta tarmoq foydalanuvchisiga to'g'ri keladi. Ustunlarning nomlari bor: 1, 2, ... - do'stlar soniga ko'ra va do'stlarning identifikatorlari ustunlarda saqlanadi. Shuni ta'kidlash kerakki, har bir satrda turli xil ustunlar soni bo'ladi. Yuqoridagi rasmdagi misolda bitta satrda uchta ustun (1, 2 va 3), ikkinchisida esa faqat ikkita (1 va 2) mavjud - bu erda biz o'zimiz relyatsion ma'lumotlar bazalarida mavjud bo'lmagan ikkita HBase xususiyatidan foydalanganmiz:
- ustunlar tarkibini dinamik ravishda o'zgartirish qobiliyati (do'st qo'shish -> ustun qo'shish, do'stni olib tashlash -> ustunni o'chirish)
- turli qatorlar turli xil ustunli kompozitsiyalarga ega bo'lishi mumkin
Keling, tuzilmamizni vazifa talablariga muvofiqligini tekshirib ko'ramiz:
- Ma'lumotlarni o'qish: Vasya Olyaga obuna bo'lganligini tushunish uchun biz ayirishimiz kerak butun chiziq RowKey = "Vasya" tugmachasi yordamida va ularda Olya bilan "uchrashgunimizcha" ustun qiymatlari bo'yicha tartiblang. Yoki barcha ustunlar qiymatlari bo'yicha takrorlang, Olya bilan "uchrashmaydi" va "False" javobini qaytaring;
- Ma'lumotlarni tahrirlash: do'st qo'shish: shunga o'xshash vazifa uchun biz ham ayirishimiz kerak butun chiziq Do'stlarining umumiy sonini hisoblash uchun RowKey = "Vasya" tugmachasidan foydalaning. Yangi do'stning identifikatorini yozishimiz kerak bo'lgan ustun sonini aniqlash uchun bizga ushbu umumiy do'stlar soni kerak.
- Ma'lumotlarni o'zgartirish: do'stni o'chirish:
- Ayirish kerak butun chiziq RowKey = "Vasya" tugmasi bo'yicha va o'chiriladigan do'st yozilgan ustunni topish uchun ustunlar bo'ylab tartiblang;
- Keyinchalik, do'stni o'chirib tashlaganimizdan so'ng, ularning raqamlanishida "bo'shliqlar" qolmasligi uchun barcha ma'lumotlarni bitta ustunga "o'tkazish" kerak.
Keling, "shartli dastur" tomonida amalga oshirishimiz kerak bo'lgan ushbu algoritmlar qanchalik samarali bo'lishini baholaymiz. . Faraziy ijtimoiy tarmog'imiz hajmini n deb belgilaymiz. Shunda bitta foydalanuvchi bo'lishi mumkin bo'lgan maksimal do'stlar soni (n-1). Bundan tashqari, biz buni (-1) o'z maqsadlarimiz uchun e'tiborsiz qoldirishimiz mumkin, chunki O-ramzlaridan foydalanish doirasida bu muhim emas.
- Ma'lumotlarni o'qish: butun chiziqni ayirish va chegaradagi barcha ustunlarini takrorlash kerak. Bu shuni anglatadiki, xarajatlarning yuqori bahosi taxminan O(n) bo'ladi.
- Ma'lumotlarni tahrirlash: do'st qo'shish: do'stlar sonini aniqlash uchun siz qatorning barcha ustunlari bo'ylab takrorlashingiz kerak va keyin yangi ustun qo'yishingiz kerak => O(n)
- Ma'lumotlarni o'zgartirish: do'stni o'chirish:
- Qo'shishga o'xshash - siz chegaradagi barcha ustunlardan o'tishingiz kerak => O(n)
- Ustunlarni olib tashlaganimizdan so'ng, biz ularni "ko'chirishimiz" kerak. Agar siz ushbu "boshqa" ni amalga oshirsangiz, chegarada sizga (n-1) gacha operatsiyalar kerak bo'ladi. Ammo bu erda va amaliy qismda biz boshqa yondashuvdan foydalanamiz, bu esa ma'lum miqdordagi operatsiyalar uchun "psevdo-shift" ni amalga oshiradi - ya'ni n dan qat'i nazar, unga doimiy vaqt sarflanadi. Bu doimiy vaqtni (aniqrog'i O (2)) O (n) bilan solishtirganda e'tiborsiz qoldirish mumkin. Yondashuv quyidagi rasmda ko'rsatilgan: biz shunchaki ma'lumotlarni "oxirgi" ustundan ma'lumotlarni o'chirmoqchi bo'lgan ustunga ko'chiramiz va keyin oxirgi ustunni o'chirib tashlaymiz:
Umuman olganda, barcha stsenariylarda biz O(n) ning asimptotik hisoblash murakkabligini oldik.
Siz allaqachon payqagandirsiz, biz deyarli har doim ma'lumotlar bazasidan butun qatorni o'qishimiz kerak, va uchta holatdan ikkitasida, faqat barcha ustunlarni ko'rib chiqish va umumiy do'stlar sonini hisoblash uchun. Shuning uchun, optimallashtirishga urinish sifatida siz har bir tarmoq foydalanuvchisining do'stlarining umumiy sonini saqlaydigan "hisoblash" ustunini qo'shishingiz mumkin. Bunday holda, biz do'stlarning umumiy sonini hisoblash uchun butun qatorni o'qiy olmaymiz, faqat bitta "hisoblash" ustunini o'qiymiz. Asosiysi, ma'lumotlarni manipulyatsiya qilishda "hisoblash" ni yangilashni unutmang. Bu. yaxshilanamiz Variant 2 (hisob):
RowKey
Ustunlar
Vasya
1: Petya
2: Olya
3: Dasha
soni: 3
Akbar
1: Masha
2: Vasya
soni: 2
Birinchi variant bilan taqqoslaganda:
- Ma'lumotlarni o'qish: "Vasya Olyani o'qiydimi?" Degan savolga javob olish uchun. hech narsa o'zgarmadi => O(n)
- Ma'lumotlarni tahrirlash: do'st qo'shish: Biz yangi do'stni kiritishni soddalashtirdik, chunki endi biz butun qatorni o'qishimiz va uning ustunlari bo'ylab takrorlashimiz shart emas, faqat "hisoblash" ustunining qiymatini olishimiz mumkin va hokazo. darhol yangi do'st kiritish uchun ustun raqamini aniqlang. Bu hisoblash murakkabligining O(1) ga kamayishiga olib keladi.
- Ma'lumotlarni o'zgartirish: do'stni o'chirish: Do'stni o'chirishda biz ushbu ustundan ma'lumotni bir katakchani chapga "o'tkazishda" kiritish-chiqarish operatsiyalari sonini kamaytirish uchun ham foydalanishimiz mumkin. Ammo o'chirilishi kerak bo'lgan ustunni topish uchun ustunlar bo'ylab takrorlash zarurati saqlanib qolmoqda, shuning uchun => O(n)
- Boshqa tomondan, endi ma'lumotlarni yangilashda biz har safar "hisoblash" ustunini yangilashimiz kerak, ammo bu doimiy vaqtni oladi, bu O-ramzlari doirasida e'tibordan chetda qolishi mumkin.
Umuman olganda, 2-variant biroz maqbulroq ko'rinadi, lekin u ko'proq "inqilob o'rniga evolyutsiya" ga o'xshaydi. "inqilob" qilish uchun bizga kerak bo'ladi Variant 3 (ko'p).
Keling, hamma narsani "teskari" aylantiramiz: biz tayinlaymiz ustun nomi foydalanuvchi identifikatori! Ustunning o'zida nima yozilishi biz uchun endi muhim emas, u 1-raqam bo'lsin (umuman, foydali narsalarni u erda saqlash mumkin, masalan, "oila / do'stlar / boshqalar" guruhi). Ushbu yondashuv oldindan NoSQL ma'lumotlar bazalari bilan ishlash tajribasiga ega bo'lmagan tayyorlanmagan "layman"ni hayratda qoldirishi mumkin, ammo aynan shu yondashuv HBase potentsialidan ushbu vazifada ancha samarali foydalanishga imkon beradi:
RowKey
Ustunlar
Vasya
Petya: 1
Olya: 1
Dasha: 1
Akbar
Masha: 1
Vasya: 1
Bu erda biz bir vaqtning o'zida bir nechta afzalliklarga ega bo'lamiz. Ularni tushunish uchun yangi tuzilmani tahlil qilamiz va hisoblash murakkabligini baholaymiz:
- Ma'lumotlarni o'qish: Vasya Olyaga obuna bo'lganmi degan savolga javob berish uchun bitta "Olya" ustunini o'qish kifoya: agar u mavjud bo'lsa, javob to'g'ri, bo'lmasa - noto'g'ri => O (1)
- Ma'lumotlarni tahrirlash: do'st qo'shish: Doʻst qoʻshish: shunchaki yangi “Doʻst ID” ustunini qoʻshing => O(1)
- Ma'lumotlarni o'zgartirish: do'stni o'chirish: shunchaki Friend ID ustunini olib tashlang => O(1)
Ko'rib turganingizdek, ushbu saqlash modelining muhim afzalligi shundaki, bizga kerak bo'lgan barcha stsenariylarda biz faqat bitta ustun bilan ishlaymiz, ma'lumotlar bazasidan butun qatorni o'qishdan qochamiz va bundan tashqari, ushbu qatorning barcha ustunlarini sanab o'tamiz. Biz u erda to'xtashimiz mumkin edi, lekin ...
Siz hayron bo'lishingiz mumkin va ma'lumotlar bazasiga kirishda ishlashni optimallashtirish va kiritish-chiqarish operatsiyalarini qisqartirish yo'lidan biroz oldinga borishingiz mumkin. To'liq aloqa ma'lumotlarini to'g'ridan-to'g'ri qator kalitida saqlasak nima bo'ladi? Ya'ni, userID.friendID kabi kalit kompozitsiyasini yarating? Bunday holda, biz satr ustunlarini umuman o'qishimiz shart emas (Variant 4 (qator)):
RowKey
Ustunlar
Vasya.Petya
Petya: 1
Vasya.Olya
Olya: 1
Vasya.Dasha
Dasha: 1
Petya.Masha
Masha: 1
Petya.Vasya
Vasya: 1
Shubhasiz, bunday tuzilmada ma'lumotlarni manipulyatsiya qilishning barcha stsenariylarini baholash, avvalgi versiyada bo'lgani kabi, O (1) bo'ladi. 3-variantdan farq faqat ma'lumotlar bazasidagi kiritish-chiqarish operatsiyalarining samaradorligida bo'ladi.
Xo'sh, oxirgi "kamon". 4-variantda qator kaliti o'zgaruvchan uzunlikka ega bo'lishini ko'rish oson, bu ishlashga ta'sir qilishi mumkin (bu erda biz HBase ma'lumotlarni baytlar to'plami sifatida saqlashini va jadvallardagi qatorlar kalit bo'yicha tartiblanganligini eslaymiz). Bundan tashqari, bizda ba'zi stsenariylarda ishlov berilishi kerak bo'lgan ajratuvchi mavjud. Ushbu ta'sirni bartaraf qilish uchun siz userID va friendID dan xeshlardan foydalanishingiz mumkin va ikkala xesh ham doimiy uzunlikka ega bo'lgani uchun ularni ajratuvchisiz oddiygina birlashtirishingiz mumkin. Keyin jadvaldagi ma'lumotlar shunday ko'rinadi (Variant 5 (xesh)):
RowKey
Ustunlar
dc084ef00e94aef49be885f9b01f51c01918fa783851db0dc1f72f83d33a5994
Petya: 1
dc084ef00e94aef49be885f9b01f51c0f06b7714b5ba522c3cf51328b66fe28a
Olya: 1
dc084ef00e94aef49be885f9b01f51c00d2c2e5d69df6b238754f650d56c896a
Dasha: 1
1918fa783851db0dc1f72f83d33a59949ee3309645bd2c0775899fca14f311e1
Masha: 1
1918fa783851db0dc1f72f83d33a5994dc084ef00e94aef49be885f9b01f51c0
Vasya: 1
Shubhasiz, biz ko'rib chiqayotgan stsenariylarda bunday tuzilma bilan ishlashning algoritmik murakkabligi 4-variant bilan bir xil bo'ladi - ya'ni O(1).
Umuman olganda, keling, hisoblash murakkabligi haqidagi barcha taxminlarimizni bitta jadvalda jamlaymiz:
Do'st qo'shish
Do'stingizni tekshirish
Do'stni olib tashlash
Variant 1 (standart)
O (n)
O (n)
O (n)
Variant 2 (hisoblash)
O (1)
O (n)
O (n)
Variant 3 (ustun)
O (1)
O (1)
O (1)
Variant 4 (qator)
O (1)
O (1)
O (1)
Variant 5 (xesh)
O (1)
O (1)
O (1)
Ko'rib turganingizdek, 3-5 variantlari eng maqbul bo'lib tuyuladi va nazariy jihatdan doimiy ravishda barcha kerakli ma'lumotlarni manipulyatsiya qilish stsenariylarining bajarilishini ta'minlaydi. Bizning vazifamiz shartlariga ko'ra, foydalanuvchining barcha do'stlari ro'yxatini olish uchun aniq talab yo'q, lekin haqiqiy loyiha faoliyatida, biz, yaxshi tahlilchilar sifatida, bunday vazifa paydo bo'lishi mumkinligini "oldindan ko'rish" yaxshi bo'lar edi. "somonni yoying." Shuning uchun, mening hamdardligim 3-variant tomonida. Ammo haqiqiy loyihada bu so'rov allaqachon boshqa vositalar bilan hal qilingan bo'lishi mumkin, shuning uchun butun muammoni umumiy tasavvur qilmasdan, buni qilmaslik yaxshiroqdir. yakuniy xulosalar.
Tajribani tayyorlash
Men yuqoridagi nazariy dalillarni amalda sinab ko'rmoqchiman - bu uzoq dam olish kunlarida paydo bo'lgan g'oyaning maqsadi edi. Buni amalga oshirish uchun ma'lumotlar bazasidan foydalanishning barcha tavsiflangan stsenariylarida "shartli ilovamiz" ning ishlash tezligini, shuningdek, ijtimoiy tarmoq hajmining (n) o'sishi bilan bu vaqtning o'sishini baholash kerak. Bizni qiziqtiradigan va tajriba davomida biz o'lchaydigan maqsadli parametr - bu "shartli dastur" tomonidan bitta "biznes operatsiyasini" bajarish uchun sarflangan vaqt. “Tadbirkorlik bitimi” deganda biz quyidagilardan birini nazarda tutamiz:
- Bitta yangi do'st qo'shilmoqda
- A foydalanuvchisi B foydalanuvchisining do'sti ekanligini tekshirish
- Bitta do'stni olib tashlash
Shunday qilib, dastlabki bayonotda ko'rsatilgan talablarni hisobga olgan holda, tekshirish stsenariysi quyidagicha paydo bo'ladi:
- Ma'lumotlarni yozib olish. Tasodifiy ravishda n o'lchamdagi boshlang'ich tarmoqni yarating. "Haqiqiy dunyo" ga yaqinlashish uchun har bir foydalanuvchining do'stlari soni ham tasodifiy o'zgaruvchidir. Bizning "shartli ilovamiz" barcha yaratilgan ma'lumotlarni HBase-ga yozadigan vaqtni o'lchang. Keyin olingan vaqtni qo'shilgan do'stlarning umumiy soniga bo'ling - biz bitta "biznes operatsiyasi" uchun o'rtacha vaqtni shunday olamiz.
- Ma'lumotlarni o'qish. Har bir foydalanuvchi uchun "shaxslar" ro'yxatini tuzing, ular uchun foydalanuvchi ularga obuna bo'lganmi yoki yo'qmi, javob olishingiz kerak. Ro'yxatning uzunligi = foydalanuvchi do'stlarining taxminan soni va tekshirilgan do'stlarning yarmi uchun javob "Ha", qolgan yarmi uchun - "Yo'q" bo'lishi kerak. Tekshirish shunday tartibda amalga oshiriladiki, "Ha" va "Yo'q" javoblari almashinadi (ya'ni har ikkinchi holatda biz 1 va 2-variantlar uchun chiziqning barcha ustunlarini bosib o'tishimiz kerak). Umumiy skrining vaqti har bir mavzu bo'yicha o'rtacha skrining vaqtini olish uchun sinovdan o'tgan do'stlar soniga bo'linadi.
- Ma'lumotlar o'chirilmoqda. Foydalanuvchidan barcha do'stlarni olib tashlang. Bundan tashqari, o'chirish tartibi tasodifiy (ya'ni, biz ma'lumotlarni yozish uchun ishlatiladigan asl ro'yxatni "aralashtiramiz"). Tekshirishning umumiy vaqti har bir chek uchun o'rtacha vaqtni olish uchun olib tashlangan do'stlar soniga bo'linadi.
Ssenariylar 5 ta maʼlumotlar modeli variantlarining har biri va ijtimoiy tarmoqning turli oʻlchamlari uchun vaqt oʻsishi bilan qanday oʻzgarishini koʻrish uchun ishga tushirilishi kerak. Bitta n ichida tarmoqdagi ulanishlar va tekshiriladigan foydalanuvchilar ro'yxati, albatta, barcha 5 variant uchun bir xil bo'lishi kerak.
Yaxshiroq tushunish uchun quyida n= 5 uchun yaratilgan maʼlumotlarga misol keltirilgan. Yozma “generator” uchta identifikator lugʻatini chiqadi:
- birinchisi kiritish uchun
- ikkinchisi tekshirish uchun
- uchinchisi - o'chirish uchun
{0: [1], 1: [4, 5, 3, 2, 1], 2: [1, 2], 3: [2, 4, 1, 5, 3], 4: [2, 1]} # всего 15 друзей
{0: [1, 10800], 1: [5, 10800, 2, 10801, 4, 10802], 2: [1, 10800], 3: [3, 10800, 1, 10801, 5, 10802], 4: [2, 10800]} # всего 18 проверяемых субъектов
{0: [1], 1: [1, 3, 2, 5, 4], 2: [1, 2], 3: [4, 1, 2, 3, 5], 4: [1, 2]} # всего 15 друзей
Ko'rib turganingizdek, tekshirish uchun lug'atda 10 000 dan katta bo'lgan barcha identifikatorlar aniq "Yolg'on" javobini beradi. "Do'stlar" ni kiritish, tekshirish va o'chirish lug'atda ko'rsatilgan ketma-ketlikda amalga oshiriladi.
Tajriba Windows 10 operatsion tizimida ishlaydigan noutbukda o‘tkazildi, u yerda bir Docker konteynerida HBase, ikkinchisida Jupyter Notebook bilan Python ishlayotgan edi. Dockerga 2 protsessor yadrosi va 2 Gb tezkor xotira ajratilgan. Barcha mantiq, ham test ma'lumotlarini yaratish va vaqtni o'lchash uchun "shartli dastur" ning emulyatsiyasi va "quvurlar" Pythonda yozilgan. Kutubxona HBase bilan ishlash uchun ishlatilgan , 5-variant uchun xeshlarni (MD5) hisoblash uchun - hashlib
Muayyan noutbukning hisoblash quvvatini hisobga olgan holda, n = 10, 30, … uchun ishga tushirish eksperimental ravishda tanlangan. 170 - to'liq sinov tsiklining umumiy ish vaqti (barcha n uchun barcha variantlar uchun barcha stsenariylar) bir choy partiyasi paytida (o'rtacha 15 daqiqa) ko'proq yoki kamroq oqilona va mos bo'lganida.
Shuni ta'kidlash kerakki, ushbu tajribada biz birinchi navbatda mutlaq samaradorlik ko'rsatkichlarini baholamaymiz. Hatto ikki xil variantni nisbiy taqqoslash ham butunlay to'g'ri bo'lmasligi mumkin. Endi biz n ga qarab vaqt o'zgarishining tabiati bilan qiziqamiz, chunki "sinov stendining" yuqoridagi konfiguratsiyasini hisobga olgan holda, tasodifiy va boshqa omillar ta'siridan "tozalangan" vaqtni hisoblash juda qiyin ( va bunday vazifa qo'yilmagan).
Tajriba natijasi
Birinchi sinov - do'stlar ro'yxatini to'ldirish uchun sarflangan vaqt qanday o'zgaradi. Natija quyidagi grafikda.
3-5-variantlar, kutilganidek, tarmoq hajmining o'sishiga va ishlashning farqlanmaydigan farqiga bog'liq bo'lmagan deyarli doimiy "biznes bitimi" vaqtini ko'rsatadi.
2-variant, shuningdek, doimiy, ammo biroz yomonroq ishlashni ko'rsatadi, 2-3-variantlarga nisbatan deyarli 5 marta. Va bu quvonib bo'lmaydi, chunki u nazariya bilan bog'liq - bu versiyada HBase-dan / dan kiritish-chiqarish operatsiyalari soni 2 baravar ko'p. Bu bizning sinov dastgohimiz, printsipial jihatdan, yaxshi aniqlikni ta'minlaydigan bilvosita dalil bo'lib xizmat qilishi mumkin.
1-variant ham, kutilganidek, eng sekin bo'lib chiqadi va tarmoq hajmiga bir-birini qo'shish uchun sarflangan vaqtning chiziqli o'sishini namoyish etadi.
Endi ikkinchi test natijalarini ko'rib chiqamiz.
Variantlar 3-5 yana kutilganidek harakat qiladi - doimiy vaqt, tarmoq hajmidan qat'iy nazar. 1 va 2-variantlar tarmoq hajmi oshgani sayin vaqtning chiziqli o'sishini va shunga o'xshash ishlashni namoyish etadi. Bundan tashqari, 2-variant biroz sekinroq bo'lib chiqdi - ko'rinishidan, qo'shimcha "hisoblash" ustunini tekshirish va qayta ishlash zarurati tufayli, n o'sishi bilan sezilarli bo'ladi. Ammo men hali ham biron bir xulosa chiqarishdan o'zimni tilayman, chunki bu taqqoslashning aniqligi nisbatan past. Bundan tashqari, bu nisbatlar (qaysi variant, 1 yoki 2, tezroq) yugurishdan yugurishga o'zgardi (qaramlik va "bo'yin va bo'yin" tabiatini saqlab qolgan holda).
Xo'sh, oxirgi grafik o'chirish testining natijasidir.
Shunga qaramay, bu erda hech qanday ajablanib bo'lmaydi. Variantlar 3-5 doimiy vaqt ichida olib tashlashni amalga oshiradi.
Bundan tashqari, qiziq tomoni shundaki, 4 va 5-variantlar, oldingi stsenariylardan farqli o'laroq, 3-variantga qaraganda sezilarli darajada yomonroq ishlashni ko'rsatadi. Ko'rinishidan, qatorni o'chirish operatsiyasi ustunni o'chirish operatsiyasidan qimmatroqdir, bu umuman mantiqiy.
1 va 2-variantlar, kutilganidek, vaqtning chiziqli o'sishini namoyish etadi. Shu bilan birga, 2-variant 1-variantga qaraganda doimiy ravishda sekinroq - hisoblash ustunini "saqlash" uchun qo'shimcha kiritish-chiqarish operatsiyasi tufayli.
Tajribaning umumiy xulosalari:
- 3-5-variantlar HBase-dan foydalanishi tufayli yuqori samaradorlikni namoyish etadi; Bundan tashqari, ularning ishlashi doimiy ravishda bir-biriga nisbatan farq qiladi va tarmoq hajmiga bog'liq emas.
- 4 va 5 variantlari orasidagi farq qayd etilmagan. Ammo bu 5-variantdan foydalanmaslik kerak degani emas. Ehtimol, sinov stendining ishlash xususiyatlarini hisobga olgan holda ishlatilgan eksperimental stsenariy uni aniqlashga imkon bermagan.
- Ma'lumotlar bilan "biznes operatsiyalari" ni amalga oshirish uchun zarur bo'lgan vaqtning o'sishi tabiati, odatda, barcha variantlar uchun ilgari olingan nazariy hisob-kitoblarni tasdiqladi.
Epilog
O'tkazilgan qo'pol tajribalarni mutlaq haqiqat sifatida qabul qilmaslik kerak. Hisobga olinmagan va natijalarni buzgan ko'plab omillar mavjud (bu tebranishlar, ayniqsa, kichik tarmoq o'lchamiga ega grafiklarda ko'rinadi). Misol uchun, happybase tomonidan qo'llaniladigan tejamkorlik tezligi, men Pythonda yozgan mantiqni amalga oshirish hajmi va usuli (kod optimal tarzda yozilgan va barcha komponentlarning imkoniyatlaridan samarali foydalanilgan deb da'vo qila olmayman), ehtimol HBase keshlash xususiyatlari, noutbukimdagi Windows 10-ning fon faoliyati va boshqalar. Umuman olganda, barcha nazariy hisob-kitoblar o'zlarining haqiqiyligini eksperimental ravishda ko'rsatdi deb taxmin qilishimiz mumkin. Xo'sh, yoki hech bo'lmaganda bunday "boshqa hujum" bilan ularni rad etishning iloji yo'q edi.
Xulosa qilib aytganda, HBase-da ma'lumotlar modellarini loyihalashni endi boshlayotgan har bir kishi uchun tavsiyalar: relyatsion ma'lumotlar bazalari bilan ishlashning oldingi tajribasidan referat va "buyruqlarni" eslang:
- Loyihalashda biz domen modelidan emas, balki vazifa va ma'lumotlarni manipulyatsiya qilish naqshlaridan kelib chiqamiz
- Samarali kirish (jadvalni to'liq skanerlashsiz) - faqat kalit bilan
- Denormalizatsiya
- Turli qatorlar turli ustunlarni o'z ichiga olishi mumkin
- Dinamiklarning dinamik tarkibi
Manba: www.habr.com