MLTV now live! New videos, new content hub.

Überblick

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:

  • Unternehmen müssen flexibel sein, um Daten zu integrieren, eine einheitliche Sicht auf Informationen zu erhalten und schnell dauerhafte Datenbestände zu liefern. Organisationen können nicht Monate oder Jahre warten, bis Daten integriert sind
  • Organisationen müssen Kosten senken – auch bei der Entwicklungszeit für neue Systeme und Anwendungen und der Zeit, die für die Verwaltung der Infrastruktur aufgewendet wird. Auf ihrem Weg in die Cloud müssen Organisationen die Cloud-Kosten kontrollieren
  • Organisationen müssen Sicherheit und Governance verbessern, um den Datenaustausch zu vereinfachen. Organisationen haben keine Zeit für das Flicken von Datensilos und Schatten-IT. Sie müssen ihre Daten während des gesamten Integrations-Lebenszyklus proaktiv verwalten

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:

  1. Oracle und MarkLogic haben grundlegend unterschiedliche Datenmodelle (relationales im Vergleich zu Multi-Modell)
  2. Oracle und MarkLogic verfolgen grundlegend unterschiedliche Ansätze für die Indizierung und den Datenzugriff (relationale Indizierung und SQL im Vergleich zur universellen, suchgesteuerten Indizierung im Multi-Modell-Ansatz von MarkLogic)
  3. Oracle und MarkLogic skalieren sehr unterschiedlich (Scale-Up-System im Vergleich zum verteilten Scale-Out-System von MarkLogic)
  4. Oracle und MarkLogic haben sehr unterschiedliche Ansätze zur Datenintegration in der Cloud (Suite traditioneller relationaler Produkte mit einem hohen Wartungsaufwand im Gegensatz zum vereinheitlichten, agilen Ansatz von MarkLogic mit wenig Abstimmung und Wartung)

Was ist Oracle?

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.

Die wichtigsten Produktlinien von Oracle

  • Oracle Database 19c – Oracle 19c, veröffentlicht im Jahr 2019, ist die neueste Version der ursprünglichen relationalen Oracle-Datenbank und das Flaggschiff unter den Angeboten für On-premise-Umgebungen. Oracle bezeichnet die Version 19c als die Version mit langfristiger Unterstützung oder „Terminal-Patch“-Version, da es sich um die letzte Version der Oracle 12c-Produktfamilie handelt, zu der Oracle 18c gehört. Es ist auch möglich, sie als ein speziell entwickeltes System unter Verwendung von Oracle Exadata zu betreiben.
  • Oracle Autonomous Database – Erstmals verfügbar 2018; ist das Cloud-Service-Angebot von Oracle. Obwohl es auf der Oracle-Datenbank ausgeführt wird, wird es als eine separate Produktfamilie gebaut und vermarktet. Die Benutzer können zwischen zwei Optionen wählen: Oracle Autonomous Data Warehouse für die Datenanalyse und Oracle Autonomous Transaction Processing für die Verarbeitung gemischter Aufgaben.

Weitere Oracle-Datenbankprodukte (Software und Cloud)

  • Oracle NoSQL Database – Eine Key-Value-Datenbank (eine zweispaltige relationale Datenbank, die so konzipiert ist, dass nur der Primärschlüssel abgefragt wird), die im Jahr 2018 den nativen JSON-Support hinzugefügt hat. Open-Source-Datenbanken wie Redis bieten ähnliche Funktionalität und dasselbe Datenmodell.
  • Oracle NoSQL Datenbase Cloud Service – Vollständig verwalteter Dienst mit ähnlichen Funktionen wie die oben erwähnte On-premise-Version. Sie kam im März 2019 auf den Markt.
  • Oracle Berkeley DB – Enthält Oracle Berkeley DB XML zum Speichern und Abfragen von XML-Dokumenten mit XQuery. Diese stammt aus der Übernahme von Sleepycat, wurde zuletzt 2017 aktualisiert und hat einen kleinen Kundenstamm. Es ist keine Cloud-Service-Version verfügbar.
  • Oracle XML DB (Cloud-Service-Fähigkeit) – XML-Speicherung und -Abfrage hinzugefügt im Mai 2019, viele Funktionen nicht verfügbar. Siehe Oracle-Dokumente für Informationen zu Aktualisierungen.
  • Oracle Spatial and Graph – Eine Option für 19c, dazu gehört die Fähigkeit, RDF-Tripel zu speichern und Wissensgraphen zu erstellen. Darunter werden die Tripel in relationalen Tabellen gespeichert.
  • Oracle Spatial and Graph (Cloud-Service-Funktionalität) – Weitere Funktionalität wurde im Laufe der Zeit hinzugefügt. Siehe Oracle-Dokumente für Informationen zu Aktualisierungen.
  • Oracle Text – Eine Option für 19c, mit der Möglichkeit, Volltextindizes zu erstellen und dann mit Standard-SQL zu suchen und zu analysieren
  • Oracle Text (Cloud-Service-Fähigkeit) – Volltextsuche hinzugefügt im Mai 2019. Viele Legacy-Funktionen sind nicht verfügbar. Siehe Oracle-Dokumente für Informationen zu Aktualisierungen.
  • Oracle TimesTen In-Memory Database – Die relationale In-Memory-Datenbank von Oracle, ähnlich wie Redis, SAP HANA oder MemSQL. Da sie im Speicher ausgeführt werden, dienen diese Datenbanken als ausgezeichnete Caching-Ebenen. Oracle verkauft sie auch als speziell entwickeltes System namens Exalytics.
  • MySQL RDBMS – Wird als Community- und Enterprise-Edition angeboten und wurde 2010 in die Produktlinie von Oracle aufgenommen, als diese Sun Microsystems übernahmen.
  • Oracle Big Data Appliances and Connectors – Oracle vertreibt auch mehrere Produkte für Kunden, die ihre Oracle-Bestände mit Tools wie Hadoop integrieren möchten, um diese zu verbinden und auf Daten zugreifen zu können, die möglicherweise nicht direkt in Oracle gespeichert sind.

Weitere Datenintegrationsprodukte von Oracle

  • Oracle Fusion Middleware – Software, die für die On-premise-SOA-Integration mit ESBs entwickelt wurde. Im Großen und Ganzen eine Zusammenstellung von Produkten aus Akquisitionen.
  • Oracle Golden Gate – Software für die Erfassung, Verteilung, Umwandlung und Bereitstellung von Änderungsdaten. Wird oft für Echtzeit-Datenflüsse von operativen zu analytischen Systemen verwendet. Auch als Cloud-Service verfügbar.
  • Oracle Data Integrator Cloud Service – Als Teil von Oracles neuerer Suite von Cloud-Produkten ist dies eine Software für traditionelle ETL-Arbeiten, jedoch in Cloud-Umgebungen. Auch als Cloud-Service verfügbar.
  • Weiterer Big Data Cloud Service – Cloud-Dienst für Datenanalysen mit Hadoop und Spark

Was ist MarkLogic?

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.

Was ist der Unterschied zwischen MarkLogic und Oracle?

Es gibt zwei Möglichkeiten, MarkLogic mit Oracle zu vergleichen:

  1. MarkLogic Server im Vergleich zur Oracle-Datenbank – Der Schwerpunkt dieses Vergleichs liegt auf dem Datenmodell. MarkLogic hat einen Multi-Modell-Ansatz und Oracle einen relationalen Ansatz. Alles in allem bietet Oracle eine fantastische relationale Datenbank. Für Organisationen, die eine relationale Datenbank benötigen und sich dem Oracle-Ökosystem verbunden fühlen, ist es eine gute Wahl. Aber für Organisationen, die Flexibilität benötigen, um Daten aus Silos zu integrieren, hat der Multi-Modell-Ansatz von MarkLogic einige deutliche Vorteile. Dies wird weiter unten ausführlicher erklärt (darunter auch die Frage, warum Oracles jüngste Behauptungen, ein Multi-Modell zu sein, etwas vermissen lassen).
  2. Suite von Oracle Cloud-Diensten zum Erstellen eines „Data Hub“ im Vergleich zum MarkLogic Data Hub Service – Wenn Sie bei der Datenintegration in der Cloud eine ähnliche Funktionalität wie mit dem MarkLogic Data Hub Service erreichen wollen, benötigen Sie Oracle Autonomous Database in Kombination mit anderen Tools, wie Oracle Data Integrator Cloud Service, Oracle GoldenGate Cloud Service, Oracle NoSQL-Database Service und andere Dienste. Unabhängig von der Umgebung stoßen Organisationen jedoch immer noch auf die zugrundeliegenden Probleme von relationalen im Gegensatz zu Multi-Modell-Datenbanken.
    1. Beachten Sie, dass Oracle zwar ein „Data Hub Service“-Produkt hatte, das i2017 angekündigt wurde, das aber vom Unternehmen nicht mehr vermarktet wird.
    2. Beachten Sie auch, dass Sie einen MarkLogic Data Hub on-premise ausführen können, und der Vergleich ist sehr ähnlich. In diesem Fall benötigen Organisationen immer noch eine große Suite von Oracle-Produkten wie die Oracle NoSQL-Datenbank, Berkeley XML DB, Oracle Spatial and Graph, ETL-Tools wie GoldenGate und andere große Datentools, die der Funktionalität des MarkLogic Data Hub entsprechen.

MarkLogic- mit Oracle-Datenbanken 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:

  • Flexibler Umgang mit sich ständig ändernden Daten und Schemata und die Fähigkeit, Schemata beim Lesen zu erstellen und mehrere Schemata zu verarbeiten (im Gegensatz zur Notwendigkeit, Ihr striktes Schema im Voraus zu definieren)
  • Reichhaltigere Darstellung Ihrer Geschäftseinheiten und dadurch reichhaltigere Abfragen und Anwendungen (im Gegensatz zur Notwendigkeit, Ihre Entitäten im Kontext strenger relationaler Schemata definieren zu müssen)
  • Beseitigung von Datensilos (im Gegensatz zur Anforderung einer neuen Datenbank für jede neue Anwendung)
  • Agile Datenintegration und -anreicherung (im Gegensatz zu langwieriger ETL und Upfront-Datenmodellierung)
  • Allgemeine Vereinfachung Ihrer Datenarchitektur (im Gegensatz zur Notwendigkeit, verschiedene Datenbanken miteinander zu verknüpfen; mit anderen Worten: Polyglot-Persistenz)

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.

Ist Oracle eine Multi-Modell-Datenbank?

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.

Datenbank-Vergleichstabelle

MarkLogic Server Oracle Database
Datenmodell
  • Multi-Modell
  • Native JSON-, XML- und RDF-Speicherung
  • Speicherung von Geodaten und Abfrage relationaler Ansichten
  • Relational. Eingeschränkte Unterstützung für Multi-Modell
  • Speichert Daten in Tabellen
  • Keine native JSON- oder RDF-Unterstützung
Suchen & Abfragen
  • Umfangreiche Abfragefunktionen, einschließlich SQL
  • JavaScript, XQuery, SPARQL, SQL
  • Schnelle Ergebnisse über strukturierte und unstrukturierte Daten
  • Nahtlos integrierte Volltextsuche
  • Nur SQL-Abfragen
  • Schnelle Ergebnisse, aber nur über strukturierte Daten
  • Suche ist ein Add-On, das sich zum Indizieren, Suchen und Analysieren auf SQL stützt; die Indizes sind asynchron
Indizierung
  • Leistungsstarker universeller Index
  • Indiziert Wörter, Sätze, Struktur, Sprachen usw. für die Volltextsuche
  • Fast keine Wartung
  • Relationale Indizes, Abstimmung erforderlich
  • Indiziert Spalten in Tabellen
  • Erheblicher Wartungsaufwand
Datenintegrität
  • 100 % ACID-Transaktionen
  • 100 % ACID-Transaktionen
Sicherheit
  • Unternehmenssicherheit
  • Granulare Sicherheit über strukturierte und unstrukturierte Daten
  • Zertifiziert
  • Unternehmenssicherheit
  • Granulare Sicherheit über strukturierte Daten
  • Zertifiziert
Skalierbarkeit
  • Scale-out-Architektur
  • Automatisches Sharding und Neuausbalancieren
  • Daten gleichmäßig über Knoten verteilt
  • Hochverfügbarkeit und Disaster Recovery
  • Monolithische, skalierbare Architektur
  • Kompliziert, erfordert möglicherweise Abspaltung/Sharding/Wartung und ist wahrscheinlich teuer
Implementierung
  • Jede Umgebung
  • Selbstverwaltete Cloud-, Hybrid- und On-premise-Systeme auf handelsüblicher Hardware
  • Mehr als 10 Jahre Erfahrung in der Cloud
  • Unterstützung für AWS- und Azure-Bereitstellung mit Bildern und Marktplatzeinträgen
  • Jede Umgebung
  • Evtl. neue ELA für neue Umgebungen erforderlich
  • Zur Nutzung von Cloud-Diensten ist eine Portierung der Daten erforderlich
Ausgereifte Lösung
  • Ausgereifteste moderne Datenbank
  • Erstmals veröffentlicht im Jahr 2002
  • Ausgereifteste relationale Datenbank
  • Erstmals veröffentlicht im Jahr 1979

Data Hubs von MarkLogic mit Oracle vergleichen

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:

  • Oracle Autonomous Database – Oracle-Datenbank optimiert für OLAP
  • Oracle Autonomous Transaction Processing – Oracle-Datenbank optimiert für OLTP
  • Oracle Spatial and Graph – Geodaten/Abfrage und etwas Unterstützung für RDF-Graphenspeicherung
  • Oracle Text – Volltextsuche
  • Oracle NoSQL Cloud Service – Bietet Unterstützung für JSON
  • Oracle XML DB – XML-Speicherung und -Abfrage
  • Oracle GoldenGate Cloud Service – Operational Data Store, einige Konvertierungsfunktionen
  • Oracle Data Integrator Cloud Services – ETL-Pipelines und Verbindungen
  • Weiterer Big Data Cloud Service – Datenanalysen mit Hadoop und Spark

Warum ist MarkLogic die bessere Option für Cloud-Services?

Der MarkLogic Data Hub Service ist aufgrund der folgenden Vorteile eine bessere Wahl im Vergleich zur Sammlung der Oracle-Produkte:

  • MarkLogic hilft Organisationen, Daten 10-mal schneller mit einem modernen, agilen Ansatz zu integrieren (im Gegensatz zu einem traditionellen Ansatz mit viel Vorab-Modellierung)
  • MarkLogic ist flexibler (Multi-Modell im Gegensatz zu relationaler Basis) und besser für die Speicherung von Dokumenten und Tripeln optimiert
  • MarkLogic ist einfacher und schneller zu implementieren, zu betreiben und zu warten (1 Produkt im Vergleich zu einer Handvoll von Oracle-Produkten)
  • MarkLogic ist kostengünstiger und transparenter (wer will schon eine weitere Oracle-ELA?). Es gibt zahlreiche Beispiele von Kunden, die Millionen von Dollar sparen, weil sie sich für MarkLogic entschieden haben (lesen Sie zum Beispiel die Fallstudie Chevron)

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.

Cloud-Verbrauch

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.

Cloud-Verbrauchsmodell von MarkLogic

Der MarkLogic Data Hub Service verwendet ein Verbrauchsmodell, das Preise in drei Kategorien aufteilt:

  1. Bandbreite – Preis in $/TB
  2. Speicherung – Preis in $/GB/Monat
  3. Rechenleistung – Preis in $/MCU/Stunde

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.

Cloud-Verbrauchsmodell von Oracle

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).

Die Zukunft der Cloud

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’“.

Cloud-Vergleichstabelle

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
  • Ja
  • Einheitliche, konsistente Echtzeit-Ansicht aller Daten
  • Synchrone Indizierung
  • Nein
  • Verbindung mehrerer Produkte erforderlich
  • Indizes müssen produktübergreifend synchronisiert werden
Zugrunde liegende Datenbank
  • MarkLogic Server
  • Native Unterstützung von Multi-Modell-Datenbanken für JSON, XML, RDF, Geodaten, Volltext
  • Weitere Informationen finden Sie im vorherigen Vergleich
  • Oracle-Datenbank 19c
  • Relationale Datenbank mit eingeschränkter Unterstützung für Multi-Modell
  • Weitere Informationen finden Sie im vorherigen Vergleich
Datenaufnahme
  • Laden in jedem beliebigen Format
  • Rohdaten-Aufnahme, mit sofortiger Indexierung
  • Traditionelles ETL
  • Aufnahme mit ETL-Tool, signifikante Schema-Modellierung vorab erforderlich
Datenanreicherung
  • Agiler Ansatz
  • Iterativer Prozess der Datenharmonisierung
  • Smart Mastering in der Datenbank für die meisten MDM-Funktionen
  • Vollständige Herkunfts- und Abstammungsverfolgung
  • Wasserfall-Ansatz
  • Datenverlust während ETL-Prozessen
  • Separate, komplexe Handhabung von Metadaten, semantischen und unstrukturierten Daten
  • Separates MDM-Werkzeug für Mastering erforderlich
Datenzugriff
  • Schneller Zugriff auf alle Daten
  • Optimiert zur Abfrage mehrfach strukturierter Daten
  • Agile Prozesse liefern Datendienste 10-mal schneller
  • Offene APIs und Standard-Abfragesprachen (JavaScript, XQuery, SPARQL, SQL)
  • SQL-Abfragen zu strukturierten Daten
  • Optimiert für SQL-Abfragen
  • Wartezeit bei langwierigen ETL-Prozessen, um Daten auf die Abfrage vorzubereiten
  • Leistungsprobleme bei Abfrage von Dokumentdaten
Sicherheit & Governance
  • Hohe Sicherheit für Unternehmen
  • Kampferprobte Sicherheit über strukturierte und unstrukturierte Daten
  • Hohe Sicherheit für Unternehmen
  • Kampferprobte Sicherheit über strukturierte Daten
Skalierung
  • Automatisierte Elastizität
  • Automatische und unabhängige Skalierung von Knoten für Anreicherung, Abläufe und Analyse
  • Kostenloses automatisches Bursting, bis zum Zwölffachen der Basis-Kapazität
  • Automatisierte Elastizität
  • Auto-Skalierung für die Datenbank, kann aber bei anderen Diensten variieren und sehr teuer sein
Kosten
  • Niedrige, vorhersehbare Kosten
  • Bezahlung für eine Dienstleistung
  • Burst führt nicht zu Kostensteigerungen
  • Teuer, unvorhersehbar
  • Bezahlung für mehrere Dienstleistungen
  • Überschüsse werden nach dem Pay-as-you-go-Prinzip bis zum Zweifachen der Basis-Kapazität gezahlt

Wann Oracle anstatt MarkLogic verwendet werden sollte

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.

Wann MarkLogic anstatt Oracle verwendet werden sollte

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.

Kunden, die sich für MarkLogic statt für Oracle entscheiden

Hier sind einige spezifische Beispiele, bei denen sich Organisationen ausdrücklich für MarkLogic statt für Oracle entschieden haben:

  • Chevron – Der „Asset 360“ Data Hub von MarkLogic bietet eine einheitliche Ansicht auf Raffineriedaten, einschließlich Anlagen, Ausrüstung und anderer Informationen, um Sicherheit und Effizienz zu gewährleisten. Der Chief Architect meinte: „Wenn Sie versuchen würden, Tausende von Dingen in einer relationalen Struktur zu modellieren, würden Sie sich wirklich schwer tun. Mit diesem Format und dieser Datenverwaltung können wir ein Problem der Stammdatenverwaltung lösen, das mich seit Jahren beschäftigt.“
  • ABN Amro – MarkLogic bietet Echtzeit-Analyse von mehr als 40 Millionen Handelsdatensätzen. Der Principal Architect der Bank sagte: „Wir müssen in der Lage sein, sofort auf sich ändernde regulatorische Anforderungen zu reagieren. Ausschlaggebend für die Entscheidung für MarkLogic waren die Vorteile der Plattform bei der Verwaltung von Handelsdaten in relationalen Datenbanken.
  • HealthCare.gov – MarkLogic bietet Versicherungen für über 10 Millionen Amerikaner, die gleichzeitig 280.000 Benutzer und 6.500 Transaktionen pro Sekunde bearbeiten. Laut Dr. Stephen Parente ist dies „das größte Regierungsprojekt zur Integration personenbezogener Daten in der Geschichte der USA.“ (Vergleichen Sie auch unseren Erfolg mit dem Misserfolg von Oracle in Oregon)
  • L.A.-Care – MarkLogic unterstützt die Genauigkeit, Validierung, Analyse, Berichterstellung und Veröffentlichung von Anbieterdaten. Der Chief Digital Officer erklärt: „Wir haben festgestellt, dass die Effizienz mit der Technologie von MarkLogic 10-mal höher ist, sowohl in Bezug auf den Wettbewerb auf dem Markt als auch in Bezug auf Kosten und Lieferung. Damit sind wir wirklich zufrieden“.

Mehr erfahren

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.

Anmeldung zu unserer Live-Demo

Erfahren Sie, wie MarkLogic Daten schneller integriert, Kosten reduziert und einen sicheren Datenaustausch ermöglicht.

Jetzt Registrieren

Auf dieser Website werden Cookies verwendet.

Mit der Nutzung dieser Webseite stimmen Sie der Verwendung von Cookies gemäß der MarkLogic Datenschutzrichtlinie zu.