Das relationale Modell hat seine Exklusivität verloren
Die Anforderungen an die Funktionalität und Struktur von Datenbanken (DB), die in relationalen Systemen am vollständigsten implementiert sind, stehen nun unter dem Druck neuer Anforderungen.
Das erste Problem ist die geringe Effizienz von Big Data. Quellen für Big Data sind soziale Netzwerke, Videoüberwachungssysteme, räumliche Sensoren, Abrechnungen usw. Eine relationale Datenbank (RDB) funktioniert gut, wenn das Datenschema vor dem Starten der Anwendung genau definiert wurde. Big Data ist jedoch in der Phase des Datenbankentwurfs von Natur aus schwer zu strukturieren. Erst wenn Informationen nach und nach gesammelt werden, wird ihre Struktur deutlicher.
Die zweite Aufgabe - Suchen, Berechnen von Abfragen in RDBs mit großen Tabellen - ist eine Aufgabe von hoher algorithmischer Komplexität. Die Verwendung von Indizierung und Hashing funktioniert gut in mehr oder weniger statischen BDBs, die weitgehend gefüllt sind, bevor das System in Betrieb genommen wird. Unter den Bedingungen des schnellen Eintreffens neuer Datenarrays in Echtzeit werden die Vorteile dieser Methoden ausgeglichen, da die Gemeinkosten stark ansteigen.
Der dritte Nachteil der RDB ergibt sich aus den strengen Anforderungen an Datenschemata im Rahmen der kanonischen "Normalformen". Die Notwendigkeit einer großen Anzahl einer Vielzahl von Anwendungen erfordert erhebliche Anstrengungen zur Erstellung von Datenmodellen, und das ungleiche Qualifikationsniveau der Programmierer und die engen Fristen führen zu Fehlern, die Korrekturen und Änderungen erfordern. Aber jede Änderung, die bereits „lebt“ und mit DBD („Migration“) gefüllt ist, ist eine noch komplexere und mühsamere Aufgabe, die in einigen Fällen überhaupt keine andere Lösung bietet, wie das vollständige Ersetzen der alten Datenbank durch eine neue.
Die „Schönheit“ und Genauigkeit des in SQL seit drei Jahrzehnten implementierten relationalen Modells hat Programmierer begeistert. Die "alten" Modelle: Netzwerk oder Hierarchie wurden fast vergessen. Ja, es gibt fast keine solchen Softwareprodukte, mit der möglichen Ausnahme des „fast unsterblichen“ IDMS [1].
In den letzten zehn Jahren wird aktiv daran gearbeitet, alternative Datenbankverwaltungssysteme (DBMS) zu erstellen, die so einfach als NoSQL bezeichnet werden. Unter dieses Konzept fallen nun sehr unterschiedliche Systeme, die sich stark voneinander unterscheiden. Interessanterweise sind das "alte" Netzwerk und die hierarchischen Modelle nicht im Konzept von NoSQL enthalten! Gute Bewertungen in diesem Bereich finden Sie in [2,3,4].
Die NoSQL-Kategorie umfasst „Graph“ -Datenbanken [5], die abstrakt dem kanonischen Netzwerkmodell CODASYL [6] nahe kommen. Wie der Name schon sagt, sind solche Systeme zwei unorganisierte Mengen - Knoten (Eckpunkte) und Kanten (Bögen). Der Hauptvorteil von Netzwerkdatenbanken - die Navigation wird nicht zum Zeitpunkt der Verarbeitung der Anforderung wie in der RDB "bestimmt", sondern zum Zeitpunkt des Hinzufügens neuer Daten (für Diagramme - Eckpunkte und Kanten) gilt dies auch für Diagrammsysteme. Im Gegensatz zur CODASYL-Datenbank wird die Diagrammdatenbank jedoch nicht vor dem Auffüllen strukturiert.
Andere beliebte NoSQL-Datenbankklassen sind "Schlüsselwert" (Beispiel - Redis [7]) und "Dokumentenspeicherung" (Beispiel - MongoDB [8]). Da eine detaillierte Überprüfung solcher Systeme nicht Gegenstand dieses Artikels ist, ist es wichtig, nur Folgendes zu beachten.
NoSQL-Systeme arbeiten in der Regel auf Basis verteilter Dateisysteme, die Skalierbarkeit und Zuverlässigkeit bieten [9]. Das Problem, das im Rahmen des relationalen Modells mathematisch rigoros gelöst wird, ist jedoch die Integrität und Konsistenz der Datenbank (vorausgesetzt natürlich ein professionell kompetenter Entwurf des normalisierten Schemas), der in den meisten NoSQL-Systemen überhaupt nicht gestellt wird.
Insgesamt ist die Situation heute ungefähr so: 75% der Datenbanken sind relational, NoSQL in seiner reinen Form wird in hochspezialisierten Systemen verwendet und Kombinationen verschiedener Datenbankmodelle werden in hoch geladenen globalen Netzwerkprojekten verwendet: Google, Facebook, Instagram, WhatsApp und dergleichen.
Relationale Datenbanken ohne SQL
Zusätzlich zu den oben beschriebenen praktischen Problemen hat die Verwendung von RDBs in letzter Zeit andere wichtige Trends gesehen.
Neben der manchmal übermäßigen „Starrheit“ des relationalen Modells besteht sein größter praktischer (nicht theoretischer) Nachteil in der Komplexität der Datenmanipulation. Die erste Option besteht darin, die Pipeline von Operationen für Mengen zu verwenden - Vereinheitlichung, Schnittmenge, Filterung usw. In der Praxis wird es fast nie verwendet, da es mit dem Aufwand kolossaler Ressourcen verbunden ist und nur mit der "Stapel" -Verarbeitung von Anforderungssätzen des gleichen Typs gerechtfertigt ist. Die zweite Option - der SQL-Interpreter erfordert hohe Professionalität, gute Kenntnisse der Mengenlehre, der Datenbanktheorie und beträchtliche praktische Erfahrung.
Objektorientierte Programmierung (OOP) ist zum Standard geworden, aber SQL ist eine deklarative Sprache, deren Grammatik nicht in die gängigsten OOP-Sprachen (C ++, Java, JavaScript, Python) passt. Infolgedessen hat die Lösung zum „Einbetten“ von RDBs (Arbeiten mit SQL-Abfragen) basierend auf Klassenbibliotheken namens ORM (Object-Relational Mapping - Object-Relational Mapping (Transformation) [9]) an Popularität gewonnen.
Durch die Verwendung von ORM-Klassen kann der Programmierer bei der Verwendung von RDBs auf SQL verzichten. ORM generiert automatisch SQL-Abfragen an die RDBs, um Tabellen zu erstellen und Daten zu bearbeiten. Die meisten ORMs verfügen über Schnittstellen zu verschiedenen gängigen DBMS - SQLite, MySQL, PostgreSQL und anderen, sodass Sie eine Auswahl treffen können, ohne den Programmcode zu ändern.
Es gibt viele ORM-Implementierungen, sogar mehrere für jede Programmiersprache. Alle von ihnen sind ähnlich, daher meinen wir mit ORM in Zukunft die entsprechende Bibliothek (Paket) von Modellen der Modellklasse des Django-Frameworks [10] in der Python-Sprache [11].
ORM ist sehr „praktisch“ und Programmierer glauben nicht wirklich, dass sie mit dieser API nicht nur die Vorteile des relationalen Modells, sondern auch alle seine Nachteile nutzen können. Im Code selbst können Sie beispielsweise keine Tabellenmodelle überschreiben - Hinzufügen oder Entfernen einer Spalte, Hinzufügen einer neuen Tabelle usw. Um die Datenbankmigration durchzuführen, müssen Sie zuerst den Code neu schreiben, dann "eine Etage höher steigen" und dann das Programm neu starten. Infolgedessen ist es unmöglich, eine Anwendung zu erstellen, die selbst die einfachsten Änderungen am Datenschema während des Betriebs des Programms bereitstellt, ohne das Programm selbst zu ändern.
Das Abrufen von Daten in ORM wird mithilfe von Methodenketten implementiert, z. B. "objects.all ()", "objects.get (...)", "objects.filter (...)" in Django. Einfach, schön und bequem, aber welche algorithmische Komplexität der Ausführung von von ORM generierten SQL-Abfragen dazu führt, ist mit „bloßem Auge“ nicht sichtbar.
Wenn eine Person eine SQL-Abfrage schreibt, wird davon ausgegangen, dass sie die Kosten für Computerressourcen denkt und versteht. ORM verschleiert diese Aufgabe.
Hypertable als Datenbank der neuen Generation
Wir haben ein neues Konzept, neue Methoden und praktische Möglichkeiten entwickelt, um die relationalen und Netzwerkdatenbankmodelle mit den Vorteilen der ORM-Idee zu kombinieren - die Ablehnung der Verwendung spezieller Abfragesprachen, wodurch wir ein neues Datenbankmodell und eine neue Datenbanktechnologie erstellen konnten.
Das Schlüsselkonzept ist die Hypertabelle (GT) - dies ist eine Datenbank als eine Reihe von Beziehungen (Tabellen), in denen verwendet werden:
- "Relationale" Attribute (Datendomänen), deren Werte wie in der RDB Feldfelder mit selbst definierten Daten für die entsprechenden Tabellenspalten sind
- "Netzwerk" -Attribute (Linkdomänen). Wir werden sie ATS nennen - Attribut vom Typ "Link"
Die Werte der PBX-Felder in den Zeilen der Tabelle sind explizite Verweise auf Zeilen in Tabellen, die in der Hypertabelle enthalten sind.
Das von uns eingeführte Konzept einer Hypertabelle hat nichts mit dem Projekt [13] zu tun, das 2016 gekürzt wurde.
Es gibt einen funktionierenden Prototyp - eine Reihe von Tools in Python - das HTMS (Hyper Table Management System), das die folgenden Ebenen (von oben nach unten) umfasst:
- HTed Hypertable Editor (Client) - ein technologischer Supportdienst, der als Website im Django-Framework implementiert ist und unabhängig von Anwendungen eine Verbindung zu jedem Server mit einer Hypertabelle herstellen kann (in gewissem Umfang funktional in der Nähe des Dienstprogramms PgAdmin für PostgeSQL).
- Bibliothek von Dienstprogrammen und Klassen auf Logikebene - API zum Erstellen einer Datenbank und zum Bearbeiten von Daten auf Anwendungsprogrammierebene (anstelle von ORM);
- eine Bibliothek von Dienstprogrammen und Klassen der physischen Ebene der Arbeit mit der Datenbank, auf der Dienstprogramme und Klassen der logischen Ebene basieren (wie die API von erfahrenen Systemprogrammierern verwendet werden kann);
- Cage-Klasse, mit der eine „virtuelle“ Schicht des zwischengespeicherten Remotezugriffs auf Datenbankdateien auf der Client- (Anwendungs-) Seite erstellt werden soll;
- CageServer-Dateiserver - Software, die im Multiprogramm- und Multithread-Modus arbeitet und Funktionen für den Remotezugriff mehrerer Benutzer auf Dateien auf einem Server mithilfe des TCP-Protokolls implementiert.
Im Prinzip ist es anstelle von Cage möglich, das übliche lokale Dateisubsystem des Betriebssystems zum Verwalten von Dateien zu verwenden und die Cage-API und die CageServer-Software als unabhängiges Tool von HTMS zu verwenden, um den verteilten Remotezugriff auf Dateien auf allen Systemen zu implementieren.
In zukünftigen Artikeln ist geplant, die Leser detaillierter in das HTMS-System einzuführen.