Kodėl reikalinga ryšio telkinimas (PgBouncer)?

Question

Accepted Answer

**Ryšio telkinimas** pakartotinai naudoja mažą duomenų bazės ryšių rinkinį daugybei kliento užklausų, užuot atidarant naują ryšį kiekvienai užklausai. PostgreSQL ryšiai yra **brangūs** (kiekvienas yra atskiras procesas, naudojantis daug atminties), todėl telkinimas yra būtinas dėl našumo ir mastelabilumo esant apkrovai. **PgBouncer** yra standartinis telkintojas.

## Problema: PostgreSQL ryšiai yra brangūs

```text
Each PostgreSQL connection = a separate OS PROCESS, using ~5-10MB of memory.
  ✗ Opening a connection has overhead (process creation, auth, setup)
  ✗ Many connections (e.g. 1000s from a busy app) → huge memory use, contention
  ✗ Postgres has a max_connections limit (often ~100); exceeding it = errors
→ Opening/closing a connection per request, or holding thousands open, doesn't scale.
```

## Sprendimas: ryšio telkinys

```text
A POOL maintains a small set of REUSABLE connections to Postgres.
Application requests BORROW a connection from the pool, use it, and RETURN it.
  ✓ Connections are reused (no per-request open/close overhead)
  ✓ Many app requests share a few DB connections (e.g. 10000 clients → 20 connections)
  ✓ Stays within max_connections, controls resource use → scales
```

## PgBouncer — standartinis išorinis telkintojas

```text
PgBouncer sits BETWEEN the application and PostgreSQL — lightweight, efficient.
Pooling modes:
  Session   → a connection is assigned for the client's whole session
  Transaction → a connection is held only for the duration of a TRANSACTION (most
               efficient — connections returned between transactions; common choice)
  Statement → per-statement (most aggressive; limited)
→ Transaction pooling maximizes connection reuse for typical web apps.
```

## Kur vyksta telkinimas

```text
Application-level → many ORM/driver libraries have built-in pools (per app instance)
External pooler (PgBouncer) → a shared pool in front of Postgres (best for many app
  instances / serverless, where per-instance pools would still overwhelm the DB)
→ Serverless especially needs an external pooler (many short-lived instances).
```

## Kodėl tai svarbu

Ryšio telkinimas yra esminės žinios, norint paleisti PostgreSQL **dideliame mastelyje**, nes PostgreSQL ryšiai yra iš esmės brangūs (kiekvienas yra atskiras operacinės sistemos procesas, naudojantis reikšmingą kiekį atminties), todėl suprasti, kodėl telkinimas reikalingas ir kaip jis veikia, yra svarbus aukštojo lygio žinios dėl našaus ir masteliaus sistemų.

Pagrindinė problema yra ta, kad naivus metodas — atidarant ryšį per užklausą, arba palaikant atvirtas tūkstančius ryšių iš užimto taikymo — neskaliuojasi su Postgres: ryšiai yra brangi (atmintis per procesą, sukūrimo pridėtinės išlaidos), o Postgres turi `max_connections` limitą (dažnai ~100), kuris lengvai viršijamas, sukeliant klaidas ir išteklių išnaudojimą. **Ryšio telkinimas** tai išsprendžia, palaikydamas mažą pakartotinai naudojamų ryšių rinkinį, kurį dalijasi daug taikymo užklausų (jie juos skolinasi ir grąžina) — todėl tūkstančiai klientų gali būti aptarnauti keliasdešimt duomenų bazės ryšių, pašalinant pridėtines išlaidas per užklausą ir liekant ribose.

Supratimas apie **PgBouncer** (standartinį išorinį telkintuvą) ir jo **telkinimo režimus** — ypač **sandorio telkinimą** (ryšio palaikymą tik sandorio metu, maksimizuojant pakartotinį naudojimą, bendrą pasirinkimą žiniatinklio programoms) — yra svarbi praktinė žinia.

Žinojimas **kur vyksta telkinimas** (taikymo lygio telkintuvai pagal instanciją, arba išorinis telkintojas, pvz., PgBouncer, dėl daugelio instancijų arba serverless) yra svarbus architektūrinis punktas — **serverless ypač reikalinga išorinis telkintojas**, nes daug trumpalaikių instancijų kitaip perpildytų Postgres ryšiais (dažna, reali problema).

Kadangi ryšio valdymas tiesiogiai veikia mastelabilumą ir stabilumą esant apkrovai (o Postgres ryšio per procesą modelis tai daro ypatingai jautrų), ir kadangi telkinimas (ypač PgBouncer su sandorio telkinimu) yra standartinis, būtinas sprendimas, supratimas apie ryšio telkinimą — kodėl Postgres to reikalinga, kaip jis veikia, PgBouncer ir jo režimai, ir serverless aplinkos svarbą — yra svarbi aukštojo lygio žinia, skirta PostgreSQL valdymui dideliame mastelyje, dažnai kritiškas dėmesys gamybos sistemoms, kurie atskiria tuos, kurie gali mastelinti Postgres, nuo tų, kurie susiduria su ryšio ribos nepaisymo klaidomis.