Обичам технологията без сървър. Играя и правя много различни приложения без сървър, за да експериментирам с други страхотни технологии. В огромния клъстер от технологии, с които използвам/експериментирам, PlanetScale беше базата данни, която основно използвах за личните си странични проекти, тъй като нямаше друга "добра" опция, която Prisma ORM поддържа .

PlanetScale е MySQL платформа без сървър, която просто продава Vitess, система за клъстериране на база данни за хоризонтално мащабиране на MySQL. Те не са написали своя собствена база данни - вероятно са допринесли за нея, но не са я написали. От документацията на Vitess:

Vitess е създаден през2010г за решаване на предизвикателствата пред мащабируемостта на MySQL, пред които е изправен екипът на YouTube.

В тази статия ще се придвижим към разбирането на структурата на тези наследени разчленени бази данни без ACID, защо те не са в състояние да поддържат нещо толкова важно като референтната цялост и защо трябва да избягваме да ги използваме в нашите приложения. Тази статия е повече за технологията на Vitess, въпреки че включих PlanetScale в заглавието, защото, както споменах по-горе, той просто продава Vitess (с някои инструменти) като услуга и те придобиха популярност през следващите месеци като "надеждна" база данни без сървър.

Фон

Първоначалният ми въпрос беше защо пише, че е невъзможно да се мащабира база данни на PlanetScale с референтна цялост, тъй като в тяхната документация пише, че:

Начинът FOREIGN KEY ограниченията са имплементирани в MySQL (или по-скоро в механизма за съхранение на InnoDB) пречат на онлайн DDL операциите. Научете повече в тази публикация в блога на Vitess.

Ограничен до един обхват на MySQL сървър, FOREIGN KEY ограниченията са невъзможни за поддържане, след като вашите данни нарастват и са разделени на множество сървъри на бази данни. Това обикновено се случва, когато въвеждате функционално разделяне/разделяне и/или хоризонтално разделяне.

Това ме наведе на мисълта:направете FOREIGN KEY ограничения засягат мащабируемостта като цяло? и ако да, как?

Мисля, че е важно да осъзнаем, че присъединяването на SQL таблици е доста скъпо, но доколкото знам, не е повлияно много от референтната цялост? Сега, ако правим нещо като анализ на данни, очевидно нямаме нужда от референтна цялост, тъй като просто бихме искали да изхвърлим данните си в една таблица, но PlanetScale и Vitess се хвалят, че се използват от големи уеб приложения като YouTube.

Това ме накара да бъда объркан защо са махнали FOREIGN KEY ограничение, тъй като бази данни като CockroachDB и Spanner все още поддържат референтна цялост, заедно с това, че са мащабируеми.

Какво е референтна цялост и защо е важна?

Нека започнем с основите, в случай че сте нов. Предполагам, че повечето хора, които четат тази публикация, имат добра представа за това, за което говорят, но ще обясня като формалност. С прости думи, FOREIGN KEY constraint е ключ на базата данни, който можем да използваме за създаване на релации между две различни таблици чрез препратка към колона или набор от колони. Референтната цялост просто се отнася до състоянието на базата данни, в което всички стойности на всички ключове са валидни.

Защо е важно?

Сега, след като имаме известна представа какво представляват, нека преминем към втората част:защо са важни?

Референтната цялост е важна, тъй като ви предпазва от въвеждане на нови грешки във вашата база данни. Това е функция, която често се предоставя от релационни бази данни, предотвратявайки на потребителите или приложенията да въвеждат непоследователни данни в базата данни. Това води до подобрено качество на данните, по-бързо развитие, много по-малко грешки и последователност във вашето приложение.

Защо Vitess го няма?

Така че, за да разберем защо Vitess не е в състояние да поддържа референтна цялост, трябва да се потопим в архитектурата на базата данни. Vitess е разчленена не-ACID SQL база данни, а не истинска разпределена ACID SQL база данни.

Сега сигурно се чудите какви са тези термини. Позволете ми да ги разбия вместо вас:ACID е акроним на атомност, последователност, изолация и издръжливост.

Тук атомарността се отнася до действие, което или завършва, или се проваля изцяло - без частично завършване на транзакция. Последователността се отнася до транзакцията, оставяща базата данни в валидно състояние. Изолирането просто означава, че две транзакции се изпълняват без никаква намеса една в друга, а трайността означава, че промените в транзакцията се запазват.

Шардът е хоризонтален дял от данни в база данни и всеки фрагмент се държи на отделен екземпляр на сървър на база данни, за да разпредели натоварването. Така че, когато говорим за база данни, която е разделена, говорим за нещо подобно. Както казах по-рано, Vitess е разчленена SQL база данни, която не е ACID, което основно означава, че НЕ гарантира ACID свойства на транзакциите.

Защо да го пуснете?

Е, проблемът започва, когато имате MySQL база данни с добре дефинирана схема и вашата услуга става популярна с проблема с твърде много четения, попадащи в базата данни. Това, което повечето хора правят тук, е, че започват да кешират често изпълнявани заявки, но четенията вече не са ACIDic.

Наред с твърде многото четене, прекомерното количество записвания във вашата база данни е сериозен проблем, с който мнозина могат да се сблъскат. Да кажем, че сме готови да запалим джобовете си – можем да мащабираме вертикално, добавяйки повече RAM, 16-ядрен процесор и множество наистина бързи твърдотелни устройства.

Разбира се, все още имаме проблема с нарастването на сложността на присъединяването на SQL таблици, така че започвате да денормализирате, за да избегнете свързвания между таблици.

Преди малко говорих на срещата Prisma Meetup, където обясних основите на проектирането на релационна база данни. Тема, която разгледах тук, беше денормализацията, ако се интересувате, не забравяйте да проверите това.

Но денормализирането е основно процесът, при който добавяте излишни данни към таблиците във вашата база данни, което подобрява производителността върху цената на дисковото пространство, тъй като вече не използвате мощността на процесора за обединения. Докато денормализацията подобрява скоростта на четене, важно е да осъзнаете, че прави записите по-бавни.

Въпреки всичко, въпреки всичко това, нашата база данни все още е бавна, така че преместваме изчисленията на базата данни върху клиента, например генериране на UUID или присвояване на дата.

Дори и след всичко това заявките ще продължат да са бавни - така че поддържаме резултатите от най-запитваните данни готови в процес, известен като материализация на база данни. Сега четенето може да е по-бързо, но записването става все по-бавно с всеки изминал ден. Единствената логична ситуация сега е да отпаднат вторични индекси.

Така че в този момент нашата база данни има

• Няма свойства на ACID поради кеширане
• Без нормализирана схема
• Без задействания
• Без изчисления на базата данни
• Без вторични индекси

Това проправи пътя за базите данни Vitess и NoSQL, тъй като компаниите имаха проблеми с мащабирането на своята база данни. По начина, по който е проектиран, те не са били в състояние да поддържат последователност на данните, свойство на ACID, когато транзакциите обхващат няколко различни фрагмента. Референтната цялост е свързана с последователност, когато данните обхващат множество фрагменти, следователно има смисъл те да не могат да го поддържат добре.

Можем да навлезем дълбоко в структурата на NoSQL бази данни без FOREIGN KEY ограничение и проблеми, с които ще се сблъскаме при приемането на този модел, но това е тема за друга публикация.

Не е само Vitess, това е стандартна практика за разчленените бази данни да избягват референтната цялост, тъй като просто няма друг избор. По отношение на модела ACID, тяхната документация гласи, че те гарантират атомарност, но не и изолация, и дори стигат дотам, че казват:

Гарантирането на киселинна изолация е много спорно и има високи разходи. Предоставянето му по подразбиране би направило Vitess непрактичен за най-често срещаните случаи на употреба.

Нека поговорим накратко за това какво е киселинна изолация. Има четири нива за него (според стандартите SQL-92), включително сериализируемост, четене, ангажирано, четене без ангажимент и повтарящо се четене. Като се има предвид това, има повече нива на изолация, като изолация на моментна снимка, която не е SQL стандарт, въпреки че се използва от няколко бази данни като Firebase или MongoDB. Ако се интересувате допълнително от това, препоръчвам да прочетете тази публикация. За да бъда кратък, няма да разглеждам какво прави/означава всяко ниво на изолация, но ако искате да прочетете повече за това, вижте тази страница от MySQL Documentation.

ACID изолирането се отнася до транзакциите в базата данни, които са ACIDic, което е важно, тъй като те гарантират, че операциите се държат по начина, по който разработчиците очакват от тях. Не съм сигурен какво имат предвид, когато казват „Гарантирането на изолиране на КИСЕЛИНА е много спорно и има високи разходи“, но ако имат предвид, че гарантирането на изолиране на КИСЕЛИНА има високи разходи за всеки продукт , грешат. Няколко разпределени ACID-съвместими бази данни имат най-високо ниво на изолация (сериализиращи се транзакции), като същевременно са производителни с бързи скорости на четене/запис. В контекста на Vitess обаче те не грешат, тъй като транзакциите с множество фрагменти не могат да отговарят на никакво ниво на изолация.

Заключение

С всичко това, сигурно се чудите:защо някой би искал да използва PlanetScale или Vitess? Е, и аз се чудя същото. При много компании и уебсайтове причината беше, че те избраха Vitess обратно, когато нямаше по-добри опции. Ако отидете в началото на статията, забележете как тя е създадена през 2010 г. Сега, когато можем да се насладим на ACID-съвместима мащабируема база данни с референтна цялост, би било в наш интерес да преминем към тези нови бази данни и аз вече започнах да го правя! Технологиите се променят бързо и поддържането на вашата база данни на скорост е решаващ компонент на всяко приложение.