2 milioni di database? Presumo tu intendessi "righe".
Comunque, per quanto riguarda le limitazioni:una delle cose più importanti da tenere a mente è che NDB/MySQL Cluster non è un database generico. In particolare, le operazioni di unione, ma anche le sottoquery e le operazioni di intervallo (query come:ordini creati da qui a una settimana fa), possono essere notevolmente più lente di quanto ci si potrebbe aspettare. Ciò è in parte dovuto al fatto che i dati sono distribuiti su più nodi. Sebbene siano stati apportati alcuni miglioramenti, le prestazioni di Join possono comunque essere molto deludenti.
D'altra parte, se hai bisogno di gestire molte (preferibilmente piccole) transazioni simultanee (in genere aggiornamenti/inserimenti/elimina ricerche di una singola riga tramite chiave primaria) e ti occupi di mantenere tutti i tuoi dati in memoria, allora può essere molto soluzione scalabile e performante.
Dovresti chiederti perché vuoi il cluster. Se desideri semplicemente il tuo database ordinario che hai ora, tranne che con una disponibilità aggiuntiva del 99.999%, potresti rimanere deluso. Certamente il cluster MySQL può fornirti grande disponibilità e tempo di attività, ma il carico di lavoro della tua app potrebbe non essere molto adatto per il cluster di cose per cui è buono. Inoltre, potresti essere in grado di utilizzare un'altra soluzione ad alta disponibilità per aumentare il tempo di attività del tuo database altrimenti tradizionale.
A proposito:ecco un elenco di limitazioni come da documento:http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-limitations.html
Ma qualunque cosa tu faccia, prova il cluster, vedi se ti fa bene. Il cluster MySQL non è "MySQL + 5 nove". Lo scoprirai quando proverai.
