Perdón por llegar tarde a la fiesta. :) Aquí está mi respuesta, basada en haber usado Mnesia desde 1996 y varias otras tecnologías de bases de datos desde 1988.
Mnesia y MySQL son bestias diferentes, y cuál es el mejor depende en gran medida de cómo pretendes usarlo.
Si su aplicación está escrita en Erlang, Mnesia le permite almacenar los datos en el mismo espacio de memoria que su aplicación, lo que significa que puede obtener un solo objeto de datos tan rápido como unos pocos microsegundos. Esto no es posible en MySQL, ya que su aplicación y la base de datos estarán separadas en la memoria. La razón por la cual Mnesia puede hacer esto y seguir siendo robusta es que Erlang implementa 'protección' de memoria a nivel de lenguaje.
En general, las bases de datos SQL tienden a favorecer el rendimiento sobre la latencia, y cuando se trata de latencia, Mnesia + Erlang son generalmente sobresalientes. Debe decidir cuál es más importante para usted. Como dice en los documentos (arriba), las aplicaciones de destino de Mnesia eran aplicaciones de conmutación de telecomunicaciones, donde los requisitos de tiempo de respuesta para, por ejemplo, una configuración de llamada eran de alrededor de 20 ms. Básicamente, esto significaba que podía leer de la base de datos solo si los datos estaban en la memoria compartida, pero evitaría escribir en el almacenamiento persistente por configuración de llamada. OTOH, estas aplicaciones prácticamente no necesitan soporte de consultas ad-hoc y no utilizan conjuntos de datos muy grandes. Se han realizado algunos trabajos para ampliar la idoneidad de Mnesia para otros dominios, pero no es una prioridad para el equipo de desarrollo de Erlang / OTP. Mnesia es lo que es, y es probable que siga así.
En el enlace anterior, donde se compara Mnesia y MySQL en cuanto a velocidad, uno debe recordar que está en eJabberd, que se ejecuta en un solo servidor si es MySQL y ejecuta una base de datos totalmente replicada si es Mnesia, y los grandes grupos de eJabberd pueden tener tanto como 10 o más nodos erlang (y por lo tanto, 10 o más réplicas de Mnesia). Desde el punto de vista de la redundancia, esto es bastante ridículo y costoso, y Mnesia de ninguna manera te obliga a hacerlo. Obviamente, ofrece lecturas rápidas en cada nodo, pero las escrituras serán muy caras. Varias comparaciones que he leído han terminado comparando Mnesia distribuida con un MySQL de un solo nodo; Si no se necesita redundancia para MySQL, tampoco debería ser necesario para Mnesia. Mnesia es bastante flexible al permitirle elegir patrones de replicación, y la ubicación de los datos es transparente para la aplicación.
Mnesia tampoco está limitada a 2 GB por tabla (aunque sí una opción de almacenamiento en particular ). La mayor base de datos de Mnesia que conozco tiene aproximadamente 600 GB de datos en el disco RAM + (64 bits), aunque no lo recomiendo. Sin embargo, cualquier cosa de hasta 10-20 GB debería estar perfectamente bien con el hardware moderno, pero omita disc_only_copies por completo y use disc_copies; compre más RAM si es necesario. Lo pensaría dos veces antes de usar el soporte de fragmentación (mnesia_frag): funciona, pero rara vez vale la pena.
Quizás la mayor diferencia entre Mnesia y MySQL es el propio SQL: Mnesia realmente no tiene una funcionalidad comparable; QLC ofrece cierto soporte para consultas ad-hoc, pero no está en la misma liga que SQL, y tampoco lo está el nivel de optimización de consultas. En herramientas y aprovisionamiento, MySQL también es superior, y si necesita análisis, no hay duda de cuál debe elegir (es decir, NO Mnesia).
La mejor manera de ver Mnesia es como una extensión del lenguaje Erlang. Pone los datos a su alcance y es excelente para pequeños conjuntos de datos donde la estructura de datos y los patrones de acceso son bien conocidos. Para este propósito, usar MySQL es tan incómodo como usar Mnesia para las cosas donde MySQL funciona mejor.
La mayoría de las aplicaciones se encuentran en algún punto intermedio, y aquí es donde se convierte en una decisión judicial. Puede terminar usando ambos ...