Сървъри за бази данни и вградени бази данни

Сървър на база данни

Сървър на база данни означава база данни, която работи като независим сървърен процес и обработва заявки от приложения през мрежата. Повечето RDBMS, с които сме запознати, като MySQL, PostgreSQL, Oracle DB, попадат в този модел. Сървърът на база данни има следните предимства:

Централизирано управление: Данните се управляват централизирано на едно място, което улеснява последователността, сигурността, архивирането и възстановяването.
Независимост на ресурсите: Осигурява стабилна производителност, независимо от състоянието на приложението, като му се разпределят собствени CPU, памет и сторидж.
Висока едновременност и мащабируемост: Оптимизиран е за едновременен достъп от много потребители, а хоризонталното мащабиране чрез клъстериране или репликация е сравнително лесно.

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

Нова тенденция: Вградени бази данни

Вградената база данни е двигател на база данни, който е включен като библиотека в приложението и работи в същия процес, без отделен сървърен процес. SQLite, LevelDB, RocksDB са типични примери за вградени бази данни. Причините, поради които тези вградени бази данни се превърнаха в мощна алтернатива в съвременната технологична среда, са следните:

Появата на SSD
В миналото, в системна среда, доминирана от HDD, производителността на произволен достъп беше значително по-ниска в сравнение с производителността на последователно четене/запис на данни. Следователно, минимизирането на дисковия I/O и максимизирането на кеширането в паметта беше ключът към оптимизацията на производителността. Сървърът на база данни се е адаптирал към това, като е управлявал мащабни кешове и е обработвал операциите по запис на групи, за да преодолее физическите ограничения на HDD.
Въпреки това, появата на SSD напълно промени това предположение. SSD е хиляди пъти по-бърз при произволен I/O в сравнение с HDD, а латентността е значително по-кратка. В резултат на това, предишното разбиране, че "дисковият I/O е най-голямото затруднение", изчезна, и вместо това, забавянето, възникващо при отдалечен достъп до DB сървър през мрежата, започна да се очертава като ново затруднение.
MSA и независимост на данните
В миналото беше обичайна структурата, при която едно гигантско монолитно приложение зависеше от една централизирана база данни. Този подход беше прост, но с нарастването на мащаба на услугата, промяната на схемата на данните ставаше трудна, а всички услуги споделяха една и съща DB, което водеше до прекомерно силна свързаност.
В съвременната архитектура на микроуслуги, за да се разрешат тези проблеми, е важен принципът "Database per Service". Чрез притежаването и капсулирането на собствено хранилище за данни от всяка услуга, се гарантира независимост между услугите, а изолирането на повреди и мащабирането стават по-лесни. В този процес, вградената DB става идеален избор за хранилище за данни на ниво услуга. Тя е лека, бърза и може да бъде разгърната заедно с кода на услугата, което я прави много подходяща за MSA среда.
Например, в Kubernetes среда, моделът sidecar често се използва за оптимизиране на обработката на локални данни, като се поставя вградена DB до контейнера на приложението. Това води до намаляване на мрежовите затруднения и минимизиране на забавянето при достъп до данни.
Опростяване на оперативната среда
Сървърът на база данни изисква сложни оперативни процедури като инсталация, пачове, архивиране, възстановяване при повреди, репликация, мониторинг на производителността, и за това са необходими специализиран DBA и професионален оперативен персонал. Особено в мащабни среди, това натоварване по управление е много голямо.
Вградената DB значително облекчава тези проблеми. Когато базата данни е интегрирана в приложението, модулното тестване, изграждането, управлението на версиите и разгръщането се извършват заедно, така че не е необходима отделна сървърна операция. Освен това, когато приложението се мащабира (Scale-out), вградената DB също се разширява заедно с него, и е възможно автоматизирано управление чрез DevOps културата и CI/CD пайплайна. Особено в стартъпи, малки услуги и среди за разработка на прототипи, вградените бази данни значително намаляват сложността на операциите и значително увеличават скоростта на разработка и разгръщане.
Развитие на високопроизводителни системни езици и екосистеми
В миналото беше обичайно базата данни и приложението да бъдат написани на различни езици. Например, двигатели на бази данни, изискващи висока производителност, обикновено се пишеха на C, C++, а приложенията се разработваха на езици като Java, Python, PHP. Този подход беше ефективен за оптимизация на производителността, но имаше ограничения като проблеми със стабилността на паметта, сложна обработка на едновременност, латентност и трудности при интегрирането и разгръщането на библиотеки.
Въпреки това, с възхода на съвременни езици за системно програмиране като Go и Rust, тези ограничения бяха значително облекчени. Особено Go е подходящ както за високопроизводителни приложения, така и за писане на нисконивови програми като двигатели на бази данни, което позволява базата данни и приложението да бъдат управлявани заедно в рамките на една езикова екосистема.
Всъщност, в Golang активно се използват високопроизводителни вградени бази данни като BadgerDB и PebbleDB. Това означава, че вградените бази данни се утвърждават като важен избор със собствена конкурентоспособност, не просто като лека алтернатива на сървъра на база данни.

Заключение

За централизирано управление на големи данни, сложни транзакции и висока едновременност, сървърът на база данни все още е най-мощното решение. Въпреки това, за отделни услуги в MSA среда, IoT Edge устройства, бързо прототипиране и проекти, където оперативната ефективност е важна, вградената база данни може да бъде по-ефективен и разумен избор. В крайна сметка, важното е да изберем най-оптималния инструмент, който най-добре отговаря на дадената ситуация и изисквания, а развитието на вградените бази данни ни предоставя по-широк и разнообразен избор.