MySQL Sharding vs MySQL Cluster

Considerando solo le prestazioni , un cluster MySQL può battere una soluzione MySQL personalizzata di condivisione dei dati? sharding = partizionamento orizzontale

Quando mi riferisco al sharding, sto considerando lo sharding creato nel livello dell'applicazione, ad esempio, distribuendo i record in modo uniforme tra istanze MySQL indipendenti. Per due server, potrebbe essere (chiave mod 2).

mysql ndbcluster

— GSB
fonte

Divulgazione: sono un dipendente MySQL, sto lavorando su MySQL Cluster.

Direi che MySQL Cluster potrebbe raggiungere un throughput / host più elevato rispetto a MySQL + InnoDB, a condizione che:

Le domande sono semplici
Tutti i dati si adattano in memoria

In termini di latenza, MySQL Cluster dovrebbe avere una latenza più stabile rispetto a MySQL frammentato. La latenza effettiva per i dati puramente in memoria potrebbe essere simile.

Man mano che le query diventano più complesse e i dati vengono archiviati su disco, il confronto delle prestazioni diventa più confuso. Per ottenere una risposta più specifica, è necessario descrivere di più sull'applicazione e sulle query eseguite, nonché il numero di host e il volume di dati. MySQL Cluster ha recentemente ottenuto l'esecuzione di query localizzate parallele (AQL), il che significa che può essere competitivo con MySQLD autonomo nonostante abbia dati distribuiti su più host.

MySQL Cluster è attualmente limitato a "sharding" su 48 host. MySQL frammentato in teoria non ha limiti. Tuttavia, per un determinato throughput di destinazione, potrebbe essere necessario un numero inferiore di host MySQL Cluster rispetto agli host MySQL frammentati.

Differenze più interessanti sono quando si guardano aree diverse dalle prestazioni:

MySQL Cluster supporta query arbitrarie su tutti i frammenti
MySQL Cluster supporta transazioni arbitrarie su tutti i frammenti
MySQL Cluster supporta la replica sincrona di frammenti con failover e ripristino automatici
MySQL Cluster supporta il nodo di aggiunta online (espansione del cluster)
Sharded MySQL è più "fai da te"

Avere lo sharding integrato nella tua applicazione ti offre il massimo potenziale di ridimensionamento, ma aggiunge complessità e limita la tua flessibilità in termini di query e operazioni cross-shard. Se il tuo sharding è prematuro, potrebbe essere la radice di alcuni problemi per te. MySQL Cluster ti consente di ottenere alcuni dei vantaggi del sharding senza dover vincolare la tua applicazione al solo frammento singolo.

Per quanto riguarda la risposta precedente, alcuni chiarimenti:

"Sebbene MySQL Cluster sia un reclamo ACID, non fornisce un motore di archiviazione adatto per i dati con chiavi composte."

MySQL Cluster supporta chiavi primarie e secondarie composte. Non sono sicuro di cosa non sia "adatto" al riguardo. Forse il poster precedente può spiegare?

"Per poter archiviare dati con le stesse caratteristiche chiave in un particolare set di nodi di dati, è possibile effettuare le seguenti operazioni:

Porta offline tutti i nodi di dati, lasciando solo quei nodi di dati che desideri ospitare i dati con le stesse caratteristiche chiave.

Carica i tuoi dati nel MySQL Cluster, che popola solo i tuoi nodi di dati selezionati

Riporta online tutti i nodi di dati "

Questo non è corretto La distribuzione dei dati è indipendente da quali nodi sono in linea in qualsiasi momento. MySQL Cluster supporta vari schemi di distribuzione dei dati per supportare le ottimizzazioni che descrivi. Descrivo la distribuzione dei dati in MySQL Cluster in un post di blog qui: Distribuzione dei dati in MySQL Cluster

— Frazer Clement
fonte

Ehi, Frazier. Ho letto il link che hai fornito. Solo per chiarire, il mio commento "chiave composta" si basava su indici non univoci. La società del mio datore di lavoro ha provato MySQL Cluster intorno al 2007 Q1 e non gli è piaciuto a causa delle scarse prestazioni. IMHO erano le scelte sbagliate del cliente per le chiavi (cardinalità piccole) e le sue domande. MySQL Cluster deve essere maturato di più da allora in base al tuo link. Per quanto riguarda la mia seconda affermazione, questo è il numero di utenti MongoDB che popolano frammenti specifici. Alcuni clienti del mio datore di lavoro lo hanno fatto con le loro configurazioni personalizzate di MySQL.

— RolandoMySQLDBA

Nel tuo link, ha menzionato "una scansione dell'indice ordinata" che non è stato possibile eliminare, poiché non è garantito che le righe corrispondenti siano memorizzate in un frammento di tabella. Questo è il motivo per cui stavo suggerendo di isolare i dati in frammenti specifici (nodi di dati) per ridurre al minimo i luoghi in cui i dati si sarebbero diffusi. Poiché la tua risposta mette in risalto il lato positivo di MySQL Cluster, si adatta meglio alla domanda originale pubblicata. La mia risposta è errata a favore di cautela, pessimismo ed essere un po 'ingenuo del potere di MySQL Cluster oggi.

— RolandoMySQLDBA

Al posto del mio sfinimento e delirio, +1 per la tua risposta !!!

— RolandoMySQLDBA

Ciao Rolando, grazie per aver chiarito le tue dichiarazioni. È vero che le scansioni dell'indice ordinate non potate sono "costose" in Cluster, poiché sono coinvolti tutti i nodi di dati. Sembra che queste scansioni su indici di cardinalità bassa siano costose su qualsiasi sistema, ma su Cluster sono diventate visibilmente costose. La tua attenzione e il tuo pessimismo ti hanno sicuramente salvato più di una volta :) Grazie per il +1

— Frazer Clement