Сървъри на бази данни и вградени бази данни: сравнение на архитектурата и характеристиките на I/O

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

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

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

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

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

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

• Появата на SSD

  В миналото, в системи с основно HDD, произволният достъп се характеризираше със значително по-ниска производителност в сравнение с последователното четене и запис на данни. Затова основна стратегия за оптимизация на производителността беше минимизирането на дисковия I/O и максимизирането на кеширането в паметта. Сървърите за бази данни се адаптираха към това, като поддържаха голям кеш и обединяваха операциите по запис, с което преодоляваха физическите ограничения на HDD.

  Появата на SSD обаче напълно промени тази предпоставка. SSD е многократно по-бърз при произволен I/O в сравнение с HDD, а латентността му е значително по-ниска. В резултат на това схващането, че „дисковият I/O е най-голямото препятствие“, изчезна, а забавянето при отдалечен достъп до сървъра на базата данни през мрежата започна да се очертава като нова основна пречка.

• MSA и независимост на данните

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

  В съвременната микросервизна архитектура за решаването на този проблем се акцентира върху принципа „Database per Service“. Всяка услуга притежава и капсулира собствено изделено хранилище за данни, което гарантира независимост между услугите и улеснява изолацията на грешки и мащабирането. В този контекст вградената база данни се превръща в идеален избор за хранилище на данни на ниво услуга. Тя е лека и бърза и може да бъде разгърната заедно с кода на услугата, поради което много добре пасва на MSA средата.

  Например в среда на Kubernetes широко се използва схемата със sidecar, при която вградена база данни се разполага до контейнера на приложението, за да се оптимизира локалната обработка на данни. Това намалява мрежовите забавяния и минимизира латентността при достъп до данните.

• Опростяване на експлоатацията

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

  Вградената база данни значително облекчава тези проблеми. Когато базата данни е интегрирана в самото приложение, unit тестването, билдването, контролът на версиите и разгръщането се извършват заедно, поради което не е необходима отделна сървърна експлоатация. Освен това при хоризонтално мащабиране на приложението вградената база данни се разширява заедно с него, а в рамките на DevOps културата и CI/CD пайплайните е възможно автоматизирано управление. Особено в стартъпи, малки услуги и среди за разработка на прототипи вградената база данни значително намалява оперативната сложност и осезаемо ускорява разработката и разгръщането.

• Системни езици с висока производителност и развитие на екосистемата

  В миналото базата данни и приложението обикновено се писаха на различни езици. Например машинните енджини за бази данни с високи изисквания за производителност се разработваха основно на C и C++, а приложенията – на Java, Python, PHP и други езици. Този подход беше ефективен за оптимизация на производителността, но имаше ограничения: проблеми с безопасността на паметта, сложна обработка на конкурентността, латентност и трудности при интеграцията и разгръщането на библиотеки.

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

  На практика в Golang се използват активно високопроизводителни вградени бази данни като BadgerDB и PebbleDB. Това означава, че вградената база данни не е просто лека алтернатива на сървъра за бази данни, а утвърдена и конкурентоспособна важна възможност.

Заключение

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