Mnesia: avantages et différences


22

Quels sont les avantages de Mnesia par rapport aux principales implémentations de bases de données SQL et en quoi elles diffèrent?

Puis-je utiliser la base de données pour stocker de très grandes quantités de données sans dégradation notable des performances?


4
Je pense que cette question nécessite un peu plus de concentration. Pouvez-vous énumérer les critères que vous utiliseriez pour juger des avantages ou des différences par rapport aux autres implémentations de base de données? Cela semble vraiment être un candidat pour un article / liste wikipedia, pas vraiment quelque chose qui peut être répondu ici. De plus, étant donné que Mnesia est vraiment plus proche de CouchDB, il n'est pas juste de demander comment il se compare aux implémentations SQL "majeures" sans nommer celles que vous souhaitez comparer. Comparé à SQLServer ou Oracle, il n'est même pas proche de nœud à nœud pour les performances.
jcolebrand

Réponses:


31

Désolé d'être en retard à la fête. :) Voici ma réponse, basée sur l'utilisation de Mnesia depuis 1996 et de diverses autres technologies de base de données depuis 1988.

Mnesia et MySQL sont en effet des bêtes différentes, et laquelle est la meilleure dépend beaucoup de la façon dont vous comptez l'utiliser.

Si votre application est écrite en Erlang, Mnesia vous permet de stocker les données dans le même espace mémoire que votre application, ce qui signifie que vous pouvez récupérer un seul objet de données aussi rapidement que quelques microsecondes. Ce n'est pas possible dans MySQL, car votre application et la base de données seront séparées en mémoire. La raison pour laquelle Mnesia peut faire cela et être encore robuste, c'est qu'Erlang implémente la «protection» de la mémoire au niveau de la langue.

Dans l'ensemble, les bases de données SQL ont tendance à favoriser le débit par rapport à la latence, et en matière de latence, Mnesia + Erlang sont généralement exceptionnelles. Vous devez décider lequel est le plus important pour vous. Comme il est dit dans les documents (ci-dessus), les applications cibles de Mnesia étaient des applications de commutation de télécommunications, où les exigences de temps de réponse pour, par exemple, une configuration d'appel étaient d'environ 20 ms. Cela signifiait essentiellement que vous ne pouviez lire à partir de la base de données que si les données étaient dans la mémoire partagée, mais éviteriez d'écrire sur le stockage persistant sur une base de configuration par appel. OTOH, ces applications n'ont pratiquement pas besoin de prise en charge de requêtes ad hoc et n'utilisent pas de très grands ensembles de données. Certains travaux ont été effectués pour étendre l'adéquation de Mnesia à d'autres domaines, mais ce n'est pas une priorité pour l'équipe de développement d'Erlang / OTP. La mnésie est ce qu'elle est et est susceptible de rester ainsi.

Dans le lien ci-dessus où Mnesia et MySQL sont comparés pour la vitesse, il faut se rappeler qu'il est dans eJabberd, qui s'exécute sur un seul serveur si c'est MySQL et exécute une base de données entièrement répliquée si c'est Mnesia - et les grands clusters eJabberd peuvent avoir autant que 10 nœuds erlang ou plus (et donc, 10 répliques Mnesia ou plus). Du point de vue de la redondance, c'est assez ridicule et coûteux, et Mnesia ne vous y oblige en aucun cas. Il donne évidemment des lectures rapides sur chaque nœud, mais les écritures seront très coûteuses. Plusieurs comparaisons que j'ai lues ont fini par comparer la Mnesia distribuée avec un MySQL à nœud unique; si la redondance n'est pas nécessaire pour MySQL, elle ne devrait pas l'être non plus pour Mnesia. Mnesia est assez flexible pour vous permettre de choisir des modèles de réplication et l'emplacement des données est transparent pour l'application.

Mnesia n'est pas non plus limité à 2 Go par table (bien qu'une option de stockage particulière le soit). La plus grande base de données Mnesia que je connaisse a environ 600 Go de données dans (64 bits) RAM + disque - bien que je ne le recommande pas. Tout ce qui peut aller jusqu'à 10-20 Go devrait être parfaitement adapté au matériel moderne, mais ignorez entièrement disc_only_copies et utilisez disc_copies - achetez plus de RAM si vous le devez. J'y réfléchirais à deux fois avant d'utiliser le support de partitionnement (mnesia_frag) - cela fonctionne, mais vaut rarement la peine.

La plus grande différence entre Mnesia et MySQL est peut-être SQL lui-même: Mnesia n'a pas vraiment de fonctionnalités comparables; QLC offre un certain support pour les requêtes ad-hoc, mais ce n'est pas dans la même ligue que SQL, ni le niveau d'optimisation des requêtes. Dans l'outillage et l'approvisionnement, MySQL est également supérieur, et si vous avez besoin d'analyses, il ne fait aucun doute lequel vous devez choisir (c.-à-d. PAS Mnesia).

La meilleure façon de voir Mnesia est une extension de la langue Erlang. Il met les données à portée de main et est excellent pour les petits ensembles de données où la structure des données et les modèles d'accès sont bien connus. À cette fin, l'utilisation de MySQL est à peu près aussi inconfortable que l'utilisation de Mnesia pour les choses où MySQL fonctionne le mieux.

La plupart des demandes se situent quelque part entre les deux, et c'est là que cela devient un appel au jugement. Vous pourriez bien finir par utiliser les deux ...


3
Merci d'avoir répondu. C'est la meilleure explication que j'ai lue sur la mnésie.
Akshat Jiwan Sharma

1
Merci de partager votre expérience avec nous, c'est beaucoup plus précieux que de lire un blog.
Rahul Gautam

Excellente réponse, mais je suis encore plus confus maintenant.
HIRA THAKUR

Réponse très complète. Donc, si je comprends bien Mnesia - serait parfait pour certains dans le magasin de clés / valeurs en mémoire au lieu de Memcached ou Redis ou d'une solution similaire, où vous voulez juste de la vitesse, et pas besoin d'analyse ou de stockage persistant "SQL query-able"? Pour tout le reste, je préfère utiliser quelque chose comme MariaDB / Postgres ou Mongo / Cassandra / RIAK? Pour clarifier - j'apprends Elixir, pas vraiment Erlang (venant de l'arrière-plan Ruby / Perl), et j'essaie de trouver la meilleure pile pour moi pour remplacer Rails / Sinatra par MariaDB & Redis
konung

13

De la documentation :

Mnesia est un système de gestion de base de données distribué, approprié pour les applications de télécommunications et d'autres applications Erlang qui nécessitent un fonctionnement continu et des propriétés en temps réel doux. Il s'agit d'une section de la plate-forme Open Telecom (OTP), qui est une plate-forme de système de contrôle pour la création d'applications de télécommunications.

En particulier, le très haut niveau de tolérance aux pannes qui est requis dans de nombreux systèmes sans arrêt, combiné aux exigences du SGBD pour fonctionner dans le même espace d'adressage que l'application, nous a amenés à mettre en œuvre un tout nouveau SGBD. appelé Mnesia. Mnesia est implémenté dans le langage de programmation Erlang et très étroitement lié à celui-ci et il fournit les fonctionnalités nécessaires à la mise en œuvre de systèmes de télécommunications tolérants aux pannes. Mnesia est un SGBD distribué multi-utilisateurs spécialement conçu pour les applications de télécommunications industrielles écrites dans le langage de programmation symbolique Erlang, qui est également le langage cible. Mnesia essaie de résoudre tous les problèmes de gestion des données requis pour les systèmes de télécommunications typiques et il possède un certain nombre de fonctionnalités que l'on ne trouve pas normalement dans les bases de données traditionnelles.

Dans les applications de télécommunications, les besoins diffèrent des fonctionnalités fournies par les SGBD traditionnels. Les applications maintenant implémentées dans le langage Erlang nécessitent un mélange d'un large éventail de fonctionnalités, qui ne sont généralement pas satisfaites par les SGBD traditionnels. Mnesia est conçu avec des exigences telles que les suivantes:

Recherche rapide de clé / valeur en temps réel

Requêtes non temps réel compliquées principalement pour l'exploitation et la maintenance

Données distribuées grâce aux applications distribuées

Haute tolérance aux pannes

Reconfiguration dynamique

Objets complexes

Ce qui distingue Mnesia de la plupart des autres SGBD, c'est qu'il est conçu en tenant compte des problèmes typiques de gestion des données des applications de télécommunications. Par conséquent, Mnesia combine de nombreux concepts trouvés dans les bases de données traditionnelles, telles que les transactions et les requêtes, avec des concepts trouvés dans les systèmes de gestion de données pour les applications de télécommunications, tels que les opérations en temps réel très rapides, le degré configurable de tolérance aux pannes (au moyen de la réplication) et la capacité de reconfigurez le système sans l'arrêter ni le suspendre. Mnesia est également intéressant en raison de son couplage étroit avec le langage de programmation Erlang, transformant ainsi presque Erlang en langage de programmation de base de données. Cela présente de nombreux avantages, le plus important étant que l'inadéquation d'impédance entre le format de données utilisé par le SGBD et le format de données utilisé par le langage de programmation,

Mnesia contre MySQL, performances :

ejabberd consomme moins de ressources de calcul lors de l'utilisation d'une base de données * SQL que lors de l'utilisation de Mnesia interne. Vous êtes probablement intéressé par ce sujet lorsque vous avez de nombreux utilisateurs simultanés (plus de 1000, par exemple). Avec peu d'utilisateurs simultanés, la consommation de CPU d'ejabberd est négligeable, donc les administrateurs de petits serveurs ne se soucient pas de configurer un serveur SQL externe et une base de données.

CouchDB v. Mnesia, V. MySQL et autres sujets Mnesia :

Une idée qui m'est immédiatement venue à l'esprit est que même s'il était évident pour moi de structurer les données pour MySQL, cela l'est moins pour Mnesia, et pour CouchDB, je ne suis pas encore tout à fait sûr de la meilleure approche. Pour l'instant, voici quelques points les plus évidents:

Un «record» a un champ «numplays» qui indique évidemment combien de fois il a été joué. C'est bien dans MySQL, mais si j'incorpore simplement ce champ dans un document pour CouchDB, j'obtiendrai une révision complète en double du document dans la base de données chaque fois que ce numéro changera, ce qui semble terriblement inefficace.

La disposition à trois tables dans MySQL des enregistrements, des balises et une table de liens entre eux (voir le script si ce n'est pas clair) est (pour moi au moins) évidemment la bonne solution, mais il existe de nombreuses façons possibles de le faire dans Mnesia et CouchDB et je trouve que je n'ai pas intuitivement les réponses.

En bref, il est conçu pour un usage très spécifique et semble bien conçu pour répondre à cet objectif. Aucune base de données ne peut être comparée de manière abstraite à une autre. Ce n'est qu'en utilisant des exigences que des éléments de commensurabilité peuvent être induits.


4

Non, je ne dirais pas que Mnesia est bon pour une grande quantité de données. Vous pouvez choisir d'utiliser Ets ou Dets comme backend. Si vous choisissez Ets, votre base de données sera uniquement en mémoire et très rapide mais les données ne sont pas persistantes. Et si vous voulez que vos données soient persistantes (enregistrées sur le disque), vous devez utiliser Dets, qui a une limite de 2 Go , de sorte que votre base de données ne peut pas contenir plus de 2 Go de données.

Vous pouvez utiliser un backend personnalisé, par exemple innostore, qui est utilisé dans la base de données Riak NoSQL.

Les avantages de Mnesia sont qu'il s'agit d'une base de données distribuée, il est donc très facile de faire des systèmes tolérants aux pannes si vous avez plus d'un ordinateur. Et il est très facile à utiliser dans Erlang car c'est une base de données en langue et agit "comme une fonction". Et il est également ultra-rapide si vous n'avez besoin que d'une base de données en mémoire, comme un cache par exemple.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.