Korzystanie z buforowania połączeń

Important

Autoskalowanie bazy danych Lakebase to najnowsza wersja bazy danych Lakebase, która umożliwia skalowanie automatyczne, skalowanie do zera, rozgałęzianie i natychmiastowe przywracanie. Aby uzyskać informacje o obsługiwanych regionach, zobacz Dostępność regionów. Jeśli jesteś użytkownikiem usługi Lakebase Provisioned, zobacz Lakebase Provisioned.

Usługa Lakebase zawiera wbudowany moduł PgBouncer do zarządzania pulą połączeń, który utrzymuje pulę połączeń serwera i udostępnia je wielu połączeniom klientów. Serwer połączeń obsługuje maksymalnie 10 000 jednoczesnych połączeń, co sprawia, że idealnie nadaje się do funkcji bezserwerowych, webowych interfejsów API oraz innych aplikacji, które otwierają wiele krótkotrwałych połączeń.

Buforowanie połączeń wymaga natywnego uwierzytelniania przy użyciu hasła w Postgresie. Nie jest ona dostępna dla ról tożsamości OAuth ani Azure Databricks.

Jak działa buforowanie połączeń

Każde połączenie Postgres zużywa zasoby serwera, ponieważ usługa Postgres tworzy oddzielny proces dla każdego klienta. Aplikacje, które otwierają wiele krótkotrwałych połączeń, takich jak internetowe interfejsy API i funkcje bezserwerowe, mogą szybko wyczerpać limit połączeń serwera.

Connection pooler znajduje się między aplikacją a Postgres. Klienci łączą się z managerem puli, a manager puli przekazuje zapytania do mniejszej puli fizycznych połączeń serwera. Po zakończeniu transakcji program pooler zwraca połączenie serwera z pulą, udostępniając je następnemu klientowi.

Lakebase uruchamia PgBouncer w trybie transakcyjnym. W trybie transakcji połączenie serwera jest przechowywane przez czas trwania pojedynczej transakcji, a następnie zwracane do puli. Dzięki temu wielu klientów współużytkuje małą pulę połączeń serwera.

Tryb transakcji poprawia wydajność połączenia, ale ogranicza niektóre funkcje bazy danych Postgres, które wymagają trwałego połączenia z serwerem. Zobacz Ograniczenia trybu transakcji.

Pule połączeń

Narzędzie PgBouncer tworzy oddzielną pulę dla każdej bazy danych i kombinacji użytkownika. Dwóch użytkowników łączących się z tą samą bazą danych uzyskują niezależne pule. Rozmiar każdej puli wynosi około 90% limitu bezpośredniego połączenia obliczeniowego.

Gdy wszystkie połączenia w puli są używane, nowe żądania od klientów oczekują w kolejce. Jeśli połączenie z serwerem nie stanie się dostępne w ciągu 2 minut, klient otrzyma błąd przekroczenia limitu czasu.

Limity połączeń

Trzy limity regulują buforowanie połączeń.

Limit	Wartość	Co kontroluje
Połączenia klienta (max_client_conn)	10 000	Maksymalna liczba połączeń z aplikacji do narzędzia PgBouncer
Rozmiar puli (default_pool_size)	~90% z max_connections	Aktywne połączenia serwerowe na każdą parę (użytkownik, baza danych)
Połączenia bezpośrednie (max_connections)	Różni się w zależności od rozmiaru obliczeniowego	Maksymalna liczba połączeń bezpośrednich Postgres

Limit połączeń bezpośrednich zależy od rozmiaru obliczeniowego. Na przykład obliczenia 8 CU obsługują 1678 połączeń bezpośrednich, a 16 obliczeń CU obsługuje 3357. Aby uzyskać pełną listę, zobacz Specyfikacje obliczeniowe.

Buforowanie połączeń umożliwia aplikacji obsługę znacznie większej liczby równoczesnych użytkowników niż zezwala sam limit połączeń bezpośrednich.

Wymagania wstępne

• Projekt Lakebase Autoscaling musi być aktywny.
• Musisz mieć natywną rolę hasła Postgres w projekcie. Aby uzyskać instrukcje, zobacz Tworzenie natywnej roli hasła Postgres.
• Aby korzystać z puli tylko do odczytu, musisz mieć punkt końcowy o wysokiej dostępności z włączoną funkcją Zezwalaj na dostęp do instancji obliczeniowych tylko do odczytu. Zobacz Wysoka dostępność.

Włącz buforowanie połączeń

1. W aplikacji Lakebase przejdź do projektu i kliknij pozycję Połącz.
2. Wybierz gałąź i jednostkę obliczeniową, z którą chcesz nawiązać połączenie.
3. Z listy rozwijanej Rola wybierz natywną rolę hasła Postgres. Przełącznik Buforowanie połączeń jest widoczny tylko wtedy, gdy rola z hasłem jest wybrana. Jest ona ukryta dla ról tożsamości OAuth i Azure Databricks.
4. Włącz funkcję buforowania połączeń.
5. Skopiuj parametry połączenia i użyj go w aplikacji.

Formaty ciągów połączeń

Parametry połączenia puli używają innej nazwy hosta niż bezpośrednie połączenia z bazą danych:

Typ	Format nazwy hosta	Kiedy stosować
Pooler odczytu i zapisu	<endpoint-id>-pooler.<region>.<cloud>.databricks.com	Wszystkie operacje zapisu i odczytu są kierowane za pomocą poolera.
Pooler tylko do odczytu	<endpoint-id>-ro-pooler.<region>.<cloud>.databricks.com	Tylko do odczytu. Wymaga punktu końcowego wysokiej dostępności z włączonym dostępem do odczytu.

Oba typy puli używają portu 5432.

Uwaga / Notatka

Skopiuj ciąg połączeniowy puli bezpośrednio z okna dialogowego Połącz w aplikacji Lakebase, aby uzyskać poprawną nazwę hosta, punkt końcowy, region i chmurę.

Ograniczenia trybu transakcji

Następujące funkcje Postgres nie są dostępne podczas korzystania z poolera połączeń:

• Instrukcje przygotowane na poziomie SQL: PREPARE i DEALLOCATE instrukcje nie są obsługiwane w trybie transakcji. Instrukcje przygotowane na poziomie sterownika (używane wewnętrznie przez psycopg2, node-postgres, JDBC i podobne biblioteki) działają poprawnie za pomocą obsługi na poziomie protokołu PgBouncer. W przypadku JDBC, jeśli dostrzegasz błędy związane z przygotowanymi instrukcjami, ustaw prepareThreshold=0 tak, aby wyłączyć buforowanie nazwanych instrukcji przygotowanych po stronie serwera.

• Ustawienia na poziomie sesji: SET polecenia nie są utrwalane między transakcjami, ponieważ każda transakcja może używać innego połączenia serwera. Przykład:

  BEGIN;
  SET search_path TO myschema;
  SELECT * FROM mytable; -- works in this transaction
  COMMIT;
  -- connection returns to pool after COMMIT
  SELECT * FROM mytable; -- ERROR: relation "mytable" does not exist
  

  Aby trwale zastosować ustawienie, użyj ALTER ROLE zamiast tego:

  ALTER ROLE myrole SET search_path TO myschema, public;
  

• Tabele tymczasowe przechowywane w sesji: tabele tymczasowe, które utrzymują się między transakcjami, nie są dostępne. Połączenie zwrócone do puli może zostać przypisane do innego klienta w następnej transakcji.

• WITH HOLD Kursory: Kursory zadeklarowane z WITH HOLD wymagają trwałego połączenia i nie są obsługiwane.

• Blokady doradcze: Narzędzie PgBouncer nie obsługuje blokad doradczych. Blokady doradcze wymagają stałego połączenia z serwerem, które nie jest dostępne w trybie transakcyjnym.

• LISTEN/NOTIFY: Nieobsługiwane. Użyj bezpośredniego połączenia (bez puli) dla aplikacji, które wymagają komunikacji w modelu pub/sub.

• pg_dump i migracje schematów: użyj bezpośredniego połączenia dla pg_dump, migracji schematów i innych narzędzi, które opierają się na stanie na poziomie sesji.

Uwaga / Notatka

W przypadku aplikacji, które wymagają funkcji Postgres na poziomie sesji, użyj bezpośredniego ciągu połączenia z okna dialogowego Connect bez włączania opcji Pula połączeń.

Następne kroki

• Parametry połączenia: odwołanie do formatu parametrów połączenia dla połączeń bezpośrednich. Zobacz Parametry połączenia.
• Tworzenie ról postgres: jak utworzyć natywne role haseł postgres wymagane do buforowania połączeń. Zobacz Tworzenie ról Postgres.
• Informacje o uwierzytelnianiu: porównanie metod uwierzytelniania OAuth i hasła. Zobacz Informacje o uwierzytelnianiu.