Forbindelsespooling for en Android-app, der opretter forbindelse til en Postgresql DB

Sådan laver du forbindelsespooling

Hver platform har en anden forbindelsespooling-grænseflade. Du skal læse dokumentationen for den specifikke platform, du bruger (Ruby+Rails eller hvad som helst), eller bruge et generisk pooling-mellemlag som PgBouncer.

Svar vedrørende ét værktøj (f.eks. PHP med Zend Framework) vil ikke have noget at gøre med svar vedrørende et andet værktøj (som Ruby on Rails). Selvom du vælger noget som PgBouncer, er der stadig detaljer relateret til, hvordan platformen håndterer transaktionslevetider, pooling-tilstand at vælge baseret på app-behov osv.

Så du skal først bestemme, hvad du bruger, og hvad du skal gøre med det. Så undersøge, hvordan man opsætter sin forbindelsespooling. (Med mange værktøjer er det bare automatisk).

Hvis du stadig sidder fast efter at have læst dokumentationen til den platform, du vælger , spørg en ny detaljeret og specifik spørgsmål tagget passende til platformen.

Pooling og middleware

Lad ikke din app oprette forbindelse direkte til PostgreSQL. Især hvis det er over internettet fra tilfældige klienter.

Brug en webserver i nærheden af ​​PostgreSQL-serveren og få den til at acceptere webserviceanmodninger for at formidle adgang til databasen via et veldefineret web-API med korte transaktioner, der er beregnet til at anmode om i så høj grad som muligt.

Dette er ikke kun et tilfælde af modtaget visdom - der er gode grunde til at gøre det, og alvorlige problemer med at køre PostgreSQL fra tilfældige enheder over internettet.

Android-app taler direkte til Pg

Problemer med at tale med Pg direkte over internettet fra mange klienter omfatter:

• Hver PostgreSQL-backend har en omkostning, uanset om den er inaktiv eller ej. PgBouncer i transaktionspooling-tilstand hjælper til en vis grad med dette.

• Forbindelser går tabt tilfældigt, når du arbejder over internettet. WiFi-fald, IP-adresseændringer på dynamiske IP-tjenester, mobiltjeneste, der fader ud eller maksimalt ud i kapacitet eller bare vakler sammen med højt pakketab der. Dette efterlader dig med masser af PostgreSQL-forbindelser i ubestemte tilstande, sandsynligvis med åbne transaktioner, hvilket giver dig <IDLE> in transaction problemer og behovet for at tillade mange flere forbindelser, end hvad der egentlig fungerer.

• Det er transaktionsbestemt - hvis noget ikke afsluttes, kan du afslutte transaktionen og vide, at det ikke har nogen effekt.

Fordele ved at have et mellemlag

En server, der reagerer på HTTP-webserviceanmodninger fra din app på Android-enheder om at fungere som mægler for databaseadgang, kan være en stor fordel.

• Du kan definere en versioneret API, så når du introducerer nye funktioner eller skal ændre API'en, behøver du ikke at bryde gamle klienter. Dette er muligt med Pg ved at bruge lagrede procedurer eller mange visninger, men det kan blive klodset.

• Du kontrollerer strengt omfanget af databaseadgang og transaktionslevetider.

• Du kan definere en idempotent API, hvor det kun har en effekt at køre den samme anmodning flere gange. (Jeg anbefaler stærkt at gøre dette på grund af det næste punkt).

• Alt er statsløst og kan have korte time-outs. Hvis noget ikke virker, skal du bare prøve det igen.

• Hver databaseforbindelse går via en pool, så du ikke har ledige sessioner siddende. Hver database-backend arbejder hårdt for maksimal gennemstrømning.

• Du kan arbejde i kø i stedet for at prøve at lave tonsvis samtidig og tæske serveren. (Du kan også gøre dette med PgBouncer i transaktionspooling-tilstand).

... og re din redigering for at ændre spørgsmålets betydning:

Ydeevne

Din "Også" re-performance er virkelig et helt andet spørgsmål (og skal helst være postet som sådan). Den meget korte version:fuldstændig umulig at forudsige uden meget mere information om arbejdsbyrden, som antal db-anmodninger pr. klientapp-anmodning, type data, type forespørgsler, datastørrelse, forespørgselsfrekvens, praktisk caching, .. .... uendeligt. Enhver, der hævder at svare definitivt på det spørgsmål, er enten den første sande synske i historien eller fuldstændig fuld af det.

Du skal finde ud af nogenlunde, hvad din datastørrelse, forespørgselsmønstre osv. vil være. Find ud af, hvor meget du har råd til at cache i en mellemlagscache som redis/memcached, hvor forældet du kan lade den blive, hvilket niveau af cache-invalidering du har brug for. Bestem, om dit "varme" datasæt (som du har adgang til meget) vil passe i RAM eller ej. Bestem, om indekserne for ofte forespurgte tabeller vil passe i RAM eller ej. Find ud af, hvad din grove læse-/skrivebalance er, og hvor meget dine skrivninger sandsynligvis kun vil være indsat (tilføj) eller mere almindelig OLTP (indsæt/opdater/slet). Dummy op et datasæt og nogle klientarbejdsbelastninger. Så du kan begynde at besvare det spørgsmål – måske. For at gøre det rigtigt skal du også simulere stoppede/forsvundne klienter osv.

Se hvorfor det ikke bare er et "Også?".