Mnesia: Vorteile und Unterschiede

Was sind die Vorteile von Mnesia gegenüber großen SQL-Datenbankimplementierungen und wie unterscheidet es sich von diesen?

Kann ich die Datenbank verwenden, um wirklich große Datenmengen zu speichern, ohne dass sich die Leistung merklich verschlechtert?

Entschuldige, dass du zu spät zur Party gekommen bist. :) Hier ist meine Antwort, basierend auf der Verwendung von Mnesia seit 1996 und verschiedenen anderen Datenbanktechnologien seit 1988.

Mnesia und MySQL sind in der Tat verschiedene Biester, und welches das beste ist, hängt sehr davon ab, wie Sie es verwenden möchten.

Wenn Ihre Anwendung in Erlang geschrieben ist, können Sie mit Mnesia die Daten im selben Speicherbereich wie Ihre Anwendung speichern, sodass Sie ein einzelnes Datenobjekt innerhalb weniger Mikrosekunden abrufen können. Dies ist in MySQL nicht möglich, da Ihre Anwendung und die Datenbank im Speicher getrennt werden. Der Grund, warum Mnesia dies kann und dennoch robust ist, besteht darin, dass Erlang den Speicherschutz auf Sprachebene implementiert.

Insgesamt bevorzugen SQL-Datenbanken den Durchsatz gegenüber der Latenz, und wenn es um die Latenz geht, sind Mnesia + Erlang im Allgemeinen hervorragend. Sie müssen sich entscheiden, welches für Sie am wichtigsten ist. Wie es in den Dokumenten (oben) heißt, waren Mnesias Zielanwendungen Telekommunikationsvermittlungsanwendungen, bei denen die Anforderungen an die Antwortzeit für z. B. einen Anrufaufbau etwa 20 ms betrugen. Dies bedeutete im Wesentlichen, dass Sie nur dann aus der Datenbank lesen konnten, wenn sich die Daten im gemeinsam genutzten Speicher befanden, aber das Schreiben in einen dauerhaften Speicher auf der Basis von Aufrufen vermeiden konnten. OTOH, diese Anwendungen benötigen praktisch keine Unterstützung für Ad-hoc-Abfragen und verwenden keine sehr großen Datenmengen. Es wurden einige Anstrengungen unternommen, um die Eignung von Mnesia für andere Domänen zu verbessern. Für das Erlang / OTP-Entwicklungsteam hat dies jedoch keine Priorität. Mnesia ist, was es ist, und wird wahrscheinlich so bleiben.

In dem obigen Link, in dem Mnesia und MySQL aus Geschwindigkeitsgründen verglichen werden, muss beachtet werden, dass es sich um eJabberd handelt, das auf einem einzelnen Server ausgeführt wird, wenn es sich um MySQL handelt, und eine vollständig replizierte Datenbank ausführt, wenn es sich um Mnesia handelt 10 oder mehr Langknoten (und damit 10 oder mehr Mnesia-Replikate). Vom Standpunkt der Redundanz aus ist dies ziemlich lächerlich und kostspielig, und Mnesia zwingt Sie keineswegs dazu. Es gibt offensichtlich unglaublich schnelle Lesevorgänge auf jedem Knoten, aber Schreibvorgänge sind sehr teuer. Mehrere Vergleiche, die ich gelesen habe, haben ergeben, dass verteilte Mnesia mit einem einzelnen MySQL-Knoten verglichen wurden. Wenn für MySQL keine Redundanz erforderlich ist, sollte dies auch für Mnesia nicht erforderlich sein. Mnesia ist sehr flexibel bei der Auswahl von Replikationsmustern, und der Speicherort der Daten ist für die Anwendung transparent.

Mnesia wird auch auf 2 GB pro Tabelle nicht beschränkt (obwohl eine bestimmte Speicher Option ist). Die größte mir bekannte Mnesia-Datenbank verfügt über ca. 600 GB Daten im (64-Bit) RAM + Datenträger - obwohl ich dies nicht empfehle. Alles bis zu 10-20 GB sollte mit moderner Hardware vollkommen in Ordnung sein, aber lassen Sie disc_only_copies komplett aus und verwenden Sie disc_copies - kaufen Sie mehr RAM, wenn Sie müssen. Ich würde es mir zweimal überlegen, bevor ich die Sharding-Unterstützung (mnesia_frag) benutze - es funktioniert, aber die Mühe lohnt sich selten.

Der vielleicht größte Unterschied zwischen Mnesia und MySQL ist SQL selbst: Mnesia hat keine wirklich vergleichbare Funktionalität; QLC bietet eine gewisse Unterstützung für Ad-hoc-Abfragen, gehört jedoch nicht zur selben Liga wie SQL, und auch nicht zum Grad der Abfrageoptimierung. In Sachen Tooling und Provisioning ist MySQL ebenfalls überlegen, und wenn Sie Analysen benötigen, steht außer Frage, welches Sie wählen sollten (dh NICHT Mnesia).

Die beste Möglichkeit, Mnesia zu betrachten, ist die Erweiterung der Erlang-Sprache. Sie haben Daten immer zur Hand und eignen sich hervorragend für kleine Datenmengen, bei denen die Datenstruktur und die Zugriffsmuster bekannt sind. Zu diesem Zweck ist die Verwendung von MySQL ungefähr so ​​unkomfortabel wie die Verwendung von Mnesia für die Dinge, bei denen MySQL am besten funktioniert.

Die meisten Anwendungen liegen irgendwo dazwischen, und hier wird es zu einem Urteilsspruch. Sie können gut mit beiden enden ...

Aus der Dokumentation :

Mnesia ist ein verteiltes Datenbankverwaltungssystem, das für Telekommunikationsanwendungen und andere Erlang-Anwendungen geeignet ist, die einen kontinuierlichen Betrieb und weiche Echtzeiteigenschaften erfordern. Es ist ein Teil der Open Telecom Platform (OTP), einer Steuerungssystemplattform zum Erstellen von Telekommunikationsanwendungen.

Insbesondere das sehr hohe Maß an Fehlertoleranz, das in vielen Nonstop-Systemen erforderlich ist, in Verbindung mit den Anforderungen an das DBMS, das im selben Adressraum wie die Anwendung ausgeführt werden muss, hat uns veranlasst, ein brandneues DBMS zu implementieren. genannt Mnesia. Mnesia ist in der Programmiersprache Erlang implementiert und sehr eng damit verbunden. Es bietet die Funktionalität, die für die Implementierung fehlertoleranter Telekommunikationssysteme erforderlich ist. Mnesia ist ein verteiltes Mehrbenutzer-DBMS, das speziell für industrielle Telekommunikationsanwendungen entwickelt wurde und in der symbolischen Programmiersprache Erlang geschrieben ist, die auch die beabsichtigte Zielsprache ist. Mnesia versucht, alle Datenverwaltungsprobleme zu lösen, die für typische Telekommunikationssysteme erforderlich sind, und verfügt über eine Reihe von Funktionen, die in herkömmlichen Datenbanken normalerweise nicht vorhanden sind.

Bei Telekommunikationsanwendungen gibt es andere Anforderungen als bei herkömmlichen DBMS. Die Anwendungen, die jetzt in der Sprache Erlang implementiert sind, benötigen eine Mischung aus einer Vielzahl von Funktionen, die von herkömmlichen DBMS im Allgemeinen nicht erfüllt werden. Mnesia wurde mit folgenden Anforderungen entwickelt:

Schnelle Echtzeitsuche nach Schlüsseln und Werten

Komplizierte Nicht-Echtzeit-Abfragen hauptsächlich für Betrieb und Wartung

Verteilte Daten aufgrund verteilter Anwendungen

Hohe Fehlertoleranz

Dynamische Neukonfiguration

Komplexe Objekte

Was Mnesia von den meisten anderen DBMS unterscheidet, ist, dass es mit Blick auf die typischen Datenverwaltungsprobleme von Telekommunikationsanwendungen entwickelt wurde. Daher kombiniert Mnesia viele in traditionellen Datenbanken vorkommende Konzepte wie Transaktionen und Abfragen mit den in Datenverwaltungssystemen für Telekommunikationsanwendungen vorkommenden Konzepten wie sehr schnelle Echtzeitoperationen, konfigurierbarer Fehlertoleranzgrad (durch Replikation) und die Fähigkeit zu Konfigurieren Sie das System neu, ohne es anzuhalten oder anzuhalten. Mnesia ist auch wegen seiner engen Kopplung an die Programmiersprache Erlang interessant, wodurch Erlang fast zu einer Datenbank-Programmiersprache wird. Dies hat viele Vorteile, in erster Linie besteht die Impedanzinkongruenz zwischen dem vom DBMS verwendeten Datenformat und dem von der Programmiersprache verwendeten Datenformat.

Mnesia versus MySQL, Leistung :

ejabberd verbraucht bei Verwendung einer SQL-Datenbank weniger Rechenressourcen als bei Verwendung einer internen Mnesia. Sie interessieren sich wahrscheinlich für dieses Thema, wenn Sie viele gleichzeitige Benutzer haben (z. B. mehr als 1000). Bei wenigen gleichzeitigen Benutzern ist der CPU-Verbrauch von ejabberd vernachlässigbar, sodass Administratoren kleiner Server keinen externen SQL-Server und keine externe SQL-Datenbank einrichten müssen.

CouchDB v. Mnesia, V. MySQL und andere Mnesia-Themen :

Eine Erkenntnis, die mir sofort einfiel, war, dass es für mich offensichtlich war, wie die Daten für MySQL zu strukturieren sind, für Mnesia jedoch weniger, und für CouchDB bin ich mir noch nicht ganz sicher, wie ich am besten vorgehen soll. Im Moment sind hier ein paar offensichtliche Punkte:

Eine 'Aufzeichnung' hat ein 'Numplay'-Feld, das offensichtlich angibt, wie oft sie abgespielt wurde. Dies ist in MySQL in Ordnung, aber wenn ich dieses Feld nur in ein Dokument für CouchDB einbinde, erhalte ich jedes Mal, wenn sich diese eine Nummer ändert, eine vollständige doppelte Revision des Dokuments in der Datenbank, was schrecklich ineffizient erscheint.

Das dreiteilige Layout in MySQL von Datensätzen, Tags und einer Verknüpfungstabelle zwischen ihnen (siehe Skript, wenn das nicht klar ist) ist (zumindest für mich) offensichtlich die richtige Lösung, aber es gibt viele Möglichkeiten, dies zu tun Sowohl in Mnesia als auch in CouchDB finde ich, dass ich die Antworten nicht intuitiv habe.

Kurz gesagt, es wurde für einen ganz bestimmten Zweck entwickelt und scheint für diesen Zweck gut geeignet zu sein. Keine Datenbank kann abstrakt mit einer anderen verglichen werden. Nur durch die Verwendung von Anforderungen können Elemente der Verhältnismäßigkeit induziert werden.

Nein, ich würde nicht sagen, dass Mnesia für große Datenmengen gut ist. Sie können Ets oder Dets als Backend verwenden. Wenn Sie Ets wählen, befindet sich Ihre Datenbank nur im Arbeitsspeicher und ist sehr schnell, die Daten sind jedoch nicht persistent. Und wenn Sie möchten, dass Ihre Daten dauerhaft (auf der Festplatte gespeichert) sind, müssen Sie Dets verwenden, das eine Beschränkung von 2 GB hat , sodass Ihre Datenbank nicht mehr als 2 GB Daten enthalten kann.

Sie können ein benutzerdefiniertes Backend verwenden, z. B. innostore , das in der Riak NoSQL-Datenbank verwendet wird.

Der Vorteil von Mnesia besteht darin, dass es sich um eine verteilte Datenbank handelt, sodass es sehr einfach ist, fehlertolerante Systeme zu erstellen, wenn Sie mehr als einen Computer haben. Und es ist sehr einfach in Erlang zu verwenden, da es eine in der Sprache verfügbare Datenbank ist und "wie eine Funktion" funktioniert. Und es geht auch superschnell, wenn Sie nur eine In-Memory-Datenbank benötigen, z. B. einen Cache.