СУБД за специализирани системи, PC World, Издателство Отворени системи

При разработване на нова информационна система или в процес на оптимизиране на съществуващо приложение задължително възниква въпросът за избор на СУБД. За някои е лесно разрешимо, те дори не го забелязват: „ние използваме това, което знаем“, „ние вземаме това, което клиентът изисква“

. Но не винаги всичко е толкова просто и недвусмислено. В редица случаи нито една от съществуващите СУБД няма набор от свойства, представени от задачата. Може да има много начини за разрешаване на такава ситуация, но най-очевидните са три: или вземете универсална СУБД и се опитайте да „заобиколите тесните места“, или започнете да създавате свой собствен сървър на база данни, или модифицирайте една от СУБД, за да отговаря на изискванията на задачата. Вторият метод е най-правилният от гледна точка на оптимизиране на решението на задачата, но и най-скъпият. В повечето случаи, когато вземат такова решение, хората просто не осъзнават мащаба на стартирания проект и дали имат достатъчно сили и знания да го реализират. Най-общо казано, всяко приложение се нуждае от специализирана система за управление на данни, но, както беше споменато по-горе, разработването на собствена СУБД далеч не винаги е икономически оправдано и физически възможно. Следователно приложенията са разделени на класове и използват готови СУБД, които са най-подходящи за определен клас. Въпреки това има информационни системи, за които има остра нужда от специализирана СУБД, фокусирана върху конкретни задачи. Пример е:

отделни системи за управление на процеси, където е необходима СУБД в реално време, която има пълната функционалност на универсална СУБД;
биометрични системи;
военни системи;
държавни информационни системи и др.

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

СУБД за биометрични системи СУБД за биометрични системи трябва да обработва текстови и цифрови данни за дадено лице (пълно име, дата и място на раждане и т.н.), а също така да поддържа специални типове биометрични данни (пръстов отпечатък, изображение на лице, модел на ириса и т.н.) Ако работата с обикновени типове данни е стандартна за всички съвременни релационни СУБД, тогава работата с биометрични типове данни се осигурява чрез създаване на разширения. Например много СУБД поддържат дефинирани от потребителя типове данни. Това означава, че програмистът може да създаде свои собствени модули с данни и да ги свърже към СУБД чрез дефиниране на операции за сравнение, агрегиране и т.н. Този подход (на допълнителен външен модул) практически няма ефект върху скоростта на СУБД, тъй като загубата на време за достъп до външен модул е незначителна в сравнение с времето за изчисление вътре в модула - алгоритмите за обработка на биометрична информация са много ресурсоемки. Но има още един важен момент за биометричните системи. Ако тези алгоритми не са вградени в двигателя на базата данни, има спад в нивото на сигурност и надеждност. Сигурността е намалена поради възможността за подмяна на външния модул, надеждността поради повишенавероятност за повреда. Например, външен модул може да разкрие латентен, труден за повторение бъг в СУБД, който може да бъде открит и коригиран само ако изходният код на самата СУБД е наличен. Когато има доказани алгоритми, е много по-изгодно да се договорите за подобряване на съществуваща СУБД с разработчиците на тази СУБД, отколкото да я разработите сами. Има много научни проблеми в биометрията, които изискват изследване, а разработването на СУБД е задача със сравнима сложност, която е най-добре оставена на специалистите по бази данни. Някои системи вече имат отделни вградени модули, необходими за решаване на биометрични задачи. Например, има разработки за СУБД ЛИНТЕР, които ще позволят използването му в задачи от този клас. Друго важно изискване за СУБД за биометрична система е защитата на данните. Това се доказва не само от приетата в България доктрина за сигурност, която откроява сред заплахите използването на несертифицирани средства за защита и използването на чуждестранни софтуерни средства при наличие на местни аналози. Необходимостта от сертифициране и използване на местен софтуер е залегнала във федералните закони „За информацията, информационните технологии и защитата на информацията“, „За държавната тайна“, „За подаване на поръчки за доставка на стоки, извършване на работи, предоставяне на услуги за държавни и общински нужди“ и др. Следователно при избора на сървър на база данни за система за биометричен контрол е необходимо да се обърне голямо внимание на възможностите му за информационна сигурност и наличието на подходящи сертификати. Променливостта ще бъде важна при избора на СУБД за биометрична система. Например, миниатюрна част от такава система трябва да работи на високоспециализирани мобилни устройства, отделна версия на същата системамогат да бъдат предназначени изключително за изследователска работа (агрегиране, групиране, класифициране на данни) върху вече натрупана база. Освен това СУБД за биометрични системи се нуждаят от средства за осигуряване на възстановяване след бедствие. Във всеки случай обаче основните изисквания към СУБД за работа с данни в биометрични системи трябва да бъдат поддръжката на специфични типове данни, надеждност и сигурност.

Военни СУБД Военните автоматизирани системи (АС ВН) изискват използването само на български и само сертифицирани сървъри за бази данни. Днес две системи отговарят на тези изисквания — СУБД Linter и Linter-VS (специална версия, създадена в края на 90-те години на миналия век на базата на комерсиалната СУБД Linter). AC VN използва Linter и Linter-VS от дълго време. Преди няколко години се появи модифицирана версия на СУБД PostgreSQL под марката Linter-VS. От една страна, това е добре - има избор, което означава възможност за повишаване на ефективността на AS HV. От друга страна, PostgreSQL не е местна разработка - тя е продукт на креативността на международната общност от разработчици, която се развива отделно от инструментите за сигурност, които са задължителни за системи от този клас. Следователно забавянето в тази посока е неизбежно - за всяка нова версия на PostgreSQL е необходимо да се вграждат задължителни механизми за достъп, трикратно изчистване на паметта и т.н. Всички СУБД имат различна вътрешна структура и следователно функции в отделните сегменти на задачите. Например, нека сравним архитектурата на LINTER и PostgreSQL. PostgreSQL има проста архитектура: на всеки клиент е присвоен "собствен" сървър. При тази архитектура за всяка от клиентските връзки се създава сървърен процес, който обслужва един клиент. Предимствата на този подход са лекота на внедряване, относителна лекота на паралелизиране и мащабиране. Оттук обаче следват и недостатъците: прекомерно високи изисквания към ресурсите; неефективно използване на ресурси с голям брой клиентски връзки; бавно създаване на нови връзки към сървъра; невъзможността за паралелизиране в рамките на заявката и др. Практически всички доставчици на СУБД изоставиха този модел поради недостатъците, изброени по-горе. Линтер първоначално имаше по-прогресивна, навремето революционна (за СУБД) архитектура. Сървърът ЛИНТЕР реализира механизъм за превантивна многозадачност. На всяка заявка се отделя определено време (квантум) за нейната обработка, след което ядрото на СУБД преминава към изпълнение на следващия квант от следващата заявка. Предимствата на този подход са ниски изисквания към ресурсите и висока ефективност на тяхното използване, незабавна връзка със сървъра, възможност за лесна поддръжка на голям брой различни операционни системи и др. Можете да продължите да сравнявате, да обмисляте плюсовете и минусите, например как се обработват транзакциите, индексиране, оптимизиране на заявки, поддръжка на SQL и т.н., но е очевидно, че разликите са дълбоки. Горният пример показва, че AS VN, работещ с PostgreSQL, не може да разчита на незабавно установяване на връзка, както се случва при работа с LINTER. Различията от този тип диктуват собствените си промени в архитектурата на автоматизираната система, което в някои случаи може значително да намали ефективността на AS VN като цяло. В бъдеще други играчи също могат да навлязат на пазара на AS VN - от време на време се появяват съобщения за плановете на различни производители за сертифициране на СУБД. Ако тези планове бъдат изпълнени, конкуренцията на пазара ще се засили и окончателнопотребителят само ще спечели от това. В същото време, въпреки изобилието от универсални СУБД, все още ще има нужда от специализирани системи. И компанията, която може да предложи възможност за модифициране на своя продукт, за да отговори на нуждите на конкретни задачи, в крайна сметка ще спечели предимство. Универсалните СУБД са проектирани за интензивността на модификациите, които са най-често необходими в бизнеса, и за най-често срещаната сложност на заявките. Не винаги едни и същи изисквания към СУБД се представят от AS VN. Може би автоматизираната система за снабдяване на военна част като цяло е подобна на изискванията на автоматизираната система за снабдяване на верига хипермаркети. Но дори и в супермаркетите (не хипермаркетите) информацията за покупките от всяка каса влиза в общата база данни на магазина само веднъж на ден. В условията на съвременния бой информацията (например за загубите, развръщането на части или резерви) трябва да се получава незабавно. А това предполага ревизия на цялата архитектура на автоматизираната система и налага съответни изисквания към използвания сървър на бази данни. В отделните AS VN или техните части, данните трябва да се вземат автоматично от сензорите и да се въвеждат в базата данни в реално време. В други случаи е необходима бърза аналитична обработка, която се постига чрез използване на различни видове индекси и компресия на данните. Универсалните СУБД не са предназначени за това. Например, ако изброите всички типове индекси, които една аналитична система изисква за себе си, тогава получавате много дълъг списък (хеш, B-дърво, растерно изображение, R-дърво, . JOIN, йерархичен и т.н.). Ако се изисква максимална скорост на модификации, тогава практически само един хеш индекс остава от горния списък като най-малко ресурсоемък. Универсалните СУБД са отделени от тези екстремни ситуации, те са относителноса бедни на индекси, които обикновено са не повече от три. Освен това те не обръщат много внимание на компресирането на данни. По този начин, един от начините за подобряване на AS VN е отказ от използване на една универсална СУБД във всички подсистеми на AS VN. Използването на различни специализирани СУБД позволява не само да се увеличи скоростта на AS VN, но и да се намалят изискванията към компютърните технологии.