Salom, Xabr.
Mening ismim Misha Butimov, men sizga Kassandra haqida bir oz gapirib bermoqchiman. Mening hikoyam NoSQL ma'lumotlar bazalarini hech qachon uchratmaganlar uchun foydali bo'ladi - unda siz bilishingiz kerak bo'lgan juda ko'p dastur xususiyatlari va tuzoqlari mavjud. Va agar siz Oracle yoki boshqa relyatsion ma'lumotlar bazasidan boshqa hech narsani ko'rmagan bo'lsangiz, bu narsalar hayotingizni saqlab qoladi.
Kassandraning nimasi yaxshi? Bu NoSQL ma'lumotlar bazasi bo'lib, yaxshi miqyosda bitta nosozliksiz ishlab chiqilgan. Agar siz ba'zi ma'lumotlar bazasi uchun bir necha terabayt qo'shishingiz kerak bo'lsa, siz shunchaki ringga tugunlarni qo'shasiz. Uni boshqa maʼlumotlar markaziga kengaytirasizmi? Klasterga tugunlarni qo'shing. Qayta ishlangan RPSni oshirasizmi? Klasterga tugunlarni qo'shing. U ham teskari yo'nalishda ishlaydi.
U yana nimada yaxshi? Bu juda ko'p so'rovlarni ko'rib chiqish haqida. Lekin qancha ko'p? Bir soniyada 10, 20, 30, 40 ming so'rovlar ko'p emas. Yozish uchun soniyada 100 ming so'rov - ham. Bir soniyada 2 million so'rovni ushlab turishini aytgan kompaniyalar bor. Ehtimol, ular bunga ishonishlari kerak.
Va printsipial jihatdan, Kassandraning relyatsion ma'lumotlardan bitta katta farqi bor - bu ularga umuman o'xshamaydi. Va buni eslash juda muhimdir.
Bir xil ko'rinishdagi hamma narsa bir xil ishlamaydi
Bir kuni bir hamkasbim yonimga kelib, so'radi: “Mana bu CQL Cassandra so'rovlar tili va unda tanlangan bayonot bor, qaerda, bor va bor. Men xat yozaman, u ishlamayapti. Nega?". Kassandraga aloqador ma'lumotlar bazasi sifatida munosabatda bo'lish - zo'ravonlik bilan o'z joniga qasd qilishning eng zo'r usuli. Va men buni targ'ib qilmayapman, bu Rossiyada taqiqlangan. Siz shunchaki noto'g'ri loyihalashtirasiz.
Masalan, mijoz bizga kelib shunday deydi: “Keling, teleseriallar uchun ma’lumotlar bazasi yoki retseptlar katalogi uchun ma’lumotlar bazasi yarataylik. Bizda u yerda taomlar yoki seriallar va aktyorlar ro‘yxati bo‘ladi”. Biz xursandchilik bilan aytamiz: "Ketdik!" Faqat ikki bayt, bir nechta belgilar yuboring va siz tugatdingiz, hamma narsa juda tez va ishonchli ishlaydi. Mijozlar kelib, uy bekalari ham teskari muammoni hal qilishayotganini aytmaguncha hammasi joyida: ularda mahsulotlar ro‘yxati bor va ular qanday taom tayyorlashni xohlashlarini bilishni xohlashadi. Siz o'lgansiz.
Buning sababi, Cassandra gibrid ma'lumotlar bazasi: u bir vaqtning o'zida asosiy qiymatni beradi va ma'lumotlarni keng ustunlarda saqlaydi. Java yoki Kotlinda buni quyidagicha tasvirlash mumkin:
Map<RowKey, SortedMap<ColumnKey, ColumnValue>>
Ya'ni, tartiblangan xaritani ham o'z ichiga olgan xarita. Ushbu xaritaning birinchi kaliti Qator tugmasi yoki Bo'lim kaliti - bo'lim kalitidir. Allaqachon tartiblangan xaritaning kaliti bo'lgan ikkinchi kalit Klasterlash kalitidir.
Ma'lumotlar bazasining taqsimlanishini tasvirlash uchun uchta tugunni chizamiz. Endi siz ma'lumotlarni tugunlarga qanday ajratishni tushunishingiz kerak. Chunki agar biz hamma narsani bittaga yig'sak (aytmoqchi, ming, ikki ming, beshta bo'lishi mumkin - siz xohlaganingizcha), bu aslida tarqatish haqida emas. Shuning uchun bizga raqamni qaytaradigan matematik funktsiya kerak. Faqat raqam, ba'zi bir diapazonga tushadigan uzun int. Va bizda bitta diapazon uchun mas'ul bo'lgan bitta tugun bo'ladi, ikkinchisi ikkinchi, n-chi n uchun.
Bu raqam xesh funktsiyasi yordamida olinadi, bu biz Bo'lim kaliti deb ataydigan narsaga qo'llaniladi. Bu birlamchi kalit direktivasida ko'rsatilgan ustun va bu ustun xaritaning birinchi va eng asosiy kaliti bo'ladi. Qaysi tugun qaysi ma'lumotlarni qabul qilishini aniqlaydi. Jadval Cassandra-da SQL-dagi kabi deyarli bir xil sintaksis bilan yaratilgan:
CREATE TABLE users (
user_id uu id,
name text,
year int,
salary float,
PRIMARY KEY(user_id)
)
Bu holda birlamchi kalit bitta ustundan iborat bo'lib, u ham bo'lish kalitidir.
Bizning foydalanuvchilarimiz qanday ishlaydi? Ba'zilar bir tugunga, boshqalari boshqasiga, ba'zilari uchinchisiga o'tadi. Natijada oddiy xesh-jadval, shuningdek, xarita sifatida ham tanilgan, Python-da lug'at sifatida ham tanilgan yoki oddiy kalit qiymat strukturasi bo'lib, biz barcha qiymatlarni o'qiymiz, kalit orqali o'qiymiz va yozishimiz mumkin.
Tanlang: filtrlash toʻliq skanerlashga ruxsat berilganda yoki nima qilmaslik kerak
Keling, bir nechta tanlangan bayonot yozamiz: select * from users where, userid = . Bu Oracle-da bo'lgani kabi bo'lib chiqdi: biz tanlashni yozamiz, shartlarni belgilaymiz va hamma narsa ishlaydi, foydalanuvchilar buni olishadi. Ammo, masalan, ma'lum bir tug'ilgan yili bo'lgan foydalanuvchini tanlasangiz, Kassandra so'rovni bajara olmasligidan shikoyat qiladi. Chunki u tug'ilgan yili haqidagi ma'lumotlarni qanday tarqatishimiz haqida umuman hech narsa bilmaydi - uning kalit sifatida faqat bitta ustuni bor. Keyin u: “Yaxshi, men hali ham bu iltimosni bajara olaman. Filtrlashga ruxsat berishni qo'shing." Biz direktivani qo'shamiz, hamma narsa ishlaydi. Va bu vaqtda dahshatli narsa yuz beradi.
Sinov ma'lumotlarini ishga tushirganimizda, hamma narsa yaxshi. Va ishlab chiqarishda so'rovni bajarganingizda, masalan, bizda 4 million yozuv mavjud bo'lsa, unda hamma narsa biz uchun unchalik yaxshi emas. Chunki filtrlashga ruxsat berish - bu Kassandraga ushbu jadvaldagi barcha tugunlardan, barcha ma'lumotlar markazlaridan (agar ular ushbu klasterda ko'p bo'lsa) to'plash va shundan keyingina uni filtrlash imkonini beruvchi ko'rsatma. Bu to'liq skanerlashning analogidir va deyarli hech kim undan mamnun emas.
Agar bizga faqat identifikatori bo'yicha foydalanuvchi kerak bo'lsa, bu bilan yaxshi bo'lar edik. Ammo ba'zida biz boshqa so'rovlarni yozishimiz va tanlovga boshqa cheklovlar qo'yishimiz kerak. Shuning uchun biz eslaymiz: bularning barchasi bo'linish kalitiga ega bo'lgan xaritadir, lekin uning ichida tartiblangan xarita mavjud.
Va uning kaliti ham bor, biz uni Klaster kaliti deb ataymiz. Bu kalit, o'z navbatida, biz tanlagan ustunlardan iborat bo'lib, uning yordami bilan Kassandra uning ma'lumotlari jismoniy tartiblanganligini va har bir tugunda joylashganligini tushunadi. Ya'ni, ba'zi Bo'lim kalitlari uchun Klasterlash kaliti sizga ma'lumotlarni ushbu daraxtga qanday kiritish kerakligini va u erda qanday joyni egallashini aniq aytib beradi.
Bu haqiqatan ham daraxt, solishtirgich shunchaki chaqiriladi, unga biz ob'ekt shaklida ma'lum ustunlar to'plamini o'tkazamiz va u ustunlar ro'yxati sifatida ham ko'rsatilgan.
CREATE TABLE users_by_year_salary_id (
user_id uuid,
name text,
year int,
salary float,
PRIMARY KEY((year), salary, user_id)
Birlamchi kalit direktivasiga e'tibor bering; uning birinchi argumenti (bizning holatda, yil) har doim Bo'lim kalitidir. U bir yoki bir nechta ustunlardan iborat bo'lishi mumkin, bu muhim emas. Agar bir nechta ustunlar mavjud bo'lsa, uni yana qavslar ichida olib tashlash kerak, shunda tilni oldindan protsessor bu Asosiy kalit ekanligini va uning orqasida qolgan barcha ustunlar Klasterlash kaliti ekanligini tushunishi kerak. Bunday holda, ular paydo bo'lish tartibida komparatorda uzatiladi. Ya'ni, birinchi ustun muhimroq, ikkinchisi kamroq ahamiyatga ega va hokazo. Masalan, biz qanday yozishimiz ma'lumotlar sinflari uchun maydonlarga teng: biz maydonlarni sanab o'tamiz va ular uchun qaysi biri kattaroq va qaysi biri kichikroq ekanligini yozamiz. Kassandrada bular, nisbatan aytganda, ma'lumotlar sinfining maydonlari bo'lib, ular uchun yozilgan tenglar qo'llaniladi.
Biz tartiblashni o'rnatamiz va cheklovlar qo'yamiz
Shuni esda tutish kerakki, tartiblash tartibi (kamayish, o'sish, nima bo'lishidan qat'iy nazar) kalit yaratilgan paytda o'rnatiladi va uni keyinroq o'zgartirib bo'lmaydi. Bu ma'lumotlarning qanday tartiblanishi va qanday saqlanishini jismonan aniqlaydi. Agar siz Klasterlash kalitini yoki tartiblash tartibini o'zgartirishingiz kerak bo'lsa, siz yangi jadval yaratishingiz va unga ma'lumotlarni uzatishingiz kerak bo'ladi. Bu mavjud bilan ishlamaydi.
Biz stolimizni foydalanuvchilar bilan to'ldirdik va ular avval tug'ilgan yili bo'yicha, keyin esa har bir tugunning ichida ish haqi va foydalanuvchi identifikatori bo'yicha halqaga tushib qolganini ko'rdik. Endi biz cheklovlar qo'yish orqali tanlashimiz mumkin.
Bizning ishlayotganimiz yana paydo bo'ladi where, and, va biz foydalanuvchilarni olamiz va yana hamma narsa yaxshi. Ammo agar biz Klasterlash kalitining faqat bir qismidan va unchalik ahamiyatli bo'lmaganidan foydalanishga harakat qilsak, Kassandra darhol xaritamizda null komparator uchun ushbu maydonlarga ega bo'lgan ushbu ob'ekt va bu joyni topa olmasligidan shikoyat qiladi. Bu hozirgina o'rnatildi , - u qaerda yotadi. Men ushbu tugundagi barcha ma'lumotlarni yana tortib olishim va uni filtrlashim kerak. Va bu tugun ichidagi Full Scanning analogidir, bu yomon.
Har qanday noaniq vaziyatda yangi jadval yarating
Agar biz foydalanuvchilarni identifikatori, yoshi yoki maoshi bo'yicha maqsad qilib olmoqchi bo'lsak, nima qilishimiz kerak? Hech narsa. Faqat ikkita jadvaldan foydalaning. Agar siz foydalanuvchilarga uch xil usulda murojaat qilishingiz kerak bo'lsa, uchta jadval mavjud. Vidada joyni saqlab qolgan kunlar o'tdi. Bu eng arzon resurs. Bu javob vaqtidan ancha kam xarajat qiladi, bu esa foydalanuvchiga zarar etkazishi mumkin. Foydalanuvchi uchun 10 daqiqadan ko'ra bir soniyada biror narsani olish ancha yoqimli.
Biz yaxshi o'lchov va ishonchli ishlash qobiliyati uchun keraksiz joy va normalizatsiya qilingan ma'lumotlarni almashtiramiz. Axir, aslida, har birida beshta tugunga ega bo'lgan, ma'lumotlarni saqlashning maqbul darajasiga ega (hech narsa yo'qolmaganda) uchta ma'lumot markazidan iborat klaster bitta ma'lumot markazining o'limidan butunlay omon qolishi mumkin. Va qolgan ikkitasining har birida yana ikkita tugun. Va shundan keyingina muammolar boshlanadi. Bu juda yaxshi ortiqcha, u bir nechta qo'shimcha SSD drayvlar va protsessorlarga arziydi. Shuning uchun, hech qachon SQL bo'lmagan, aloqalar, xorijiy kalitlar mavjud bo'lmagan Cassandra-dan foydalanish uchun siz oddiy qoidalarni bilishingiz kerak.
Biz hamma narsani sizning so'rovingiz bo'yicha loyihalashtiramiz. Asosiysi, ma'lumotlar emas, balki dastur u bilan qanday ishlashi. Agar u turli xil ma'lumotlarni turli yo'llar bilan yoki bir xil ma'lumotlarni turli yo'llar bilan olishi kerak bo'lsa, biz uni dastur uchun qulay bo'lgan tarzda joylashtirishimiz kerak. Aks holda, biz to'liq skanerlashda muvaffaqiyatsizlikka uchraymiz va Kassandra bizga hech qanday afzallik bermaydi.
Ma'lumotlarni normalizatsiya qilish odatiy holdir. Biz oddiy shakllarni unutamiz, endi bizda relyatsion ma'lumotlar bazalari yo'q. Agar biror narsani 100 marta qo'ysak, u 100 marta yotadi. Bu hali ham to'xtashdan ko'ra arzonroq.
Biz bo'linish uchun kalitlarni tanlaymiz, shunda ular normal taqsimlanadi. Biz kalitlarimizning xeshlari bitta tor doiraga tushishini istamaymiz. Ya'ni, yuqoridagi misolda tug'ilgan yil yomon misoldir. Aniqrog'i, foydalanuvchilarimiz tug'ilgan yili bo'yicha normal taqsimlangan bo'lsa yaxshi, va agar 5-sinf o'quvchilari haqida gapiradigan bo'lsak, yomon - u erda bo'linish unchalik yaxshi bo'lmaydi.
Saralash Klaster kalitini yaratish bosqichida bir marta tanlanadi. Agar uni o'zgartirish kerak bo'lsa, biz jadvalimizni boshqa kalit bilan yangilashimiz kerak.
Va eng muhimi: agar biz bir xil ma'lumotlarni 100 xil usulda olishimiz kerak bo'lsa, bizda 100 xil jadval bo'ladi.
Manba: www.habr.com