Data Lakes, Data Hubs, Federation: Which One Is Best?

Unabhängig aus welcher Branche Sie kommen, Sie werden höchstwahrscheinlich noch mit Data-Silos arbeiten. Und diese Silos bremsen Ihr Unternehmen.

Manchmal entpuppen sich Daten-Silos als Problem. Teams können dann simple Fragen nicht schnell und einfach beantworten, weil die Daten in zwei oder mehreren Systemen liegen. Manchmal verhindern fragmentierte und inkompatible Daten auch Innovationen. Dann wird aber nicht den Silos die Schuld gegeben, sondern oftmals der IT.

Leider ist die Integration von Daten zur Zusammenführung von Silos eine komplexe Angelegenheit. Es gibt keine „Zauberformel“, um unterschiedliche Daten einfach zu integrieren. Aber es gibt neue Technologien, die dieses Vorhaben erleichtern.

In diesem Blog gehe ich auf drei neuere Ansätze ein: virtuelle Datenbanken (auch als Datenbank-„Federation“ oder „Zusammenführung“ bezeichnet), Data Lakes und Data Hubs. Im folgenden werde ich erklären, worin sie sich unterschieden und die Vor- und Nachteile des jeweiligen Konzpetes aufzeigen.

MarkLogic unterstützt alle drei (Data Lakes, Data Hubs, virtuelle Datenbanken) in unterschiedlichem Umfang, aber wir bevorzugen Data Hubs. Daher werde ich auch erklären, warum Hubs die beste Lösung sind und wie genau MarkLogic diesen Ansatz unterstützt. Aber selbst wenn Sie keinen Data Hub entwickeln oder MarkLogic nicht verwenden, bin ich überzeugt, dass dieser Blog für Sie aufschlussreich sein wird.


Traditionelle Methode: umfassendes Enterprise Modeling

Traditionelle Methode: umfassendes Enterprise Modeling

Zuerst ein paar Worte zum herkömmlichen Ansatz. Viele IT Abteilungen haben früher (und manche machen das auch noch heute) neue Enterprise-Datenmodelle entwickelt, die jedes Feld und jeden Wert des bestehenden Unternehmens übergreifend über alle Silos abdecken und dann jeden Silo diesem neuen Modell in einem neuen Data Warehouse mit ETL Jobs per Mapping zuordnen.

ITBusinessEdge hat Unternehmen befragt und herausgefunden, dass solche Aufgaben wie vorher beschrieben, bei allen Befragten das Budget überschritten wurde oder das Projekt nicht den gewünschten Erfolg brachte.

Sprechen wir jetzt lieber über virtuelle Datenbanken, Data Lakes und Data Hubs, die jeder für sich genommen dieses Problem auf neue Weise zu lösen veruchen.


Definitionen: virtuelle Datenbanken, Data Lakes und Data Hubs

Definieren wir zuerst die Begriffe.

Virtuelle Datenbank

Eine virtuelle Datenbank ist ein System, das Anfragen annimmt und vorgibt, eine große Datenbank zu sein, die viele unterschiedliche Datenbestände und Silos umfasst. Tatsächlich stellt diese Datenbank in Echtzeit eine Anfrage beim Backend-System (live, Produktion oder Warehouse) und wandet die Daten für die Anfrage in ein allgemeines Format um.Man spricht hier auch von einer „Federated“ oder virtuellen Datenbank und die Subsysteme werden als „Federates“ bezeichnet.

Man spricht hier auch von einer „Federated“-Datenbank und die Subsysteme werden als „Federates“ bezeichnet.

Data Lake

Der Begriff „Data Lake“ stammt aus der Hadoop Community und wird auf verschiedene Weise definiert. Im weitesten Sinne erhalten Sie einen Data Lake, wenn Sie all Ihre Daten von getrennten Silos in ein System (Hadoop/HDFS) verlagern. Die Daten müssen nicht harmonisiert, indiziert, durchsuchbar oder einfach verwendbar gemacht werden. Aber zumindest müssen Sie so nicht jedes Mal eine Verbindung zu einem Live-System aufbauen.

Data Hub

Ein Data Hub ist ein Hub-and-Spoke-Ansatz für die Datenintegration, bei dem die Daten physisch in ein neues System gelangen und erneut indiziert werden. Vom Data Lake unterscheidet sich ein Data Hub darin, dass dieses System Discovery, Indizierung und Analytik unterstützt.


Bewegung, Harmonisierung und Indizierung

Ich gehe davon aus, dass wir diese drei dahingehend unterscheiden können, wie und wann (und ob überhaupt) eine Bewegung, Harmonisierung und Indizierung der Daten erfolgt. Weitere Definitionen im Folgenden.

Ich verwende die Begriffe „Bewegung“, „Harmonisierung“ und „Indizierung“ im Folgenden als Fachbegriffe und möchte an dieser Stelle darauf hinweisen, dass es sich hierbei um die drei Hauptkonzepte handelt, die Lakes, Hubs und virteuelle Datenbanken unterscheiden.

Datenbewegung

Hubs und Lakes bewegen beide Daten. Die Daten stammen aus Silos und werden auf andere Festplatten kopiert und von anderen Servern oder anderer Software weiter verarbeitet. Festplattenspeicher ist heutzutage relativ günstig. Die operativen (und organisatorischen) Vorteile sind enorm, wenn nicht bei jeder Suchanfrage auf den Produktionsserver zugegriffen werden muss.

Virtuelle Datenbanken (Federations) greifen dagegen bei jeder Abfrage auf das Quellsystem zu. Die Daten werden also nicht bewegt und bleiben in den Silos.

Datenharmonisierung

Hubs und Federations harmonisieren Daten (wobei Federations dies nur dann tun, wenn die Daten zurückgegeben oder verarbeitet werden). Die Daten sind in unterschiedlichen Formaten mit verschiedenen Feldnamen und Schemata in den verschiedenen Silos gespeichert. Sie müssen aber zumindest ähnlich aussehen, um als Gruppe verarbeitet werden zu können. Die Harmonisierung lässt sich in drei Kategorien unterteilen:

  1. Unterschiedliche Namen: Am einfachsten sind Namensunterschiede zu bewältigen, wenn verschiedene Silos einen identischen Wert mit identischer Bedeutung haben, aber einen anderen Namen verwenden. Beispiel: „PERSON.Vorname“ und „IDENTITÄT.VORNAME“ in zwei verschiedenen relationalen Datenbanktabellen –, die aber die gleiche Art von Daten enthalten.
  2. Unterschiedliche Strukturen: Etwas schwieriger als unterschiedliche Namen sind strukturelle Unterschiede, wenn sich die Anzahl und Kombination der Felder von Silo zu Silo unterscheiden. Beispiel, „verfügbare_Kisten“: in einem System kann das der Gesamtzahl der Kisten im Lager entsprechen, zu der der Wert aus einem Feld namens „jede_Kiste_zählen“ hinzugerechnet wird, um die Gesamtzahl der Artikel zu ermitteln, was in einem anderen System dem Feld „alle_Artikel“ entspricht. Dazu kommt, das eine System kann den verfügbaren Bestand als noch nicht zur Erfüllung offener Bestellungen ausweisen, während im anderen System der gesamte physische Bestand unabhängig von offenen Bestellungen angegeben wird.
  3. Semantische Unterschiede: Diese sind am schlimmsten. Das eine System kann z. B. drei Statusangaben für Patienten verwenden, ein anderes fünf. Diese Statusangaben überschneiden sich oft und lassen sich nur schwer gegenseitig zuweisen.

Progressive Harmonisierung für mehr Agilität

Letztlich müssen gut strukturierte, dokumentierte APIs oder Datenexporte kohärente Daten in einer festgelegten Form liefern. Diese Harmonisierung kann und sollte agil und progressiv sein.

In der Regel werden die Hauptanforderungen frühzeitig erkannt und die Datenelemente als „kritische Datenelemente“ definiert und zuerst harmonisiert. Im Lauf der Zeit kommen weitere Anforderungen hinzu, die zur Harmonisierung von immer mehr Daten führen. Ich bezeichne diese Harmonisierung kritischer Daten als „Teilharmonisierung“. Wird die zu harmonisierende Teilmenge mit der Zeit erhöht, handelt es sich um sich um eine „progressive“ Harmonisierung.

MarkLogic ist besonders in diesem Bereich sehr gut, da der MarkLogic Server die Struktur der Daten von Quellsystemen in harmonisierter Form und im Rohdatenformat indiziert. Das bedeutet, dass einige Suchen und weiter Verarbeitung im Data-Lake-Stil erfolgen können, aber wichtige Daten indiziert werden und darauf in harmonisierter Form zugegriffen wird.

Indizierung

Was die Ansätze letztlich definiert und unterscheidet, ist die Art und Weise, wie die Indizierung der Daten erfolgt. Eine Indizierung erlaubt schnelle Suchabfragen und Analysen jedes indizierten Feldes. Indexe werden auf Festplatten geschrieben und den Datenfeldern übergeordnet. Dadurch entscheidet die Art und Weise, wie Daten bewegt und harmonisiert werden, über deren Indizierungsformen.

  • Federated (virtuelle) Datenbanken verfügen über keine Indizierung oder getrennte Datenspeicherung, die überhaupt indiziert werden könnte. Sie müssen sich darauf verlassen, dass die verschiedenen Silos und Quellsysteme eine geeignete Indizierung bieten. Mit dem Map-Verfahren ordnen sie jede Anfrage jedem Quellsystem zu und führen diese bei allen Quellsystemen aus.
  • Data Lakes nehmen eine Indizierung nur in äußerst geringem Umfang vor. Wenn sie einen Index anlegen, geschieht dies durch die Integration zusätzlicher Komponenten, um Teile getrennt zu indizieren – wie kleinere Data Marts, SOLR-Textindexe, HBase-Tabellen mit Indexen usw.
  • Data Hubs bewegen alle Daten an eine Stelle, harmonisieren diese teilweise – oder vollständig – und indizieren dann die Daten in deren harmonisierter Form. Das ist ideal, weil sich die nützlichsten Indexe nur auf Grundlage von harmonisierten Daten erstellen lassen.

Wie man sich das Leben schwer macht...

Zweifellos ist es sehr schwer, Daten zu aggregieren, zu finden oder zu analysieren, wenn die Daten unterschiedlich benannt sind, grundlegend anders strukturiert sind, semantische Unterschiede aufweisen oder nicht indiziert sind. Sie oder Ihre Entwickler müssen für diese Unterschiede einen Workaround in irgendeiner Form finden. Aber wenn Sie dabei nicht umsichtig vorgehen, werden Sie alles verschlimmbessern – und erhalten am Ende Berge von Code, den Sie nicht in den Griff bekommen und der über viele Berichte, Batch-Prozesse und ETL-Jobs verteilt ist.


Zusammenfassung der Unterschiede

Es gibt also drei Ansätze und drei Kriterien, um diese zu unterscheiden. Die folgende Tabelle zeigt die drei Ansätze und wie sich diese in Bezug auf jedes Kriterium verhalten:

Ansätze Werden Daten bewegt? Werden Daten harmonisiert? Werden Daten indiziert?
Virtuelle Datenban (Federation) Nein. Die Daten bleiben in den Silos. Alles erfolgt zum Zeitpunkt der Abfrage. Keine Indizierung. Abfragen werden an die Quellsysteme weitergeleitet.
Data Lakes Ja. Die Daten werden an einen anderen Ort bewegt, aber im Quellformat belassen. In gewisser Hinsicht ja. Data-Lake-Analysen und Reporting-Code müssen innerhalb der Logik des Berichts implizit harmonisiert werden, um Zusammenfassungen oder die Korrelation ähnlicher Felder zu ermöglichen.

Dadurch ist jeder Algorithmus oder jeder ETL-Prozess für die unterschiedlichen Datenformate auf seine sehr eigene Weise zuständig.

Nur in sehr geringen Umfang. Es is schwer, Daten zu indizieren, wenn es viele inkompatible Formate gibt.
Data Hub Ja, die Daten werden an eine zentrale Stelle bewegt. Ja. Die Daten werden (zumindest teilweise) beim Bewegen harmonisiert. Ja. Die Daten werden in der harmonisierten Form indiziert, damit Zugriff und Analyse effizient erfolgen.

Auswirkungen der einzelnen Modelle

Dies ergibt sich größtenteils aus den Unterschieden der Ansätze. Aber wie man so schön sagt: Der Teufel steckt im Detail.

Deshalb werde ich auf einige Folgen dieser Unterschiede eingehen, um zu zeigen, was jeder Ansatz in der Praxis bedeutet, und darlegen, warum Data Hubs die beste Lösung sind.

Auswirkungen auf Virtuellen Datenbanken (Federation)

Da virtuelle Datenbanken bei Abfragen sich auf die Quellsysteme verlassen müssen, werden sie durch die Kapazitäten und Verfügbarkeit dieser Quellsysteme beschränkt.

Kleinster gemeinsamer Nenner: Wenn ein Quellsystem oder ein Silo eine Abfrage nicht unterstützt – weil diese Abfrage nach in einem bestimmten Feld sucht oder ordnet, nach Geodaten bzw. Koordinaten sucht, eine Textsuche durchführt oder benutzerdefinierte Relevanzbewertungen umfasst – kann dieses Gesamtsystem das nicht unterstützen. Das bedeutet auch, dass jedes neu hinzugefügte System später tatsächlich die Gesamtkapazität der Federation verschlechtert als es verbessert.

Erneutes Mapping von Abfragen: Das große Manko einer virtuellen Federated-Datenbank ist, dass jede Abfrage an das Gesamtsystem in viele verschiedene Abfragen oder Anfragen umgewandelt werden muss – und zwar eine pro Federated-Silo oder Subsystem. Das sorgt für zusätzliche Entwicklungsarbeit und bindet das Federated-System eng an die Silos.

Echtzeitdaten: Das ist ein Vorteil der Federation. Sie brauchen weder Mechanismen zum Erkennen von Änderungen noch müssen Sie diese implementieren, sollten sie fehlen. Mein Argument: Wenn Ihre verschiedenen Quellen und Silos nicht herausfinden können, was sich innerhalb einer Stunde, eines Tages oder nach einem bestimmten Zeitplan geändert hat, ist das ein grundlegendes Problem. Andererseits fragen Federated-Systeme immer Live-Daten ab und arbeiten somit immer in Echtzeit, auch wenn Veränderungen im Quellsystem nicht erkannt werden können.

Operative Isolation: Federated-Systeme fallen aus, wenn ein Federate-Mitglied ausfällt. Oder sie erfordern einen komplexen Code und Benutzerinteraktionen für Teilabfragen in einem Degraded-Zustand. Oft haben Live-Quellsysteme nicht die Kapazität für selbst minimale Echtzeitabfragen und weniger wichtige Batch-Prozesse, sodass die virtuelle Federated-Datenbank erfolgskritische vorgeschaltete Systeme zum Erliegen.

Diese Grafik veranschaulicht, wie die bedarfsorientierte Harmonisierung bei einer Federation funktioniert.

Virtuelles - Federated Modell

Virtuelle (Federated-) Datenbanken nehmen die gesamte Harmonisierung in Echtzeit vor. Dadurch ermöglichen sie zwar Web Services in Echtzeit für Geschäftsprozesse, sind in der Regel aber nicht skalierbar, um Batch-Verarbeitungen oder Analytics zu unterstützen. Sie können einige Geschäftsabläufe mit einer Federated-Datenbank betreiben, müssen aber genau darauf achten, die Systeme nicht zu überlasten.

Fazit – meine Meinung über virtuelle Federated-Datenbanken:

Selbst wenn Sie den Abfrageprozess geschickt auf zehn verschiedene Systeme verteilen, bleiben es weiterhin zehn Systeme, die bei Abfragen involviert sind.


Auswirkungen von Data Lakes

Operative Isolation: Data Lakes sind besser als Federated-Systeme, weil sie eine operative Isolation bieten, indem die Daten in eine separate Infrastruktur bewegt werden. Dies ist wohl ihr Hauptvorteil.

Abfrage: Data Lakes nehmen weder eine Indizierung noch eine Harmonisierung der Daten vor. Auch sind die Indexe des Quellsystems nicht im Data Lake verfügbar. Folglich bietet ein Data Lake per se noch schlechtere Abfragekapazitäten als eine virtuelle Federated-Datenbank.

Batch-Verarbeitung: Data Lakes (und Hadoop-Systeme im Allgemeinen) brillieren bei der Batch-Verarbeitung und Predictive Analytics. Wenn Sie bereit sind, jeden Datensatz um jeden Preis zu laden und zu verarbeiten, brauchen Sie keine intelligenten Abfragefunktionen und können einen Workaround für die fehlende Indizierung finden.

Vereinfachung und Verwaltung: Weil Daten in verschiedenen Formaten in einem Data Lake vorliegen, wird eine komplexe Logik für jeden Batch-Prozess, ETL- oder Analyse-Job benötigt. Dieser Code gerät schnell außer Kontrolle oder veraltet– und wird damit zur Belastung.

Virtuelles - Federated Modell

Data Lakes erfordern Batch Analytics, um mit einer Brute-Force-Methode Daten während der Analyse zu verarbeiten. Gleiches gilt für die Batch-Verarbeitung von ETL-Jobs, um unterschiedliche Datenformate in ein neues Formular zu laden. Sie eignen sich generell besser für die Datenanalytik oder das Gewinnen von Einblicken als für die Echtzeitverarbeitung. Mit einem Data Lake erhalten Sie einen „Blick auf Ihr Unternehmen“, aber Sie können damit wegen ihrer analytischen bzw. Batch-Natur keine operativen Prozesse unterstützen.

Da Data Lakes somit zusätzliche ETL-Aufgaben mit sich bringen, harmonisieren sie tatsächlich die Daten und bewegen sie in einen Data Hub, das aber ohne die transaktionalen Echtzeitkapazitäten, die der eigentliche Geschäftsbetrieb erfordert.

Fazit – meine Meinung über Data Lakes:

Wenn das Zimmer Ihres Kindes aussieht, als hätte eine Bombe eingeschlagen, und Ihr Kind dann nur alles irgendwie in den Schrank stopft und die Tür gerade noch zubekommt, ist dann das Kinderzimmer wirklich aufgeräumt? Oder herrscht immer noch Chaos, nur an einer zentralen Stelle?

Auswirkungen von Data Hubs

Abfrage: Data Hubs pflegen eigene Indexe – und bauen diese Indexe über harmonisierte Daten auf. Zur Erinnerung: Die Harmonisierung kann ein progressiver, agiler Prozess sein. Wächst also der Umfang der harmonisierten Daten, wird die Indizierung leistungsstärker.

Andere Systeme müssen dagegen als Standard bei der Indizierung und Abfrage mindestens einen „kleinsten gemeinsamen Nenner“ aufweisen. Abfragen werden bei einer Federation nur unterstütz, wenn auch das schwächste System in dieser Federation diese unterstützt. Analytische oder Reporting-Prozesse können bei einem Data Lake nur dann unterstützt werden, wenn der Code mit dem am wenigsten kompatiblen Datenquellen im Lake zurechtkommt.

Anders ausgedrückt: Abfragen werden vom leistungsschwächsten System oder Datenquelle ohne Harmonisierung und Indizierung bestimmt, aber bei einem Data Hub kann die Abfragefunktionalität selbst die Leistung des besten Systems übertreffen, weil die Indexe auf harmonisierten Daten basieren.

Bei MarkLogic ist die Indizierung von Feldern, XML-Strukturen, JSON-Strukturen, Text, semantischen RDF-Daten und Geodaten bereits vorkonfiguriert. Binäre Daten werden ebenfalls gespeichert, wobei Text und binäre Metadaten aus Formaten wie Word-Dateien, PDFs, JPEGs und anderen extrahiert werden. Das ist ein Grund, warum MarkLogic meistens zum Data Hub rät.

Operative Isolation: Wie bei einem Data Lake bewegt ein Data Hub Daten auf separate Festplatten und in eine gesonderte Infrastruktur. Dadurch erfolgt das Laden und Management isoliert von den Quellsystemen.

Batch-Verarbeitung: Wie bei einem Data Lake können Sie bei einem Hub bei Bedarf viele Datensätze abfragen und verarbeiten. Im Gegensatz zu einem Data Lake erlauben Data Hubs indexgesteuerte Abfragen, um die für jeglichen Zweck verarbeitete Datenmenge zu begrenzen. Dies ermöglicht auch schnelle Suchabfragen und Datenkombinationen bei Batch-Jobs ohne „Sub-Batch“, um relevante, zugehörige Datensätze zu finden.

Vereinfachung und Verwaltbarkeit: Da die Daten in einem Data Hub zumindest teilharmonisiert sind, können Sie für alle Daten einen gemeinsamen Code verwenden. Beim Aufbau eines Inventars kann der harmonisierte Datenbestand z. B. ein harmonisiertes Feld „verfügbareEinheiten“ unabhängig davon aufweisen, aus welchen inkompatiblen Quellsystemen die Daten stammen. Die harmonisierten Felder werden indiziert und vereinheitlicht, was den Zugriff auf die Bestandsinformationen erheblich vereinfacht.

Discovery und Exploration: Ad-hoc- oder unerwartete Analysen kann ein Data Hub einfach unterstützten. Durch Bewegen der Daten an eine zentrale Stelle und Harmonisieren der wichtigen Datenelemente, wird die „Schwerstarbeit“ während des Bewegens und Indizierens erledigt. Das vereinfacht Abfragen, Interaktion, Filter und Drill-down der Daten bei Bedarf.

Erneutes Mapping von Abfragen: Data Hubs vermeiden ein erneutes Mapping von Abfragen bei jedem Quellsystem, indem die Daten zuerst harmonisiert werden und dann ein einheitlicher Datenbestand indiziert wird. Beachten Sie dabei, dass die Harmonisierung die Ist-Kosten der Entwicklung deutlich sinken lässt, da sie nicht mit einem System arbeiten können, das Daten aus allen Quellen in einem anderen Format liefert– alle Ansätze müssen irgendwann harmonisieren (selbst eigens entwickelter Code in jedem Bericht). Durch Indizieren und Speichern nach erfolgter Harmonisierung ermöglichen Data Hubs simple, einheitliche Abfragen.

Traditionelle Methode: umfassendes Enterprise Modeling

Data Hubs verfügen über indizierte, abfragbare Daten in einer gemeinsamen Form, wodurch sie Web Services, Echtzeitanwendungen, Batch-Verarbeitung und auch Analytics ermöglichen. Insbesondere wegen der Echtzeit-Services können Sie mit einem Data Hub operative Geschäftsprozesse unterstützen.

Fazit – meine Meinung über Data Hubs:

Bauen Sie eine Data Hub auf. Denn das ist der leistungsstärkste Ansatz und er ist am einfachsten zu entwickeln und zu pflegen.


Überzeugende Argumente für MarkLogic

Ich hoffe, dass all diese unabhängig von Ihrem jetzigen Ansatz oder der letztlich gewählten Architektur für Sie nützlich sind.

Während MarkLogic Server Data Lakes und Federations unterstützt, sind Hubs unserer Erfahrung nach die beste Option, nachdem wir über ein Jahrzehnt Funktionen dafür entwickelt haben.

Zu diesen Funktionen gehören:

Universal-Index: MarkLogic akzeptiert die Daten „as is“, um sie zu speichern und zu indizieren. Wir nutzen die bereits in gängigen Datensatzformaten wie XML, JSON und RDF vorhandene Struktur und indizieren diese Struktur automatisch (ohne Coding).

Hochgradig skalierbar:  MarkLogic is per se (und transparent!) als Cluster konstruiert und verwendet Reverse-Indexe. Dadurch ist MarkLogic wie eine Suchmaschine horizontal sklaierbar – statt vertikal wie die meisten anderen Datenbanklösungen.

Big Data Gesamtbetriebskosten: Da gewaltige Datenmengen integriert und verfügbar werden, bewegt MarkLogic automatisch ältere oder weniger wichtige Daten in billige Speicherlösungen wie HDFS oder S3, damit hohe Rechenleistung und Kosten in einem vernünftigen Verhältnis stehen.

Erstklassige Sicherheit: Das Auflösen von Daten-Silos ist für jede Art von Unternehmen wichtig, weil es den Zugriff auf Daten einfacher macht... leider aber auch den Datendiebstahl. MarkLogic bietet marktführende Sicherheitsfunktionen wie z. B. Rollen- und Abteilungs-basierend.

Flexible Services: MarkLogic liefert eine suchfähige REST API zur Abfrage oder Anpassung integrierter Daten. Sie können beliebige Datentransformationen anwenden, damit alle Clients und APIs die integrierten Daten im richtigen Format erhalten. In der Regel sind dies verschiedene JSON-, XML-, RDF- und CSV-Formate.

Textsuche: MarkLogic indiziert alle Wörter gemäß Ihrer Datenbankkonfiguration. Es gibt u.a. Funktionen wie Wortstammerkennung, Phrasensuche, tf/idf-Relevanz, Abfragen wie „and/or/not/near“, Wortzerlegung und verschiedene Sprachen-Pakete.

Abfrage von Geodaten: Je mehr Daten Sie integrieren, desto mehr Möglichkeiten brauchen Sie, um darauf zuzugreifen. Allein in der vorkonfigurierten Fassung unterstützt MarkLogic mehr Geodaten als andere Lösungen, einschließlich Abfragen nach Längen- und Breitengrad mit Punkten und Polygonen.

Interested in Learning More?

Operational Data Hubs: A series of short video tutorials, averaging 15 min each, that guides you through to create a data hub.