Миналата седмица в CHAR(10) конференция имахме семинар на тема „Облачни бази данни“. Казано по-просто:какво да правим, когато изискванията на случаите на използване надвишават наличните ресурси в сървъра на базата данни.
Това беше основна тема на цялата конференция и през деня бяха илюстрирани няколко решения. Обща тема е, че никое решение не отговаря на всички случаи на употреба и че всяко решение идва със своята цена; следователно трябва да изберете решението, което вашият случай на употреба може да си позволи.
Друг често срещан (макар и имплицитен) момент е фокусът върху решенията на „високо ниво“, тоест:свързване на няколко сървъра на бази данни на по-високо ниво, за да се емулира един сървър с по-големи ресурси.
Очевидно предимство е, че не е нужно да променяте добре проверения PostgreSQL код; недостатъкът е, че като използвате множество сървъри на бази данни с техните независими времеви линии, губите някои полезни свойства. Два примера:частичната загуба на транзакционната семантика генерира конфликти; Предварителният анализ на всяка заявка извън базата данни въвежда ограничения върху приетите заявки.
Дискусията беше доста интересна и когато Димитри Фонтейн спомена отдалечени пространства за таблици, започнах да се чудя около свързана, но отделна идея, а именно:дали подход на по-ниско ниво към проблема с обединяването на ресурсите наистина би било непрактично. Преди да успея да разясня детайлите, семинарът приключи и можех само да скицирам идеята на някои от хората, които бяха около бялата дъска (сред които Габриеле Бартолини, Ник Фериер, Марко Крин, Хану Кросинг, Грег Смит) заедно с основните въпроси "осъществимо ли изглежда?" и „това прилича ли на нещо, което вече знаете?“.
Кратка скица:стекът от приложения може да бъде представен по този начин
(application) --> (connection) --> (db server) --> (resources)
където ресурсите, използвани от базата данни, включват съхранение, RAM и CPU. Целта е да се позволи на приложението да управлява повече ресурси, за да увеличи капацитета и скоростта. „Умните“ приложения, които управляват няколко бази данни, могат да бъдат представени като
(application) --> (connection) --> (db server) --> (resources) | +---------> (connection) --> (db server) --> (resources)
докато решенията за „обединяване на връзки“ могат да бъдат представени като
(application) --> (connection) --> (db server) --> (resources) | +---------> (db server) --> (resources)
под решения на „по-ниско ниво“ имам предвид нещо като
(application) --> (connection) --> (db server) --> (resources) | +---------> (resources)
което може да прилича на нещо познато, но не е това, което предлагам тук. За да обясня разликата, мога да увелича детайлите и да напиша
(resources) = (virtual resources) --> (physical resources)
за да представи факта, че на най-ниското ниво можете да имате нетривиално съпоставяне между физически и виртуални обекти. Например, SAN съхранение или RAID ивици могат да осигурят по-големи виртуални дискове чрез свързване на по-малки физически дискове. Такива случаи могат да бъдат представени като
(application) --> (connection) --> (db server) --> (virt.res.) --> (ph.res.) | +--------> (ph.res.)
Моето предложение е да се обединят ресурси на сървъра на базата данни ниво, така че да можем да имаме по-ефективна „виртуализация“, като използваме познанията за конкретните случаи на използване за всеки ресурс (CPU, RAM, диск), и в същото време можем да избегнем трудностите на транзакционната парадигма. Картината ще бъде:
(application) --> (connection) --> (db server) --> (virt.res.) --> (ph.res.) | +--------> (virt.res.) --> (ph.res.)
Предимството е, че не е необходимо да управляваме всички възможни случаи на използване за всеки виртуален ресурс; просто трябва да управляваме (и да оптимизираме) случаите на употреба, които всъщност са необходими на PostgreSQL. Например:WAL все пак трябва да се записва в локално “невиртуализирано” хранилище, bgwriter ще има достъп до локални и отдалечени ресурси (RAM и диск) и т.н.
Някои последни думи за надеждността. За да работи правилно цялата система се нуждае от всяка подсистема; частичните откази не се управляват, тъй като тази архитектура не е излишна. Това е разпределена система, но не е споделена. Ако тази архитектура може да осигури евтина и проста мащабируемост чрез сървър на виртуална база данни, който е функционално еквивалентен на физически сървър с по-големи ресурси, тогава високата наличност може да се получи по стандартния начин чрез настройка на два идентични виртуални сървъра в конфигурация с горещ режим на готовност.
Качеството на мрежата оказва голямо влияние върху цялостната производителност; този дизайн може да бъде полезен само ако имате масив от машини в една и съща локална мрежа, не само от съображения за скорост, но и защото мрежовата повреда всъщност би била системна повреда. Дори и с тези ограничения, моето мнение е, че тази опция би била доста полезна.
Това все още е скица, която да се използва като справка за по-нататъшно обсъждане. Следващи възможни стъпки:
- за да направите подробен списък на случаите на използване на ресурсите
- за да решите кои технологии могат да помогнат най-добре във всеки случай на употреба
- за оценка на действителните разходи за изпълнение/разработка
