Come eseguire il pool di connessioni
Ogni piattaforma ha un'interfaccia di pool di connessioni diversa. Dovrai leggere la documentazione per la piattaforma specifica che utilizzi (Ruby+Rails o altro) o utilizzare un midlayer di pooling generico come PgBouncer.
Le risposte relative a uno strumento (ad esempio, PHP con Zend Framework) non avranno nulla a che fare con le risposte relative a un altro strumento (come Ruby on Rails). Anche se scegli qualcosa come PgBouncer, ci sono ancora dettagli relativi al modo in cui la piattaforma gestisce la durata delle transazioni, la modalità di pool da scegliere in base alle esigenze dell'app, ecc.
Quindi devi prima determinare cosa stai usando e cosa devi farne. Allora studia come impostare il pool di connessioni. (Con molti strumenti è solo automatico).
Se sei ancora bloccato dopo aver letto la documentazione per la piattaforma scelta , chiedi un nuovo dettagliato e specifico domanda contrassegnata in modo appropriato per la piattaforma.
Pooling e middleware
La tua app non si connette direttamente a PostgreSQL. Specialmente se è su Internet da client casuali.
Utilizza un server Web vicino al server PostgreSQL e fallo accettare richieste di servizi Web per intermediario l'accesso al database tramite un'API Web ben definita con transazioni brevi che hanno lo scopo di richiedere nella misura più ampia possibile.
Questo non è solo un caso di saggezza acquisita:ci sono buone ragioni per farlo e seri problemi con l'esecuzione di PostgreSQL da dispositivi casuali su Internet.
App per Android che parla direttamente con Pg
I problemi con la conversazione con Pg direttamente su Internet da molti client includono:
-
Ogni back-end PostgreSQL ha un costo, inattivo o meno. PgBouncer in modalità di pooling delle transazioni aiuta in una certa misura in questo.
-
Le connessioni si perdono casualmente quando lavori su Internet. Cadute WiFi, modifiche dell'indirizzo IP su servizi IP dinamici, servizi mobili che svaniscono o esauriscono la capacità o semplicemente scaglionano insieme a un'elevata perdita di pacchetti lì. Questo ti lascia molte connessioni PostgreSQL in stati indeterminati, probabilmente con transazioni aperte, dandoti
<IDLE> in transactionproblemi e la necessità di consentire molte più connessioni rispetto a quelle che stanno effettivamente facendo. -
È transazionale:se qualcosa non va a buon fine, puoi terminare la transazione e sapere che non avrà alcun effetto.
Vantaggi di avere uno strato intermedio
Un server che risponde alle richieste del servizio Web HTTP dalla tua app su dispositivi Android per fungere da broker per l'accesso al database può essere un grande vantaggio.
-
Puoi definire un'API con versione, quindi quando introduci nuove funzionalità o devi modificare l'API non devi rompere i vecchi client. Ciò è possibile con Pg utilizzando stored procedure o molte visualizzazioni, ma può diventare goffo.
-
Sei tu a controllare rigorosamente l'ambito dell'accesso al database e la durata delle transazioni.
-
Puoi definire un'API idempotente, in cui l'esecuzione della stessa richiesta più volte ha solo un effetto. (Consiglio vivamente di farlo a causa del prossimo punto).
-
Tutto è apolide e può avere brevi timeout. Se qualcosa non funziona, riprova.
-
Ogni connessione al database passa attraverso un pool, quindi non hai sessioni inattive in giro. Ogni back-end di database sta lavorando duramente per la massima velocità effettiva.
-
Puoi fare la coda piuttosto che provare a fare tonnellate contemporaneamente e distruggere il server. (Puoi farlo anche con PgBouncer in modalità pool di transazioni).
... e fai la tua modifica per cambiare il significato della domanda:
Prestazioni
La tua interpretazione di "Anche" è davvero una domanda completamente diversa (e dovrebbe preferibilmente essere pubblicata come tale). La versione molto breve:totalmente impossibile da prevedere senza molte più informazioni sul carico di lavoro, come il numero di richieste db per richiesta dell'app client, il tipo di dati, il tipo di query, la dimensione dei dati, la frequenza delle query, la praticità della memorizzazione nella cache, .. .... infinitamente. Chiunque affermi di rispondere definitivamente a questa domanda o è il primo vero sensitivo della storia o ne è completamente pieno.
Devi capire all'incirca quali saranno le dimensioni dei tuoi dati, i modelli di query, ecc. Scopri quanto puoi permetterti di memorizzare nella cache in una cache di livello intermedio come redis/memcached, quanto stantio puoi lasciarlo ottenere, quale livello di invalidamento della cache di cui hai bisogno. Determina se il tuo set di dati "caldo" (a cui accedi molto) si adatterà o meno alla RAM. Determina se gli indici per le tabelle sottoposte a query frequenti si adatteranno o meno alla RAM. Scopri qual è il tuo bilancio di lettura/scrittura approssimativo e quanto è probabile che le tue scritture siano di solo inserimento (aggiungi) o più regolari OLTP (inserisci/aggiorna/elimina). Crea il fittizio di un set di dati e di alcuni carichi di lavoro del client. Allora puoi iniziare a rispondere a questa domanda - forse. Per farlo bene devi anche simulare client bloccati/scomparsi, ecc.
Scopri perché non è solo un "Anche?".
