Die Oracle Converged Datenbank
Moderne Applikationen stellen immer häufiger höhere und vielfältigere Anforderungen an die verwendeten Datenbanken bzw. Datenhaltungssysteme. Umkreissuche, Übersetzungsdienste, Restaurant- oder Hotelsuche nach speziellen Kategorien sind nur einige Beispiele aus dem eigenen Leben. Im geschäftlichen Kontext gehen diese Anforderungen sogar noch weiter. Echtzeit Analysen mit KI-Algorithmen, Location-Abfragen, unterschiedlichste Arten von Suchen – wie Google-like-Suche oder Facettensuche, um nur einige Beispiele zu nennen.
Eine Möglichkeit, den unterschiedlichen Anforderungen gerecht zu werden, besteht darin, separate Produkte zu haben, die spezielle Modelle für bestimmte Anwendungen verwenden. So haben sich in den letzten Jahren mehr und mehr spezialisierte Datenbanken am Markt etabliert, wie zum Beispiel NoSQL-Datenbanken, Dokument-Datenbanken, semantische Graph-Datenbanken und viele mehr.
Die Oracle-Datenbank hingegen folgt dem Konzept der Converged-Datenbank, um den steigenden Anforderungen unterschiedlicher Applikationen gerecht zu werden. So unterstützt die Oracle-Datenbank unterschiedlichste Datenmodelle – unabhängig vom Workload – und ermöglicht dabei die Verwendung unterschiedlicher Programmiersprachen. Und das alles integriert in eine einzige Datenbank. Oder kurz zusammengefasst: Die Oracle Converged Datenbank ist gekennzeichnet durch die Eigenschaften Multi-Model, Multi-Workload und Multitenant.
Mehrere Single-Model-Datenbanken oder besser gleich Multi-Model
Was sind Single- oder Multi-Model-Datenbanken eigentlich? Single-Model-Datenbanken sind hochspezialisiert auf einen oder wenige Anwendungsfälle und stellen in der Regel nur ein spezielles Datenmodell wie zum Beispiel der Key Value Store oder Triple Store (für Knoten und Kanten) bei Graphen zur Verfügung. Der Zugriff und die Verarbeitung sind spezialisiert auf den Anwendungsfall und erfordern in der Regel gesondertes Programmier- und Framework-Know-how. Multi-Model-Datenbanken hingegen unterstützen, wie der Name schon sagt, mehrere Modelle gleichzeitig in einem einzigen integrierten Datenhaltungssystem. Warum lohnt es sich statt einer Vielzahl von hochspezialisierten Single-Model-Datenbanken für einzelne Anforderungen eine einzige Multi-Model-Datenbank einzusetzen?
Die Verwendung von mehreren Single-Model-Datenbanken erfordert häufig einen hohen Integrationsaufwand und teilweise Duplizierung von Daten. Das Vorhandensein nur eines oder weniger Datenmodelle führt zu erhöhter Komplexität bei der Entwicklung integrierter Anwendungen. Das Fehlen eines einheitlichen und gemeinsamen Betriebskonzepts um beispielsweise die Verfügbarkeit oder einheitliche Sicherheit zu gewährleisten muss bei der Verwendung von mehreren Single-Model-Datenbanken separat implementiert werden.
In der Oracle-Datenbank hingegen können nicht nur relationale Daten, sondern auch verschiedenste heterogene Daten – die strukturiert oder unstrukturiert vorliegen – verwendet werden und sogar in Kombination miteinander abgefragt werden. Die Speicherung von Daten erfolgt entweder über Standard-Datentypen wie CHAR, VARCHAR2 und SECUREFILE für Large Objects oder auch über spezialisierte Datentypen wie XMLTYPE und JSON. Dabei spielt es keine Rolle, ob die Daten innerhalb oder außerhalb der Datenbank auf dem Filesystem oder auf einem preiswerten Object Store gespeichert sind. Mit der Oracle-External-Table-Technologie lässt sich beispielsweise ganz einfach auf Daten die außerhalb der Datenbank gespeichert sind zugreifen. Nur die Metadaten der Tabelle selbst sind in der Datenbank gespeichert. Mittlerweile besteht sogar die Möglichkeit, hybrid partitionierte Tabellen (engl. hybrid partitioned tables) anzulegen. Die Partitionen von hybrid partitionierten Tabellen können dann sowohl in der Oracle-Datenbank in Oracle Tablespaces als auch in externen Quellen vorliegen, wie z. B. CSV-Dateien, Parquet-Dateien oder sonstige Dateien im Hadoop Distributed File System (HDFS). So lassen sich Partitionen, die nicht mehr häufig abgefragt werden, einfach in externe Dateien verschieben, um so eine kostengünstigere Speicherlösung zu verwenden.
Dabei gelten weiterhin die gleichen durchgängigen Oracle-Datenbank-Standard-Konzepte wie ACID-Transaktionen, Multiversion Read Consistency, Nonblocking Queries und Non Escalating Row Locking.
Und nicht zu vergessen: Einheitliche Betriebskonzepte für eine sichere, performante und hochverfügbare Verwendung mit zentralen Schnittstellen und Werkzeugen zum Monitoren und zur Verwaltung gehören ebenfalls standardmäßig zur Ausstattung einer Oracle-Datenbank.
Integrierte Abfragen auf heterogene Datenmodelle mit SQL
Wie kann man heterogene Daten in der Oracle-Datenbank verwenden? Welche Techniken gibt es, um moderne Anforderungen wie Daten-Mining, Sentiment-Analysen, Umkreissuchen oder auch Property-Graph-Kontexte zu nutzen? Wie sehen gemischte Abfragen dabei aus?
Im Folgenden wird konkret an einem Beispiel demonstriert, wie eine komplexe Anfrage auf Daten, die in der Oracle-Datenbank gespeichert sind, realisiert wird. Nicht nur relational gespeicherte Stammdaten sondern auch heterogene und unstrukturierte Daten können hierzu verwendet werden. Das Ziel ist dabei, alles mit SQL – sogar mit einem einzigen Statement – zu erledigen und keine weiteren Sprachen oder Frameworks verwenden zu müssen.
SELECT
c.customer_id,
c.cust_last_name,
c.GENDER
FROM warehouses w,
customers c
WHERE w.warehouse_id = 3 and contains(c.cust_last_name,'!Herschei')>0
and sdo_within_distance (c.cust_geo_location, w.wh_geo_location, 'distance = 500 unit=MILE') = 'TRUE';
Ein Filtering auf Stammdaten (w.warehouse_id = 3) verknüpft mit einer unscharfen Suche nach einem ähnlich klingendem Namen (contains(c.cust_last_name,'!Herschei')>0) sowie eine Umkreissuche (sdo_within_distance (c.cust_geo_location, w.wh_geo_location, 'distance = 500 unit=MILE') = 'TRUE') grenzen die Ergebnismenge ein.
Das Ergebnis sieht dann folgendermaßen aus:
CUSTOMER_ID CUST_LAST_NAME GENDER 181 Hershey F
Die Technologien, die in der Abfrage verwendet werden, sind Oracle Text für die unscharfe Suchanfrage und Oracle Spatial für die Umkreissuche der Location-Anfrage. Grundlage sind spezielle Indizes, die vorab angelegt worden sind.
- Oracle TEXT ist eine in die Datenbank integrierte Volltextrecherche. Über die Standard-Suchfunktionalitäten hinaus, verfügt Oracle Text auch über Textmining-Funktionen wie Klassifizierung, Clustering und Sentiment-Analyse, liefert Thesaurus-Unterstützung und Internationalisierung. Dokumente in unterschiedlichen Formaten wie Word, PDF, PPT etc. werden unterstützt und in nativer Form gespeichert; ein Filter sorgt allerdings dafür, dass eine vorläufige Version in reinem (plain-)Text oder HTML-Version des Dokuments zur Verfügung steht, um dann die Wörter zum Indizieren verwenden zu können. Möchte man Oracle Text ausprobieren, kann man beispielsweise mit einem einfachen Oracle Text Tutorial auf LiveSQL starten [1] oder unseren deutschsprachigen Blog dazu verwenden [2].
- Oracle Spatial und Graph besteht aus Funktionen, Prozeduren, Datentypen und Datenmodellen zur räumlichen und graphischen Analyse. Spezielle Funktionen ermöglichen schnelle und effiziente Speicherungen, Zugriffe und Analysen von räumlichen Daten. Darüber hinaus werden semantische Daten wie Property-Graphen unterstützt, um die Abbildung und die Analyse von hochgradig vernetzten Informationen zu ermöglichen. Für den Einstieg eignet sich das Tutorial "Introduction to Location-Based Analysis Using Spatial Features of Oracle Database" [3]. Auf Github gibt es einen Spatial Workshop, der mit dem Oracle Free Trial verwendet werden kann [4].
Häufig liegen Daten im unstrukturierten JSON- oder XML-Format vor. Auch hier können Informationen aus den Dokumenten mit Standard-Datenbankmitteln abgefragt werden. Dazu gibt es spezielle SQL/JSON- und SQL/XML-Funktionen, mit denen sogar ein "Piecewise Update" auf die Dokumente durchgeführt werden kann. So kann das gezeigte SQL-Beispiel um eine Abfrage auf JSON-Dokumente erweitert werden. Informationen über Produkte sind dabei im JSON-Format und in der Spalte JSON_DOC gespeichert.
SELECT
c.customer_id,
c.cust_last_name,
c.GENDER
P.JSON_DOC.QUANTITY
FROM warehouses w,
customers c,
products p
WHERE w.warehouse_id = 3
and p.json_value(json_doc,’$CUSTNumber’ returning number) = c.customer_id
and contains(c.cust_last_name,'!Herschei')>0
and sdo_within_distance (c.cust_geo_location, w.wh_geo_location, 'distance = 500 unit=MILE') = 'TRUE';
Mit einfacher Punktnotation (P.JSON_DOC.QUANTITY) werden im Beispiel die JSON-Inhalte selektiert. Auch mit der SQL/JSON-Funktion JSON_VALUE können JSON-Inhalte (hier die CUSTNumber) extrahiert werden. Zusätzliche Indizes für effiziente JSON-Dokument-Zugriffe werden auf diese Weise definiert. Mit einem speziellen Index – dem sogenannte DataGuide – können sogar Informationen über die Struktur und den Inhalt der gespeicherten JSON-Dokumente ermittelt werden. Damit lassen sich schnell relationale Views erzeugen und sogar Volltextsuchen durchführen. Interessant für Oracle-Spatial-Nutzer ist auch die Möglichkeit, aus gespeicherten Geometrien das Format GeoJSON zu generieren und somit zur Speicherung ein leicht lesbares offenes Format zur Verfügung zu haben. Umgekehrt können aus GeoJSON-Informationen, Oracle-Spatial-Daten generiert werden. Codebeispiele gibt es auch auf Github [5] oder in der Code Library auf LiveSQL (Suchwort: JSON).
Die verwendeten Technologien stehen out-of-the-box ohne zusätzliche Installation zur Verfügung. Alle Abfragen funktionieren gleichermaßen unabhängig von der eingesetzten Oracle-Datenbank-Installation – wie Cloud- oder On-premise-Installationen. Auch die Verwendung von speziellen Verarbeitungstechnologien wie Real Application Clusters, In-Memory für den Zugriff auf den Column Store, Parallelisierung, Komprimierung, Verschlüsselung oder Multitenant kann transparent stattfinden. Beim Entwickeln muss keine Änderung an den SQL-Abfragen durchgeführt werden. Keine Kenntnisse der darunterliegenden Strukturen sind erforderlich.
Lowcode Web-Entwicklung mit APEX
Jetzt fehlt nur noch eine Schnittstelle, um möglichst einfach und schnell eine Web-Anwendung zu programmieren, die auch für den mobilen Einsatz geeignet ist. Hier kann Oracle Application Express (APEX) die Lösung sein. APEX ist eine Lowcode-App-Development-Plattform, die in allen Datenbank und Cloud-Editionen kostenlos enthalten ist. Mit wenigen SQL-Kenntnissen können sichere und skalierbare Anwendungen einfach und schnell programmiert werden. Das gesamte APEX-Konzept ist dabei deklarativ. Es handelt sich um einen repository-basierten Ansatz zur Generierung einer beliebigen Web-Anwendung, ohne eine einzige Zeile Code für die Benutzeroberfläche, die Controller-Logik oder die Grundfunktionalität zu erzeugen. Natürlich können auch hier alle genannten Technologien wie z. B. Text, Spatial, JSON und XML ohne Einschränkung verwendet werden. Tutorials und weitere Informationen dazu finden sich bei APEX [6].
Nur SQL oder auch polyglott?
Der Zugriff kann nicht nur über SQL erfolgen, sondern auch andere Frameworks und APIs können nahtlos eingebunden werden. Für das Zusammenspiel mit der Oracle-Datenbank existieren nämlich APIs und Schnittstellen für alle am Markt relevanten Frameworks und Programmiersprachen wie REST, Python, PHP, Java etc. Oracle liefert dabei den passenden Treiber direkt wie z. B. bei Java, .NET und C aus oder stellt Open-Source-Treiber auch über Partner zur Verfügung. So kann beispielsweise Phyton über cx_Oracle oder Node.js über node-oracldb verwendet werden.
Aber es gibt noch weitere Schnittstellen. Protokoll-Zugriffe wie HTTP, TCP und ftp werden mit vorgefertigten Oracle-Funktionen zur Verfügung gestellt. Möchte man mit REST-Anbindungen arbeiten, ist Oracle Data Rest Services (ORDS) die geeignete Schnittstelle. Hiermit können über Standard-HTTP-Aufrufe wie GET|POST|PUT|DELETE|HEAD SQL-Abfragen oder Stored Procedure Calls an die Datenbank gestellt werden. Das Ergebnis wird dann in JSON-Format ausgeliefert.
Die SODA-(Simple Oracle Document Access)-API ist eine Schnittstelle, die es ermöglicht, schemaless schnell und einfach Documentstore-Anwendungen in Oracle-Datenbanken zu entwickeln. Developer finden sich intuitiv zurecht.
Die SODA-API ist eine Schnittstelle, die es erlaubt, die Oracle-Datenbank wie eine Document Database – schemaless und mit einer NoSQL-like Abfragsprache zu verwenden. Die Daten werden also nicht auf eine oder mehrere relationale Tabellen (mit anwendungsspezifischen Spalten) abgebildet. Stattdessen werden Business-Objekte als JSON-Dokument in einer sogenannten Collection abgelegt. Collections sind einfache systemgenerierte Tabellen (mit Spalten für JSON-Inhalte, eine ID und weitere Metadaten), auf der die SODA-Schnittstelle mit CRUD-(Create, Read, Update und Delete)-Operationen und Filter-Anfragen einfach möglich ist. Documentstore-Entwickler werden sich intuitiv zurechtfinden. SODA ist Programmiersprachen unabhängig: es gibt Treiber für REST, Java, JavaScript (nodeJS), Python, PL/SQL und C. Zusätzlich existiert der volle SQL-Zugriff, falls der CRUD-Zugriff nicht ausreichen sollte.
Folgende Beispiele im Werkzeug SQL Developer Web, einer REST-enabled Applikation, die mit ORDS verfügbar ist, demonstrieren die einfache Verwendung:
Erzeugen einer Collection
soda create cities;
Successfully created collection: cities
Einfügen von JSON Dokumenten
soda insert cities {"name": "San Jose","population":1021795,"county":"Santa Clara"};
Json String inserted successfully.
Filtern des Dokuments mit bestimmter Eigenschaft
soda get cities -f {"county":"Fulton"};
Key: B391694FE65446CE9159D4D5299B52F8
Content: {"name":"Atlanta","population":506811,"county":["Fulton","DeKalb"]}
-----------------------------------------
1 row selected.
Damit ist eine moderne JSON-basierte Entwicklung mit der Oracle-Datenbank als Document Database möglich, die sehr einfach in der Anwendung ist. Der neue Cloud-Service Autonomous JSON Database, der auf der bewährten Autonomous-Datenbank-Infrastruktur basiert, richtet sich dabei an Entwickler, die JSON-basierte Applikationen mit einer einfachen API (z. B. mit SODA) erstellen wollen und nicht auf die Möglichkeiten von SQL verzichten wollen. Die Entscheidung, welches Modell – relational oder Documentstore – man verwenden möchte, bleibt dabei dem Programmierer überlassen.
Unterstützung unterschiedlicher Workloads
Nicht nur unterschiedliche Modelle sondern auch die verschiedensten Arten von Workloads müssen von der Converged Database unterstützt werden. Dabei geht es nicht nur um die Standard Workloads wie OLTP und DWH, die gemeinsam verwendet werden können. Seit der Einführung des Column Stores mit der In-Memory-Funktionalität sind keine separaten In-Memory-Datenbanken/Stores mehr zur Beschleunigung von analytischen Abfragen erforderlich. Zusätzlich sind innerhalb der Oracle-Datenbank eine Vielzahl leistungsfähiger Data-Mining- und Machine-Learning-Algorithmen implementiert. Diese können direkt auf Daten angewendet werden, ohne diese erst in ein geeignetes ML-System importieren zu müssen. Data Scientists können dabei wie gewohnt in Notebooks mit den Algorithmen arbeiten.
Für Big-Data-Anwendungen kann die Datenbank sogar direkt auf preiswerten Object Storage verschiedener Cloud-Anbieter zugreifen. Auch Workloads wie High-Speed Data Ingestion für IoT-Anwendungen sowie die Verwendung von Blockchain-Tabellen sind mit der Oracle Converged Datenbank möglich. Somit können Oracle-Anwender auch diese Workloads betreiben, ohne ihre Datenlandschaft durch zusätzliche Spezial-Datenbanken weiter fragmentieren zu müssen.
Multitenant und Microservices – eine perfekte Ergänzung
Was ist die Antwort auf Anwendungen, die aus den bekannten Gründen Microservices verwenden – um beispielsweise parallel und unabhängig zu arbeiten und Continuous Delivery zu gewährleisten? Bei der Verwendung von Microservices geht es nicht nur um die Verwendung von Docker-Containern, sondern jeder Microservice kann sogar in einem eigenen Container eine eigene Datenbank und ein eigenes Datenmodell besitzen. Wie bei der Verwendung von Single-Model-Datenbanken sind hoher Aufwand und Komplexität bei der Verwaltung der Services, und Fehlen von einheitlichen Konzepten für Security und Backup charakteristisch. Und nicht nur das: Wie steht es um Transaktionen, die über mehrere Services hinweg funktionieren sollen?
Die Oracle-Multitenant-Architektur liefert eine Lösung für den Microservice-Ansatz. Die Multitenant-Architektur besteht dabei aus Datenbank-Containern (Pluggable Databases), die sich gemeinsam nutzbare Prozesse und Speicherbereiche teilen. Jeder Microservice kann seine eigene Pluggable Database (PDB) mit eigenem Datenmodell haben. Der Root-Container übernimmt das gesamte Infrastrukturmanagement. Das Credo "Manage many databases as one" ist einer der großen Vorteile der Verwendung dieser Architektur. So können Datenbank-Clones schnell und einfach erzeugt oder wieder verworfen werden und somit für das Deployment einer neuen Test-Datenbank in einer CI/CD-Pipeline genutzt werden. Sichere Trennung der Daten, transaktionale Abfragen über PDBs hinweg sind weitere Punkte, die das Multitenant-Konzept auszeichnen.
Oracle Converged Datenbank ausprobieren
Neben der klassischen Installation auf unterschiedlichen Plattformen ist auch der Betrieb unter Docker (Docker Images) möglich. Der Einsatz ist allerdings eher im Test- und Entwicklungsbereich als im unternehmenskritischen Anwendungsgebiet zu finden.
Aber es gibt auch die Möglichkeit, ohne eine eigene Installation auf eine Oracle-Datenbank zuzugreifen. LiveSQL beispielsweise ist ein kostenloser Online-Service, um SQL mit einer Oracle-Datenbank auszuprobieren. Man benötigt nur einen Webbrowser und einen OTN Account und schon kann man starten [7]. Tutorials mit Code Snippets helfen dabei bestimmte Techniken zu erlernen. Eine andere Möglichkeit ist, Workshops im Rahmen der LiveLabs [8] auszuprobieren. Mit Oracle LiveLabs kann man die Oracle-Datenbank in der Oracle-Cloud nutzen, ohne einen eigenen Oracle-Cloud-Tenant zu erstellen. Die Nutzung von LiveLabs ist zudem völlig kostenlos. Um einen Workshop zu reservieren, genügt es, sich einfach mit dem Oracle-Account anzumelden und Datum und Uhrzeit des Workshops anzugeben.
Darüberhinaus gibt es im Rahmen der Oracle Cloud Always Free Services die Möglichkeit, eine eigene kostenlose Autonomous Oracle Database zu provisionieren. Sie ist in wenigen Minuten über ein paar Klicks erstellt und steht sofort zur Anwendung zur Verfügung.
Fazit
Mit der Oracle Converged Datenbank lassen sich alle Arten von Daten speichern und verarbeiten – ob strukturiert oder unstrukturiert – völlig unabhängig von der Art des Workloads. Auch die Kombination von unterschiedlichen Arten von Abfragen ist ohne Weiteres möglich. Die Vorteile liegen dabei auf der Hand: Die Verwendung einer einheitlichen Sprache wie zum Beispiel SQL, zentrales Monitoring, einheitliches Tooling und Anwendung von einheitlichen Backupkonzepten, Performance und Sicherheitmechanismen. Keinerlei Integration von verschiedenen Technologien ist erforderlich. Die Speicherung der Daten kann dabei den unterschiedlichsten Anforderungen genügen – innerhalb oder außerhalb der Datenbank oder auch gemischt in hybrider Form. Die Auswahl an Programmiersprachen und Schnittstellen um auf die Oracle-Datenbank zuzugreifen, ist dabei groß. Also einfach einmal ausprobieren!