Pula połączeń PostgreSQL:część 1 – zalety i wady

Dawno temu, w odległej galaktyce, „wątki” były rzadko używaną i rzadko zaufaną nowością programistyczną. W tym środowisku pierwsi programiści PostgreSQL zdecydowali, że rozwidlenie procesu dla każdego połączenia z bazą danych jest najbezpieczniejszym wyborem. Szkoda, gdyby baza danych uległa awarii.

Od tego czasu pod tym mostem przepłynęło dużo wody, ale społeczność PostgreSQL utknęła w swojej pierwotnej decyzji. Trudno im zarzucić ich argumentację – bo to prawda, że:

• Każdy klient posiadający własny proces zapobiega awariom całej bazy danych przez źle zachowującego się klienta.
• W nowoczesnych systemach Linux różnica w narzutach między rozwidleniem procesu a tworzeniem wątku jest znacznie mniejsza niż kiedyś.
• Przejście na architekturę wielowątkową będzie wymagało obszernych przepisywania.

Jednak we współczesnych aplikacjach internetowych klienci mają tendencję do otwierania wielu połączeń. Deweloperzy są często silnie zniechęcani do utrzymywania połączenia z bazą danych podczas innych operacji. „Otwórz połączenie tak późno, jak to możliwe, zamknij połączenie tak szybko, jak to możliwe”. Ale to powoduje problem z architekturą PostgreSQL – rozwidlenie procesu staje się kosztowne, gdy transakcje są bardzo krótkie, jak nakazuje powszechna mądrość.

Architektura puli połączeń

Korzystanie z nowoczesnej biblioteki językowej nieco zmniejsza problem — łączenie połączeń jest istotną cechą najpopularniejszych bibliotek dostępu do baz danych. Zapewnia to, że „zamknięte” połączenia nie są tak naprawdę zamykane, ale zwracane do puli, a „otwarcie” nowego połączenia zwraca to samo „połączenie fizyczne”, zmniejszając faktyczne rozwidlenie po stronie PostgreSQL.

Jednak nowoczesne aplikacje internetowe rzadko są monolityczne i często używają wielu języków i technologii. Korzystanie z puli połączeń w każdym module jest mało wydajne:

• Nawet przy stosunkowo niewielkiej liczbie modułów i małym rozmiarze puli w każdym z nich, otrzymujesz wiele procesów serwerowych. Przełączanie kontekstu między nimi jest kosztowne.
• Obsługa pulowania różni się znacznie w zależności od bibliotek i języków – jedna źle zachowująca się pula może zużywać wszystkie zasoby i pozostawiać bazę danych niedostępną dla innych modułów.
• Nie ma scentralizowanej kontroli – nie można używać środków, takich jak limity dostępu specyficzne dla klienta.

W rezultacie powstało popularne oprogramowanie pośredniczące dla PostgreSQL. Znajdują się one między bazą danych a klientami, czasami na osobnym serwerze (fizycznym lub wirtualnym), a czasami na tym samym urządzeniu, i tworzą pulę, z którą mogą się łączyć klienci. Te oprogramowanie pośredniczące to:

• Zoptymalizowany pod kątem PostgreSQL i jego dość unikalnej architektury wśród nowoczesnych DBMS.
• Zapewnij scentralizowaną kontrolę dostępu dla różnych klientów.
• Pozwól ci zbierać te same nagrody, co pule po stronie klienta, a następnie trochę więcej (omówimy je bardziej szczegółowo w naszych następnych postach)!

Wady puli połączeń PostgreSQL

pooler połączeń jest prawie nieodzowną częścią gotowej do produkcji konfiguracji PostgreSQL. Chociaż istnieje wiele dobrze udokumentowanych korzyści z używania puli połączeń, są kilka argumentów przeciwko użyciu jednego z nich:

• Wprowadzenie do komunikacji oprogramowania pośredniczącego nieuchronnie wprowadza pewne opóźnienia. Jednak w przypadku lokalizacji na tym samym hoście i uwzględniania narzutów związanych z rozwidleniem połączenia jest to pomijalne w praktyce, jak zobaczymy w następnej sekcji.
• Oprogramowanie pośredniczące staje się pojedynczym punktem awarii. Korzystanie z klastra na tym poziomie może rozwiązać ten problem, ale wprowadza dodatkową złożoność architektury.

  

• Oprogramowanie pośredniczące oznacza dodatkowe koszty. Potrzebujesz albo dodatkowego serwera (lub 3), albo serwery baz danych muszą mieć wystarczającą ilość zasobów do obsługi puli połączeń, oprócz PostgreSQL.
• Udostępnianie połączeń między różnymi modułami może stać się luką w zabezpieczeniach. Bardzo ważne jest, abyśmy skonfigurowali pgPool lub PgBouncer do czyszczenia połączeń, zanim zostaną zwrócone do puli.
• Uwierzytelnianie przenosi się z DBMS do puli połączeń. Nie zawsze jest to akceptowalne.

  

• Zwiększa powierzchnię ataku, chyba że dostęp do bazowej bazy danych jest zablokowany, aby umożliwić dostęp tylko za pośrednictwem puli połączeń.
• Tworzy kolejny komponent, który musi być utrzymany, dostrojony do obciążenia, często łatany i aktualizowany zgodnie z wymaganiami.

Czy powinieneś używać puli połączeń PostgreSQL?

Jednak wszystkie te problemy są dobrze omawiane w społeczności PostgreSQL, a strategie łagodzenia zapewniają, że zalety puli połączeń znacznie przewyższają ich wady. Z naszych testów wynika, że ​​nawet niewielka liczba klientów może znacząco skorzystać na korzystaniu z puli połączeń. Są warte dodatkowego wysiłku związanego z konfiguracją i konserwacją.

W następnym poście omówimy jeden z najpopularniejszych poolerów połączeń w świecie PostgreSQL – PgBouncer, następnie Pgpool-II, a na koniec omówimy porównanie testów wydajności tych dwóch Pule połączeń PostgreSQL w naszym ostatnim poście z tej serii.