Anslutningspoolning för en Android-app som ansluter till en Postgresql DB

Hur man gör anslutningspoolning

Varje plattform har olika anslutningspoolningsgränssnitt. Du måste läsa dokumentationen för den specifika plattformen du använder (Ruby+Rails eller vad som helst), eller använda ett generiskt poolande mellanlager som PgBouncer.

Svar som rör ett verktyg (säg PHP med Zend Framework) har inget att göra med svar som rör ett annat verktyg (som Ruby on Rails). Även om du väljer något som PgBouncer, finns det fortfarande detaljer relaterade till hur plattformen hanterar transaktionslivslängder, poolläge att välja baserat på appbehov, etc.

Så du måste först bestämma vad du använder och vad du behöver göra med det. Då studera hur man ställer in sin anslutningspoolning. (Med många verktyg är det bara automatiskt).

Om du fortfarande har fastnat efter att ha läst dokumentationen för den plattform du väljer , fråga en ny detaljerad och specifik fråga taggade på lämpligt sätt för plattformen.

Pooling och mellanprogram

Låt inte din app ansluta direkt till PostgreSQL. Särskilt om det är över Internet från slumpmässiga klienter.

Använd en webbserver nära PostgreSQL-servern och låt den acceptera webbtjänstförfrågningar för att förmedla åtkomst till databasen via ett väldefinierat webb-API med korta transaktioner som är avsedda att begära i så stor utsträckning som möjligt.

Det här är inte bara ett fall av mottagen visdom - det finns goda skäl att göra det och allvarliga problem med att köra PostgreSQL från slumpmässiga enheter över Internet.

Android-appen talar direkt till Pg

Problem med att prata med Pg direkt över Internet från många klienter inkluderar:

• Varje PostgreSQL-backend har en kostnad, oavsett om den är inaktiv eller inte. PgBouncer i transaktionspoolningsläge hjälper till med detta till viss del.

• Anslutningar försvinner slumpmässigt när du arbetar över internet. WiFi tappar, IP-adressändringar på dynamiska IP-tjänster, mobiltjänst som tonar ut eller maxar i kapacitet eller bara vacklar tillsammans med hög paketförlust där. Detta lämnar dig med massor av PostgreSQL-anslutningar i obestämda tillstånd, förmodligen med öppna transaktioner, vilket ger dig <IDLE> in transaction problem och behovet av att tillåta mycket fler anslutningar än vad som verkligen fungerar.

• Det är transaktionsmässigt - om något inte slutförs kan du avsluta transaktionen och veta att det inte kommer att ha någon effekt.

Fördelar med att ha ett mellanlager

En server som svarar på HTTP-webbtjänstförfrågningar från din app på Android-enheter för att fungera som en mäklare för databasåtkomst kan vara en stor fördel.

• Du kan definiera ett API med versioner, så när du introducerar nya funktioner eller behöver ändra API:et behöver du inte bryta gamla klienter. Detta är möjligt med Pg med hjälp av lagrade procedurer eller många vyer men kan bli klumpig.

• Du kontrollerar strikt omfattningen av databasåtkomst och transaktionslivslängder.

• Du kan definiera ett idempotent API, där att köra samma begäran flera gånger bara har en effekt en. (Jag rekommenderar starkt att du gör detta på grund av nästa punkt).

• Allt är statslöst och kan ha korta time-outs. Om något inte fungerar är det bara att försöka igen.

• Varje databasanslutning går via en pool, så att du inte har lediga sessioner. Varje databasbackend arbetar hårt för maximal genomströmning.

• Du kan arbeta i kö i stället för att försöka göra massor samtidigt och slå ner servern. (Du kan också göra detta med PgBouncer i transaktionspoolningsläge).

... och ändra din redigering för att ändra frågans betydelse:

Prestanda

Din "Också" om prestanda är egentligen en helt annan fråga (och bör helst postas som sådan). Den mycket korta versionen:helt omöjlig att förutsäga utan mycket mer information om arbetsbelastningen, som antal db-förfrågningar per klientappförfrågan, typ av data, typ av frågor, storlek på data, frekvens av frågor, praktisk cachning, .. .... oändligt. Alla som påstår sig definitivt svara på den frågan är antingen den första sanna synska i historien eller helt full av den.

Du måste räkna ut ungefär vad din datastorlek, frågemönster etc kommer att vara. Ta reda på hur mycket du har råd att cache i en mellanlagercache som redis/memcached, hur inaktuell du kan låta den bli, vilken nivå av cache-ogiltigförklaring du behöver. Bestäm om din "heta" datauppsättning (som du kommer åt mycket) kommer att passa i RAM eller inte. Bestäm om indexen för ofta efterfrågade tabeller kommer att passa i RAM eller inte. Ta reda på vad din grova läs/skrivbalans är och hur mycket dina skrivningar sannolikt kommer att vara enbart infogning (lägg till) eller mer vanlig OLTP (infoga/uppdatera/ta bort). Dumma upp en datamängd och vissa klientbelastningar. Då du kan börja svara på den frågan – kanske. För att göra det rätt måste du också simulera låsta/försvunna klienter, etc.

Se varför det inte bara är ett "Också?".