Verbindingspooling voor een Android-app die verbinding maakt met een Postgresql DB

Verbindingspooling doen

Elk platform heeft een andere interface voor het poolen van verbindingen. Je moet de documentatie lezen voor het specifieke platform dat je gebruikt (Ruby+Rails of wat dan ook), of een generieke pooling-middenlaag zoals PgBouncer gebruiken.

Antwoorden met betrekking tot een tool (bijvoorbeeld PHP met Zend Framework) hebben niets te maken met antwoorden met betrekking tot een andere tool (zoals Ruby on Rails). Zelfs als je iets als PgBouncer kiest, zijn er nog steeds details met betrekking tot hoe het platform omgaat met de levensduur van transacties, pooling-modus om te kiezen op basis van app-behoeften, enz.

Je moet dus eerst bepalen wat je gebruikt en wat je ermee moet doen. Dan bestuderen hoe u de pooling van verbindingen kunt opzetten. (Bij veel tools gaat het gewoon automatisch).

Als je nog steeds vastzit na het lezen van de documentatie voor het platform dat je kiest , vraag een nieuwe gedetailleerde en specifieke vraag op de juiste manier getagd voor het platform.

Pooling en middleware

Laat uw app niet rechtstreeks verbinding maken met PostgreSQL. Vooral als het via internet is van willekeurige clients.

Gebruik een webserver in de buurt van de PostgreSQL-server en laat deze webserviceverzoeken accepteren om toegang tot de database te bemiddelen via een goed gedefinieerde web-API met korte transacties die zo veel mogelijk kunnen worden aangevraagd.

Dit is niet alleen een kwestie van ontvangen wijsheid - er zijn goede redenen om het te doen, en ernstige problemen met het uitvoeren van PostgreSQL vanaf willekeurige apparaten via internet.

Android-app praat rechtstreeks met Pg

Problemen met rechtstreeks via internet met Pg praten vanaf veel klanten zijn onder meer:

• Elke PostgreSQL-backend heeft een prijs, of deze nu inactief is of niet. PgBouncer in transactiepooling-modus helpt hier tot op zekere hoogte bij.

• Verbindingen gaan willekeurig verloren wanneer u via internet werkt. WiFi valt weg, IP-adreswijzigingen op dynamische IP-services, mobiele services die vervagen of maximaal zijn in capaciteit of gewoon wankelen met hoog pakketverlies daar. Dit laat je achter met veel PostgreSQL-verbindingen in onbepaalde toestanden, waarschijnlijk met open transacties, waardoor je <IDLE> in transaction krijgt problemen en de noodzaak om veel meer verbindingen toe te staan ​​dan echt werk doen.

• Het is een transactie - als iets niet wordt voltooid, kun je de transactie beëindigen en weten dat het geen effect heeft.

Voordelen van een tussenlaag

Een server die reageert op HTTP-webserviceverzoeken van uw app op Android-apparaten om als tussenpersoon voor databasetoegang te fungeren, kan een groot voordeel zijn.

• U kunt een API met versiebeheer definiëren, dus wanneer u nieuwe functies introduceert of de API moet wijzigen, hoeft u geen oude clients te breken. Dit is mogelijk met Pg met behulp van opgeslagen procedures of veel weergaven, maar kan onhandig worden.

• U controleert strikt de reikwijdte van databasetoegang en transactielevensduren.

• U kunt een idempotent API definiëren, waarbij het meerdere keren uitvoeren van hetzelfde verzoek slechts één effect heeft. (Ik raad je ten zeerste aan dit te doen vanwege het volgende punt).

• Alles is stateloos en kan korte time-outs hebben. Als iets niet werkt, probeer je het gewoon opnieuw.

• Elke databaseverbinding gaat via een pool, dus je hebt geen inactieve sessies. Elke database-backend werkt hard voor maximale doorvoer.

• Je kunt in de wachtrij werken in plaats van te proberen tonnen tegelijk te doen en de server te verslaan. (U kunt dit ook doen met PgBouncer in de modus voor transactiepooling).

... en pas je bewerking aan om de betekenis van de vraag te wijzigen:

Prestaties

Uw "Ook" re-performance is echt een heel andere vraag (en zou bij voorkeur als zodanig gepost moeten worden). De zeer korte versie:totaal onmogelijk te voorspellen zonder veel meer informatie over de werklast, zoals aantal db-verzoeken per client-app-verzoek, soort gegevens, soort vragen, grootte van gegevens, frequentie van vragen, bruikbaarheid van caching, .. .... eindeloos. Iedereen die beweert die vraag definitief te beantwoorden, is ofwel de eerste echte paranormaal begaafde in de geschiedenis of zit er helemaal vol van.

U moet er ongeveer achter komen wat uw gegevensomvang, querypatronen, enz. zullen zijn. Zoek uit hoeveel je je kunt veroorloven om te cachen in een midlayer-cache zoals redis/memcached, hoe oud je het kunt laten worden, welk niveau van cache-invalidatie je nodig hebt. Bepaal of uw "hot" dataset (waar u veel toegang toe hebt) in RAM past of niet. Bepaal of de indexen voor vaak opgevraagde tabellen in het RAM passen of niet. Zoek uit wat uw ruwe lees-/schrijfbalans is en hoeveel uw schrijfbewerkingen waarschijnlijk alleen invoegen (toevoegen) of meer reguliere OLTP (invoegen/bijwerken/verwijderen) zijn. Dummy-up van een dataset en enkele client-workloads. Dan je kunt beginnen met het beantwoorden van die vraag - misschien. Om het goed te doen, moet je ook vastgelopen/verdwenen klanten, enz. simuleren.

Zie waarom het niet alleen een "Ook?" is.