Cassandra. Hvernig á ekki að deyja ef þú þekkir aðeins Oracle

Hæ Habr.

Ég heiti Misha Butrimov, mig langar að segja þér aðeins frá Cassöndru. Sagan mín mun nýtast þeim sem hafa aldrei kynnst NoSQL gagnagrunnum - hún hefur fullt af útfærslueiginleikum og gildrum sem þú þarft að vita um. Og ef þú hefur ekki séð neitt annað en Oracle eða einhvern annan venslagagnagrunn, munu þessir hlutir bjarga lífi þínu.

Hvað er svona gott við Cassöndru? Það er NoSQL gagnagrunnur sem er hannaður án eins bilunarpunkts sem mælist vel. Ef þú þarft að bæta við nokkrum terabætum fyrir einhvern gagnagrunn, bætirðu einfaldlega hnútum við hringinn. Stækka það í annað gagnaver? Bættu hnútum við þyrpinguna. Auka unnu RPS? Bættu hnútum við þyrpinguna. Það virkar líka í gagnstæða átt.

Hvað er hún annars góð í? Þetta snýst um að afgreiða mikið af beiðnum. En hvað er mikið? 10, 20, 30, 40 þúsund beiðnir á sekúndu er ekki mikið. 100 þúsund beiðnir á sekúndu fyrir upptöku - líka. Það eru fyrirtæki sem sögðust halda 2 milljón beiðnum á sekúndu. Þeir verða líklega að trúa því.

Og í grundvallaratriðum er einn stór munur á Cassandra frá tengslagögnum - þau eru alls ekki lík þeim. Og þetta er mjög mikilvægt að muna.

Ekki allt sem lítur eins út virkar eins

Einu sinni kom samstarfsmaður til mín og spurði: „Hér er CQL Cassandra fyrirspurnartungumál, og það hefur valið, það hefur hvar, það hefur og. Ég skrifa bréf og það virkar ekki. Hvers vegna?". Að meðhöndla Cassöndru eins og tengslagagnagrunn er fullkomin leið til að fremja ofbeldisfullt sjálfsvíg. Og ég er ekki að kynna það, það er bannað í Rússlandi. Þú munt bara hanna eitthvað vitlaust.

Til dæmis kemur viðskiptavinur til okkar og segir: „Búum til gagnagrunn fyrir sjónvarpsþætti, eða gagnagrunn fyrir uppskriftaskrá. Þar verðum við með matarrétti eða lista yfir sjónvarpsþætti og leikara í honum.“ Við segjum glöð: „Við skulum fara! Sendu bara tvö bæti, nokkur merki og þú ert búinn, allt mun virka mjög hratt og áreiðanlega. Og allt er í lagi þar til viðskiptavinirnir koma og segja að húsmæður séu líka að leysa hið gagnstæða vandamál: þær eru með vörulista og þær vilja vita hvaða rétt þær vilji elda. Þú ert dauður.

Þetta er vegna þess að Cassandra er blendingur gagnagrunnur: hann gefur samtímis lykilgildi og geymir gögn í breiðum dálkum. Í Java eða Kotlin gæti það verið lýst svona:

Map<RowKey, SortedMap<ColumnKey, ColumnValue>>

Það er að segja kort sem inniheldur líka flokkað kort. Fyrsti lykillinn að þessu korti er Row lykillinn eða Partition lykillinn - skipting lykillinn. Annar lykillinn, sem er lykillinn að þegar flokkuðu korti, er Clustering lykillinn.

Til að sýna dreifingu gagnagrunnsins skulum við teikna þrjá hnúta. Nú þarftu að skilja hvernig á að sundra gögnunum í hnúta. Vegna þess að ef við ýtum öllu í einn (við the vegur, það geta verið þúsund, tvö þúsund, fimm - eins margir og þú vilt), þá snýst þetta í raun ekki um dreifingu. Þess vegna þurfum við stærðfræðilegt fall sem mun skila tölu. Bara tala, langur int sem mun falla á einhverju sviði. Og fyrir okkur mun einn hnút vera ábyrgur fyrir einu sviði, annað - fyrir annað, það n. - fyrir það n.

Þetta númer er tekið með því að nota kjötkássaaðgerð, sem er notuð á það sem við köllum skiptingarlykilinn. Þetta er dálkurinn sem er tilgreindur í aðallyklatilskipuninni og þetta er sá dálkur sem verður fyrsti og grunnlykillinn á kortinu. Það ákvarðar hvaða hnút mun fá hvaða gögn. Tafla er búin til í Cassandra með næstum sömu setningafræði og í SQL:

CREATE TABLE users (
	user_id uu id,
	name text,
	year int,
	salary float,
	PRIMARY KEY(user_id)

)

Aðallykillinn í þessu tilfelli samanstendur af einum dálki og það er einnig skiptingarlykillinn.

Hvernig munu notendur okkar standa sig? Sumir fara í einn hnút, sumir í annan og sumir í þriðja. Niðurstaðan er venjuleg kjötkássatafla, einnig þekkt sem kort, einnig þekkt sem orðabók í Python, eða einföld lykilgildauppbygging þar sem við getum lesið öll gildin, lesið og skrifað eftir lykli.

Veldu: þegar leyfa síun breytist í fulla skönnun, eða hvað á ekki að gera

Við skulum skrifa nokkrar valdar fullyrðingar: select * from users where, userid = . Það kemur út eins og í Oracle: við skrifum select, tilgreinum skilyrðin og allt virkar, notendur fá það. En ef þú velur til dæmis notanda með ákveðið fæðingarár kvartar Cassandra yfir því að hann geti ekki uppfyllt beiðnina. Vegna þess að hún veit ekki neitt um hvernig við dreifum gögnum um fæðingarárið - hún hefur aðeins einn dálk tilgreindan sem lykil. Þá segir hún: „Allt í lagi, ég get samt uppfyllt þessa beiðni. Bæta við leyfa síun." Við bætum við tilskipuninni, allt virkar. Og á þessari stundu gerist eitthvað hræðilegt.

Þegar við keyrum á prófunargögnum er allt í lagi. Og þegar þú framkvæmir fyrirspurn í framleiðslu, þar sem við höfum til dæmis 4 milljónir gagna, þá er allt ekki mjög gott fyrir okkur. Vegna þess að leyfa síun er tilskipun sem gerir Cassandra kleift að safna öllum gögnum úr þessari töflu frá öllum hnútum, öllum gagnaverum (ef þær eru margar í þessum klasa), og aðeins þá sía þau. Þetta er hliðstæða við Full Scan og varla nokkur maður er ánægður með það.

Ef við þyrftum aðeins notendur með auðkenni, þá værum við í lagi með þetta. En stundum þurfum við að skrifa aðrar fyrirspurnir og setja aðrar takmarkanir á valið. Þess vegna munum við: þetta er allt kort sem hefur skiptingarlykil, en inni í því er flokkað kort.

Og hún er líka með lykil, sem við köllum Clustering Key. Þessi lykill, sem aftur á móti samanstendur af dálkunum sem við veljum, með hjálp sem Cassandra skilur hvernig gögn hans eru flokkuð líkamlega og verða staðsett á hverjum hnút. Það er, fyrir einhvern skiptingarlykla mun Clustering lykillinn segja þér nákvæmlega hvernig á að ýta gögnunum inn í þetta tré, hvaða stað það mun taka þar.

Þetta er í raun tré, þar er einfaldlega kallaður samanburður, sem við sendum tiltekið sett af dálkum í formi hlutar og það er líka tilgreint sem listi yfir dálka.

CREATE TABLE users_by_year_salary_id (
	user_id uuid,
	name text,
	year int,
	salary float,
	PRIMARY KEY((year), salary, user_id)

Gefðu gaum að aðallyklatilskipuninni; fyrsta rök hennar (í okkar tilfelli, árið) er alltaf skiptingarlykill. Það getur samanstendur af einum eða fleiri dálkum, það skiptir ekki máli. Ef það eru nokkrir dálkar þarf að fjarlægja hann innan sviga aftur svo að tungumálaforvinnslan skilji að þetta er aðallykillinn og á bak við hann eru allir hinir dálkarnir Clustering lykillinn. Í þessu tilviki verða þau send í samanburðartækinu í þeirri röð sem þau birtast. Það er að segja að fyrsti dálkurinn er marktækari, sá síðari er minni og svo framvegis. Hvernig við skrifum, til dæmis, jafngildir reitum fyrir gagnaflokka: við skráum reitina og fyrir þá skrifum við hverjir eru stærri og hverjir eru minni. Í Cassöndru eru þetta, tiltölulega séð, svið gagnaklasans, sem jafngildir sem skrifaðir eru fyrir hann verða notaðir á.

Við setjum flokkun og setjum takmarkanir

Þú þarft að muna að flokkunarröðin (lækkandi, hækkandi, hvað sem er) er stillt á sama augnabliki og lykillinn er búinn til og henni er ekki hægt að breyta síðar. Það ákvarðar líkamlega hvernig gögnin verða flokkuð og hvernig þau verða geymd. Ef þú þarft að breyta klasalyklinum eða flokkunarröð, verður þú að búa til nýja töflu og flytja gögn inn í hana. Þetta mun ekki virka með núverandi.

Við fylltum borðið okkar af notendum og sáum að þeir féllu í hring, fyrst eftir fæðingarári, og svo inni á hverjum hnút eftir launum og notandakenni. Nú getum við valið með því að setja takmarkanir.

Vinnandi okkar birtist aftur where, and, og við fáum notendur, og allt er í lagi aftur. En ef við reynum að nota aðeins hluta af Clustering lyklinum, og minna mikilvægan, þá mun Cassandra strax kvarta yfir því að hún geti ekki fundið staðinn á kortinu okkar þar sem þessi hlutur, sem hefur þessa reiti fyrir núllsamanburðinn, og þessi. það var bara sett , - þar sem hann liggur. Ég verð að draga upp öll gögn frá þessum hnút aftur og sía þau. Og þetta er hliðstæða við Full Scan innan hnút, þetta er slæmt.

Í öllum óljósum aðstæðum skaltu búa til nýja töflu

Ef við viljum geta miðað á notendur eftir auðkenni, eða eftir aldri eða eftir launum, hvað ættum við að gera? Ekkert. Notaðu bara tvö borð. Ef þú þarft að ná til notenda á þrjá mismunandi vegu verða þrjár töflur. Þeir dagar eru liðnir þegar við björguðum plássi á skrúfunni. Þetta er ódýrasta auðlindin. Það kostar mun minna en viðbragðstíma, sem getur verið skaðlegt fyrir notandann. Það er mun notalegra fyrir notandann að fá eitthvað á sekúndu en á 10 mínútum.

Við skiptum út óþarfa plássi og óeðlileg gögn fyrir getu til að skala vel og starfa áreiðanlega. Þegar öllu er á botninn hvolft, í raun, getur þyrping sem samanstendur af þremur gagnaverum, sem hver um sig hefur fimm hnúta, með ásættanlegu stigi gagnavarðveislu (þegar ekkert tapast), lifað dauða eins gagnavers alveg af. Og tveir hnútar í viðbót í hverjum hinna tveggja sem eftir eru. Og aðeins eftir þetta byrja vandamálin. Þetta er nokkuð góð offramboð, það er þess virði að fá nokkra auka SSD drif og örgjörva. Þess vegna, til þess að nota Cassandra, sem er aldrei SQL, þar sem engin sambönd eru, erlendir lyklar, þarftu að þekkja einfaldar reglur.

Við hönnum allt í samræmi við beiðni þína. Aðalatriðið er ekki gögnin, heldur hvernig forritið mun vinna með þau. Ef það þarf að taka við mismunandi gögnum á mismunandi hátt eða sömu gögnum á mismunandi hátt verðum við að setja þau á þann hátt sem hentar forritinu. Annars munum við mistakast í fullri skönnun og Cassandra mun ekki gefa okkur neitt forskot.

Afeðlun gagna er normið. Við gleymum venjulegum formum, við höfum ekki lengur venslagagnagrunna. Ef við leggjum eitthvað niður 100 sinnum, þá leggst það niður 100 sinnum. Það er samt ódýrara en að hætta.

Við veljum lyklana fyrir skiptingu þannig að þeir dreifist eðlilega. Við viljum ekki að kjötkássa lyklana okkar falli í eitt þröngt svið. Það er að segja að fæðingarárið í dæminu hér að ofan er slæmt dæmi. Nánar tiltekið er gott ef notendur okkar eru normaldreifðir eftir fæðingarárum og slæmt ef við erum að tala um nemendur í 5. bekk - skiptingin þar verður ekki mjög góð.

Flokkun er valin einu sinni á stigi Clustering Key stofnunar. Ef það þarf að breyta því verðum við að uppfæra töfluna okkar með öðrum lykli.

Og það mikilvægasta: ef við þurfum að sækja sömu gögnin á 100 mismunandi vegu, þá munum við hafa 100 mismunandi töflur.

Heimild: www.habr.com