Ular hayotdagi hamma narsani kamida bir marta sinab ko'rishga arziydi, deyishadi. Va agar siz relyatsion DBMS bilan ishlashga odatlangan bo'lsangiz, unda NoSQL bilan amalda, birinchi navbatda, hech bo'lmaganda umumiy rivojlanish uchun tanishishga arziydi. Hozir ushbu texnologiyaning jadal rivojlanishi tufayli ushbu mavzu bo'yicha juda ko'p qarama-qarshi fikrlar va qizg'in bahs-munozaralar mavjud bo'lib, bu ayniqsa qiziqishni kuchaytiradi.
Agar siz ushbu nizolarning mohiyatini o'rgansangiz, ular noto'g'ri yondashuv tufayli paydo bo'lganligini ko'rishingiz mumkin. NoSQL ma'lumotlar bazalaridan kerakli joyda foydalanadiganlar qoniqishadi va ushbu yechimdan barcha afzalliklarga ega bo'lishadi. Va bu texnologiyani umuman qo'llash mumkin bo'lmagan panatseya sifatida tayanadigan eksperimentchilar, sezilarli foyda keltirmasdan, aloqador ma'lumotlar bazalarining kuchli tomonlarini yo'qotib, hafsalasi pir bo'ladi.
Men sizga Cassandra DBMS asosidagi yechimni amalga oshirish bo'yicha tajribamiz haqida gapirib beraman: biz nimaga duch keldik, qiyin vaziyatlardan qanday chiqdik, NoSQL-dan foydalanishdan foyda ko'ra oldikmi va qayerga qo'shimcha kuch/mablag'larni sarflashimiz kerak edi. .
Boshlang'ich vazifa qo'ng'iroqlarni qandaydir xotirada qayd qiluvchi tizimni yaratishdir.
Tizimning ishlash printsipi quyidagicha. Kirish qo'ng'iroq tuzilishini tavsiflovchi ma'lum bir tuzilishga ega fayllarni o'z ichiga oladi. Keyin dastur ushbu strukturaning tegishli ustunlarda saqlanishini ta'minlaydi. Kelajakda saqlangan qo'ng'iroqlar abonentlar uchun trafik sarfi (to'lovlar, qo'ng'iroqlar, balans tarixi) haqidagi ma'lumotlarni ko'rsatish uchun ishlatiladi.
Nima uchun ular Kassandrani tanlaganlari aniq - u avtomat kabi yozadi, osonlikcha kengaytiriladi va xatolarga chidamli.
Demak, bu bizga tajriba berdi
Ha, muvaffaqiyatsiz tugun fojia emas. Kassandraning xatolarga chidamliligining mohiyati shundan iborat. Lekin tugun tirik bo'lishi mumkin va ayni paytda ishlashda azob chekishni boshlaydi. Ma'lum bo'lishicha, bu darhol butun klasterning ishlashiga ta'sir qiladi.
Oracle o'z cheklovlari bilan sizni qutqargan joyda Kassandra sizni himoya qilmaydi. Va agar ariza muallifi buni oldindan tushunmagan bo'lsa, Kassandra uchun kelgan dubl asl nusxadan yomon emas. Kelgach, biz uni joylashtiramiz.
IB qutidagi bepul Kassandrani juda yoqtirmadi: Foydalanuvchi harakatlarini qayd qilish, huquqlarni farqlash yo'q. Qo'ng'iroqlar to'g'risidagi ma'lumotlar shaxsiy ma'lumotlar hisoblanadi, ya'ni uni har qanday tarzda so'rash/o'zgartirish bo'yicha barcha urinishlar keyinchalik tekshirish imkoniyati bilan qayd etilishi kerak. Bundan tashqari, siz turli foydalanuvchilar uchun turli darajadagi huquqlarni ajratish zarurligini bilishingiz kerak. Oddiy operatsiya muhandisi va barcha kalitlar maydonini erkin o'chira oladigan super administrator turli rollar, turli mas'uliyat va vakolatlardir. Kirish huquqlarining bunday tabaqalanishisiz ma'lumotlarning qiymati va yaxlitligi HAR QANDAY izchillik darajasiga qaraganda tezroq shubha ostiga olinadi.
Biz qo'ng'iroqlar jiddiy tahlillarni va turli sharoitlar uchun davriy namuna olishni talab qilishini hisobga olmadik. Tanlangan yozuvlar keyin o'chirilishi va qayta yozilishi kerak bo'lganligi sababli (topshiriqning bir qismi sifatida ma'lumotlar dastlab bizning tsiklimizga noto'g'ri kiritilganda ma'lumotlarni yangilash jarayonini qo'llab-quvvatlashimiz kerak), Kassandra bu erda bizning do'stimiz emas. Kassandra cho'chqachilik bankiga o'xshaydi - narsalarni qo'yish qulay, lekin siz unda hisoblay olmaysiz.
Sinov zonalariga maʼlumotlarni uzatishda muammoga duch keldik (Testda 5 tugun, bitiruvda 20 tugun). Bunday holda, dumpdan foydalanish mumkin emas.
Kassandraga yozilayotgan ilovaning ma'lumotlar sxemasini yangilash bilan bog'liq muammo. Orqaga qaytarish juda ko'p qabr toshlarini keltirib chiqaradi, bu esa oldindan aytib bo'lmaydigan yo'llar bilan hosildorlikning yo'qolishiga olib kelishi mumkin.. Kassandra yozib olish uchun optimallashtirilgan va yozishdan oldin ko'p o'ylamaydi.Unda mavjud ma'lumotlar bilan har qanday operatsiya ham yozuvdir. Ya'ni, keraksizlarni o'chirish orqali biz shunchaki ko'proq yozuvlarni ishlab chiqaramiz va ulardan faqat ba'zilari qabr toshlari bilan belgilanadi.
Kiritish vaqtida kutish vaqti. Kassandra yozuvda chiroyli, lekin ba'zan kiruvchi oqim uni sezilarli darajada jumboq qilishi mumkin. Bu dastur biron sababga ko'ra kiritib bo'lmaydigan bir nechta yozuvlar atrofida aylana boshlaganda sodir bo'ladi. Va bizga gc.log, tizim va disk raskadrovka jurnallarini sekin so'rovlar, siqishni kutilayotgan ko'rsatkichlar uchun kuzatadigan haqiqiy DBA kerak bo'ladi.
Klasterda bir nechta ma'lumotlar markazlari. Qayerdan o'qish va qayerdan yozish kerak?
Ehtimol, o'qish va yozishga bo'linganmi? Va agar shunday bo'lsa, yozish yoki o'qish uchun dasturga yaqinroq DC bo'lishi kerakmi? Va agar biz noto'g'ri mustahkamlik darajasini tanlasak, haqiqiy bo'lingan miya bilan yakunlanmaymizmi? Ko'p savollar, juda ko'p noma'lum sozlamalar, siz chindan ham o'ylab ko'rmoqchi bo'lgan imkoniyatlar mavjud.
Biz qanday qaror qildik
Tugunning cho'kib ketishining oldini olish uchun SWAP o'chirildi. Va endi, agar xotira etishmasligi bo'lsa, tugun pastga tushishi va katta gc pauzalarini yaratmasligi kerak.
Shunday qilib, biz endi ma'lumotlar bazasidagi mantiqqa tayanmaymiz. Ilova ishlab chiquvchilari o'zlarini qayta tayyorlashmoqda va o'z kodlarida faol choralar ko'rishni boshladilar. Ma'lumotlarni saqlash va qayta ishlashni ideal tarzda aniq ajratish.
Biz DataStax’dan yordam sotib oldik. Kassandra qutisini ishlab chiqish allaqachon to'xtatilgan (oxirgi majburiyat 2018 yil fevral oyida bo'lgan). Shu bilan birga, Datastax mavjud IP yechimlari uchun mukammal xizmat va ko‘p sonli o‘zgartirilgan va moslashtirilgan yechimlarni taklif etadi.
Shuni ham ta'kidlashni istardimki, Kassandra tanlov so'rovlari uchun juda qulay emas. Albatta, CQL foydalanuvchilar uchun oldinga katta qadamdir (Trift bilan solishtirganda). Ammo agar sizda bunday qulay ulanishlarga, istalgan soha bo'yicha bepul filtrlash va so'rovlarni optimallashtirish imkoniyatlariga odatlangan butun bo'limlar bo'lsa va bu bo'limlar shikoyatlar va baxtsiz hodisalarni hal qilish uchun ishlayotgan bo'lsa, Kassandra bo'yicha yechim ularga dushman va ahmoqona tuyuladi. Va biz hamkasblarimiz namunalarni qanday qilish kerakligini hal qila boshladik.
Biz ikkita variantni ko'rib chiqdik.Birinchi variantda biz qo'ng'iroqlarni nafaqat C* da, balki arxivlangan Oracle ma'lumotlar bazasiga ham yozamiz. Faqat, C * dan farqli o'laroq, bu ma'lumotlar bazasi faqat joriy oy uchun qo'ng'iroqlarni saqlaydi (zaryadlash uchun qo'ng'iroqlarni saqlash chuqurligi etarli). Bu erda biz darhol quyidagi muammoni ko'rdik: agar biz sinxron tarzda yozsak, C* ning tez kiritish bilan bog'liq barcha afzalliklarini yo'qotamiz; agar biz asinxron yozsak, barcha kerakli qo'ng'iroqlar Oracle-ga umuman tushishiga kafolat yo'q. Bitta plyus bor edi, lekin kattasi: ishlash uchun o'sha tanish PL/SQL Developer qoladi, ya'ni biz “Fasad” naqshini amalda qo'llaymiz.Muqobil variant. Biz C* dan qo'ng'iroqlarni olib tashlaydigan mexanizmni amalga oshiramiz, Oracle'dagi tegishli jadvallardan ba'zi ma'lumotlarni boyitish uchun tortib olamiz, olingan namunalarga qo'shamiz va natijani bizga beradi, biz undan keyin qandaydir tarzda foydalanamiz (orqaga qaytarish, takrorlash, tahlil qilish, hayratlanish). Kamchiliklari: jarayon juda ko'p bosqichli va bundan tashqari, operatsion xodimlar uchun interfeys yo'q.
Oxir-oqibat, biz ikkinchi variantga qaror qildik. Apache Spark turli bankalardan namuna olish uchun ishlatilgan. Mexanizmning mohiyati Java kodiga qisqartirildi, u ko'rsatilgan kalitlar (abonent, qo'ng'iroq vaqti - bo'lim tugmalari) yordamida C* dan ma'lumotlarni, shuningdek boshqa har qanday ma'lumotlar bazasidan boyitish uchun kerakli ma'lumotlarni chiqaradi. Shundan so'ng u ularni xotirasiga qo'shib, natijani olingan jadvalda ko'rsatadi. Biz uchqun ustiga veb yuzini chizdik va u juda foydali bo'lib chiqdi.
Sanoat sinovlari ma'lumotlarini yangilash muammosini hal qilishda biz yana bir nechta echimlarni ko'rib chiqdik. Ikkala Sstloader orqali uzatish va test zonasidagi klasterni ikkita qismga bo'lish opsiyasi, ularning har biri navbatma-navbat reklama klasteri bilan bir xil klasterga tegishli bo'lib, shu tariqa u tomonidan quvvatlanadi. Sinovni yangilashda ularni almashtirish rejalashtirilgan edi: testda ishlagan qism tozalanadi va ishlab chiqarishga kiritiladi, ikkinchisi esa alohida ma'lumotlar bilan ishlay boshlaydi. Biroq, yana bir bor o'ylab ko'rganimizdan so'ng, biz uzatishga arziydigan ma'lumotlarni yanada oqilona baholadik va qo'ng'iroqlarning o'zi testlar uchun mos kelmaydigan ob'ekt ekanligini angladik, agar kerak bo'lsa, tezda yaratiladi va bu reklama ma'lumotlari to'plamiga o'tkazish uchun hech qanday ahamiyatga ega emas. sinov. Ko'chirishga arziydigan bir nechta saqlash ob'ektlari mavjud, ammo bular tom ma'noda bir nechta jadvallar va unchalik og'ir emas. Shuning uchun biz yechim sifatida Spark yana yordamga keldi, uning yordamida biz jadvallar, prom-test o'rtasida ma'lumotlarni uzatish uchun skriptni yozdik va faol foydalanishni boshladik.
Bizning joriy joylashtirish siyosatimiz orqaga qaytarilmasdan ishlashga imkon beradi. Promodan oldin majburiy sinov o'tkaziladi, bu erda xato unchalik qimmat emas. Muvaffaqiyatsiz bo'lsa, siz har doim ish maydonini tashlab, butun sxemani boshidan siljitishingiz mumkin.
Kassandraning doimiy mavjudligini ta'minlash uchun sizga nafaqat unga emas, balki dba kerak. Ilova bilan ishlaydigan har bir kishi hozirgi vaziyatga qayerda va qanday qarash kerakligini va muammolarni o'z vaqtida aniqlashni tushunishi kerak. Buning uchun biz DataStax OpsCenter (ish yuklarini boshqarish va monitoring qilish), Cassandra Driver tizimi ko'rsatkichlaridan (C* ga yozish uchun kutish vaqti, C* dan o'qish uchun kutish vaqti, maksimal kechikish va boshqalar) faol foydalanamiz, operatsiyani kuzatib boramiz. ilovaning o'zi, Kassandra bilan ishlash.
Oldingi savol haqida o'ylaganimizda, biz asosiy xavf-xatarimiz qayerda bo'lishi mumkinligini tushundik. Bular bir nechta mustaqil so'rovlardan ma'lumotlarni saqlashga ko'rsatadigan ma'lumotlarni ko'rsatish shakllari. Shunday qilib, biz juda mos kelmaydigan ma'lumotlarni olishimiz mumkin. Ammo, agar biz faqat bitta ma'lumot markazi bilan ishlagan bo'lsak, bu muammo xuddi shunday dolzarb bo'lar edi. Shunday qilib, bu erda eng oqilona narsa, albatta, ma'lumotlarning bir vaqtning o'zida olinishini ta'minlaydigan uchinchi tomon ilovasidagi ma'lumotlarni o'qish uchun ommaviy funksiyani yaratishdir. Ishlash bo'yicha o'qish va yozishga bo'linishga kelsak, bu erda biz DC lar o'rtasidagi aloqaning biroz yo'qolishi bilan biz bir-biriga mutlaqo mos kelmaydigan ikkita klasterga ega bo'lishimiz xavfi bilan to'xtatildi.
Natijada, hozircha EACH_QUORUM yozish uchun izchillik darajasida, o'qish uchun esa - LOCAL_QUORUM
Qisqacha taassurotlar va xulosalar
Olingan yechimni operatsion qo'llab-quvvatlash va keyingi rivojlanish istiqbollari nuqtai nazaridan baholash uchun biz bunday rivojlanishni yana qayerda qo'llash mumkinligi haqida o'ylashga qaror qildik.
Darhol “Qulay bo‘lganda to‘lash” kabi dasturlar uchun ma’lumotlarni baholash (biz C* ga ma’lumot yuklaymiz, Spark skriptlari yordamida hisoblaymiz), hududlar bo‘yicha jamlagan holda da’volarni hisobga olish, rollarni saqlash va rol asosida foydalanuvchi kirish huquqlarini hisoblash. matritsa.
Ko'rib turganingizdek, repertuar keng va rang-barang. Va agar biz NoSQL tarafdorlari/opponentlari lagerini tanlasak, unda biz tarafdorlarga qo'shilamiz, chunki biz o'z afzalliklarimizni va biz kutgan joyda oldik.
Hatto qutidan tashqarida joylashgan Cassandra opsiyasi ham tizimdagi ma'lumotlarni ko'paytirish masalasini mutlaqo og'riqsiz hal qilib, real vaqt rejimida gorizontal o'lchash imkonini beradi. Biz qo'ng'iroqlar agregatlarini hisoblash uchun juda yuqori yuk mexanizmini alohida sxemaga ko'chirishga muvaffaq bo'ldik, shuningdek, ma'lumotlar bazasining o'zida maxsus ishlar va ob'ektlarni yozishning yomon amaliyotidan xalos bo'lgan holda dastur sxemasi va mantig'ini ajratib oldik. Biz tanlash va sozlash, tezlashtirish imkoniyatiga ega bo'ldik, biz qaysi DClarda hisob-kitoblarni amalga oshiramiz va qaysilarida ma'lumotlarni yozamiz, biz o'zimizni alohida tugunlarning va umuman DCning ishdan chiqishidan sug'urta qildik.
Arxitekturamizni yangi loyihalarga qo'llagan holda va allaqachon biroz tajribaga ega bo'lgan holda, men yuqorida tavsiflangan nuanslarni darhol hisobga olishni va ba'zi xatolarga yo'l qo'ymaslikni, dastlab oldini olish mumkin bo'lmagan o'tkir burchaklarni tekislashni istardim.
Misol uchun, Kassandraning yangilanishlarini o'z vaqtida kuzatib boringchunki biz duch kelgan muammolarning bir qanchasi allaqachon ma'lum va tuzatilgan edi.
Ma'lumotlar bazasini ham, Sparkni ham bir xil tugunlarga qo'ymang (yoki qat'iy ravishda ruxsat etilgan resurslardan foydalanish miqdoriga bo'linadi), chunki Spark kutilganidan ko'ra ko'proq OP iste'mol qilishi mumkin va biz tezda ro'yxatimizdan 1-sonli muammoni olamiz.
Loyihani sinovdan o'tkazish bosqichida monitoring va operatsion malakani oshirish. Dastlab, iloji boricha bizning yechimimizning barcha potentsial iste'molchilarini hisobga oling, chunki ma'lumotlar bazasi tuzilishi oxir-oqibat nimaga bog'liq bo'ladi.
Olingan sxemani mumkin bo'lgan optimallashtirish uchun bir necha marta aylantiring. Qaysi maydonlarni ketma-ketlashtirish mumkinligini tanlang. To'g'ri va eng maqbul tarzda hisobga olish uchun qanday qo'shimcha jadvallarni tuzishimiz kerakligini tushunib oling va so'ngra so'rov bo'yicha kerakli ma'lumotlarni taqdim eting (masalan, biz bir xil ma'lumotlarni turli jadvallarda saqlashimiz mumkin, deb hisoblab, turli xil taqsimotlarni hisobga olgan holda). turli mezonlar, biz o'qish so'rovlari uchun CPU vaqtini sezilarli darajada tejashimiz mumkin).
Yomon emas Darhol TTLni biriktirish va eskirgan ma'lumotlarni tozalashni ta'minlang.
Cassandra'dan ma'lumotlarni yuklab olishda Ilova mantig'i FETCH printsipi bo'yicha ishlashi kerak, shuning uchun barcha qatorlar bir vaqtning o'zida xotiraga yuklanmaydi, lekin to'plamlarda tanlanadi.
Loyihani tavsiflangan yechimga o'tkazishdan oldin tavsiya etiladi bir qator halokat testlarini o'tkazish orqali tizimning nosozliklarga chidamliligini tekshiring, masalan, bitta ma'lumot markazida ma'lumotlarning yo'qolishi, ma'lum vaqt davomida buzilgan ma'lumotlarni qayta tiklash, ma'lumotlar markazlari o'rtasida tarmoqning uzilishi. Bunday sinovlar nafaqat taklif qilingan arxitekturaning ijobiy va salbiy tomonlarini baholashga imkon beradi, balki ularni o'tkazayotgan muhandislar uchun yaxshi isitish amaliyotini ta'minlaydi va ishlab chiqarishda tizimdagi nosozliklar takrorlansa, olingan mahorat ortiqcha bo'lmaydi.
Agar biz muhim ma'lumotlar bilan ishlayotgan bo'lsak (masalan, hisob-kitoblar uchun ma'lumotlar, abonent qarzini hisoblash), unda DBMS xususiyatlari tufayli yuzaga keladigan xavflarni kamaytiradigan vositalarga ham e'tibor qaratish lozim. Masalan, nodesync yordam dasturidan (Datastax) foydalaning, undan foydalanish uchun optimal strategiyani ishlab chiqing. mustahkamlik uchun Kassandraga ortiqcha yuk yaratmang va faqat ma'lum bir davrdagi ma'lum jadvallar uchun foydalaning.
Olti oylik hayotdan keyin Kassandra bilan nima sodir bo'ladi? Umuman olganda, hal qilinmagan muammolar yo'q. Shuningdek, biz jiddiy baxtsiz hodisalar yoki ma'lumotlar yo'qolishiga yo'l qo'ymadik. Ha, biz ilgari paydo bo'lmagan ba'zi muammolarni bartaraf etish haqida o'ylashimiz kerak edi, lekin oxir-oqibat bu bizning me'moriy yechimimizni xira qilmadi. Agar siz yangi narsani sinab ko'rishni xohlasangiz va qo'rqmasangiz va shu bilan birga umidsizlikka tushishni xohlamasangiz, unda hech narsa bepul emasligiga tayyor bo'ling. Siz tushunishingiz, hujjatlarni o'rganishingiz va o'zingizning shaxsiy rakengizni eski eski yechimga qaraganda ko'proq yig'ishingiz kerak bo'ladi va hech qanday nazariya sizni qaysi rake kutayotganini oldindan aytib bermaydi.
Manba: www.habr.com