Python și Postgres: nu mai trageți masa în memorie

Articolul SQL este interogarea. Acesta este Python care refuză să-l anuleze. Tot văd același accident: un traseu FastAPI care arată curat, un model SQLAlchemy care arată curat și un set de lucru de 200 MB, deoarece scalars().all() înseamnă „toate”. Baza de date și-a făcut treaba. Aplicația a cerut un CSV al depozitului.

Am scris deja cele cinci forme SQL pe care le folosesc în loc de o buclă. Această piesă este plicul: parametrii, un pool, un timeout și disciplina de a nu colecta un tabel deoarece cadrul de date API este convenabil.

1. Scriptul care a funcționat pe 800 de rânduri

Dump local, pandas, un groupby, un to_excel. Apoi cineva îl indică pe producție „doar pentru acest raport”. Acesta nu este un raport. Acesta este un extras din baza de date primară într-un proces care va fi ucis de OOM. Dacă răspunsul este un număr, o listă de cincizeci de rânduri sau un fișier pe care îl puteți transmite în flux, nu colectați tabelul. Scriu agregarea în SQL – sau o vedere materializată dacă este zilnică – și păstrez Python ca plic: auth, parametri, format.

2. șirurile f nu sunt o interogare API

Construirea comenzilor SELECT * FROM WHERE id = {order_id} cu un șir f este modul în care donați baza de date. Utilizați $1, %(id)s sau parametri legați. Fiecare șofer le are. SQLAlchemy text() le are. Un LLM care concatenează SQL este același bug cu mai bune maniere. Aceeași familie: construirea de liste IN prin unirea șirurilor. Utilizați ANY($1::int[]) sau o legătură adecvată. Eu nu „scapa” din calea mea.

3. ORM N+1 care arată ca Python curat

pentru factură în facturi: invoice.customer.name este o interogare de plus-un pe rând. selectinload, o alăturare sau o interogare de listă dedicată. „Voi adăuga un încărcător mai târziu” este modul în care pagina de listă moare după o expoziție comercială. Folosesc un ORM pentru scrieri care se potrivesc cu unitatea de lucru - creează ordine plus linii într-o singură sesiune. Folosesc SQL pentru pagini de listă și exporturi. Hibridul nu este un eșec. Un ORM care ascunde patru sute de interogări este.

4. O conexiune per cerere nu este un pool

Deschiderea psycopg în fiecare handler sau crearea unui motor în interiorul funcției este modul în care atingeți max_connections în timpul unei implementări. Un motor sau un pool asincron pentru proces. Un timeout la achiziție. O casă care nu poate trăi peste o așteptare care apelează la un alt serviciu. asyncpg sau psycopg 3 pentru calea fierbinte pe care o controlez. SQLAlchemy dacă echipa gândește deja în sesiuni și am nevoie de migrații plus o hartă de identitate. Nu pornesc trei ORM-uri pentru că un tutorial a folosit Django.

5. Pandas este o a doua bază de date – tratați-o ca pe una

O grupare pandas pe un cadru de doi gigaocteți este o interogare de depozit pe care o executați pe o cutie de API. Dacă aveți nevoie de pandas, extrasul ar trebui să fie deja îngust: coloanele pe care le utilizați, ziua de care aveți nevoie, o COPIE sau un cursor pe partea de server. chunksisize există. fetchmany există. randament exista. Îmi place pandas în caietele de analiză. Nu-mi place ca implementarea /stats. Acea rută este SQL plus un dict tastat.

6. Ce expediez de fapt

Un router FastAPI. Parametri validați – date, ID spațiu de lucru, o limită. O funcție care rulează o interogare parametrizată, adesea formele funcției de fereastră din celălalt articol. O piscină. O declarație expiră, astfel încât un plan prost eșuează cererea în locul instanței. Fără SELECT *. Nu silent .all() pe o tabelă nelimitată. O cerere, o tranzacție, cu excepția cazului în care am un motiv numit – căsuță de ieșire, transfer de plată. Izolarea rămâne CITEȘTE ANGAJAT până pot numi anomalia de care mă tem.

Concluzie: adeziv este permis, un al doilea depozit nu este

Python este cel mai bun lipici pe care îl am pentru HTTP și joburi. Devine costisitor atunci când se uită la Postgres. Scrieți interogarea, legați parametrii, transmiteți în flux sau agregați și mențineți procesul mic. Bucla inteligentă poate aștepta. Baza de date avea deja una mai bună – acesta este celălalt articol.