PostgreSQL Connection Pooling:Част 1 – Плюсове и минуси

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

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

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

В съвременните уеб приложения обаче клиентите са склонни да отварят много връзки. Често разработчиците са силно обезкуражени да поддържат връзка с база данни, докато се извършват други операции. „Отворете връзка възможно най-късно, затворете връзка възможно най-скоро“. Но това създава проблем с архитектурата на PostgreSQL – разклоняването на процес става скъпо, когато транзакциите са много кратки, тъй като общата мъдрост диктува, че трябва да бъдат.

Архитектурата на пула за връзки

Използването на модерна езикова библиотека намалява донякъде проблема – обединяването на връзки е съществена характеристика на повечето популярни библиотеки за достъп до база данни. Той гарантира, че „затворените“ връзки не са наистина затворени, а се връщат в пул, а „отварянето“ на нова връзка връща обратно същата „физическа връзка“, намалявайки действителното разклоняване от страна на PostgreSQL.

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

• Дори с относително малък брой модули и малък размер на пула във всеки, в крайна сметка имате много сървърни процеси. Превключването на контекста между тях е скъпо.
• Поддръжката на пул варира в широки граници между библиотеките и езиците – един пул с лошо поведение може да консумира всички ресурси и да остави базата данни недостъпна за други модули.
• Няма централизиран контрол – не можете да използвате мерки като ограничения за достъп, специфични за клиента.

В резултат на това са разработени популярни междинни програми за PostgreSQL. Те се намират между базата данни и клиентите, понякога на отделен сървър (физически или виртуален), а понякога в една и съща кутия и създават пул, към който клиентите могат да се свързват. Този междинен софтуер са:

• Оптимизиран за PostgreSQL и неговата доста уникална архитектура сред съвременните СУБД.
• Осигурете централизиран контрол на достъпа за различни клиенти.
• Позволява ви да извлечете същите награди като пуловете от страна на клиента, а след това още малко (ще ги обсъдим по-подробно в следващите ни публикации)!

Недостатъци на PostgreSQL Connection Pooler

Пулърът за връзки е почти незаменима част от готовата за производство настройка на PostgreSQL. Въпреки че има много добре документирани предимства от използването на пул за връзки, има някои аргументи срещу използването на такъв:

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

  

• Мидълуерът предполага допълнителни разходи. Или имате нужда от допълнителен сървър (или 3), или сървърите на базата данни трябва да имат достатъчно ресурси, за да поддържат пул за свързване, в допълнение към PostgreSQL.
• Споделянето на връзки между различни модули може да се превърне в уязвимост в сигурността. Много е важно да конфигурираме pgPool или PgBouncer да почистват връзките, преди да бъдат върнати в пула.
• Удостоверяването преминава от СУБД към пула на връзки. Това може да не винаги е приемливо.

  

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

Трябва ли да използвате PostgreSQL Connection Pooler?

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

В следващата публикация ще обсъдим един от най-популярните пулери за връзки в света на PostgreSQL – PgBouncer, следван от Pgpool-II, и накрая сравнение на тест за производителност на тези две PostgreSQL пулери за връзки в последната ни публикация от поредицата.