MySQL Cluster(NDB) vs MySQL Replication(InnoDB) per le app Rails 3: pro/contro?



ruby-on-rails (1)

Stiamo facendo una panoramica dei nostri attuali sistemi, cercando di capire se possiamo migliorare le prestazioni e l'affidabilità.

Attualmente gestiamo una serie di app Rails interne e il nostro sito Web basato su Rails. Alcuni sono già Rails 3, alcuni vengono convertiti in Rails 3. Tutti si collegano al seguente Setup di MySQL.

mysql01 ( master server) => mysql02 (slave) => (backup giornalieri del DB su un'unità, di cui viene eseguito il backup su base giornaliera, settimanale, mensile e semestrale).

Tutte le scritture avvengono su mysql01 e anche le letture più brevi vengono eseguite, alcune "letture che consumano più risorse" (come i rapporti mensili / settimanali che richiedono 3-10 minuti per l'esecuzione e il riversamento dei dati in csv o backup) sul server mysql02. Riceviamo circa 3-5.000 visite al giorno sul nostro sito e abbiamo circa 20-30 utenti interni, che utilizzano quotidianamente varie app per l'inventario, l'elaborazione degli ordini, ecc. Quindi questi server non sono particolarmente soggetti a carichi pesanti diversi da quelli correre dello schiavo comunque.

Tutti i server vengono eseguiti in un pool virtualized XEN su VM Debian Lenny.

Quindi stiamo facendo una revisione dei sistemi, e qualcuno ha suggerito di passare all'installazione di MySQL Cluster (NDB) . Lo so in teoria, ma non l'ho mai eseguito. Quindi, chiunque abbia esperienza con esso, conosce qualsiasi pro / contro rispetto alla nostra attuale configurazione, e di eventuali avvertimenti particolari quando coinvolge applicazioni Ruby / Rails?


C'è un buon confronto tra InnoDB e MySQL Cluster (ndb) recentemente pubblicato sui documenti ... vale la pena dare un'occhiata: http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-compared.html

L'architettura del cluster è costituita da un pool di server MySQL ai quali si accede tramite le applicazioni; questi server MySQL in realtà non memorizzano i dati del cluster, i dati sono partizionati sul pool di nodi di dati sottostanti. Ogni server MySQL ha accesso ai dati in tutti i nodi dati. Se un server MySQL cambia una parte di dati, è immediatamente visibile a tutti gli altri server MySQL.

Ovviamente, questa architettura rende estremamente facile scalare il database. A differenza della condivisione, l'applicazione non ha bisogno di sapere dove sono conservati i dati - può solo bilanciare il carico su tutti i server MySQL disponibili. Diversamente dal ridimensionamento con la replica MySQL Cluster consente di ridimensionare le scritture tanto quanto le letture. Nuovi nodi dati o server MySQL possono essere aggiunti a un Cluster esistente senza alcuna perdita di servizio per l'applicazione.

L'architettura a zero condiviso di MySQL Cluster consente di offrire una disponibilità estremamente elevata (99,999% +). Ogni volta che si cambiano i dati, viene replicato in modo sincrono su un secondo nodo di dati; se un nodo dati non funziona, le richieste di lettura e scrittura delle applicazioni vengono gestite automaticamente dal nodo dati di backup.

A causa della natura distribuita di MySQL Cluster, alcune operazioni possono essere più lente (ad esempio JOIN che hanno migliaia di risultati intermedi - sebbene sia disponibile una soluzione prototipo che la indirizzi) ma altre possono essere molto veloci e possono scalare estremamente bene (ad es. chiave legge e scrive). Hai la possibilità di memorizzare tabelle (o anche colonne) in memoria o su disco e scegliendo l'opzione di memoria (con le modifiche checkpoint su disco nel backgoround) le transazioni possono essere molto veloci.

MySQL Cluster può essere più complesso da configurare rispetto a un singolo server MySQL ma può impedire l'implementazione di sharding o di divisione lettura / scrittura nell'applicazione. Altalene e rotatorie.

Per ottenere le migliori prestazioni e scalabilità da MySQL Cluster, potrebbe essere necessario modificare l'applicazione (vedere White paper sull'ottimizzazione delle prestazioni del cluster: http://www.mysql.com/why-mysql/white-papers/mysql_wp_cluster_perfomance.php ). Se si possiede l'applicazione, questo non è normalmente un grosso problema, ma se si sta utilizzando l'applicazione di qualcun altro che non è possibile modificare, potrebbe essere un problema.

Una nota finale è che non ha bisogno di essere tutto o niente - puoi scegliere di salvare alcune delle tue tabelle in Cluster e altre utilizzando altri motori di archiviazione, questa è un'opzione per tabella. Inoltre è possibile replicare tra Cluster e altri motori di archiviazione (ad esempio, utilizzare Cluster per il database di runtime e quindi replicare su InnoDB per generare report complessi).





ruby-on-rails