Mnesia: ventajas y diferencias

¿Cuáles son las ventajas de Mnesia sobre las principales implementaciones de bases de datos SQL y en qué se diferencian de ellas?

¿Puedo usar la base de datos para almacenar grandes cantidades de datos sin una degradación notable del rendimiento?

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 ...

De la documentación :

Mnesia es un sistema de gestión de bases de datos distribuido, apropiado para aplicaciones de telecomunicaciones y otras aplicaciones de Erlang que requieren un funcionamiento continuo y propiedades suaves en tiempo real. Es una sección de la Open Telecom Platform (OTP), que es una plataforma de sistema de control para crear aplicaciones de telecomunicaciones.

En particular, el muy alto nivel de tolerancia a fallas que se requiere en muchos sistemas continuos, combinado con los requisitos del DBMS para ejecutarse en el mismo espacio de direcciones que la aplicación, nos ha llevado a implementar un nuevo DBMS. llamado Mnesia Mnesia está implementado en el lenguaje de programación Erlang, y está estrechamente conectado con él, y proporciona la funcionalidad necesaria para la implementación de sistemas de telecomunicaciones tolerantes a fallas. Mnesia es un DBMS distribuido multiusuario especialmente diseñado para aplicaciones de telecomunicaciones industriales escrito en el lenguaje de programación simbólico Erlang, que también es el lenguaje de destino previsto. Mnesia intenta abordar todos los problemas de gestión de datos necesarios para los sistemas de telecomunicaciones típicos y tiene una serie de características que normalmente no se encuentran en las bases de datos tradicionales.

En las aplicaciones de telecomunicaciones hay diferentes necesidades de las características proporcionadas por los DBMS tradicionales. Las aplicaciones ahora implementadas en el lenguaje Erlang necesitan una combinación de una amplia gama de características, que generalmente no satisfacen los DBMS tradicionales. Mnesia está diseñado con requisitos como los siguientes en mente:

Búsqueda rápida de clave / valor en tiempo real

Consultas complicadas en tiempo no real principalmente para operación y mantenimiento

Datos distribuidos debido a aplicaciones distribuidas

Alta tolerancia a fallas

Reconfiguración dinámica

Objetos complejos

Lo que diferencia a Mnesia de la mayoría de los otros DBMS es que está diseñado teniendo en cuenta los problemas típicos de gestión de datos de las aplicaciones de telecomunicaciones. Por lo tanto, Mnesia combina muchos conceptos encontrados en bases de datos tradicionales, como transacciones y consultas con conceptos encontrados en sistemas de gestión de datos para aplicaciones de telecomunicaciones, tales como operaciones en tiempo real muy rápidas, grado configurable de tolerancia a fallas (por medio de replicación) y la capacidad de reconfigurar el sistema sin detenerlo o suspenderlo. Mnesia también es interesante debido a su estrecha relación con el lenguaje de programación Erlang, que casi convierte a Erlang en un lenguaje de programación de bases de datos. Esto tiene muchos beneficios, el más importante es que la falta de coincidencia de impedancia entre el formato de datos utilizado por el DBMS y el formato de datos utilizado por el lenguaje de programación,

Mnesia versus MySQL, rendimiento :

ejabberd consume menos recursos computacionales cuando usa alguna * base de datos SQL que cuando usa Mnesia interna. Probablemente le interese ese tema cuando tenga muchos usuarios concurrentes (más de 1000, por ejemplo). Con pocos usuarios concurrentes, el consumo de CPU de ejabberd es insignificante, por lo que a los administradores de servidores pequeños no les importa configurar un servidor SQL externo y una base de datos.

CouchDB v. Mnesia, V. MySQL y otros temas de Mnesia :

Una idea que me vino a la mente de inmediato es que, aunque para mí era obvio cómo estructurar los datos para MySQL, lo es menos para Mnesia, y para CouchDB todavía no estoy completamente seguro del mejor enfoque. Por ahora, aquí hay algunos de los puntos más obvios:

Un 'registro' tiene un campo 'numplays' que obviamente indica cuántas veces se ha reproducido. Esto está bien en MySQL, pero si solo incorporo este campo en un documento para CouchDB, obtendré una revisión duplicada completa del documento en la base de datos cada vez que cambie este número, lo que parece terriblemente ineficiente.

El diseño de tres tablas en MySQL de registros, etiquetas y una tabla de enlaces entre ellos (vea el script si eso no está claro) es (al menos para mí) obviamente la solución correcta, pero hay muchas formas posibles de hacerlo. tanto en Mnesia como en CouchDB y encuentro que intuitivamente no tengo las respuestas.

En resumen, está diseñado para un propósito muy específico y parece estar bien diseñado para adaptarse al propósito. Ninguna base de datos puede compararse de manera abstracta con otra. Solo mediante el uso de requisitos se pueden inducir elementos de conmensurabilidad.

No, no diría que Mnesia es buena para una gran cantidad de datos. Puedes elegir usar Ets o Dets como backend. Si elige Ets, su base de datos solo estará en la memoria y será muy rápida, pero los datos no son persistentes. Y si desea que sus datos sean persistentes (guardados en el disco), debe usar Dets, que tiene un límite de 2 GB , por lo que su base de datos no puede contener más de 2 GB de datos.

Puede usar un backend personalizado, por ejemplo, innostore que se usa en la base de datos Riak NoSQL.

Las ventajas de Mnesia es que es una base de datos distribuida, por lo que es muy fácil hacer sistemas tolerantes a fallas si tiene más de una computadora. Y es muy fácil de usar en Erlang ya que es una base de datos en lenguaje y actúa "como una función". Y también es súper rápido si solo necesita una base de datos en memoria, por ejemplo, como un caché.