Хеј Хабр.
Моје име је Миша Бутримов, желео бих да вам кажем нешто о Касандри. Моја прича ће бити корисна онима који се никада нису сусрели са НоСКЛ базама података - она има много карактеристика имплементације и замки о којима морате да знате. А ако нисте видели ништа осим Орацле-а или било које друге релационе базе података, ове ствари ће вам спасити живот.
Шта је тако добро код Касандре? То је НоСКЛ база података дизајнирана без иједне тачке квара која се добро скалира. Ако треба да додате пар терабајта за неку базу података, једноставно додате чворове у прстен. Проширити га на други центар података? Додајте чворове у кластер. Повећати обрађени РПС? Додајте чворове у кластер. Делује и у супротном смеру.
У чему је још добра? Ради се о обради великог броја захтева. Али колико је много? 10, 20, 30, 40 хиљада захтева у секунди није много. 100 хиљада захтева у секунди за снимање - такође. Постоје компаније које кажу да држе 2 милиона захтева у секунди. Вероватно ће морати да верују.
И у принципу, Касандра има једну велику разлику од релационих података – уопште није слична њима. И ово је веома важно запамтити.
Не ради све што изгледа исто
Једном ми је дошао колега и питао: „Ево ЦКЛ Цассандра језика упита, и он има наредбу за одабир, има где, има и. Пишем писма и не иде. Зашто?". Третирање Касандре као релационе базе података је савршен начин да се изврши насилно самоубиство. И не промовишем то, забрањено је у Русији. Само ћеш дизајнирати нешто погрешно.
На пример, дође нам купац и каже: „Хајде да направимо базу података за ТВ серије, или базу података за директоријум рецепата. Тамо ћемо имати јела са храном или списак ТВ серија и глумаца. Радосно кажемо: „Идемо! Само пошаљите два бајта, пар знакова и готови сте, све ће радити врло брзо и поуздано. И све је у реду док муштерије не дођу и кажу да домаћице решавају и супротан проблем: имају списак производа, а желе да знају које јело желе да кувају. Ти си мртав.
То је зато што је Цассандра хибридна база података: она истовремено пружа кључну вредност и складишти податке у широким колонама. У Јави или Котлину, то би се могло описати овако:
Map<RowKey, SortedMap<ColumnKey, ColumnValue>>
То јест, мапа која такође садржи сортирану мапу. Први кључ ове мапе је тастер за ред или партициони кључ - партициони кључ. Други кључ, који је кључ за већ сортирану мапу, је кључ за груписање.
Да бисмо илустровали дистрибуцију базе података, нацртајмо три чвора. Сада морате да разумете како да декомпонујете податке у чворове. Јер ако све стрпамо у једно (узгред, може их бити хиљаду, две хиљаде, пет – колико хоћете), овде се заправо и не ради о дистрибуцији. Стога нам је потребна математичка функција која ће вратити број. Само број, дуги инт који ће пасти у неки опсег. И имаћемо један чвор одговоран за један опсег, други за други, н-ти за н-ти.
Овај број се узима помоћу хеш функције, која се примењује на оно што називамо партиционим кључем. Ово је колона која је наведена у директиви о примарном кључу, а ово је колона која ће бити први и најосновнији кључ мапе. Одређује који чвор ће примити које податке. Табела је креирана у Цассандри са скоро истом синтаксом као у СКЛ-у:
CREATE TABLE users (
user_id uu id,
name text,
year int,
salary float,
PRIMARY KEY(user_id)
)
Примарни кључ се у овом случају састоји од једне колоне, а такође је и партициони кључ.
Како ће се понашати наши корисници? Неки ће ићи у један чвор, неки у други, а неки у трећи. Резултат је обична хеш табела, позната и као мапа, позната и као речник у Питхон-у, или једноставна структура вредности кључа из које можемо читати све вредности, читати и писати по кључу.
Изаберите: када се дозволи филтрирање претвори у потпуно скенирање или шта не треба радити
Хајде да напишемо неку изабрану изјаву: select * from users where, userid = . Испада као у Орацле-у: пишемо селецт, специфицирамо услове и све ради, корисници то добијају. Али ако изаберете, на пример, корисника са одређеном годином рођења, Касандра се жали да не може да испуни захтев. Пошто она уопште не зна ништа о томе како дистрибуирамо податке о години рођења - она има само једну колону означену као кључ. Онда она каже: „У реду, још увек могу да испуним овај захтев. Додајте дозвољено филтрирање." Додамо директиву, све функционише. И у овом тренутку се дешава нешто страшно.
Када радимо на тестним подацима, све је у реду. А када извршите упит у продукцији, где имамо, на пример, 4 милиона записа, онда нам није баш све добро. Зато што је дозвољено филтрирање директива која омогућава Цассандри да прикупи све податке из ове табеле са свих чворова, свих центара података (ако их има много у овом кластеру), а тек онда их филтрира. Ово је аналог Фулл Сцан и ретко ко је одушевљен њиме.
Да су нам потребни само корисници по ИД-у, ово би нам било у реду. Али понекад морамо да напишемо друге упите и наметнемо друга ограничења за избор. Стога, сећамо се: ово је све мапа која има кључ за партиционисање, али унутар ње је сортирана мапа.
И она такође има кључ, који ми зовемо кључ за груписање. Овај кључ, који се, пак, састоји од колона које бирамо, уз помоћ којих Касандра разуме како су њени подаци физички сортирани и биће смештени на сваком чвору. То јест, за неки партициони кључ, тастер за груписање ће вам рећи тачно како да гурнете податке у ово стабло, које место ће тамо заузети.
Ово је заиста дрво, тамо се једноставно позива компаратор, коме прослеђујемо одређени скуп колона у облику објекта, а такође се наводи као листа колона.
CREATE TABLE users_by_year_salary_id (
user_id uuid,
name text,
year int,
salary float,
PRIMARY KEY((year), salary, user_id)
Обратите пажњу на директиву о примарном кључу; њен први аргумент (у нашем случају, година) је увек партициони кључ. Може се састојати од једне или више колона, није битно. Ако постоји неколико колона, треба га поново уклонити у заградама да би језички предпроцесор схватио да је ово примарни кључ, а иза њега све остале колоне су кључ за груписање. У овом случају, они ће бити пренети у компаратору редоследом којим се појављују. Односно, прва колона је значајнија, друга мање значајна, итд. Начин на који пишемо, на пример, једнак је пољима за класе података: наводимо поља, а за њих пишемо која су већа, а која мања. У Касандри, то су, релативно говорећи, поља класе података, на која ће се применити једнаки за њу.
Постављамо сортирање и намећемо ограничења
Морате имати на уму да је редослед сортирања (силазни, растући, било који) постављен у истом тренутку када је кључ креиран и не може се касније променити. Она физички одређује како ће подаци бити сортирани и како ће се чувати. Ако треба да промените кључ за груписање или редослед сортирања, мораћете да креирате нову табелу и пренесете податке у њу. Ово неће радити са постојећим.
Попунили смо нашу табелу корисницима и видели да су упали у прстен, прво по години рођења, а затим унутра на сваком чвору по плати и ИД-у корисника. Сада можемо да бирамо наметањем ограничења.
Поново се појављује наш радни where, and, и добијамо кориснике, и опет је све у реду. Али ако покушамо да користимо само део кључа за груписање, и то мање значајан, онда ће се Касандра одмах пожалити да не може да пронађе место на нашој мапи где је овај објекат, који има ова поља за нулти компаратор, и овај који је управо постављен, - где лежи. Мораћу поново да извучем све податке са овог чвора и да их филтрирам. А ово је аналог пуног скенирања унутар чвора, ово је лоше.
У било којој нејасној ситуацији, направите нову табелу
Ако желимо да можемо да циљамо кориснике према ИД-у, или према годинама, или према плати, шта треба да радимо? Ништа. Користите само два стола. Ако треба да дођете до корисника на три различита начина, постојаће три табеле. Прошло је време када смо штедели простор на завртњу. Ово је најјефтинији ресурс. То кошта много мање од времена одговора, што може бити штетно за корисника. Кориснику је много пријатније да добије нешто у секунди него за 10 минута.
Ми мењамо непотребан простор и денормализоване податке за могућност доброг скалирања и поузданог рада. На крају крајева, у ствари, кластер који се састоји од три дата центра, од којих сваки има пет чворова, са прихватљивим нивоом очувања података (када ништа није изгубљено), у стању је да преживи смрт једног дата центра у потпуности. И још два чвора у сваком од преостала два. И тек након тога почињу проблеми. Ово је прилично добра редундантност, вреди неколико додатних ССД дискова и процесора. Стога, да бисте користили Цассандру, која никада није СКЛ, у којој нема релација, страних кључева, морате знати једноставна правила.
Дизајнирамо све по вашем захтеву. Главна ствар нису подаци, већ како ће апликација радити са њима. Ако треба да прими различите податке на различите начине или исте податке на различите начине, морамо их поставити на начин који је погодан за апликацију. У супротном, нећемо успети у Фулл Сцан и Касандра нам неће дати никакву предност.
Денормализација података је норма. Заборављамо на нормалне форме, више немамо релационе базе података. Ако нешто спустимо 100 пута, оно ће лежати 100 пута. И даље је јефтиније од заустављања.
Бирамо кључеве за партиционисање тако да се нормално дистрибуирају. Не желимо да хеш наших кључева падне у један уски опсег. Односно, година рођења у горњем примеру је лош пример. Тачније, добро је ако су наши корисници нормално распоређени по годинама рођења, а лоше ако је реч о ученицима 5. разреда - подела тамо неће бити баш добра.
Сортирање се бира једном у фази креирања кључа кластера. Ако треба да се промени, мораћемо да ажурирамо нашу табелу другим кључем.
И оно најважније: ако треба да преузмемо исте податке на 100 различитих начина, онда ћемо имати 100 различитих табела.
Извор: ввв.хабр.цом