Zum Inhalt springen
Vektorhirn, das im Gedächtnis symbolisiert

In-Memory-Datenbank

Was ist ein In-Memory-Datenbankverwaltungssystem?

Eine In-Memory-Datenbank (IMDB; auch Hauptspeicher-Datenbanksystem oder MMDB) wird im Hauptspeicher eines Computers gespeichert (RAM) und wird von einem In-Memory-Datenbankverwaltungssystem verwaltet. Herkömmliche Datenbanken werden auf Festplatten gespeichert.
Herkömmliche festplattenbasierte Datenbanken werden unter Berücksichtigung des blockorientierten Geräts formatiert, auf dem die Daten gelesen und geschrieben werden. Wenn ein Teil einer Datenbank auf einen anderen Teil verweist, muss möglicherweise ein anderer Block von der Festplatte gelesen werden. Dies ist bei speicherinternen Datenbanken kein Problem, und Wechselbeziehungen zwischen Teilen der Datenbank können über direkte Zeiger verwaltet werden. Die speicherinternen Daten sind immer vorhanden, sodass keine Latenz zum Lesen besteht. Das Schreiben von Daten auf die Festplatte muss "atomar" erfolgen, wobei alle Schreibvorgänge registriert werden oder keiner von ihnen. Dies erfordert häufig Journaling oder Doppelschreibvorgänge. Für eine speicherinterne Datenbank sind solche Anforderungen nicht erforderlich, sodass die Änderungen am Speicher nahezu augenblicklich erfolgen.

On-Disk-Datenbanken Vs. In-Memory-Datenbanken

On-Disk-Datenbanken

  • Alle Daten werden auf der Festplatte gespeichert. Die Festplatten-E / A werden benötigt, um Daten bei Bedarf in den Hauptspeicher zu verschieben.
  • Die Daten bleiben immer auf der Festplatte erhalten.
  • Herkömmliche Datenstrukturen wie B-Trees dienen zum effizienten Speichern von Tabellen und Indizes auf der Festplatte.
  • Unterstützt eine sehr breite Palette von Workloads, z. B. OLTP, Data Warehousing, gemischte Workloads usw.

In-Memory-Datenbanken

  • Alle Daten im Hauptspeicher gespeichert, keine Festplatten-E / A erforderlich, um Daten abzufragen oder zu aktualisieren.
  • Die Daten sind abhängig vom In-Memory-Datenbankprodukt persistent oder flüchtig.
  • Spezialisierte Datenstrukturen und Indexstrukturen setzen voraus, dass sich Daten immer im Hauptspeicher befinden.
  • Optimiert für hohe Leistung.

Wie wird in einem In-Memory-Datenbankverwaltungssystem auf Daten zugegriffen und diese geändert?

Daten in einer RDM-In-Memory-Datenbank sind sofort einsatzbereit. Wenn Daten in einem Plattenblock komprimiert, verschlüsselt, abgeflacht oder codiert werden können, liegen die Daten im Speicher in einem direkt verwendbaren Format vor. Die Struktur ist unabhängig von Problemen mit der Festplattenblockierung. Sie ermöglicht die direkte Navigation von Spalte zu Spalte, von Zeile zu Zeile oder von Index zu Zeile und ermöglicht die Implementierung von Änderungen durch Zuweisen von Speicherblöcken und Neuanordnen von Zeigern.

Wie werden speicherinterne Daten von mehreren Aufgaben gemeinsam genutzt?

Die Antwort ist zweifach: schnell und schneller. Für diejenigen, die mit dem RDM Transactional File Server (TFS) vertraut sind, mit dem eine Datenbank für Benutzerprozesse auf demselben Computer, im Office-LAN oder weltweit freigegeben werden kann, kann die Datenbank vom TFS im Arbeitsspeicher verwaltet werden. Dies ist schneller als On-Disk-Datenbanken, die vom TFS verwaltet werden.

Der schnellste Weg, eine Datenbank für mehrere Aufgaben freizugeben, besteht darin, einen einzelnen Prozess mit mehreren Threads auszuführen, wobei jede Aufgabe in einem eigenen Thread ausgeführt wird. Diese Form einer Anwendung wird auf einem Computer ausgeführt und ermöglicht jedem Thread den direkten Zugriff auf die Datenbank im lokalen Heapspeicher. Es umgeht auch die Notwendigkeit, unveränderte Datenbankobjekte in einen lokalen Cache einzulesen, da das ursprüngliche Objekt direkt aus dem Datenbankspeicher angezeigt werden kann. Dies ist eine sehr schnelle Möglichkeit, eine Datenbank in einem Mehrbenutzermodus freizugeben.

Kann eine On-Disk-Datenbank im Arbeitsspeicher verwendet werden?

Bei Verwendung von RDM lautet die Antwort "Ja!" In-Memory-Datenbanken können beim Öffnen von der Festplatte geladen und beim Schließen oder beim Anfordern von „Speicherpunkten“ auch auf der Festplatte gespeichert werden. Speicherpunkte sind atomar, dh alle Änderungen an den Daten seit dem letzten Speicherpunkt werden zusammen auf die Festplatte geschrieben, oder keiner von ihnen. Dadurch werden sie transaktional, jedoch nicht an denselben Transaktionsgrenzen wie eine Datenbank auf der Festplatte.

Was sind die Vor- und Nachteile von In-Memory-Datenbanken?

In-Memory-DatenbankenBehandeln Sie per Definition die Daten, die sie im Hauptspeicher verarbeiten. Es besteht keine Notwendigkeit, sich mit Sekundärspeicher zu befassen, der um Größenordnungen langsamer sein kann als der Zugriff auf Daten, die im Hauptspeicher gespeichert sind. Das Eliminieren der Anforderung des Zugriffs auf den langsameren Sekundärspeicher ermöglicht die Verwendung von Algorithmen in einer speicherinternen Datenbank, die für eine festplattenbasierte Datenbank nicht möglich wären. Beispielsweise verwendet eine festplattenbasierte Datenbank üblicherweise einen B-Tree-basierten Index, um die Anzahl der zum Auffinden einer Zeile erforderlichen Festplattenzugriffe zu begrenzen. Eine In-Memory-Datenbank kann eine verwenden AVL-Baum anstelle einer B-Baum Dies reduziert (oder eliminiert) die Notwendigkeit, Daten zu duplizieren, erhöht jedoch die Anzahl der Zeilen, auf die während des Durchlaufs zugegriffen wird.

Ohne die Notwendigkeit eines Sekundärspeichers kann eine In-Memory-Datenbank in Systemen ohne Sekundärspeicher verwendet werden.
Dies ermöglicht die Verwendung eines Datenbankmoduls in vielen Fällen eingebettete Systeme das könnte eine herkömmliche festplattenbasierte Engine nicht unterstützen.
In der Regel ist der Speichertyp, der mit einem speicherinternen Datenbanksystem verwendet wird, nicht dauerhaft. Wenn eine Anwendung sauber oder unerwartet geschlossen wird, gehen die in einer speicherinternen Datenbank gespeicherten Daten verloren. Bestimmte Anwendungsdomänen erfordern keine Datenpersistenz zwischen den Läufen, andere jedoch möglicherweise. Anwendungen, die ein hohes Maß an Persistenz erfordern, sind möglicherweise nicht für die Verwendung einer In-Memory-Datenbank geeignet.

Eine speicherinterne Datenbank speichert alle Daten im Hauptspeicher, wodurch die Menge der Daten, die gespeichert werden können, stark eingeschränkt werden kann. Die meisten Datenbanksysteme können die Zuweisung von Speicher ad-hoc zum Speichern von Datenbankobjekten übernehmen oder einen Teil des Speichers erhalten, der als Speicher verwendet werden kann. In beiden Fällen ist das Datenvolumen, das in einer In-Memory-Datenbank gespeichert werden kann, tendenziell viel kleiner als das in einem festplattenbasierten System gespeicherte.

Was ist der Unterschied zwischen einer In-Memory-Datenbank und dem einfachen Speichern von Daten in gemeinsam genutzten Speichersegmenten?

Der größte Unterschied zwischen speicherinternen Datenbanken und dem Speichern von Daten in gemeinsam genutzten Speichersegmenten besteht in einem strukturierten Ansatz für den Datenzugriff. In-Memory-Datenbanken verwalten Komponenten der “ACIDAttribute von Datenspeicher-Engines. Die ACID-Eigenschaften umfassen Atomizität, Konsistenz, Isolierung und Haltbarkeit. In-Memory-Datenbanken können zwar die Haltbarkeitseigenschaft basierend auf nicht persistentem Speicher lockern, unterstützen jedoch üblicherweise die anderen Eigenschaften:

• • Atomarität - Mehrere Änderungen werden als Alles-oder-Nichts-Operation in die Datenbank übernommen
• • Konsistenz - Strukturelle Regeln und Beziehungen werden für alle Benutzer beibehalten
• • Isolation - Transaktionsänderungen können von anderen Benutzern erst gesehen werden, wenn sie festgeschrieben wurden

Es kann zeitaufwändig und fehleranfällig sein, diese Funktionalität auf gemeinsam genutzten Speichersegmenten zu implementieren.
Neben den Transaktionseigenschaften von In-Memory-Datenbanken gibt es noch viele andere
Out-of-the-Box-Vorteile, einschließlich:
Verwendung allgemeiner genau definierter Datendefinitionssprachen (SQL DDL-Anweisungen) Verwendung allgemeiner genau definierter Datenabfragesprachen (SQL DML-Anweisungen) Fernzugriff auf Daten über ein Netzwerkkommunikationsprotokoll
Möglichkeit zum Speichern von Daten in einem plattformunabhängigen Format
Für den Import / Export über CSV, XML, JSON usw. verfügbare Tools. Möglichkeit, speicherinterne Daten auf der Festplatte zu speichern

Eine In-Memory-Datenbank kann zu Datenverlust führen, wenn etwas nicht mehr funktioniert: Wie gehen Sie damit um?

Ein Anwendungsentwickler muss verstehen, dass Datenverlust bei der Arbeit mit einer In-Memory-Datenbank möglich ist. Es gibt verschiedene Ansätze wie Persistenz und Replikation, mit denen Datenverlustszenarien gemindert werden können. Datenverlust ist jedoch weiterhin möglich.

Beharrlichkeit
Raima unterstützt zwei Modi zum Öffnen einer Datenbank im Arbeitsspeicher.
• • Flüchtig - Die Datenbank ist beim ersten Öffnen leer und alle Inhalte werden beim Schließen der Datenbank verworfen
• • Hartnäckig - Beim Öffnen wird die Datenbank aus Inhalten im Sekundärspeicher gefüllt, beim Schließen werden geänderte Daten (Einfügungen, Aktualisierungen, Löschungen) in den Sekundärspeicher geschrieben

Wenn eine Datenbank im permanenten In-Memory-Modus geöffnet wird, werden geänderte Inhalte beim Schließen der Datenbank automatisch in den Sekundärspeicher geschrieben. Darüber hinaus kann der Entwickler die Änderung des Sekundärspeichers bei Bedarf beibehalten. Verwenden von
Die Persistenz kann den Datenverlust auf das beschränken, was seit dem letzten Persistenzvorgang passiert ist.

Reproduzieren
Viele Datenbanksysteme unterstützen das Replizieren von Änderungen auf eine andere Datenbankinstanz (oder ein anderes Datenbanksystem). Durch die Verwendung der Replikation können Daten, die möglicherweise von der In-Memory-Kopie verloren gegangen sind, von der replizierten Kopie wiederhergestellt werden.

Sind alle eingebetteten Datenbanken auch In-Memory-Datenbanken?

Ein eingebettete Datenbank kann als Datenbankmodul definiert werden, das in einer Anwendung ausgeführt wird und für das keine anderen Prozesse installiert, konfiguriert oder auf die zugegriffen werden muss. Das Speichermedium für die von der Engine verwalteten Daten ist implementierungsabhängig.
Ursprünglich verwendeten die meisten Datenbankmodule eine Festplatte zur Datenspeicherung, da die verfügbare Speichermenge kein ausreichendes Datenvolumen für nützliche Datensätze zulässt. Mit zunehmender Speichergröße fügten viele Anbieter In-Memory-Funktionen hinzu. Heutzutage unterstützen viele eingebettete oder herkömmliche Datenbank-Engines In-Memory.

Wie implementiert Raima ein In-Memory-Datenbanksystem in RDM?

Das Raima RDM-Datenbankmodul ist in zwei Komponenten unterteilt: das Laufzeitmodul und das Speichermodul.
Die Laufzeit ist für die Transaktionsverwaltung, die Durchsetzung von Regeln, die Abfrageverarbeitung und die Verwaltung lokaler, nicht festgeschriebener Änderungen an der Datenbank verantwortlich. Immer wenn die Laufzeit-Engine ein Datenbankobjekt benötigt, fordert sie das Objekt von der Speicher-Engine an. Wenn lokale Änderungen in der Laufzeit festgeschrieben werden, werden sie außerdem an die Speicher-Engine übergeben, um an einem Speicherort gespeichert zu werden, der von allen Benutzern der Datenbank gemeinsam genutzt wird. Die Laufzeit-Engine weiß oder kümmert sich nicht darum, ob die Speicher-Engine den Hauptspeicher oder den Sekundärspeicher verwendet.

Die Speicher-Engine kann als betrachtet werden Schlüssel / Wert-Paar-Repository. Die Schlüssel sind Datenbankobjektkennungen und die Werte sind der Speicherort der Datenbankobjekte. Bei festplattenbasierten Datenbanken sind die Werte eine Dateikennung, ein Dateiversatz und eine Größe. Bei einer speicherinternen Datenbank sind die Werte der Speicherort des Datenbankobjekts.
Die Objekte selbst können codiert, komprimiert und verschlüsselt sein, aber die Laufzeit-Engine weiß, wie der Inhalt zu interpretieren ist.

Durch Beibehalten dieser Abstraktion muss ein Anwendungsentwickler nichts anderes tun, als einen vorgeöffneten Konfigurationsparameter anzugeben, um eine speicherinterne RDM-Datenbank zu verwenden. Die Anwendung, die Laufzeit und die Speicher-Engine können alle auf demselben Speicherplatz ausgeführt werden und bieten einen Zugriff mit sehr geringer Latenz. Wenn ein Entwickler weiß, dass eine Datenbank hauptsächlich im Arbeitsspeicher verwendet wird, kann er Methoden wie z AVL-Indizierung zur Optimierung des In-Memory-Zugriffs.

Lesen Sie mehr über Raimas In-Memory-Implementierung.

Erfahren Sie, wie Raima bietet Hochleistung, tragbar eingebettete Datenbank und mobile Datenbank Lösungen.