Cassandra. Как да не умреш, ако знаеш само Oracle

Здравей, Хабр.

Казвам се Миша Бутримов и искам да разкажа малко за Cassandra. Моят разказ ще бъде полезен за тези, които никога не са имали работа с NoSQL бази, тъй като тя има много спецификации и подводни камъни, за които е важно да знаете. И ако освен Oracle или друга релационна база не сте виждали нищо, тези неща ще ви спасят живота.

Какво е хубавото на Cassandra? Това е NoSQL база данни, проектирана без единна точка на отказ, която се мащабира добре. Ако трябва да добавите няколко терабайта към някоя база, просто добавяте възли в клъстера. Искате да я разширите в нов дата център? Добавяте възли в клъстера. Трябва да увеличите обработваните RPS? Добавяте възли в клъстера. И обратното също работи.

В какво още е добра? В обработката на много заявки. Но много — това колко е? 10, 20, 30, 40 хиляди заявки в секунда — това е малко. 100 хиляди заявки в секунда за запис — също. Има компании, които твърдят, че залагат 2 милиона заявки в секунда. На тях, вероятно, ще трябва да повярвате.

И в принципе, Cassandra има едно голямо отличие от релационните данни — тя въобще не прилича на тях. И е важно да го запомните.

Не всичко, което изглежда еднакво, работи по един и същи начин.

Веднъж идва при мен колега и пита: "Ето, СQL Cassandra query language, има select statement, има where, има and. Пиша букви и не работи. Защо?". Ако се отнасяте към Cassandra като релационна база данни, това е идеален начин да приключите живота си по жесток начин. И не го пропагандирам, това е забранено в Русия. Просто ще проектирате нещо неправилно.

Например, идва при нас клиент и казва: "Нека изградим база данни за сериалите или база данни за справочника на рецепти. Ще имаме ястия с продукти или списък на сериалите и актьорите в тях". Ние радостно отговаряме: "Нека!". Това са два байта да прехвърлим, няколко таблици и всичко е готово, всичко ще работи много бързо, надеждно. И всичко е прекрасно, докато клиентите не дойдат и не кажат, че домакините решават и обратния проблем: те имат списък с продукти и искат да знаят какво ястие могат да приготвят. Вие сте мъртви.

Всичко е, защото Cassandra е хибридна база данни: тя е едновременно и key value, и съхранява данни в широки колони. Ако говорим на Java или Kotlin, може да се опише по следния начин:

Map<RowKey, SortedMap>

Т.е. карта, в която има и сортирана карта. Първият ключ за тази карта е Row key или Partition key — ключ за партициониране. Вторият ключ, който е ключ за вече сортираната карта, е Clustering key.

За илюстрация на разпределеността на базата данни нарисувайте три ноди. Сега трябва да разберем как да разпределим данните по нодовете. Защото ако сложим всичко в един (а те могат да бъдат хиляда, две хиляди, пет — колкото искате), това не е особено разпределено. Затова ни е нужна математическа функция, която ще връща число. Просто число, дълъг int, който ще попада в определен диапазон. И една нода ще отговаря за един диапазон, втората — за втори, n-тата — за n-тия.

Това число се взима с помощта на хеш-функция, която се прилага към това, което наричаме Partition key. Това е колоната, която се посочва в директивата Primary key, и това е колоната, която ще бъде първият и основен ключ на картата. Тя определя, в коя нода ще попаднат какви данни. Таблицата се създава в Cassandra почти с такъв същия синтаксис, както в SQL:

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

)

Primary key в този случай се състои от една колона, която също е ключ за партициониране.

Как ще се разпределят потребителите? Част от тях ще попаднат на една нода, част — на друга, и част — на трета. Получава се обикновена хеш-таблица, т.е. карта, а в Python — речник, също така — проста key value структура, от която можем да четем всички стойности, да четем и пишем по ключ.

Select: когато allow filtering се превръща в пълен скан, или как не трябва да се прави

Нека напишем някакъв select statement: select * from users where userid = . Изглежда, че е като в Oracle: пишем select, указваме условията и всичко работи, потребителите се извличат. Но ако изберем, например, потребител с определена година на раждане, Cassandra издава грешка, че не може да изпълни записа. Защото не знае как се разпределят данните за година на раждане — имаме само една колона като ключ. Тогава тя казва: «Добре, мога все пак да изпълня този запит. Добавете allow filtering». Добавяме директивата, всичко работи. И в този момент се случва нещо ужасно.

Когато работим с тестови данни, всичко е прекрасно. Но когато изпълните запитване в продукция, където имаме, например, 4 милиона записа, нещата не вървят особено добре. Защото allow filtering — това е директива, която позволява на Cassandra да събере всички данни от тази таблица от всички нодове, дата-центрове (ако има много в този кластер), и след това да отфилтрира. Това е аналог на Full Scan и едва ли някой е доволен от него.

Ако ни бяха нужни потребители само по идентификатори, щеше да е окей. Но понякога трябва да пишем други запитвания и да налагаме други ограничения на извадките. Затова си спомняме: всичко това е мапа, чийто ключ е партиционирането, но вътре в нея има отсортирована мапа.

И тя също има ключ, който наричаме Clustering Key. Този ключ, който от своя страна, се състои от колоните, които избера, позволява на Cassandra да разбере как физически ще бъдат сортирани и разположени данните на всяка нода. Тоест, за определен Partition key Clustering key ще разкаже как точно данните да бъдат поставени в това дърво, какво място ще заемат.

Това е наистина дърво, там просто се извиква компаратор, в който подаваме набор от колони във вид на обект, и той се задава също в вид на изброяване на колоните.

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

Обърнете внимание на директивата Primary key, където първият аргумент (в нашия случай година) винаги е Partition key. Той може да се състои от една или повече колони, което няма значение. Ако колоните са няколко, още веднъж трябва да ги поставим в скоби, за да може препроцесорът на езика да разбере, че това е именно Primary key, а зад него идват всички останали колони — Clustering key. Те ще преминават през компаратора в реда, в който се намират. Тоест, първата колона е по-значима, втората — по-малко значима и т.н. Както пишем за data класовете, например, полета equals: изброяваме полетата и за тях указваме, кои са по-големи, а кои по-малки. В Cassandra това, условно казано, са полета на data class, за който ще се прилага написаният за него equals.

Задаваме сортиране, налагаме ограничения

Трябва да помним, че редът на сортиране (намаляващ, увеличаващ, няма значение) се задава в момента на създаване на ключа и по-късно няма да може да се промени. Той физически определя как ще бъдат сортирани данните и как ще се разполагат. Ако е необходимо да се промени Clustering key или реда на сортиране, ще трябва да създадем нова таблица и да преливаме данните в нея. С вече съществуваща таблица това няма да е възможно.

Запълнихме таблицата с потребители и видяхме, че те се разположиха в кръг първо по година на раждане, а след това вътре на всяка нода по заплата и по user ID. Сега можем да селектираме, налагайки ограничения.

Отново се появява нашият работещ where, and, и потребителите ни се предоставят, и всичко отново е наред. Но ако опитаме да използваме само част от Clustering key, и то по-малко значима, Cassandra веднага ще излезе с грешка, че не може да намери в нашата карта мястото, където този обект, който има тези полета за компаратора null, а този, който току-що зададохме — къде лежи. Ще трябва отново да изтегля всички данни от тази нода и да ги филтрирам. И това е аналог на Full Scan в рамките на нодата, което е лошо.

В всяка неясна ситуация създавай нова таблица

Ако искаме да имаме възможността да извеждаме потребители по ID, възраст или заплата, какво да правим? Нищо. Просто използваме две таблици. Ако трябва да извличаме потребители по три различни начина — таблиците ще бъдат три. Отминаха времето, когато икономисвахме място на диска. Това е най-евтиният ресурс. Той струва много по-евтино от времето за отговор, което може да бъде катастрофално за потребителя. На потребителя е много по-приятно да получи нещо за секунда, отколкото за 10 минути.

Ние разменяме излишното заето място, денормализираните данни за възможността да се мащабира добре, да работи надеждно. Всъщност, клъстер, който се състои от три дата центъра, всеки от които има по пет нода, при приемливо ниво на запазване на данните (когато определено нищо не се губи), е в състояние да преживее загубата на един дата център напълно. И още по две ноди в оставащите два. И само след това ще започнат проблемите. Това е доста добро резервиране, струва наистина само няколко излишни SSD накопителя и процесори. Следователно, за да използваме Cassandra, която не е SQL, в която няма отношения, външни ключове, трябва да знаем прости правила.

Проектираме всичко от запитването. Главните стават не данните, а това как приложението ще работи с тях. Ако му е необходимо да получава различни данни по различни начини или същите данни по различни начини, трябва да ги поставим така, че да бъде удобно на приложението. В противен случай ще влезем в Full Scan и никакви предимства на Cassandra няма да ни помогнат.

Денормализирането на данните е нормално. Забравяме за нормалните форми, вече нямаме релационни бази. Ако положим нещо 100 пъти, ще бъде там 100 пъти. Това е все още по-евтино, отколкото да забавим системата.

Избираме ключове за партициониране така, че те да се разпределят нормално. Не искаме хешът от нашите ключове да попада в един тесен диапазон. Тоест, годината на раждане в примера по-горе е лош пример. Всъщност, той е добър, ако имаме потребители, родени през различни години, и лош, ако става въпрос за ученици от 5-ти клас — там нещата не ще се партиционират добре.

Сортиране се избира един път при създаване на Clustering Key. Ако трябва да го променим, ще трябва да прехвърлим таблицата с друг ключ.

И най-важното: ако трябва да получим едни и същи данни по 100 различни начина, означава, че ще имаме 100 различни таблици.

Източник: habr.com