Новият начин за управление на бази данни с отворен код

Не толкова отдавна индустрията за бази данни се състоеше от шепа доставчици. Базите данни бяха предимно релационни и работеха на единични машини. Високата наличност беше реализирана чрез „клъстери“ в активен режим на готовност. При вертикален модел на „увеличаване“ ставаше дума най-вече за споделено съхранение (SAN или DRBD) или асинхронна репликация на регистрационни файлове за синхронизиране на състоянието към възел в режим на готовност. През 2001 г., когато започнах да работя с NDB Cluster (това, което по-късно ще стане MySQL Cluster), концепцията за държане на цяла база данни в основната памет беше странна – „ами ако изключите сървъра?“. Разпределянето на база данни между множество сървъри беше тревожно – „имате части от данни тук и там“. И цялата идея за база данни с отворен код за критични работни натоварвания беше смешна.

Бързо напред 15 години и вече имаме десетки доставчици на бази данни на пазара - предимно с отворен код, различни модели (ключова стойност, документ, графика,...) и разпространявани по подразбиране. Пребиваващите в паметта данни са почти норма за постигане на висока производителност и ниска латентност. Три от първите 5 най-популярни бази данни (според класирането на db-engines) са с отворен код (MySQL, PostgreSQL и MongoDB). В днешно време е по-вероятно да управлявате флот от сървъри на бази данни, разпределени в различни центрове за данни. Може дори да имате някои от вашите бази данни, управлявани от доставчик на облак на трета страна.

И така, какво е да управляваш бази данни през 2018 г.?

АВТОМАТИЗАЦИЯ

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

Автоматизацията е чудесен начин да свършите нещата. Когато имахме малко бази данни за управление, работата с базата данни щеше да бъде много практична, като някои задачи бяха скриптирани в нещо като bash или perl - например скрипт за архивиране на базата данни, друг за преместване на архивни файлове на някакво място. Отказът ще бъде ръчен и дори ще обсъждаме дали трябва да бъде автоматизирано или не.

В днешно време автоматизацията е безпроблемна. Има редица ИТ системи за автоматизация или управление на конфигурацията, които могат да бъдат използвани - Puppet, Chef, Ansible и Salt всички предлагат рамки с общо предназначение, които могат да се използват за изграждане на автоматизация за различни топологии на бази данни. Софтуерът за управление на клъстери, написан специално за управление на настройките на базата данни, включва MongoDB Ops Manager и ClusterControl. Те дават възможност на оперативните екипи да управляват своите клъстери с нещо, което е лесно достъпно на пазара. Изграждането на система за управление на клъстери от нулата с помощта на система за управление на конфигурацията не е малък подвиг. Изисква се значителен опит в инструмента за автоматизация, както и разбиране на операциите за управление, като планиране и проверка на архивиране, автоматично преодоляване на срив с последващо преконфигуриране на системите, внедряване на промени в конфигурацията, корекция, надграждане или понижаване на версията и др.

И разбира се, има нарастване на платформите за услуги DBaaS, където разполагането, здравето, преодоляването на срив, архивирането и т.н. се контролира от софтуер. Доставчиците на облак наистина са много добри в автоматизацията. Amazon RDS е чудесен пример за автоматизация на база данни в мащаб – той автоматизира внедряването, надстройките на корекцията, архивирането, възстановяването в момента, мащабирането на репликите и високата наличност/отказът.

ДОМАШНИ ДОМАШНИ СРЕЩУ ГОВЕДИ

През 90-те и до бума и срива на дотком, Sun Microsystems и Oracle направиха състояние, продавайки мащабни бази данни на голям SMTP хардуер. Добавете малко SAN хранилище и софтуер за преодоляване при отказ на Veritas и ще имате най-съвременен клъстер за преодоляване на срив в активна готовност за висока наличност. Сървърите за бази данни бяха сравнително малко на брой, но мощни, тъй като щяха да растат вертикално. Те получиха имена (точно както назовавате домашните си любимци!) и бяха обгрижвани от администратори на база данни.

В днешно време базите данни са евтини и работят добре със стандартен хардуер. Има много от тях и ние им даваме номера - точно като добитък. Ако някой се счупи, можем просто да вземем нов.

Това също е нова порода говеда - говеда с отворен код! Три от първите пет бази данни според db-engines са с отворен код - те бавно, но сигурно изяждат пазарния дял на двата собствени доставчици. Отвореният код е новият стандарт на центъра за данни, не само за операционна система, но и за бази данни.

И така, какво означава това за вас? Е, в бъдеще е по-вероятно да управлявате база данни с отворен код - или дори множество такива за приложения, използващи хетерогенни колекции от данни. В свят на постоянство на полиглоти и микроуслуги, основното хранилище за данни вече се диктува от естеството на данните. От архитектурна гледна точка базите данни с един екземпляр с дисково базирана HA отстъпват място на клъстери, които са потенциално разпределени в множество центрове за данни.

Имаме ли нужда от DBA?

Ролята на DBA е специализирана - необходими са години опит, за да станете такава. В миналото, когато имаше само няколко собствени доставчици на бази данни, от които да избирате, бихте имали специализирани администратори на база данни със специфичен набор от умения и опит. Това също беше необходимо - бази данни като Oracle или SQL Server имат огромни набори от функции, изградени в продължение на десетилетия. Не са лесни за управление. Обикновено те се разполагаха като единствена база данни за приложение и трябваше да бъдат наблюдавани, архивирани данни и всички възникнали проблеми трябваше да бъдат решени. Тези задачи бяха точно това, върху което DBA трябваше да се съсредоточи.

През последното десетилетие обаче се появи цяла нова индустрия за бази данни - с десетки и десетки бази данни с отворен код, както и облачни услуги за бази данни. Както видяхме по-рано, не е необичайно приложение да използва няколко различни хранилища за данни. Но компаниите рядко имат DBA за тези хранилища за данни, които използват. Къде намирате MongoDB или Cassandra или <вмъкнете новата си любима база данни> DBA с 5+ години производствен опит? Може да се твърди, че новото поколение бази данни NoSQL са много по-прости от техните предшественици със затворен код и следователно не би имало същата крива на обучение.

Управлението им би било просто още една задача, добавена към списъка със задачи на екипа SysAdmin или DevOps или Site Reliability Engineering (SRE). И днес виждаме, че много компании нямат DBA на пълен работен ден. Вместо това отговорността се разпределя между екипи, като инструментите за автоматизация все по-често се използват за извършване на рутинни ежедневни задачи. За бази данни, които са преместени в облака, оперативните аспекти на това как се съхраняват данните се възлагат изцяло на доставчика на облака. Така че вместо да работи върху това как да съхранява данни, оперативният екип вече може да се съсредоточи върху използването на данните.

Жизнен цикъл на базата данни

Средният жизнен цикъл на база данни е бил много по-дълъг от този днес. След като сте избрали платформа за база данни, това беше всичко. Решението ще бъде взето между две или три релационни бази данни, обикновено от DBA или някой по-високо в организацията. Компанията ще намери пари за закупуване на безсрочни лицензи. След като решението беше взето, сега трябваше да живеете с него през следващите 10+ години. Базите данни бяха монолитни и приложенията обикновено използваха една споделена база данни.

Днес, в свят на контейнери, облак, микросервизи и CI/CD тръбопроводи, не е необичайно разработчиците да правят технологичния избор – особено ако това е база данни с отворен код, която може лесно да бъде изтеглена или предлагана като услуга, без да се налага да говорите с търговски представител или да се налага да търсите бюджет от ръководството. Организациите са изправени пред предизвикателството да създават стойност по-бързо, така че скоростта на промяна в инфраструктурата/приложенията се е увеличила драстично. Монолитните бази данни вече са разделени на множество малки бази данни, като всяка база данни управлява данни за домейн за отделна микроуслуга. С разнообразието от продукти за бази данни, налични днес в екосистемата с отворен код, екипите имат избор и свобода да преминат към по-добро хранилище за данни. Тъй като услугите се пускат в експлоатация и извеждат от експлоатация, базите данни също следват - въпреки че самите данни могат да бъдат архивирани или преместени в езеро от данни. В инфраструктурен пейзаж, който днес е много по-динамичен, откриваме, че нашите бази данни живеят по-кратък живот.

РОЛЯ на DBA

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

Високата цена на сътрудничеството и бързата иновация/краткото време за излизане на пазара не вървят добре заедно. Както видяхме по-рано, микроуслугите са пример за това как инфраструктурните и приложните услуги сега са проектирани така, че да се разделят колкото е възможно повече. Базите данни все повече се автоматизират и контролът върху базата данни се прехвърля към разработчиците или проектните екипи. Дори неща като промените в схемата не са толкова тежки, колкото преди. Те бяха много по-трудни в контекста на централна база данни за монолитно приложение. Тъй като данните се споделят между различни компоненти, промените в схемата ще трябва да бъдат координирани и внимателно планирани - обикновено месеци предварително. DBA имаха ключова роля в разбирането и извършването на промените. Динамиката е различна днес, където скоростта на промяна е много по-бърза. Не е необичайно екипите за разработка да налагат промени в кода в производството на седмична или дневна база - или дори няколко пъти на ден! Базите данни се нуждаят от постоянни актуализации, за да бъдат в крак с промените в приложенията и те се извършват от разработчиците. Някои от по-новите бази данни като MongoDB дори го правят много опростено, като имат модел без схема. Това ефективно означава, че схемата на базата данни се премества в кода на приложението.

И така, ако всички общи основни задачи се автоматизират, какво ще се случи с ролята на DBA в бъдеще? Вместо да се фокусира върху административните задачи, DBA ще функционира повече като ментор за други екипи в организацията. Организациите трябва да разберат с какви данни разполагат и как тези данни могат да бъдат използвани. В крайна сметка данните са най-ценни, когато се споделят и комбинират с други ресурси, а не само съхранявани. Schemaless звучи страхотно, но все пак трябва да следим нашите данни - или в базата данни, или в кода. Сигурността е предизвикателство, а нарушенията на данните продължават да се влошават. Така че, ако искаме отново да направим данните страхотни, DBA трябва да премине към хоризонтална роля на съветник/активатор, която обхваща всички екипи. От гледна точка на компетентността, съвременният DBA трябва да разбере как да проектира разпределени системи с висока наличност и да въведе ефективни системи за автоматизация, които да се грижат за ежедневните задачи. Тъй като компаниите внедряват инфраструктура в облачни или дори контейнерни среди, разбирането как да се изградят високодостъпни и мащабируеми бази данни на тези платформи ще гарантира оцеляването на DBA.

Резюме

Намираме се на очарователен кръстопът в историята на индустрията за бази данни, която премина през огромна трансформация през последните 2 десетилетия. Таблицата по-долу се опитва да го обобщи.

Ще ми е интересно да чуя вашите мисли за управлението на база данни с отворен код и дали сте виждали същите тенденции? Как изглеждаха вашите борби или успехи с OSDB през последните години? И какво предвиждате да се случи следващата година?

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

Но междувременно ми кажете какво мислите и ще се видим през 2019 г.!

Снимки от SoRad (Shutterstock) &The Simpsons; другите снимки са от съответните им собственици.