Jenseits von NoSQL: Der Fall für verteiltes SQL

Am Anfang gab es Dateien. Später gab es Navigationsdatenbanken, die auf strukturierten Dateien basierten. Dann gab es IMS und CODASYL, und vor ungefähr 40 Jahren hatten wir einige der ersten relationalen Datenbanken. Während eines Großteils der 1980er und 1990er Jahre bedeutete "Datenbank" streng genommen "relationale Datenbank". SQL regierte. 

Angesichts der wachsenden Beliebtheit objektorientierter Programmiersprachen dachten einige, die Lösung für die „Impedanzfehlanpassung“ objektorientierter Sprachen und relationaler Datenbanken bestehe darin, Objekte in der Datenbank abzubilden. So kamen wir zu "objektorientierten Datenbanken". Das Lustige an Objektdatenbanken war, dass es sich in vielen Fällen im Grunde genommen um eine normale Datenbank mit integriertem Objekt-Mapper handelte. Diese wurden immer beliebter und der nächste echte Massenmarktversuch war „NoSQL“ in den 2010er Jahren.

Der Angriff auf SQL

NoSQL hat sowohl relationale Datenbanken als auch SQL auf dieselbe Weise angegriffen. Das Hauptproblem war diesmal, dass das Internet die zugrunde liegende Prämisse der 40 Jahre alten RDBMS-Architektur (Relational Database Management System) zerstört hatte. Diese Datenbanken wurden entwickelt, um wertvollen Speicherplatz zu sparen und vertikal zu skalieren. Es gab jetzt viel zu viele Benutzer und viel zu viel für einen fetten Server. NoSQL-Datenbanken gaben an, dass Sie, wenn Sie eine Datenbank ohne Joins, ohne Standardabfragesprache (da die Implementierung von SQL Zeit benötigt) und ohne Datenintegrität hätten, horizontal skalieren und dieses Volume verarbeiten könnten. Dies löste das Problem der vertikalen Skalierung, führte jedoch zu neuen Problemen.

Parallel zu diesen Online-Transaktionsverarbeitungssystemen (OLTP) wurde eine andere Art von hauptsächlich relationaler Datenbank entwickelt, die als Online-Analyseverarbeitungssystem (OLAP) bezeichnet wird. Diese Datenbanken unterstützten die relationale Struktur, führten jedoch Abfragen mit dem Verständnis aus, dass sie riesige Datenmengen zurückgeben würden. Die Unternehmen in den 1980er und 1990er Jahren waren noch weitgehend von der Stapelverarbeitung getrieben. Darüber hinaus entwickelten OLAP-Systeme die Möglichkeit für Entwickler und Analysten, sich Daten als n-dimensionale Würfel vorzustellen und zu speichern. Wenn Sie sich ein zweidimensionales Array und Lookups vorstellen, die auf zwei Indizes basieren, so dass Sie im Grunde so effizient wie die konstante Zeit sind, dann nehmen Sie diese und fügen Sie eine andere Dimension hinzu, damit Sie im Wesentlichen Lookups von drei oder mehr Faktoren durchführen können (z Angebot, Nachfrage,und die Anzahl der Wettbewerber) - Sie könnten die Dinge effizienter analysieren und prognostizieren. Das Konstruieren dieser ist jedoch mühsam und sehr chargenorientiert.

Etwa zur gleichen Zeit wie das Scale-out von NoSQL entstanden Graphendatenbanken. Viele Dinge sind an sich nicht „relational“ oder basieren nicht auf Mengenlehre und relationaler Algebra, sondern auf Eltern-Kind- oder Freund-eines-Freund-Beziehungen. Ein klassisches Beispiel ist die Produktlinie zur Produktmarke zum Modellieren zu Komponenten im Modell. Wenn Sie wissen möchten, „welches Motherboard sich in meinem Laptop befindet“, stellen Sie fest, dass die Hersteller eine komplizierte Beschaffung haben und die Marken- oder Modellnummer möglicherweise nicht ausreicht. Wenn Sie wissen möchten, welche Motherboards in einer Produktlinie verwendet werden, müssen Sie in klassischem SQL (Nicht-CTE oder Common Table Expression) in mehreren Schritten Tabellen durchlaufen und Abfragen ausführen. Anfangs waren die meisten Graphendatenbanken überhaupt nicht zerbrochen. In Wahrheit können viele Arten der Diagrammanalyse durchgeführt werden, ohne die Daten tatsächlich als Diagramm zu speichern.

NoSQL-Versprechen gehalten und Versprechen gebrochen

NoSQL-Datenbanken skalierten viel, viel besser als Oracle Database, DB2 oder SQL Server, die alle auf einem 40 Jahre alten Design basieren. Für jeden NoSQL-Datenbanktyp gab es jedoch neue Einschränkungen:

  • Schlüsselwertspeicher: Es gibt keine einfachere Suche als db.get (Schlüssel). Viele Daten und Anwendungsfälle der Welt können jedoch nicht auf diese Weise strukturiert werden. Darüber hinaus sprechen wir wirklich über eine Caching-Strategie. Die Suche nach Primärschlüsseln ist in jeder Datenbank schnell. es kommt nur darauf an, was im Gedächtnis ist. Im besten Fall skalieren diese wie eine Hash-Karte. Wenn Sie jedoch 30 Datenbankfahrten durchführen müssen, um Ihre Daten wieder zusammenzusetzen, oder eine komplizierte Abfrage durchführen müssen, funktioniert dies nicht. Diese werden jetzt häufiger als Caches vor anderen Datenbanken implementiert. (Beispiel: Redis.)
  • Dokumentendatenbanken: Diese haben ihre Popularität erreicht, weil sie JSON verwenden und Objekte einfach in JSON serialisiert werden können. Die ersten Versionen dieser Datenbanken hatten keine Verknüpfungen, und es hatte seine eigenen Nachteile, Ihre gesamte „Entität“ in einem riesigen Dokument zusammenzufassen. Ohne Transaktionsgarantien hatten Sie auch Probleme mit der Datenintegrität. Heutzutage unterstützen einige Dokumentendatenbanken eine weniger robuste Form der Transaktion, aber es ist nicht das gleiche Maß an Garantie, an das die meisten Menschen gewöhnt sind. Selbst bei einfachen Abfragen sind diese häufig in Bezug auf die Latenz langsam - selbst wenn sie in Bezug auf die Gesamtheit besser skaliert werden. (Beispiele: MongoDB, Amazon DocumentDB.)
  • Spaltenspeicher: Diese sind so schnell wie Schlüsselwertspeicher für Suchvorgänge und können kompliziertere Datenstrukturen speichern. Es ist jedoch bestenfalls schmerzhaft, etwas zu tun, das wie eine Verknüpfung zwischen drei Tabellen (im RDBMS-Jargon) oder drei Sammlungen (im MongoDB-Jargon) aussieht. Diese sind wirklich großartig für Zeitreihendaten (geben Sie mir alles, was zwischen 13:00 und 14:00 Uhr passiert ist).

Und es gibt andere, esoterischere NoSQL-Datenbanken. Allen diesen Datenbanken ist jedoch gemeinsam, dass gemeinsame Datenbanksprachen nicht unterstützt werden und die Tendenz besteht, sich auf einen „besonderen Zweck“ zu konzentrieren. Einige beliebte NoSQL-Datenbanken (z. B. MongoDB) haben großartige Datenbank-Frontends und Ökosystem-Tools geschrieben, die es Entwicklern wirklich leicht machten, sie zu übernehmen, aber schwerwiegende Einschränkungen in ihrer Speicher-Engine verursachten - ganz zu schweigen von Einschränkungen in Bezug auf Ausfallsicherheit und Skalierbarkeit.

Datenbankstandards sind immer noch wichtig

Eines der Dinge, die relationale Datenbanken dominierten, war, dass sie ein gemeinsames Ökosystem von Werkzeugen hatten. Zuerst gab es SQL. Obwohl Dialekte unterschiedlich sein können - als Entwickler oder Analyst, wenn Sie von SQL Server 6.5 zu Oracle 7 gewechselt sind, müssen Sie möglicherweise Ihre Abfragen korrigieren und "(+)" für äußere Verknüpfungen verwenden -, aber einfache und harte Aufgaben waren recht einfach übersetzen.

Zweitens hatten Sie unter anderem ODBC und später JDBC. Nahezu jedes Tool, das eine Verbindung zu einem RDBMS herstellen kann (es sei denn, es wurde speziell für die Verwaltung dieses RDBMS entwickelt), kann eine Verbindung zu einem anderen RDBMS herstellen. Es gibt viele Leute, die täglich eine Verbindung zu einem RDBMS herstellen und die Daten in Excel saugen, um sie zu analysieren. Ich beziehe mich nicht auf Tableau oder eines von Hunderten anderer Tools. Ich spreche von dem "Mutterschiff" Excel.

NoSQL hat Standards abgeschafft. MongoDB verwendet SQL nicht als Primärsprache. Als der engste Konkurrent von MongoDB, Couchbase, nach einer Abfragesprache suchte, um das Java-basierte Mapreduce-Framework zu ersetzen, erstellten sie ihren eigenen SQL-Dialekt.

Standards sind wichtig, um das Ökosystem der Tools zu unterstützen, oder weil viele Leute, die Datenbanken abfragen, keine Entwickler sind - und SQL kennen.

GraphQL und der Aufstieg des State Managements

Sie wissen, wer zwei Daumen hat und nur möchte, dass der Status seiner App in die Datenbank gelangt, und es ist Ihnen egal, wie? Dieser Typ. Und es stellt sich heraus, dass eine ganze Generation von Entwicklern. GraphQL - das nichts mit Diagrammdatenbanken zu tun hat - speichert Ihr Objektdiagramm in einem zugrunde liegenden Datenspeicher. Dies befreit den Entwickler von der Sorge um dieses Problem.

Ein früherer Versuch waren objektrelationale Mapping-Tools oder ORMs wie Hibernate. Sie nahmen ein Objekt und wandelten es im Grunde genommen in SQL um, basierend auf einem Objekt-zu-Tabelle-Mapping-Setup. Viele der ersten Generationen waren schwer zu konfigurieren. Darüber hinaus befanden wir uns in einer Lernkurve.

Die meisten GraphQL-Implementierungen arbeiten mit objektrelationalen Mapping-Tools wie Sequelize oder TypeORM. Anstatt das Problem der Statusverwaltung in Ihrem Code zu verlieren, schreibt eine gut strukturierte GraphQL-Implementierung und -API die relevanten Daten und gibt sie zurück, wenn Änderungen an Ihrem Objektdiagramm vorgenommen werden. Wen interessiert es auf Anwendungsebene wirklich, wie die Daten gespeichert werden?

Eine der Grundlagen objektorientierter und NoSQL-Datenbanken bestand darin, dass der Anwendungsentwickler sich der Komplexität der Speicherung von Daten in der Datenbank bewusst sein musste. Natürlich war es für Entwickler schwierig, mit neueren Technologien fertig zu werden, aber es ist nicht mehr schwer. Weil GraphQL dieses Problem vollständig beseitigt.

Geben Sie NewSQL oder verteiltes SQL ein

Google hatte ein Datenbankproblem und schrieb ein Papier und später eine Implementierung namens "Spanner", in der beschrieben wurde, wie eine global verteilte relationale Datenbank funktionieren würde. Spanner löste eine neue Innovationswelle in der relationalen Datenbanktechnologie aus. Sie könnten tatsächlich eine relationale Datenbank haben und diese nicht nur mit Shards, sondern bei Bedarf weltweit skalieren lassen. Und wir sprechen von Skalierung im modernen Sinne, nicht von der oft enttäuschenden und immer komplizierteren Art von RAC / Streams / GoldenGate.

Die Prämisse, Objekte in einem relationalen System zu speichern, war also falsch. Was wäre, wenn das Hauptproblem bei relationalen Datenbanken das Back-End und nicht das Front-End wäre? Dies ist die Idee hinter sogenannten "NewSQL" - oder besser "verteilten SQL" -Datenbanken. Die Idee ist, NoSQL-Speichererfahrungen und Googles Spanner-Idee mit einem ausgereiften Open-Source-RDBMS-Frontend wie PostgreSQL oder MySQL / MariaDB zu kombinieren.

Was bedeutet das? Es bedeutet, dass Sie Ihren Kuchen haben und ihn auch essen können. Dies bedeutet, dass Sie mehrere Knoten haben und horizontal skalieren können - auch über Cloud-Verfügbarkeitszonen hinweg. Dies bedeutet, dass Sie mehrere Rechenzentren oder geografische Cloud-Regionen haben können - mit einer Datenbank. Dies bedeutet, dass Sie echte Zuverlässigkeit haben können, ein Datenbankcluster, der für Benutzer niemals ausfällt.

Inzwischen funktioniert das gesamte SQL-Ökosystem noch! Sie können dies tun, ohne Ihre gesamte IT-Infrastruktur neu aufzubauen. Während Sie möglicherweise kein Spiel sind, um Ihr traditionelles RDBMS zu "rippen und zu ersetzen", versuchen die meisten Unternehmen nicht, mehr Oracle zu verwenden. Und das Beste ist, dass Sie SQL und alle Ihre Tools sowohl in der Cloud als auch weltweit verwenden können.