Ci scusiamo per il ritardo alla festa. :) Ecco la mia risposta, basata sull'utilizzo di Mnesia dal 1996 e varie altre tecnologie di database dal 1988.
Mnesia e MySQL sono davvero bestie diverse, e quale è la migliore dipende molto da come intendi usarlo.
Se l'applicazione è scritta in Erlang, Mnesia ti consente di memorizzare i dati nello stesso spazio di memoria dell'applicazione, il che significa che puoi recuperare un singolo oggetto dati in pochi microsecondi. Questo non è possibile in MySQL, poiché l'applicazione e il database saranno separati in memoria. Il motivo per cui la Mnesia può fare questo ed essere ancora robusto, è che Erlang implementa la "protezione" della memoria a livello linguistico.
Nel complesso, i database SQL tendono a favorire la velocità effettiva rispetto alla latenza e, quando si parla di latenza, Mnesia + Erlang sono generalmente eccezionali. Devi decidere quale è più importante per te. Come indicato nei documenti (sopra), le applicazioni target di Mnesia erano applicazioni di commutazione di telecomunicazione, in cui i requisiti di tempo di risposta, ad esempio un'impostazione della chiamata, erano di circa 20 ms. Ciò significa essenzialmente che è possibile leggere dal database solo se i dati erano nella memoria condivisa, ma evitare di scrivere nella memoria permanente in base all'impostazione per chiamata. OTOH, queste applicazioni non hanno praticamente bisogno del supporto di query ad hoc e non usano set di dati molto grandi. Alcuni lavori sono stati fatti per estendere l'idoneità di Mnesia per altri domini, ma non è una priorità per il team di sviluppo Erlang / OTP. La mnesia è quella che è ed è probabile che rimanga tale.
Nel link sopra dove Mnesia e MySQL vengono confrontati per velocità, bisogna ricordare che è in eJabberd, che funziona su un singolo server se è MySQL e esegue un database completamente replicato se è Mnesia - e i grandi cluster di eJabberd possono avere fino a 10 o più nodi erlang (e quindi, 10 o più repliche di Mnesia). Dal punto di vista della ridondanza, questo è abbastanza ridicolo e costoso, e la Mnesia non ti obbliga affatto a farlo. Ovviamente fornisce letture velocissime su ciascun nodo, ma le scritture saranno molto costose. Diversi confronti che ho letto hanno finito per confrontare Mnesia distribuita con un MySQL a nodo singolo; se la ridondanza non è necessaria per MySQL, non dovrebbe essere richiesta nemmeno per Mnesia. Mnesia è abbastanza flessibile nel consentire di scegliere i modelli di replica e la posizione dei dati è trasparente per l'applicazione.
Inoltre, Mnesia non si limita a 2 GB per tabella (sebbene sia una particolare opzione di archiviazione ). Il più grande database Mnesia che conosco ha circa 600 GB di dati nel disco RAM + (64-bit), anche se non lo consiglio. Qualsiasi cosa fino a 10-20 GB dovrebbe andare perfettamente bene con l'hardware moderno, ma salta del tutto disc_only_copies e usa disc_copies - acquista più RAM se devi. Ci penserei due volte prima di usare il supporto di sharding (mnesia_frag) - funziona, ma raramente vale la pena.
Forse la più grande differenza tra Mnesia e MySQL è lo stesso SQL: Mnesia non ha davvero funzionalità comparabili; QLC offre un certo supporto per le query ad hoc, ma non è nella stessa lega di SQL e nemmeno il livello di ottimizzazione delle query. In tooling e provisioning, MySQL è anche superiore e, se hai bisogno di analisi, non c'è dubbio su quale dovresti scegliere (cioè NON Mnesia).
Il modo migliore per vedere la Mnesia è come un'estensione della lingua Erlang. Mette i dati a portata di mano ed è eccellente per piccoli set di dati in cui la struttura dei dati e i modelli di accesso sono ben noti. A tal fine, l'utilizzo di MySQL è scomodo quanto l'utilizzo di Mnesia per le cose in cui MySQL funziona meglio.
La maggior parte delle applicazioni cadono da qualche parte nel mezzo, ed è qui che diventa una chiamata di giudizio. Potresti finire per usare entrambi ...