Die Oracle-Datenbank ist eines der erfolgreichsten Softwareprodukte aller Zeiten. In den letzten 40 Jahren hat sie sich zu der dominierenden Technologie für die Speicherung und Verwaltung von Daten entwickelt. Die RDBMS- und SQL-Standards sind heute in jedem großen Unternehmen fest verankert. Alternativen wie MarkLogic wurden in jüngerer Zeit entwickelt, um neue Herausforderungen beim Datenmanagement, insbesondere bei der Datenintegration, zu bewältigen.
Heute sehen sich Organisationen mit neuen Herausforderungen konfrontiert, die es in den 80- und 90-er Jahren nicht gab. Die Daten sind groß, schnell, vielfältig und ändern sich. Statt einer kleinen Handvoll von Systemen sind in Organisationen über Hunderte von Systemen und Petabytes von Daten vorhanden. Zudem ändern sich die Anforderungen der Unternehmen schneller als je zuvor und sind stärker reguliert als je zuvor. Dies bedeutet, dass neu überdacht werden muss, wie Daten verwaltet werden, um den sich schnell entwickelnden Geschäftsanforderungen gerecht zu werden:
MarkLogic bietet in allen oben genannten Bereichen deutliche Vorteile im Vergleich zu Oracle. MarkLogic bietet eine flexiblere Datenintegration bei weniger Risiko, senkt Cloud-Kosten deutlich und macht diese vorhersehbarer, beschleunigt die Bereitstellung neuer Anwendungen und vernachlässigt weder Datensicherheit noch Governance.
Dieser Vergleich befasst sich mit den grundlegenden Unterschieden zwischen Oracle- und MarkLogic-Datenbanken und wie der Data Hub Service von MarkLogic im Vergleich zu den Cloud-Produkten von Oracle abschneidet. Zusammenfassend sind folgende zugrunde liegende Unterschiede ausschlaggebend:
Oracle ist eines der zehn größten Softwareunternehmen der Welt und bietet die am weitesten verbreitete relationale Datenbank. Oracle erzielt weiterhin einen relativ großen Prozentsatz seiner Einnahmen aus der Lizenzierung der Oracle-Datenbank (und ihrer vielen Derivate). In den letzten Jahren hat Oracle erheblich in den Ausbau der Oracle-Cloud investiert, deren Suite aus über 120 verschiedenen Produkten auch SAAS, PAAS und IAAS umfasst.
Die relationale Datenbank von Oracle wurde erstmals im Jahr 1979 veröffentlicht. Die neueste Version dieser Software ist Oracle Database 19c (die langfristige Unterstützungsversion von Oracle 12c und 18c). Es gibt verschiedene Iterationen dieses Kernproduktes und die Produktsuite von Oracle umfasst jetzt spezifische Produkte für unterschiedliche Workloads (analytisch anstatt transaktional), technische Systeme (kombinierte Hardware/Software-Anwendungen) und vollständig verwaltete Cloud-Dienste.
Der MarkLogic Data Hub Service ist das Flaggschiffprodukt von MarkLogic. Es handelt sich um einen vollständig verwalteten Cloud-Data-Hub für agile Datenintegration und Datenmanagement. Er basiert auf MarkLogic Server und verfügt über die gleichen Multi-Modell-, Sicherheits- und Scale-Out-Funktionen.
MarkLogic Server: Eine Multi-Modell-Datenbank mit modernen NoSQL- und vertrauenswürdigen Enterprise-Funktionen. Sie kann als Teil des MarkLogic Data Hub Service oder allein in einer beliebigen Umgebung (On-premise, Cloud, Hybrid) eingesetzt werden.
MarkLogic entwickelt auch zugehörige Tools und Konnektoren für das Ökosystem, einschließlich verschiedener APIs und Konnektoren.
Es gibt zwei Möglichkeiten, MarkLogic mit Oracle zu vergleichen:
MarkLogic Server war die erste moderne, Multi-Modell-Datenbank auf dem Markt. MarkLogic bietet mehrere Möglichkeiten, Daten zu modellieren (z. B. Dokumente, Diagramme, relationale Daten), sogar Daten, die dieselbe Entität repräsentieren. MarkLogic unterstützt zudem die gleichzeitige Speicherung von Daten in mehreren Schemata – alle in derselben Datenbank – mit einem einzigen integrierten Back-End.
Noch vor wenigen Jahren war der Begriff „Multi-Modell“ relativ neu und es war ziemlich anstrengend, um zu erklären, was es war und warum man es brauchte. Heute ist das nicht der mehr Fall – es wird allgemein anerkannt, dass Multi-Modell-Datenbanken Teil jeder modernen Datenarchitektur sein sollten.
Die folgenden Ressourcen bieten einen tieferen Einblick, um zu verstehen, welchen Vorteil das von MarkLogic bereitgestellte Multi-Modell bietet:
Hier eine Zusammenfassung der Vorteile des Multi-Modells von MarkLogic:
Oracle ist eine relationale Datenbank, die Daten in Zeilen und Spalten speichert. Hier sind drei konkrete Beispiele, die verdeutlichen, wie sich dieser Ansatz von einem Multi-Modell-Ansatz unterscheidet:
Datenmodellierung und -zugriff – Mit Oracle müssen Benutzer relationale Schemata verstehen, die oft sehr komplex sind. Bei dieser Struktur können möglicherweise Daten, die eine einzelne Geschäftsentität definieren, auf eine große Anzahl von Tabellen aufgeteilt werden. Dies führt in der Regel zu kryptischen Spalten- und Feldnamen (oder VARCHAR-Spalten), die nur der Datenbankadministrator versteht, d. h. nur er weiß, wie er richtig auf die Daten zugreifen kann. Wenn zum Beispiel Daten über Medikamente gespeichert sind, müssen die Benutzer wissen, ob sie nach „Aspirin“, „Acetylsalicylsäure“, „Excedrin“ oder „Bufferin“ (alles Namen für dasselbe Produkt) suchen sollen. Wenn Benutzer den falschen Begriff abfragen, sehen sie die meisten Ergebnisse nicht.
MarkLogic Server löst diese Probleme durch die Verwendung des Dokumentenmodells, das für den Menschen besser lesbar ist und kein Shreddern von Entitätsdaten erfordert. Darüber hinaus können sich die Benutzer von MarkLogic Server auf die integrierten Such- und Semantik-Funktionen verlassen, um die Daten wie einen Wissensgraphen zu durchsuchen, was es für Nicht-Datenbank- und Domänenexperten erheblich einfacher macht, Daten abzufragen.
Indizierung und Leistung – Oracle ist sehr wartungsaufwändig, da Datenbank-Administratoren Zeit damit verbringen, Tabellen und Indizes ständig für die Abfrageleistung zu optimieren. Beispielsweise erfordert Oracle eine ständige Defragmentierung der Tablespaces (vielleicht wöchentlich oder öfter, je nach Anzahl der Löschvorgänge), damit die Leistung beim Einfügen nicht abfällt. Zudem müssen Oracle-Indizes in der Regel ständig neu gewichtet und neu indiziert werden. Bei Oracle müssen die Benutzer damit rechnen, dass Ausführungspläne häufig beeinträchtigt werden und neue erstellt werden müssen, um die Leistung aufrechtzuerhalten. Sich dabei auf den Oracle-Optimierer zu verlassen, kann die Dinge selbst bei einem gut gewarteten System noch verschlimmern. Auch die Verwendung der Oracle-Datenreplikation kann sich negativ auf die Transaktionsleistung auswirken.
Im Gegensatz zu einer relationalen Datenbank verfügt MarkLogic Server über einen Universal Index, der automatisch Wörter, Sätze, Beziehungen, Werte und Struktur indexiert. Dieser Index braucht keinerlei Wartung für die Erstellung, Aktualisierung oder ständige Synchronisierung. Die Abfrageleistung bei diesem Index ähnelt eher einer Google-Suche und ist auch bei unterschiedlichen Workloads konsistent.
Metadaten und Data Governance – Bei Oracle erfordert die Verfolgung von Metadaten eine Vorausplanung, Änderungen sind schwierig und Daten gehen oft verloren. Wie bei anderen relationalen Datenbanken mit definierten Schemata müssen Spalten hinzugefügt werden, um neue Metadaten zu verarbeiten. Häufig werden Metadaten jedoch verworfen oder einfach separat gespeichert. Bei Herkunfts- und Abstammungsinformationen handelt es sich um Metadaten, die für die Datenverwaltung von entscheidender Bedeutung sind. Jedoch ist es oft zu umständlich, diese zu verwalten, insbesondere in einem komplexen Datenintegrations-Lebenszyklus.
MarkLogic Server speichert jede beliebige Menge an Metadaten direkt neben den Daten selbst – es sind nur weitere Attribute im Dokument. Der PROV-O-Standard wird für die Speicherung von Herkunfts- und Abstammungsmetadaten verwendet, sodass jedes Tool sie verstehen kann. Darüber hinaus können sie, wie alle Daten in MarkLogic, harmonisiert und semantisch angereichert werden. Dasselbe kann man nicht über einen relationalen Ansatz behaupten.
In gewisser Weise ist die neueste Version von Oracle eine Multi-Modell-Datenbank. Historisch gesehen hat Orakel jedoch über jeden anderen Ansatz als einen rein relationalen gelacht. In einem 2015 erschienenen eWeek-Artikel sagte der Oracle-Vorstandsvorsitzende, Andy Mendelsohn, dass NoSQL-Datenbanken, einschließlich Multi-Modell-Datenbanken, „für einfache Probleme beim Datenmanagement konzipiert“ seien, “eine sehr geringe Produktivität„ hätten und „begrenzt“ seien. In Wirklichkeit gab es auf dem NoSQL-Markt ein massives Wachstum. 2019 erklärte Mendelsohn bei Oracle Open World, dass Oracle tatsächlich eine NoSQL-Multi-Modell-Datenbank ist: „Im Laufe der Jahre haben sich relationale Datenbanken in Multi-Modell-Datenbanken verwandelt. Wir unterstützen JSON als Datentyp. Wir unterstützen XML ...“
Er hat Recht. Es ist möglich, JSON, XML und RDF in Oracle einzuspielen. Aber unter der Oberfläche ist Oracle immer noch relational, kein echtes Multi-Modell, genau wie jede andere Version davor.
Oracle speichert JSON nicht nativ. Oracle gibt in seiner Dokumentation an, dass „JSON-Daten in Oracle Database mit den geläufigen SQL-Datentypen VARCHAR2, CLOB und BLOB gespeichert werden (im Gegensatz zu XML-Daten, die mittels des abstrakten SQL-Datentyps XMLType gespeichert werden).“
Wenn also ein Wert aus dem JSON-Dokument abgerufen werden soll, muss das gesamte JSON-Dokument durchforstet werden, bis die relevanten Daten gefunden wurden. Dieser Ansatz ist langsam. Es gibt zwei Umgehungslösungen, die Oracle empfiehlt, um die Leistung zu steigern. Bei einem sollen die Daten in eine materialisierte Ansicht extrahiert werden, während die Werte in eine andere Tabelle verschoben werden (auch als Shredding bekannt). Bei der anderen Umgehungslösung handelt es sich um einen JSON-Suchindex, der die ACID-Compliance allerdings nicht einhalten kann – er wird nur in periodischen Abständen aktualisiert, wenn er genutzt wird.
Generell sind Multi-Modell-Workloads, die über relationale Datenbanken ausgeführt werden, unflexibel, anfällig oder beides. Sie können zudem nicht nur einfache Herausforderungen, wie das Abfragen von Dokumenten, nur schwer überwinden, sondern relationale Datenbanken können auch nicht von erweiterten Funktionen Gebrauch machen, wie das Verknüpfen von XML- und JSON-Dokumenten. All diese Aufgaben sind mit MarkLogic Server kein Problem.
In der Vergangenheit waren Entwickler oft gezwungen, relationale Datenbanken zu verwenden, da diese so weit verbreitet waren. Wie Jeff Bezos 2018 in seinem Brief an die Aktionäre ausführte, „wurden relationale Datenbanken bei Entwicklern zur ersten Wahl, weil sie alle so mit ihnen vertraut waren, auch wenn diese Technologie nicht ideal war“. Heutzutage haben die Benutzer mehr denn je die Wahl, welche Datenbank sie verwenden möchten, und die Akzeptanzbarriere wird immer niedriger, da Multi-Modells immer beliebter werden.
MarkLogic Server | Oracle Database | |
---|---|---|
Datenmodell |
|
|
Suchen & Abfragen |
|
|
Indizierung |
|
|
Datenintegrität |
|
|
Sicherheit |
|
|
Skalierbarkeit |
|
|
Implementierung |
|
|
Ausgereifte Lösung |
|
|
Dieser Vergleich befasst sich mit den Ähnlichkeiten und Unterschieden zwischen dem MarkLogic Data Hub Service und einem „Cloud Data Hub“ von Oracle. Wie haben dies in Anführungszeichen gesetzt, da Oracle kein vereinheitlichtes Produkt anbietet. Wenn eine Organisation einen Cloud-Hub von Oracle wünscht, muss sie eine Sammlung von Oracle-Cloud-Produkten (oder andere Produkte von Drittanbietern) zusammensetzen, um eine ähnliche Funktionalität zu erreichen.
Hier ist eine Liste mit einigen der Oracle-Produkten, die möglicherweise zusammengesetzt werden müssen, um einen Oracle-„Cloud Data Hub“ zu schaffen:
Der MarkLogic Data Hub Service ist aufgrund der folgenden Vorteile eine bessere Wahl im Vergleich zur Sammlung der Oracle-Produkte:
Mit dem MarkLogic Data Hub Service können Organisationen die großen Schritte der Vorab-Modellierung überspringen, die zum Laden von Daten erforderlich sind. Beim Laden von Daten fügen die Benutzer einfach die Daten hinzu, die ihnen zur Verfügung stehen, um die unmittelbaren Geschäftsanforderungen zu erfüllen. Benutzer können sich wiederholende hierarchische Attribute wie Telefonnummern und Adressen natürlich als JSON- oder XML-Dokumente repräsentieren, ohne dafür gesonderte Tabellen anlegen zu müssen. Da MarkLogic die Daten auch unmittelbar beim Hinzufügen indiziert, sind diese Informationen sofort auffindbar.
Wenn MarkLogic-Benutzer Daten integrieren, bauen sie iterativ ein kanonisches Datenmodell auf, verwalten die Daten, reichern sie mit Metadaten an, fügen Semantik hinzu und steuern den gesamten Prozess. Dadurch lassen sich Datendienste für nachgelagerte Geschäftsanforderungen viel schneller und mit weniger Risiko erstellen, wenn sich die Dinge ändern. Außerdem unterstützt MarkLogic Betriebsanwendungen in Echtzeit – zusätzlich zu den herkömmlichen BI- und Analysefunktionen.
Eine Cloud-Infrastruktur wird rasch bereitgestellt, ist oft komplex und kann ohne entsprechende Überlegungen schnell teuer werden. Es ist wichtig, zu verstehen, welche Faktoren die Kosten bestimmen und wie variabel ein Cloud-Service ist, um eine Kostenexplosion zu verhindern. Verschiedene Dienste gehen sehr unterschiedlich mit einem Burst um (eine überschüssige Nachfrage, die über den normalen vorhergesagten Verbrauch hinausgeht), was wiederum zu großen Abweichungen bei der verbrauchsabhängigen Wirtschaftlichkeit führt.
Der MarkLogic Data Hub Service verwendet ein Verbrauchsmodell, das Preise in drei Kategorien aufteilt:
Der Service berücksichtigt den Kontext beliebiger Workloads beim Hoch- oder Herunterskalieren des Clusters. Betriebs-, Analyse- und Anreicherungs-Workloads werden unabhängig voneinander skaliert, um ein hohes Maß an Zuverlässigkeit und Reaktionsfähigkeit zu gewährleisten. Diese verbrauchsabhängige Preisgestaltung befreit Organisationen vom Druck unvorhersehbarer Ausgaben, die bei komplexen Cloud-Diensten oft anfallen.
Mit dem MarkLogic Data Hub Service ist Skalierung und Bursting einfach und vorhersehbar. MarkLogic verwendet ein System von Übertrags-Minuten, sodass ungenutzte Einheiten gespeichert und auf den nächsten Abrechnungszyklus „übertragen“ werden. Organisationen können maximal das Zwölffache ihrer Kapazität (anstatt nur das Zweifache) speichern und müssen für die Nutzung der bereits bezahlten Credits nicht extra bezahlen. Mit diesem Ansatz vermeiden Organisationen den kostspieligen Fehler, Rückstellungen für den Spitzenbedarf zu bilden, aber sie vermeiden auch, dass die Rechnung außer Kontrolle gerät, wenn dieser Spitzenbedarf eintritt.
Oracle wendet auch einen verbrauchsabhängigen Abrechnungsmodus an und verwendet eigene Cloud Credit Units, genannt OCPUs (Oracle Compute Units). Auch hier müssen Organisationen zusätzlich einen nominalen Satz für Bandbreite und Speicher bezahlen.
Das Set der Cloud-Services von Oracle wird zusammengenommen teurer sein als der MarkLogic Data Hub Service. Dies liegt daran, dass Organisationen einfach mehr Dienste betreiben werden, die eine um Größenordnungen höhere Infrastruktur erfordern (Datenduplizierung, Backup und Wiederherstellung, redundante Indexierung usw.). Organisationen müssen bei jede einzelnen Dienstleistung von Oracle für die Kapazität bezahlen, während Sie bei MarkLogic nur für einen umfassenden Service bezahlen. Die Cloud Credit Units werden etwas willkürlich bestimmt, daher ist es schwierig, exakt zu kalkulieren. Schätzungen zufolge betragen die Kosten für Oracle aber in den meisten Use Cases das Dreifache der Kosten von MarkLogic. Sowohl Organisationen als auch Analysten wissen, dass die Preisgestaltung von Oracle häufig Sorgen bereitet und Organisationen das Risiko eingehen, bei einer überraschend hohen Rechnungsstellung in Zahlungsrückstand zu geraten.
Die oben genannten Kostenunterschiede berücksichtigen noch nicht einmal, wie jeder Dienst mit einem Burst umgeht. Beide Produkte können mit Bursting umgehen, aber bei Oracle ist es unvorhersehbarer, restriktiver und teurer als bei MarkLogic. Bei einem Burst berechnet Oracle den Organisationen überschüssige Kapazitäten nach einem Pay-as-you-go-Prinzip. Dabei beträgt das Limit bei einem Burst die doppelte Kapazität ihres Abonnements (siehe Oracle-Dokumente). Wenn Organisationen ihr Burstlimit überschreiten, benachrichtigt Oracle Cloud sie und sperrt zudem das Konto (siehe Oracle-Dokumente).
MarkLogic ist ein cloud-neutraler Anbieter und ein strategischer Partner der führenden Cloud-Anbieter. Der MarkLogic Data Hub Service fügt sich nahtlos in deren Ökosysteme ein. Anstatt einer weiteren relationalen Datenbank (AWS und Azure verfügen über relationale Datenbanken, die Sie verwenden können), bietet MarkLogic ein sehr differenziertes Produkt, wobei die Kunden die Möglichkeit haben, später bei Bedarf den Cloud-Anbieter zu wechseln.
Oracle dominierte früher den Markt für Datenbanksoftware, aber das ist nicht die Zukunft. Die Zukunft liegt im Cloud-Datenmanagement – nicht gerade die Stärke von Oracle. In einem Artikel in Forbes hieß es: „Nur 2 Prozent [der befragten CIOs] sehen Oracle als ‘ihren ganzheitlichen Anbieter für Cloud-Computing’“.
Die folgende Tabelle vergleicht den MarkLogic Data Hub Service mit der Sammlung von Oracle-Cloud-Komponenten, die für eine ähnliche Funktionalität erforderlich sind.
MarkLogic Data Hub-Service | Oracle-Komponenten „Cloud Data Hub“ * | |
---|---|---|
Zentrale Plattform |
|
|
Zugrunde liegende Datenbank |
|
|
Datenaufnahme |
|
|
Datenanreicherung |
|
|
Datenzugriff |
|
|
Sicherheit & Governance |
|
|
Skalierung |
|
|
Kosten |
|
|
Oracle ist für die Speicherung und Verwaltung traditioneller relationaler Daten konzipiert, die in Zeilen und Spalten modelliert und mit SQL abgefragt werden. Dieser strukturierte Ansatz, kombiniert mit der Allgegenwart von SQL und den Kenntnissen der relationalen Modellierung auf dem Markt, bedeutet, dass Oracle für transaktionale und analytische Anwendungen eingesetzt wird – wofür es gut geeignet ist. Angesichts der langen Geschichte von Oracle als führendes Unternehmen für On-premise-Software verfügen viele Organisationen bereits über Oracle-ELAs. Wenn die Daten vorhersehbar sind, on-premise verwaltet werden und Lizenzen verfügbar sind, ist es sinnvoll, weiterhin Oracle zu verwenden.
Werden die Workloads beim Datenmanagement aber größer, vielfältiger und komplexer – und wenn Organisationen in die Cloud migrieren –, dann ist MarkLogic die bessere Wahl.
MarkLogic ist bei Use Cases rund um die Datenintegration die bessere Wahl als Oracle – insbesondere wenn es sich um große, komplexe Datensätze handelt, die sowohl für Transaktions- als auch für Analysezwecke benötigt werden. Dabei kann es um den Aufbau eines Hub für Use Cases wie 360-Grad-Ansicht von allem, operative Analysen oder Search und Discovery gehen. Wann immer die Daten etwas unordentlich sind und sich schnell ändern, funktionieren sie in einem Data Hub mit einer Multi-Modell-Datenbank besser als in einem RDBMS.
Obwohl MarkLogic keine Option ist, um alle Oracle-Systeme komplett zu ersetzen, kann MarkLogic problemlos Daten von Oracle einlesen. Außerdem unterstützt MarkLogic relationale Ansichten für herkömmliche SQL-Abfragen und eine Ein-Klick-Integration mit führenden BI-Tools. Aus diesen Gründen gibt es viele Organisationen, die Oracle zusammen mit MarkLogic einsetzen, sodass beide Technologien in ihren jeweiligen Bereichen das Beste bieten. Beispielsweise können sie Oracle GoldenGate verwenden, um Daten aus vorgelagerten Oracle-Systemen zu aggregieren, bevor diese in einen MarkLogic Data Hub aufgenommen werden – dies ist ein gängiges Muster. Oftmals ist es sinnvoll, eine vorhandene Oracle-Lizenz zu nutzen, wenn man zum ersten Mal mit MarkLogic arbeitet, auch wenn es längerfristige Pläne gibt, Oracle auslaufen zu lassen.
Hier sind einige spezifische Beispiele, bei denen sich Organisationen ausdrücklich für MarkLogic statt für Oracle entschieden haben:
Virtueller Rundgang: Entkommen Sie der Matrix
In diesem kurzen Rundgang wird näher erläutert, wie ein relationaler Ansatz die Datenintegration behindert und mehr Risiken schafft.
MarkLogic aus der relationalen Perspektive
Diese 3-teilige Blog-Serie, die von einem erfahrenen Ingenieur in der Finanzdienstleistungsbranche geschrieben wurde, beschreibt, warum Organisationen zu Multi-Modellen übergehen, und erklärt einige der Schlüsselkonzepte bei diesem Übergang.
Data Hub-Handbuch für Architekten
Dieses ausführliche eBook erzählt die Geschichte der Datenintegration und die zugrunde liegenden Probleme mit einem relationalen und ETL-gesteuerten Ansatz und wie MarkLogic diese löst.
Mit der Nutzung dieser Webseite stimmen Sie der Verwendung von Cookies gemäß der MarkLogic Datenschutzrichtlinie zu.