Навремето собствените бази данни бяха единствените приемливи опции.
„Никой никога не е бил уволнен за покупка от Oracle/Microsoft/IBM“ беше поговорката.
Огромни, монолитни бази данни, използвани за всяка отделна цел. Платена поддръжка - така изглеждаше пейзажът на базата данни през 90-те и началото на 00-те. Разбира се, имаше бази данни с отворен код, но те бяха третирани като „база данни за играчки“, подходяща за малък уебсайт, може би блог или много малък електронен магазин. Никой разумен не би ги използвал за нещо критично.
Нещата се промениха с времето и базите данни с отворен код узряха. Всяка година се създават все повече и повече. Вече виждаме специализация, позволяваща на потребителите да избират най-добрата опция за дадено работно натоварване – времеви серии, аналитични, columnstore, NoSQL, релационни, ключ-стойност – можете да изберете каквито бази данни имате нужда и обикновено има много опции, от които да избирате. Това води до това, че отвореният код става все по-популярен в света на бази данни. Компаниите сега разглеждат сметките си от техния доставчик на собствена база данни и се чудят дали могат да я намалят малко, като приемат безплатна база данни с отворен код.
Както обикновено, има плюсове и минуси. Кои са нещата, които може да искате да обмислите, преди да внедрите база данни с отворен код? В тази публикация в блога ще споделим някои съвети, които може да искате да имате предвид, когато планирате да мигрирате към бази данни с отворен код.
Започнете малко и разгънете
Ако вашата организация не използва бази данни с отворен код, най-вероятно тя също няма опит в управлението им. Макар че е възможно чрез външни консултанти, вероятно не е добра идея да мигрирате цялата си среда в бази данни с отворен код.
По-добрият подход би бил да започнете с малки проекти. Може би трябва да изградите някакъв вътрешен инструмент или уебсайт, може би някакъв инструмент за наблюдение - това е чудесна възможност да използвате бази данни с отворен код и да получите опит от използването им в реални среди. Това ще ви позволи да научите тънкостите на базата данни - как да я диагностицирате, как да проследявате нейната производителност, как да я настроите, за да подобрите нейната производителност.
Освен това ще научите повече за опциите и реализациите с висока наличност. Работата с него също помага да разберете разликите между собствената база данни, която използвате, и базите данни с отворен код, които сте приложили за по-малки проекти. След време трябва да видите, че отпечатъкът на базата данни с отворен код във вашата организация се увеличи значително заедно с опита на вашите екипи.
В даден момент, след като съберете достатъчно опит, за да стартирате базите данни с отворен код, може да решите да дръпнете лоста и да започнете проект за миграция. Друг, също доста вероятен вариант, е постепенно да премествате операциите си към бази данни с отворен код на база проект по проект. В крайна сметка съществуващите ви приложения, които използват собствена RDBMS, ще бъдат оттеглени и в крайна сметка ще бъдат заменени с нова итерация на софтуера, която разчита на бази данни с отворен код.
Изберете правилната база данни за работата
Вече споменахме, че базите данни с отворен код обикновено са доста специализирани. Можете да изберете хранилище за данни, подходящо за различни употреби - времеви серии, хранилище на документи, хранилище ключ-стойност, колонно хранилище, текстово търсене. Това, в комбинация с предишния съвет, ви позволява да изберете точно типа база данни, която изисква вашият малък проект. Да кажем, че искате да изградите стек за наблюдение за вашата среда.
Може да искате да разгледате бази данни от времеви серии като Prometheus или TimeScaleDB, за да захранвате вашето приложение за наблюдение. Може би искате да внедрите някакви решения за аналитични/големи данни. Ще трябва да проектирате някакъв ETL процес, за да извлечете данните от вашата основна RDBMS и да ги заредите в решение с отворен код. Има много опции, които да се използват като хранилище за данни. В зависимост от изискванията и данните можете да избирате от голямо разнообразие от бази данни, например Clickhouse, Cassandra, Hive и много други.
Ами преместването на някои части от приложението от собствената RDBMS към решение с отворен код?
Има опции и за това. Магазини за данни като PostgreSQL или MariaDB имат много функции, свързани с лесната миграция от хранилища за данни като Oracle. Те идват с, например, поддръжка за PL/SQL и други SQL функции, налични за Oracle. Това е голяма помощ - по-малко код трябва да се конвертира заедно с миграцията от Oracle към други бази данни, по-вероятно е вашите съхранени процедури и функции също да работят предимно извън кутията и няма да ви се налага да харчите значително време за пренаписване, тестване и отстраняване на грешки в код, който представлява основна логика на вашето приложение.
Не бива да забравяте и ресурсите, които вече имате в екипа си. Може би някой има опит в по-популярните хранилища за данни с отворен код? Ако те отговарят на изискванията ви и се вписват във вашата среда, може да успеете да използвате съществуващите знания във вашия екип и лесен преход към света с отворен код.
Помислете за получаване на поддръжка
Мигрирането в хранилища за данни, с които нямате много опит, винаги е трудно. Дори и да продължите с малки стъпки, все пак може да бъдете хванати от изненадващо поведение, неочаквана ситуация, грешки или дори просто оперативни ситуации, с които не сте запознати.
Базите данни с отворен код обикновено имат страхотна поддръжка на общността - имейл списъци, форуми, Slack канали. Обикновено, когато попитате, някой ще се опита да ви помогне. Това може да не е достатъчно в някои случаи. Ако случаят е такъв, трябва да потърсите платена поддръжка. Има много начини как това може да се постигне.
Първо, не всички проекти с отворен код са равни. По-големи проекти, като PostgreSQL или MySQL може да са разработили екосистема от консултантски компании, които наемат експерти, които могат да направят консултации вместо вас. Ако такава опция по някаква причина не е налична или осъществима, винаги можете да се свържете с поддържащите проекта.
Много често се случва компанията, която разработва хранилището за данни, да се радва да помогне срещу определена цена.
Независимите консултантски компании имат значително предимство - те са независими и ще предложат решение въз основа на своя опит, а не въз основа на хранилището за данни и инструментите, които разработват. Доставчиците, добре, те обикновено прокарват свои собствени решения и среда. От друга страна, доставчиците са доста заинтересовани от увеличаване на приемането на тяхното хранилище за данни. Ако мигрирате от собствено хранилище за данни, те може да са били в тази ситуация няколко пъти преди, така че би трябвало да могат да ви предоставят добри практики, да ви помогнат да проектирате процеса на миграция и така нататък. За една неопитна компания достъпът до експертите в областта на миграцията може да бъде голямо предимство.
Може да намерите достъп до външна поддръжка полезен не само на етапа на миграция. Справянето с ново хранилище за данни винаги е трудно и изучаването на всички аспекти на операциите отнема време. Дори и след миграцията все още може да имате полза от някого, на когото можете да се обадите, да попитате и, което е най-важното, да се поучите от него. Обучения, отдалечен DBA, всичко това са често срещани опции в света на базите данни с отворен код, особено за тези по-големи, по-утвърдени проекти.
Намерете система или инструмент за помощ
Базите данни с отворен код се предлагат с различни инструменти, някои повече или по-малко сложни. Някои добавят функционалност (висока наличност, архивиране, наблюдение), някои са предназначени да улеснят управлението на базата данни.
Важно е да ги използвате (консултантските договори може да са полезни тук, за да ви запознаят с най-важните инструменти за хранилището на данни с отворен код по ваш избор), тъй като те могат значително да увеличат вашата оперативна скорост и производителност и стабилност на цялата настройка.
Някои инструменти са безплатни, някои изискват лиценз за работа, трябва да погледнете в басейна и да изберете това, което ви подхожда най-много. Тук говорим за балансьори на натоварване, инструменти за управление на топологията на репликация, инструменти за управление на виртуални IP адреси, клъстерни решения, повече или по-малко специализирани платформи за наблюдение и наблюдение, които могат да проследяват всичко, като се започне от типични показатели за производителност на базата данни през даване на интелигентни прогнози въз основа на данните до специализирани анализ на ефективността на заявката.
Светът с отворен код е мястото, където подобни инструменти процъфтяват – това също има плюсове и минуси. Лесно е да се намери инструмент „A“, трудно е да се намери инструмент „THE“. Можете да намерите множество проекти в GitHub, като всеки прави почти същото като другите. Кое да изберете е трудната част. Ето защо в идеалния случай бихте имали ръка за помощ или в договор за поддръжка, или можете да разчитате на платформи за управление, които ще ви помогнат да управлявате множество аспекти на операциите с бази данни с отворен код, включително да ви помогне да стандартизирате и изберете правилните инструменти за това.
Съществуват и платформи като ClusterControl, който е предназначен да помогне на хора без опит да разберат напълно силата на базите данни с отворен код. ClusterControl поддържа множество различни видове хранилища за данни с отворен код:MySQL и неговите разновидности, PostgreSQL, TimeScaleDB или MongoDB. Той осигурява унифициран потребителски интерфейс за достъп до функциите за управление на тези хранилища за данни, което го прави лесно разгръщането и управлението им. Вместо да прекарвате време в тестване на различни инструменти и решения, с помощта на ClusterControl можете лесно да разгръщате високодостъпна среда, да планирате архивиране и да следите показателите в системата.
Инструменти като ClusterControl намаляват натоварването на вашия екип, увеличавайки способността му да разбират какво се случва в базата данни, с която не са толкова запознати, колкото биха искали.
Не бързайте
Това, което е добре да имате предвид, е, че няма нужда да бързате. Стабилността на вашата среда и благосъстоянието на вашите потребители са от първостепенно значение. Отделете време, за да стартирате тестовете, проверете всички аспекти на вашето приложение. Уверете се, че имате правилни процеси за висока наличност и възстановяване след бедствие.
Само когато сте 100% сигурни, че сте готови да превключите, ще е време да дръпнете лоста и да преминете към бази данни с отворен код.
