La radice non è sufficientemente specifica per dare un fermo suggerimento, ma l'elenco completo di ciò che si potrebbe fare è il seguente:
- Gruppo di database :adatto per situazioni in cui non si desidera modificare il livello dell'applicazione e il database è tutto ciò che si tocca. C'è un limite a quanto puoi ottenere da un cluster di database. Se il volume delle tue richieste continua a crescere, anche questa soluzione alla fine fallirà. Ma la buona notizia è che hai tutte le funzionalità che avevi già in un normale MySQL a istanza singola.
- Sharding :Poiché la tua domanda è contrassegnata da MySQL e non supporta lo sharding da solo, se desideri utilizzare questa soluzione devi implementarla nel livello dell'applicazione. In questa soluzione disperderai i tuoi dati su più database (preferibilmente in più istanze MySQL su hardware separato) logicamente. Sarà tua responsabilità trovare il database appropriato che contenga i tuoi dati designati. È una delle soluzioni più efficaci in assoluto, ma non è sempre fattibile. Il suo più grande difetto è che i dati sparsi tra due o più database non possono essere inclusi in una transazione.
- Replica :a seconda dello scenario, potresti essere in grado di incorporare la replica del database e disporre di copie dei tuoi dati su di essi. In questo modo puoi connetterti a loro invece del database principale e ridurre il carico su di esso. La definizione di replica predefinita è uno scenario master/slave in cui il flusso di dati è unidirezionale, dal master allo slave. Quindi le modifiche che potresti apportare allo schiavo mentre verranno applicate al balsamo, non influiranno sul master. Ma esiste anche una configurazione di replica master/master in cui il flusso di dati avviene in entrambi i modi. Tuttavia non è possibile presumere l'integrità atomica per modifiche simultanee di dati tra entrambi i master. Alla fine questa soluzione è più efficace se si prevede di utilizzarla in modalità master/slave e utilizzare gli slave per l'accesso in sola lettura.
- Memorizzazione nella cache :Forse questa soluzione non dovrebbe essere inclusa qui, ma poiché la tua radice non la rifiuta, eccola qui. Uno dei modi per ridurre il carico del database è memorizzare nella cache i suoi dati una volta estratti. Questa soluzione può essere vantaggiosa soprattutto se l'estrazione dei dati è costosa. Ci sono molti server cache là fuori, come memcached o redis . In questo modo puoi omettere tante connessioni al database ma solo per l'estrazione dei dati.
- Altri motori di archiviazione :puoi sempre passare a motori più performanti se quello attuale non ti fornisce ciò di cui hai bisogno. Ovviamente questo è fattibile solo se le tue esigenze te lo consentono. Al giorno d'oggi ci sono motori NoSQL, molto più performanti di RDBMS, che supportano lo sharding in modo nativo e puoi scalarli linearmente con il minimo sforzo. Esistono anche soluzioni basate su Lucene con potenti funzionalità di ricerca full-text che forniscono lo stesso partizionamento orizzontale automatico. In effetti, l'unico motivo per cui dovresti utilizzare un RDBMS tradizionale è il comportamento atomico delle transazioni. Ma se le transazioni non sono un must, ci sono soluzioni molto migliori di RDBMS.
