Pattern per l'accesso alla connessione MySQL

1

Abbiamo un'applicazione che è C ++ che tenta di accedere al database MySQL.

Ci sono diversi (circa 5) thread nell'applicazione (con la libreria Boost per il threading) e in ogni thread ci sono alcuni oggetti, ognuno dei quali sta tentando di accedere al Database per il proprio scopo. Ha un modello di ORM semplice ma in realtà non è un fattore importante.

Ci sono tre possibili modelli di accesso a cui posso pensare:

  1. Potrebbe esserci un singolo connection object per applicazione o thread ed è condiviso tra tutto (o gruppo). L'oggetto deve essere thread-safe e ci saranno contese, ma MySQL non verrà licenziato con troppe connessioni.

  2. Ogni oggetto può avviare la connessione da solo. Il database deve occuparsi della concorrenza (che credo possa essere MySQL) e il design potrebbe essere molto più semplice. Ci potrebbero essere due possibilità qui. un. entrambi gli oggetti mantengono una connessione persistente per la propria vita OR b. connessione di inizio oggetto come e quando necessario.

  3. Per semplificare la contesa come nel caso di 1 e non creare troppi socket come nel caso di 2, possiamo avere connessioni basate su gruppo / set. Quindi potrebbe esserci più di una connessione (ad esempio N), ciascuna di queste connessioni potrebbe essere una connessione condivisa tra gli oggetti M.

Naturalmente, ciascuno dei modelli ha costi di risorse differenti e funzionerebbe in base a diversi vincoli e obiettivi.

Quali criteri dovrei usare per scegliere il modello di questo per la mia applicazione?

Quali sono alcuni dei vantaggi e degli svantaggi di ciascuno di questi pattern rispetto all'altro?

C'è qualche altro modello che è meglio?

PS: ho seguito queste domande:
mysql, una connessione vs multipla e
MySQL con thread e processi mutiple
Ma non rispondono esattamente a quello che sto cercando di chiedere.

    
posta Dipan Mehta 12.06.2012 - 15:57
fonte

3 risposte

2
  1. There could be single connection object per application or thread and is shared between all (or group). The object needs to be thread safe and there will be contentions but MySQL will not be fired with too many connections.

Questo essenzialmente fa ciò che il server sta già facendo, dal lato client. A meno che il lato client non sia in grado di generare un numero pazzesco di connessioni e non si abbia il controllo su di esso, è meglio creare connessioni e lasciare che il server gestisca la sincronizzazione.

La tua seconda opzione non comporta necessariamente molte connessioni. Dai un'occhiata a Scoping dinamico . È facile implementare l'ambito dinamico in C ++ in modo da avere una connessione base per thread.

La terza opzione è più o meno opposta all'opzione 1 - se ti limiti ad una connessione per approccio di thread, perché non limitarti semplicemente al numero di thread?

    
risposta data 12.06.2012 - 23:31
fonte
1

Prima di tutto devo dire che le connessioni per-thread (se non sono connessioni di persistenza) è un modo assolutamente infruttuoso per far funzionare il sistema più velocemente, a meno che non sia un re delle applicazioni CGI. L'inizializzazione della connessione potrebbe costare troppo a causa del carico elevato. Quindi se la tua domanda è

What criteria should i use to choose the pattern of this for my own application?

la mia risposta è: dovremmo sempre cercare di semplificare le nostre soluzioni, quindi se il tuo codice è semplice e non supponiamo di essere un'applicazione ad alto carico, puoi utilizzare semplici operazioni di inizializzazione della connessione sul posto; ma nel caso delle applicazioni con carico elevato sono preferite le connessioni persistence .

Are there any other pattern which is better?

Ecco la mia ricevuta per "come risolvere la domanda". Per una delle mie applicazioni web ho usato un re della tua 3a variante mista a 2 nella modalità in cui le connessioni vivevano nel sistema. Quindi la strategia era semplice: sullo stadio di inizializzazione dell'applicazione si crea un oggetto, diciamo un pool di connettori di database (DCP) condiviso tramite thread e che può servire fino a connessioni persistenti pre-create. Potrebbe generare tutti i connettori necessari in base al comportamento in tempo dell'applicazione. I connettori non utilizzati potrebbero essere uccisi in fase di esecuzione, se necessario.

Quindi abbiamo una coda di connettori auto-controllante che è piuttosto veloce per qualsiasi applicazione ad alto carico.

Ecco un semplice esempio di come il pattern descritto sopra sia realizzato in Python link

    
risposta data 13.06.2012 - 16:24
fonte
0

Non proverei mai a condividere connessioni di database tra thread. Suddividilo e avrai solo 1 connessione per thread.

    
risposta data 12.06.2012 - 16:04
fonte

Leggi altre domande sui tag