Ho letto MOLTO sulle opzioni disponibili. Ho anche messo le mani su High Performance MySQL 2a edizione, che consiglio vivamente.
Questo è ciò che sono riuscito a mettere insieme:
Raggruppamento
Il clustering in senso generale sta distribuendo il carico su molti server che appaiono a un'applicazione esterna come un unico server.
Cluster NDB MySQL
MySQL NDB Cluster è un motore di archiviazione distribuito, in-memory, shared-nothing con replica sincrona e partizionamento automatico dei dati (mi scusi, prendo in prestito letteralmente dal libro High Performance, ma l'hanno messo molto bene lì). Può essere una soluzione ad alte prestazioni per alcune applicazioni, ma le applicazioni web generalmente non funzionano bene su di essa.
Il problema principale è che al di là delle query molto semplici (che toccano solo una tabella), il cluster dovrà generalmente cercare i dati su più nodi, consentendo alla latenza di rete di insinuarsi e rallentare notevolmente i tempi di completamento delle query. Poiché l'applicazione tratta il cluster come un computer, non può dirgli da quale nodo recuperare i dati.
Inoltre, il requisito della memoria non è applicabile per molti database di grandi dimensioni.
Sequoia continua
Questa è un'altra soluzione di clustering per MySQL, che funge da middleware sopra il server MySQL. Offre replica sincrona, bilanciamento del carico e failover. Garantisce inoltre che le richieste ottengano sempre i dati dalla copia più recente, scegliendo automaticamente un nodo con i dati aggiornati.
Ho letto alcune cose buone su di esso, e nel complesso sembra piuttosto promettente.
Federazione
La federazione è simile al clustering, quindi l'ho tirato anche qui. MySQL offre la federazione tramite il motore di archiviazione federato. Simile alla soluzione cluster NDB, funziona bene solo con query semplici, ma peggio ancora con il cluster per quelle complicate (poiché la latenza di rete è molto più elevata).
Replica e bilanciamento del carico
MySQL ha la capacità integrata di creare repliche di un database su server diversi. Questo può essere utilizzato per molte cose:dividere il carico tra server, backup a caldo, creare server di prova e failover.
L'impostazione di base della replica prevede che un server master gestisca principalmente le scritture e uno o più slave che gestiscano solo le letture. Una variante più avanzata è quella del master-master configurazione, che consente di ridimensionare anche le scritture avendo più server che scrivono contemporaneamente.
Ogni configurazione ha i suoi pro e contro, ma un problema che tutti condividono è il ritardo di replica:poiché la replica di MySQL è asincrona, non tutti i nodi hanno sempre i dati più recenti. Ciò richiede che l'applicazione sia a conoscenza della replica e incorpori le query compatibili con la replica per funzionare come previsto. Per alcune applicazioni questo potrebbe non essere un problema, ma se hai sempre bisogno dei dati più recenti le cose si complicano.
La replica richiede un certo bilanciamento del carico per suddividere il carico tra i nodi. Questo può essere semplice come alcune modifiche al codice dell'applicazione o utilizzando soluzioni software e hardware dedicate.
Sharding e partizionamento
Il partizionamento orizzontale è un approccio comunemente utilizzato per ridimensionare le soluzioni di database. Dividi i dati in frammenti più piccoli e li distribuisci su diversi nodi del server. Ciò richiede che l'applicazione sia a conoscenza della modifica all'archiviazione dei dati per funzionare in modo efficiente, poiché deve sapere dove trovare le informazioni di cui ha bisogno.
Sono disponibili framework di astrazione per aiutare a gestire lo sharding dei dati, come Hibernate Shards , un'estensione di Hibernate ORM (che purtroppo è in Java. Sto usando PHP). HiveDB è un'altra soluzione di questo tipo che supporta anche il ribilanciamento degli shard.
Altri
Sfinge
Sfinge è un motore di ricerca full-text, che può essere utilizzato per molto di più delle ricerche di prova. Per molte query è molto più veloce di MySQL (soprattutto per il raggruppamento e l'ordinamento) e può interrogare sistemi remoti in parallelo e aggregare i risultati, il che lo rende molto utile nell'uso con lo sharding.
In generale, sphinx dovrebbe essere utilizzato con altre soluzioni di ridimensionamento per ottenere più hardware e infrastruttura disponibili. Lo svantaggio è che ancora una volta è necessario che il codice dell'applicazione sia a conoscenza della sfinge per usarlo con saggezza.
Riepilogo
Le soluzioni di ridimensionamento variano a seconda delle esigenze dell'applicazione che ne ha bisogno. Per noi e per la maggior parte delle applicazioni Web, credo che la replica (probabilmente multi-master) sia la strada da percorrere con un sistema di bilanciamento del carico che distribuisce il carico. Anche il partizionamento orizzontale di aree problematiche specifiche (tabelle enormi) è un must per poter ridimensionare orizzontalmente.
Darò anche una possibilità a Continuent Sequoia e vedrò se può davvero fare ciò che promette poiché comporterà il minor numero di modifiche al codice dell'applicazione.
