DE102020113545A1

DE102020113545A1 - Verfahren, vorrichtungen, systeme und erzeugnisse zum bereitstellen von abfrageauswahlsystemen

Info

Publication number: DE102020113545A1
Application number: DE102020113545.9A
Authority: DE
Inventors: Luis Carlos Maria Remis; Justin Gottschlich; Javier Sebastian Turek; Ignacio Javier Alvarez; David Israel Gonzalez Aguirre; Javier Felip Leon
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2019-06-28
Filing date: 2020-05-19
Publication date: 2020-12-31
Also published as: US20190325292A1; US12008456B2

Abstract

Es werden Verfahren, Vorrichtungen, Systeme und Erzeugnisse zum Bereitstellen von Abfrageauswahlsystemen offenbart. Ein beispielhaftes Abfrageauswahlsystem enthält einen Prozessor für Folgendes: Analysieren einer Graphdatenbank; Identifizieren jeweiliger der Graphdatenbank zugeordneter Objekte; Beziehen von den Objekten zugeordneten Eigenschaften; Identifizieren gemeinsamer, in den jeweiligen Objekten vorhandener Eigenschaften; als Antwort auf das Bestimmen der gemeinsamen, in den identifizierten Objekten vorhandenen Eigenschaften Ausgeben einer Liste der gemeinsamen, mit den jeweiligen Objekten korrespondierenden Eigenschaften; Generieren einer Tabelle für die gemeinsamen Eigenschaften und die jeweiligen Objekte; und Auffüllen der Tabelle mit den gemeinsamen Eigenschaften und den jeweiligen Objekten aus der Graphdatenbank, um eine relationale Datenbank einzurichten. Das System enthält ferner einen Machine-Learning-Modellklassifikator zum Ermöglichen des Suchens durch Abfragen relationaler Datenbanken über die relationale Datenbank.

Description

GEBIET DER OFFENBARUNG
Diese Offenbarung betrifft allgemein die Codeentwicklung und insbesondere Verfahren, Vorrichtungen, Systeme und Erzeugnisse zum Bereitstellen von Abfrageauswahlsystemen.
ALLGEMEINER STAND DER TECHNIK
Anwendungen, die auf einer Plattform wie einem Personal Computer (PC), einem Server oder einem Tablet ausgeführt werden, machen von bestimmten Datenstrukturen zur vereinfachten Datenmanipulation Gebrauch. Um eine Benutzerabfrage zu ermöglichen, verwenden Plattformen oft nur ein Datenmodell, zum Beispiel ein Graphenmodell oder ein relationales Modell. Graphenmodelle ermöglichen zum Beispiel die Abfrage von Informationen aus einer visuellen Verarbeitung, und relationale Datenbanken ermöglichen die Abfrage von Informationen durch Iterieren über Eigenschaften von Objekten, die als Spalten und Zeilen in einer Tabelle repräsentiert sind.
Figurenliste

1 ist ein Blockschema eines beispielhaften, gemäß Lehren dieser Offenbarung aufgebauten Abfrageauswahlsystems zum Auswählen zwischen mehreren Abfrage-Engines.
2 ist ein Blockschema eines beispielhaften Abfrageklassifikators des beispielhaften Abfrageauswahlsystems aus 1 zum Auswählen zwischen mehreren Abfrage-Engines.
3 ist ein Blockschema eines beispielhaften Hybriddatenbankgenerators des beispielhaften Abfrageauswahlsystems aus 1 zum Generieren einer relationalen Datenbank aus Informationen, die aus einer Graphdatenbank bezogen werden.
4 ist ein Ablaufschema, das für maschinenlesbare Befehle, die zum Implementieren des beispielhaften Abfrageauswahlsystems aus 1 ausgeführt werden können, repräsentativ ist.
5 ist ein Ablaufschema, das für maschinenlesbare Befehle, die zum Implementieren eines beispielhaften Abfrageklassifikators des beispielhaften Abfrageauswahlsystems aus 1 ausgeführt werden können, repräsentativ ist.
6 ist ein Ablaufschema, das für maschinenlesbare Befehle, die zum Implementieren eines beispielhaften Modelltrainers des beispielhaften Abfrageauswahlsystems aus 1 zum Trainieren eines Machine-Learning-Modells ausgeführt werden können, repräsentativ ist.
7 ist ein Ablaufschema, das für maschinenlesbare Befehle, die zum Erstellen einer beispielhaften relationalen Datenbank des beispielhaften Abfrageauswahlsystems aus 1 aus Informationen, die aus einer Graphdatenbank bezogen werden, ausgeführt werden können, repräsentativ ist.
8A ist eine schematische Darstellung, die ein beispielhaftes relationales Modell mit unterschiedlichen Beziehungen darstellt.
8B ist eine schematische Darstellung, die ein beispielhaftes Graphenmodell darstellt.
9 ist eine schematische Darstellung, die ein beispielhaftes relationales Modell darstellt.
10 ist ein Blockschema einer beispielhaften Verarbeitungsplattform, die so strukturiert ist, dass die Befehle aus den 4-7 zur Implementierung des beispielhaften Abfrageauswahlsystems aus 1 ausgeführt werden.

AUSFÜHRLICHE BESCHREIBUNG
Der Gebrauch und sonst die Auswahl einer bestimmten Datenstruktur haben Auswirkungen auf eine Performance-Metrik einer in einer Plattform ausgeführten Anwendung. Performance-Metriken sind unter anderem der von der Datenstruktur verbrauchte Speicherplatz, die Geschwindigkeit, mit der die Datenstruktur Daten transferieren (z. B. lesen oder schreiben) und/oder modifizieren kann, oder die Anzahl der Zyklen des Computerprozessors (CPU), die bei (einer) bestimmten Speicheroperation(en) durchlaufen werden. Performance-Metriken, die dem von der Anwendung verbrauchten Speicherplatz zugeordnet sind, sind beispielsweise immer dann wichtig, wenn die Anwendung in einer Geräteplattform mit endlich viel Speicherplatz betrieben wird. Demgegenüber sind Performance-Metriken, die der Geschwindigkeit, mit der Daten transferiert werden können, zugeordnet sind, immer dann wichtig, wenn die Anwendung relativ große Datenmengen in Echtzeit verarbeitet. In wiederum anderen Beispielen ermöglicht der Datenstrukturtyp einer sortierten Liste, dass Datensätze relativ schnell abgerufen werden können, jedoch lassen sich mit diesem Datenstrukturtyp Elemente erheblich langsamer abspeichern.
Um Datenabfragen zu ermöglichen, verwenden einige Plattformen oder elektronische Geräte unterschiedliche Datenbanktypen, um Daten in einem durchsuchbaren Format zu ordnen. Einige Plattformen verwenden zum Beispiel eine graphenorientierte Datenbank. Bei Graphen handelt es sich typischerweise um eine natürliche Repräsentation von Daten oder Informationen, die aus einer visuellen Verarbeitung stammen können. Um Aussagen oder Informationen aus einer Graphdatenbank zu extrahieren, wird oft eine Graphabfragesprache verwendet. Einige beispielhafte Graphabfragesprachen sind so konzipiert, dass sie von Benutzern einfach les- und verstehbar sind, da sie die Art und Weise nachahmen, in der ein Benutzer intuitiv Abfragen unter Nutzung von Diagrammen in der Art von Whiteboard-Diagrammen beschreiben würde. Einige beispielhafte Plattformen verwenden eine relationale Datenbank. Relationale Datenbanken repräsentieren Daten oder Informationen, die in Tabellenform (z. B. als Tabelle mit Spalten und Zeilen) geordnet sind.
Graphdatenbanken bieten bislang eine im Vergleich zu relationalen Datenbanken geringe Performance. Tabellen sind in ihrer Art sequenziell, daher eignen sich relationale Datenbanken besonders gut für aufeinanderfolgende Lese- und Schreibzugriffe auf rotierende Festplatten und sind unter solchen zugrundeliegenden Hardware-Bedingungen oft performanter als Graphdatenbanken. Da aber aufgrund neuer Speichertechnologien (Solid State Drives, Intel Optane© etc.) derzeit die Latenzlücke zwischen sequenziellen und wahlfreien Zugriffen immer kleiner wird, werden Graphdatenbanken für bestimmte Abfragearten zunehmend attraktiv. Hinsichtlich der Speichertechnik gibt es zwei Datenbankzugriffsmuster: (1) den wahlfreien Zugriff; und (2) den sequenziellen Zugriff.
Bei einem wahlfreien Zugriff kann durch Beziehungen auf unterschiedliche Eigenschaften unterschiedlicher Objekte zugegriffen werden. Hierbei handelt es sich um die typische Art des Zugriffs auf zufällige Teile von Daten. Hierfür beispielhafte Abfragen sind etwa „erstelle eine Liste der am meisten verkauften Produkte der Bereiche in einem Einzelhandelsgeschäft, die Kunde A bereits aufgesucht hat“ oder „erstelle eine Liste von Hirnscans, die mit Patienten, die über 75 Jahre alt sind und eine Chemotherapie mit dem Medikament X bekommen haben, korrespondieren“. In diesen Beispielen erfolgen wahlfreie Zugriffe, da diese Abfragetypen die Untersuchung von Beziehungen zwischen Objekten erfordern. Wenn die Informationen unter Nutzung eines relationalen Modells ausgedrückt sind, muss auf unterschiedliche Tabellen zugegriffen werden, um die nötigen Informationen zu beziehen. 8A veranschaulicht beispielhaft ein relationales Modell (das z. B. Beziehungen zwischen Objekten ausdrückt).
8A veranschaulicht beispielhaft, wie verknüpfte Informationen unter Nutzung eines relationalen Modells 800 repräsentiert und abgespeichert werden. Das relationale Modell 800 enthält eine Kauftabelle 802, eine Kundentabelle 804 und eine Produkttabelle 806, die über Fremdschlüssel 808, 810 miteinander verknüpft sind. Wenn die Abfrage in diesem Beispiel darauf abzielt, welche Produkte „Alice“ am häufigsten gekauft hat, greift eine Abfrage-Engine auf die Kauftabelle 802, die Kundentabelle 804 und die Produkttabelle 806 (z. B. drei unterschiedliche Tabellen) zu. Die Beziehungen zwischen den Tabellen 802-806 werden durch die Fremdschlüssel 808 und 810 in der Kauftabelle 802, der Kundentabelle 804 und der Produkttabelle 806 ausgedrückt. In der Kauftabelle 802 stehen beispielhaft (z. B. in jeder Zeile) die Fremdschlüssel 808 und 810, um anzuzeigen, welcher Kunde (z. B. Kunden-ID) einen Kauf getätigt hat. Um zu bestimmen, welcher Kunde (z. B. Kunden-ID) welches Produkt (z. B. Produkt-ID) gekauft hat, wird entweder sowohl auf die Kundentabelle 804 als auch auf die Produkttabelle 806 zugegriffen oder sie werden beide ausgelesen, was im relationalen Modell 800 eine rechen- und/oder zeitaufwendige Operation sein kann.
8B stellt Daten aus 8A in einem Graphenmodell 801 dar. Genauer enthält 8B eine abstrakte Repräsentation von Informationen 803 im Graphenmodell 801 und eine mit ihr korrespondierende Speicherrepräsentation 805. Das Durchsuchen des Graphenmodells 801 schließt ein, dass ein Knoten 807 durchsucht wird und benachbarte Knoten 809, die über eine oder mehrere Verknüpfungen 811 mit dem Knoten 807 verknüpft sind, geprüft werden. Eine Abfrage, die enthält, „welche Produkte Alice am häufigsten gekauft hat“, schließt zum Beispiel ein, dass ein mit „Alice“ korrespondierender Knoten 807a durchsucht wird und die benachbarten Knoten 809a, 809b, die über eine „Kauf“-Verbindung der -Verknüpfung 811a mit dem Alice-Knoten 807a verknüpft sind, geprüft werden. In einem Graphenmodell (z. B. im Graphenmodell 801) ist die Performance von Abfragen, die Beziehungen einschließen, besser, wodurch Kostensenkungen und/oder Zeiteinsparungen möglich werden.
Bei einem sequenziellen Zugriff kann hingegen auf Eigenschaften von Objekten in derselben Kategorie zugegriffen werden. Hierbei wird typischerweise auf sehr große Datenmengen sequenziell zugegriffen. Hierfür beispielhafte Abfragen sind etwa „ermittle das Durchschnittsgehalt aller Mitarbeiter in einem Unternehmen“ oder „ermittle die häufigste Autofarbe“. Diese Beispiele schließen sequenzielle Zugriffsmuster ein. Ein weiteres Charakteristikum derartiger Abfragen besteht darin, dass sie gewöhnlich auf spezielle Eigenschaften aller Objekte von einem bestimmten Typ (etwa die Farbe aller Autos oder das Alter jeder Person) zugreifen. Diese Abfragen nutzen keine Informationen über die Beziehungen zwischen Objekten von unterschiedlichen Typen. Bei derartigen Abfragen, die auf Beziehungen basieren, ist die Performance des relationalen Modells, das Tabellen zur Repräsentation von Informationen nutzt, am besten. Da die Informationen in Form einer Tabelle im Speicher vorliegen, ist der Zugriff auf vorgegebene Eigenschaften der Tabelle sequenziell.
9 veranschaulicht ein relationales Modell 900 (das z. B. sequenzielle Eigenschaften enthält). Die Eigenschaft „Gehalt“ von Mitarbeitern 902 (die in 9 z. B. über ein Textfeld markiert ist) kann in einem Speicher zum Beispiel durch eine spaltenorientierte Speicherung zusammenhängend abgespeichert werden. Eine derartige Ordnung von Informationen ermöglicht eine Berechnung von Abfragen mit nicht relationalen Verbindungen (z. B. „was ist das Durchschnittsgehalt“), die verglichen mit der Nutzung eines Graphenmodells (z. B. des Graphenmodells 801) effizienter ist, denn dabei würde auf zufällig angeordnete Knoten (z. B. die Knoten 807) zugegriffen. Würden die Informationen aus 9 zum Beispiel in einem Graphenmodell abgespeichert, müsste auf jeden mit einem Mitarbeiter korrespondierenden Knoten (z. B. wenn jeder Knoten an einer zufälligen Speicherstelle abgespeichert ist) zugegriffen werden.
Graphdatenbanken zeigen bei Abfragen, die eine Untersuchung von Verbindungen zwischen Daten erfordern, oft eine Performance, die verglichen mit relationalen Datenbanken besser ist, da die Graphkanten einfach traversiert werden. Jedoch bieten relationale Datenbanken bei Abfragen, die über Eigenschaften von Objekten iterieren, die beste Performance, da diese Eigenschaften als Spalten in einer Tabelle, auf die einfach und effizient zugegriffen werden kann, repräsentiert sind. Wird nur ein Datenmodell (also entweder ein Graphenmodell oder ein relationales Modell) genutzt, kann es bei manchen Abfragetypen aufgrund der zugrundeliegenden Datenstrukturen (z. B. Graphdatenstrukturen oder relationalen Datenstrukturen), die zum Repräsentieren der Informationen genutzt werden, zu Performance-Einbußen kommen.
Eine bessere Abfrageausführungsperformance ließe sich erzielen, wenn gleichzeitig das relationale Modell und das Graphenmodell kombiniert würden. In diesen Beispielen ist es möglich, abhängig von den Abfragecharakteristika das für die Abfrageausführung geeignetste Modell (z. B. entweder das Graphenmodell oder das relationale Modell) auszuwählen. Allerdings ist eine manuelle gleichzeitige Anwendung beider Modelle keine pragmatische Lösung. Die einzelnen Datenstrukturen werden typischerweise von einem Codeentwickler beim Anwendungscodeentwicklungsprozess ausgewählt. Der Codeentwickler muss sich deshalb mit relativ vielen unterschiedlichen Datenstrukturtypen, mit der Implementierung der Syntax der unterschiedlichen Datenstrukturtypen sowie damit, welche Datenstrukturtypen die betreffenden Performance-Metriken am ehesten verbessern, sehr gut auskennen. Wenn darüber hinaus eine Anwendung während ihres Betriebs einen bestimmten Typ von Daten und/oder unterschiedliche Datentypen nutzt, sind derart viele sich immer noch ändernde Eingaben und/oder heterogene Systemen vorhanden, dass das Codeentwicklungspersonal diese nicht wirksam berücksichtigen kann. Beispielsweise erlaubt der Datentyp einer sortierten Liste (z. B. ein Datencontainer) relativ schnelle Datensatzabfragen, jedoch lassen sich mit demselben Datencontainertyp neue Elemente nur relativ langsam einfügen. In einem weiteren Beispiel ermöglicht ein Hashtabellendatentyp relativ schnelle Einfügungen und/oder Abrufe bestimmter Datensatzelemente, jedoch laufen Tasks im Zusammenhang mit der Auflistung ganzer Datensätze in einer bestimmten Reihenfolge (z. B. in numerischer oder alphabetischer Reihenfolge) relativ langsam ab. Wird außerdem zunächst ein erster Datenstrukturtyp ausgewählt und dann beobachtet, dass er in Verbindung mit einem ersten Eingabedatentyp relativ gute Performance-Charakteristika aufweist, und ändern sich dann die Eingabedatentypen und/oder Eingabedatenmengen im Verlauf der Nutzung der codierten Anwendung, können sich die Performance-Charakteristika verschlechtern. Weil die Datenstrukturauswahl ein mühsamer Prozess ist, der umfangreiche Fachkenntnisse, vielfältige Gestaltungsfaktoren und/oder mögliche dynamische Betriebsbedingungen voraussetzt, könnte sich die Auswahl bestimmter Datenstrukturen nachteilig auf ein oder mehrere Performance-Charakteristika der vom Codeentwicklungspersonal geschriebenen und/oder in anderer Weise entwickelten Anwendungen auswirken. Mit anderen Worten, verlässt man sich auf die Ermessensentscheidungen des Codeentwicklungspersonals, kann dies eine unzulängliche Anwendungsperformance zur Folge haben. Durch eine zweckmäßige Auswahl von Datenstrukturen können eine oder mehrere Performance-Metriken einer Anwendung verbessert werden.
Einige bekannte Modelle definieren eine Schicht, die eine Graphabfragesprache (z. B. Apache Gremlin) über einer relationalen Datenbank bietet. Weitere Lösungen schließen eine Übersetzung von (z. B. relationalen) Abfragen in SQL (Structured Query Language) in eine Graphabfragesprache für den Zugriff auf eine Datenbank, die eine Graphstruktur implementiert, ein. Die meisten relationalen Datenbanken und Graphdatenbanken implementieren Caching-Mechanismen zur Beschleunigung von Abfragen durch Abspeichern von Teilmengen der Daten in einem Speicher. Manche Datenbanken sind so konfiguriert, dass sie mit der In-Memory-Technik arbeiten (MemSQL, MemGraph etc.), also weniger häufige Aktualisierungen an die Festplatte ausgeben. Derartige bekannte Lösungen konzentrieren sich jedoch nur auf einzelne Aspekte: eine einfache Nutzung durch eine Graphschnittstelle, eine optimierte Abfrage-Performance basierend auf graphartigen Beziehungen oder eine optimierte Abfrage-Performance für SQL-artige Abfragen.
Hierin werden beispielhafte Systeme und Verfahren zum Generieren einer Hybriddatenbank offenbart. Genauer stellen die Beispiele, die hierin offenbart werden, ein Datenmodell bereit, das eine Graphenmodellschnittstelle nutzt und eine (z. B. automatische) Hybriddatenbank unter Nutzung sowohl eines relationalen Modells als auch eines Graphenmodells bereitstellt. Zum Beispiel stellen die hierin offenbarten Verfahren und Vorrichtungen ein Hybriddatenbanksystem bereit, das eine Graphschnittstelle implementiert. Intern werden durch die hierin offenbarten, beispielhaften Verfahren und Vorrichtungen Informationen als Graph abgespeichert. Darüber hinaus werden durch die hierin offenbarten, beispielhaften Verfahren und Vorrichtungen relationale Datenbanken (z. B. Tabellen) basierend auf den Graphdatenbanken (z. B. automatisch) generiert, um die Performance für bestimmte Typen von Abfragen (die z. B. möglicherweise für relationale Abfragen besser geeignet sind) zu erhöhen. Zum Beispiel werden Tabellen nach einem relationalen Modell nur für relevante, den Graphdatenbanken zugeordnete Daten (also Daten, die zum schnelleren Antworten auf Abfragen genutzt werden können) erzeugt. Infolgedessen verwenden die hierin offenbarten, beispielhaften Systeme ein Hybriddatenbanksystem, das performanter ist als entweder nur ein Graphdatenbanksystem oder nur ein relationales Datenbanksystem.
Darüber hinaus werden hierin beispielhafte Systeme und Verfahren zum Verwenden von künstlicher Intelligenz und/oder maschinellem Lernen zum Vorhersagen einer Abfrageausführungsperformance (z. B. der schnellsten Abfrageausführungsperformance) unter Nutzung des Hybriddatenbanksystems (z. B. des Graphenmodells oder des relationalen Modells) offenbart.
Durch künstliche Intelligenz (KI), die maschinelles Lernen (ML), Deep Learning (DL) und/oder andere künstliche, maschinengesteuerte Logik einschließt, können Maschinen (z. B. Computer oder logische Schaltungen) ein Modell (z. B. einen Modellklassifikator oder ein LSTM-Modell) zum Verarbeiten von Eingabedaten (z. B. einer Abfrage oder von Kontextinformationen) nutzen, um basierend auf Mustern und/oder Assoziationen, die durch das Modell vorher über einen Trainingsprozess gelernt wurden, eine Ausgabe (z. B. eine Binärausgabe) zu generieren oder vorherzusagen. Das Modell kann beispielsweise mit Daten (z. B. früheren Abfragen oder Kontext-informationen) trainiert werden, damit Muster und/oder Assoziationen erkannt sowie diese Muster und/oder Assoziationen bei der Verarbeitung von Eingabedaten befolgt werden, sodass aus weiteren Eingaben Ausgaben, die mit den erkannten Mustern und/oder Assoziationen übereinstimmen, resultieren.
Es gibt viele unterschiedliche Typen von Machine-Learning-Modellen und Machine-Learning-Architekturen. Für die Nutzung bei den hierin offenbarten, beispielhaften Ansätzen allgemein geeignet sind Machine-Learning-Modelle/-Architekturen von beliebigen Typen, künstliche Intelligenz von beliebigen Typen und/oder neuronale Netze von beliebigen Typen (z. B. Variational Encoder, gefaltete neuronale Netze, tiefe neuronale Netze oder neuronale Ersatznetze).
Die Implementierung eines ML/KI-Systems läuft gewöhnlich in zwei Phasen ab, einer Lern-/Trainingsphase und einer Inferenzphase. In der Lern-/Trainingsphase wird durch einen Trainingsalgorithmus oder eine Trainingsprozedur ein Modell so trainiert, dass es sich folglich an Mustern und/oder Assoziationen, die zum Beispiel auf Trainingsdaten basieren, ausrichten kann. Allgemein enthält das Modell interne Parameter, die darauf verweisen, wie Eingabe- in Ausgabedaten überführt werden, etwa durch eine Reihe von Knoten und Verbindungen innerhalb des Modells zur Überführung von Eingabe- in Ausgabedaten. Darüber hinaus werden beim Trainingsprozess Hyperparameter genutzt, um zu regeln, wie das Lernen durchgeführt wird (z. B. eine Lernrate oder eine Anzahl von im Machine-Learning-Modell genutzten Schichten). Hyperparameter werden als Trainingsparameter definiert, die vor dem Initiieren des Trainingsprozesses bestimmt werden.
Das Training kann basierend auf dem ML/KI-Modelltyp und/oder der erwarteten Ausgabe auf unterschiedliche Arten durchgeführt werden. Bei einem überwachten Training werden zum Beispiel Eingaben und entsprechende erwartete (z. B. beschriftete) Ausgaben zur Auswahl von Parametern (z. B. durch Iterieren über Kombinationen ausgewählter Parameter) für das ML/KI-Modell, die Modellfehler verringern, genutzt. Das Beschriften, wie hierin genutzt, bezieht sich auf eine erwartete Ausgabe des Machine-Learning-Modells (z. B. eine Klassifizierung oder einen erwarteten Ausgabewert). Bei einem selbstüberwachten Training werden Charakteristika eines überwachten Trainings genutzt, jedoch erfolgt eine Selbstinitiierung des Trainings, also ohne Benutzerbeteiligung. Alternativ werden bei einem un-überwachten Training (das z. B. beim Deep Learning, einem Teilgebiet des maschinellen Lernens, genutzt wird) Muster aus Eingaben abgeleitet, um Parameter für das ML/KI-Modell auszuwählen (z. B. ohne den Nutzen aus erwarteten (z. B. beschrifteten) Ausgaben).
Sobald das Modell trainiert worden ist, kann es nach dem Deployment in einer Inferenzphase zur Datenverarbeitung eingesetzt werden. In der Inferenzphase werden zu analysierende Daten (z. B. Live-Daten) in das Modell eingegeben, und das Modell wird ausgeführt, um eine Ausgabe zu erzeugen. Diese Inferenzphase ist gleichsam das „Denken“ der KI zum Generieren der Ausgabe basierend darauf, was sie bei dem Training gelernt hat (z. B. durch Ausführen des Modells, um die gelernten Muster und/oder Assoziationen auf die Live-Daten anzuwenden). In einigen Beispielen werden Eingabedaten vorverarbeitet, bevor sie als Eingabe in das Machine-Learning-Modell genutzt werden. Außerdem werden die Ausgabedaten in einigen Beispielen möglicherweise nachverarbeitet, nachdem sie durch das KI-Modell generiert worden sind, um die Ausgabe in ein brauchbares Ergebnis (z. B. eine Anzeige von Daten oder einen durch eine Maschine auszuführenden Befehl) zu überführen.
In einigen Beispielen, die hierin offenbart werden, wird ein Long-Short-Term-Memory-Modell genutzt. Die Nutzung eines Long-Short-Term-Memory-Modells ermöglicht Vorhersagen einer optimalen Abfrage-Engine für eine empfangene Abfrage durch das Modell basierend auf den aktuellen Bedingungen eines Abfrageauswahlsystems. Einige Beispiele, die hierin offenbart werden, verwenden ein rekurrentes neuronales Netz (RNN) mit selbst-überwachtem Lernen während einer Trainingsphase, um das Abfrageklassifikatormodell so anzulernen oder zu trainieren, dass es vorhersagen kann, welche Such-Engine (z. B. Graph oder relational) für die Ausführung einer empfangenen Abfrage beim Betrieb in einer Inferenzphase optimal ist. Jedoch könnten zusätzlich oder alternativ auch noch andere Machine-Learning-Modelltypen genutzt werden.
Mithin können hierin offenbarte, beispielhafte Abfrageauswahlsysteme durch Folgendes gebildet werden: a) automatisches Generieren von Code zum Generieren einer Hybriddatenbank (z. B. Erzeugung relationaler Tabellen, Beschleunigen der Beantwortung von Abfragen von einem bestimmten Typ); und b) automatisches Übersetzen von Abfragen/automatisches Leiten von Abfragen an die optimale (z. B. schnellste) Abfrage-Engine (relational oder Graph) basierend auf einem Klassifizierungssystem unter Nutzung von Machine-Learning-Techniken (z. B. einer kontextbasierten Klassifizierung eines neuronalen Netzes unter Nutzung eines Long-Short-Term-Memory(LSTM)-Modells).
1 ist eine schematische Darstellung eines beispielhaften Abfrageauswahlsystems 100 gemäß Lehren dieser Offenbarung zum Verbessern der Abfrageausführungsperformance. In einigen Beispielen wird ein auf maschinellem Lernen basierendes Abfrageauswahlsystem genutzt, um eine optimale Abfrageausführungsperformance vorherzusagen. Das beispielhafte Abfrageauswahlsystem 100 kann zum Beispiel unter Nutzung eines Servers, eines PC, einer Workstation, einer selbstlernenden Maschine (z. B. eines neuronalen Netzes), eines Mobilgeräts (z. B. eines Handys, eines Smartphones oder eines Tablets, etwa eines i-Pad™), eines Personal Digital Assistant (PDA), einer Internet-Appliance oder eines Computergeräts von einem beliebigen anderen Typ und/oder einer Kombination daraus implementiert werden. In einigen Beispielen befinden sich eine oder mehrere Komponenten des Abfrageauswahlsystems 100 aus 1 möglicherweise entfernt von einer oder mehreren anderen Komponenten des beispielhaften Abfrageauswahlsystems 100 und sind (z. B. über eine LAN-Verbindung (LAN = Local Area Network), eine Mobilfunkverbindung, ein Netz, ein Netz, usw.) kommunikativ an die eine oder die mehreren anderen Komponenten des beispielhaften Abfrageauswahlsystems gekoppelt. In einigen Beispielen kann es sich hierbei um ein autonomes Abfrageauswahlsystem 100 innerhalb eines Computergeräts (z. B. eines Servers) handeln. In einigen Beispielen ist das Abfrageauswahlsystem 100 möglicherweise eine separate Einheit, die in einem ersten Computergerät (z. B. einem Mobilgerät oder einer Workstation) untergebracht und (z. B. über ein Netz) mit einem zweiten Computergerät (z. B. einem Server), das eine Hybriddatenbank 102 enthält, kommunikativ verbunden ist.
Zur Verbesserung der Abfrageausführungsperformance enthält das Abfrageauswahlsystem 100 in dem veranschaulichten Beispiel die Hybriddatenbank 102. Genauer enthält die Hybriddatenbank 102 in dem veranschaulichten Beispiel eine Graphdatenbank 104 und eine relationale Datenbank 106. Um zum Beispiel die Abfrage-Performance für bestimmte Typen von Abfragen, die unter Nutzung relationaler Modelle eine effizientere Performance aufweisen (z. B. Abfragen, die Beziehungen enthalten), zu verbessern, implementiert die Hybriddatenbank 102 in dem veranschaulichten Beispiel eine Graphschnittstelle, die (z. B. intern) Informationen basierend auf einem Graphenmodell (z. B. über die Graphdatenbank 104) abspeichert und die Informationen generiert oder aus dem Graphenmodell (z. B. über die relationale Datenbank 106) in ein relationales Modell überführt.
Die Graphdatenbank 104 in dem veranschaulichten Beispiel kann Daten enthalten, die über eine Benutzereingabe (z. B. eine von einem Benutzer generierte Datei) empfangen, aus einem Bild oder Video extrahiert, aus einer oder mehreren Dateien extrahiert und/oder über (eine) beliebige andere Eingabe(n) bezogen werden. In einigen Beispielen kann das Abfrageauswahlsystem 100 eine Benutzerschnittstelle zum Ermöglichen der Eingabe von Daten oder Informationen in die Graphdatenbank 104 verwenden. In einigen Beispielen empfängt das Abfrageauswahlsystem 100 der Graphdatenbank 104 zugeordnete Informationen, oder es greift auf sie zu, ruft sie ab oder bezieht sie auf andere Weise. In einigen Beispielen stellt das Abfrageauswahlsystem 100 die Graphdatenbank 104 über von einem Benutzer, von einer Maschine, aus einer Datei, aus einer Videodatei etc. empfangene Eingaben bereit und generiert die relationale Datenbank 106 basierend auf den empfangenen Eingaben (z. B. automatisch).
Um die relationale Datenbank 106 zu generieren, verwendet das beispielhaften Abfrageauswahlsystem 100 in dem veranschaulichten Beispiel einen Hybriddatenbankgenerator 108. Genauer wird die relationale Datenbank 106 vom Hybriddatenbankgenerator 108 in dem veranschaulichten Beispiel basierend auf Informationen und/oder Daten aus der Graphdatenbank 104 (z. B. in ihr abgespeicherten Informationen und/oder Daten) generiert (z. B. erstellt oder aufgefüllt). Genauer generiert der Hybriddatenbankgenerator 108 Tabellen nach einem relationalen Modell nur für relevante Daten, die in der Graphdatenbank 104 bereitgestellt sind. Relevante Daten sind zum Beispiel möglicherweise Informationen, die zur Verbesserung (z. B. Verlängerung) von Abfrageantwortzeiten genutzt werden können. Mit anderen Worten, es werden genaue Informationen aus der Graphdatenbank 104 genutzt, um die relationale Datenbank 106 zu generieren. In einigen Fällen enthält die relationale Datenbank 106 mithin Teildaten aus der Graphdatenbank 104. Um Informationen (z. B. neue Daten) in der Graphdatenbank 104 zu detektieren, führt der Hybriddatenbankgenerator 108 an der Graphdatenbank 104 periodische Analysen durch. Die Häufigkeit der periodischen Analysen kann von der jeweiligen Auslastung des Abfrageauswahlsystems 100 (z. B. nur lesend oder sowohl lesend als auch schreibend) abhängen. In einigen Beispielen stellt der Hybriddatenbankgenerator 108 Mittel zum Generieren der Hybriddatenbank 102 und/oder der relationalen Datenbank 106 bereit. Der Hybriddatenbankgenerator 108 wird in Verbindung mit 3 und 6 noch ausführlicher beschrieben.
Um eine Abfrage 115 von einem Benutzer 111 gemäß einer Graphsyntax zu parsen, enthält das Abfrageauswahlsystem 100 in dem veranschaulichten Beispiel eine Graphsprachabfrage 110. In einigen Beispielen empfängt die Graphsprachabfrage 110 die Abfrage 115 (oder eine Vielzahl von Abfragen) vom Benutzer 111 und/oder eine Vielzahl von Abfragen gleichzeitig von mehreren Benutzern. Die Graphsprachabfrage 110 in dem veranschaulichten Beispiel verwendet eine Graphabfragesprachsyntax zum Konvertieren der Eingabe der Abfrage 115 in ein maschinenlesbares Format, das vom Abfrageauswahlsystem 100 gelesen werden kann. Die Graphsprachabfrage 110 konvertiert die Abfrage 115 zum Beispiel in eine Abfrageschnittstellenfunktion. Genauer identifiziert die Graphsprachabfrage 110 eine Funktion der Abfrage 115 und die Eingabeargumente der identifizierten Funktion. Zum Beispiel kann die folgende Abfrage „dessen Name Hercules ist“ durch die Graphsprachabfrage 110 wie folgt ausgedrückt oder identifiziert werden:

• $q=g .V () . has (' name','Hercules')$

Die Funktion wird als „V()“ identifiziert, und die Eingabeargumente der Funktion werden als „name“ und „Hercules“ identifiziert. Die Graphsprachabfrage 110 kommuniziert die Abfrage (q) zur weiteren Verarbeitung an einen Kontextabfrageklassifikator 112, wie in 2 beschrieben. In einigen Beispielen stellt die Graphsprachabfrage 102 Mittel zum Empfangen einer Abfrage (z. B. der Abfrage 115 vom Benutzer 111) bereit. In einigen Beispielen stellt die Graphsprachabfrage 110 Mittel zum Konvertieren einer Textabfrage in eine Abfrageschnittstellenfunktion bereit.
In einigen Beispielen kann die Graphsprachabfrage 110 hingegen auch andere Schnittstellen für Sprachabfragen enthalten, etwa gemäß der Structured-Query-Language-Syntax und/oder sonstigen nicht graphenorientierten Abfragesprachen. In einigen solchen Fällen kann die Abfrage 115 in anderen Formaten vorliegen, zum Beispiel in der Structured-Query-Language-Syntax und/oder einer anderen nicht graphenorientierten Abfragesprachsyntax. In einigen Beispielen enthält das Abfrageauswahlsystem 100 zum Ermöglichen der Eingabe der Abfrage 115 möglicherweise eine Benutzeroberfläche, auf der das beispielhafte Abfrageauswahlsystem 100 eine grafische Bedienoberfläche (GUI) und/oder einen Endgerätbildschirm für Datenein- und -ausgaben durch den Benutzer 111 wiedergibt. In einigen Beispielen verbindet sich ein vom Benutzer 111 verwendetes Computergerät (z. B. remote) über eine Benutzeroberfläche kommunikativ mit dem Abfrageauswahlsystem 100, wobei das beispielhafte Abfrageauswahlsystem 100 auf der Benutzeroberfläche eine grafische Bedienoberfläche (GUI) und/oder einen Endgerätbildschirm für Datenein- und -ausgaben, die/der über ein Netz kommunikativ an das Computergerät gekoppelt sein kann, wiedergibt. In einigen Beispielen empfängt die Graphsprachabfrage 110 eine Abfrage von einem anderen Computergerät (z. B. einem anderen Server oder einer anderen Workstation).
Um eine optimale Abfrage-Performance oder Ausführung der Abfrage 115 vorherzusagen, enthält das Abfrageauswahlsystem 100 in dem veranschaulichten Beispiel einen Kontextabfrageklassifikator 112. Die Graphsprachabfrage 110 in dem veranschaulichten Beispiel kommuniziert die Abfrage 115 an den Kontextabfrageklassifikator 112. Der Kontextabfrageklassifikator 112 bewertet und/oder sagt vorher, welche Datenbank (z. B. die Graphdatenbank 104 oder die relationale Datenbank 106) für die Ausführung der Abfrage 115 optimal ist. Wie in Verbindung mit den 2 und 4-6 noch ausführlicher beschrieben wird, erfolgen Vorhersagen der optimalen Such-Engine für jede durch das Abfrageauswahlsystem 100 empfangene Abfrage (z. B. die Abfrage 115) durch den Kontextabfrageklassifikator 112 durch künstliche Intelligenz und/oder maschinelles Lernen.
Nach der Vorhersage, welche Datenbank für eine gegebene Abfrage optimal ist, leitet der Kontextabfrageklassifikator 112 in dem veranschaulichten Beispiel die Abfrage 115 entweder an eine Graphabfrage-Engine 114, um die Ausführung der Abfrage 115 unter Nutzung der Graphdatenbank 104 durchzuführen, oder an eine für relationale Abfragen vorgesehene Engine 116, um die Abfrage 115 unter Nutzung der relationalen Datenbank 106 auszuführen. In einigen Beispielen stellt der Kontextabfrageklassifikator 112 Mittel zum Vorhersagen einer optimalen (z. B. schnellsten) Abfrage-Engine bereit. In einigen Beispielen stellt der Kontextabfrageklassifikator 112 Mittel zum Trainieren eines Modellklassifikators zum Vorhersagen einer optimalen (z. B. schnellsten) Abfrage-Engine bereit.
Die Graphabfrage-Engine 114 in dem veranschaulichten Beispiel muss die Abfrage 115 vor dem Durchsuchen der Graphdatenbank 104 nicht erst in eine Graphsprachsyntax übersetzen, da die Graphsprachabfrage 110 die Abfrage 115 gemäß einer Graphabfragesprachsyntax konfiguriert. In einigen derartigen Beispielen kann die Graphabfrage-Engine 114 einen Übersetzer verwenden, um die Abfrage 115 vor dem Ausführen der Abfrage 115 über die Graphdatenbank 104 in eine Graphabfragesprachsyntax zu übersetzen. In einigen Beispielen stellt die Graphabfrage-Engine 114 Mittel zum Durchsuchen der Graphdatenbank 104 bereit.
Der Übersetzer 117 übersetzt die Abfrage 115 vor dem Ausführen der Abfrage 115 in eine zweckmäßige Abfragesprache, die vom relationalen Modell (z. B. von der für relationale Abfragen vorgesehenen Engine 116) unterstützt wird. Der Übersetzer 117 übersetzt zum Beispiel Ausdrücke in einer Graphabfragesprachsyntax in eine Syntax einer relationalen Abfragesprache (z. B. eine SQL-Syntax). Der Übersetzer 117 in dem veranschaulichten Beispiel ist zum Beispiel ein SQL-Übersetzer (SQL = Structured Query Language), der konfiguriert ist, um die Abfrage 115 (z. B. oder eine Graphsprachabfrage) in eine für Suchen geeignete Abfrage zur Nutzung durch die für relationale Abfragen vorgesehene Engine 116 (z. B. eine Abfrage in einer relationalen Sprache) zu übersetzen. In einigen Beispielen stellt der Übersetzer 117 Mittel zum Konvertieren einer Abfrage aus einer ersten Syntax (z. B. einer Graphsprachabfragesyntax) in eine zweite Syntax (z. B. eine Syntax einer Abfrage in einer relationalen Sprache) für die Suche in der relationalen Datenbank 106 bereit.
Die für relationale Abfragen vorgesehene Engine 116 parst die Abfrage in der relationalen Sprache (z. B. die vom Übersetzer 117 übersetzte Abfrage) und führt die Abfrage unter Nutzung der relationalen Datenbank 106 aus. In einigen Beispielen stellt die für relationale Abfragen vorgesehene Engine 116 Mittel zum Durchsuchen der relationalen Datenbank 106 bereit.
Ein Datenspeicher 118 implementiert den Kontextabfrageklassifikator 112 und/oder speichert die Graphdatenbank 104 und die relationale Datenbank 106 ab. Der Datenspeicher 118 in dem veranschaulichten Beispiel aus 1 ist durch beliebige Speicherelemente, Speichergeräte oder Speicherplatten zur Abspeicherung von Daten implementierbar, zum Beispiel durch einen Flashspeicher, magnetische Datenträger, optische Datenträger, einen Halbleiterspeicher, eine SSD (Solid State Drive), (eine) Festplatte(n) (HDDs), (einen) Speicherstick(s) und/oder (ein) beliebige(s) andere(s) geeignete(s) Laufwerk(e) und/oder (einen) beliebige(n) andere(n) geeignete(n) Datenspeicher zum Abspeichern und Abrufen digitaler Informationen oder Daten. In einigen Beispielen stellt der Datenspeicher 118 Mittel zum Abspeichern der Graphdatenbank 104 und/oder der relationalen Datenbank 106 bereit.
Im Betrieb beschleunigt das Abfrageauswahlsystem 100 aus 1 die Abfrageberechnungen dadurch, dass es die geeignetste Datenrepräsentation für jede Abfrage (z. B. die Abfrage 115), die über die Graphsprachabfrage 110 empfangen wird, nutzt. Genauer bietet das beispielhafte Abfrageauswahlsystem 100 aus 1 eine vereinheitlichte Datenbank-Performance-Verbesserung, insofern als die Graphdatenbank 104 basierend auf der ausgeführten Abfrage 115 performanter ist als die relationale Datenbank 106 oder umgekehrt. Das beispielhafte Abfrageauswahlsystem 100 aus 1 generiert die Graphdatenbank 104 basierend auf Informationen, die dem Abfrageauswahlsystem 100 (z. B. von einem Benutzer oder über ein Video) bereitgestellt werden, und erzeugt die relationale Datenbank 106 basierend auf der Graphdatenbank 104 (z. B. automatisch), um Abfragen nach Bedarf an die relationale Datenbank 106 zu leiten, um die Abfrageausführungsperformance zu verbessern. Wie unten noch ausführlicher beschrieben wird, enthält das beispielhafte Abfrageauswahlsystem 100 aus 1 Folgendes: eine automatische Codegenerierung; und eine Abfrageklassifizierung, wodurch Benutzer dauerhaft eine brauchbare oder leistungsfähige Graphabstraktion erhalten und unabhängig von den darunterliegenden Hardware- und Low-Level-Datenstrukturen, die zum Abspeichern des Abfrageauswahlsystems 100 genutzt werden, optimierte Datenzugriffe ermöglicht werden.
2 ist eine schematische Darstellung des beispielhaften Kontextabfrageklassifikators 112 aus 1. Der beispielhafte Kontextabfrageklassifikator 112 aus 2 enthält einen beispielhaften Abfrageparser 202, einen beispielhaften Abfragevalidierer 204, einen beispielhaften Abfragetracker 206, einen beispielhaften Vektorkonverter 208, einen beispielhaften Modellklassifikator 210, einen beispielhaften Modelltrainer 212, einen beispielhaften Machine-Learning-Modelltrainerverarbeiter 214, einen beispielhaften Modellüberprüfer 216, einen beispielhaften Kontextbestimmer 218, einen beispielhaften Abfragedatenspeicher 220 und einen beispielhaften Modelldatenspeicher 222, wobei die oben genannte Struktur über einen beispielhaften Bus 224 kommunikativ zusammengeschaltet sein kann.
Der Abfrageparser 202 parst die Abfrage (q) aus der Graphsprachabfrage 110, um die Abfrage (q) in diskrete semantische Elemente (z. B. ein Array aus diskreten semantischen Elementen) zu zergliedern. Der Abfrageparser 202 parst zum Beispiel eine Abfrage (die z. B. unter Nutzung der Gremlin-Abfragesprache ausgedrückt ist: finde die Knoten, deren „name“-Eigenschaft gleich „Hercules“ ist) gemäß der Abfragesprachsyntax in semantische Elemente. In einigen Beispielen parst der Abfrageparser 202 jede Abfrage (z. B. eine Abfrage q), die durch die Graphsprachabfrage 110 empfangen wird. Der Abfrageparser 202 parst zum Beispiel die Elemente der Abfrage (q) in der oben angeführten Gleichung 1 (z. B. q=g.V(). Has (‚name‘, ‚Hercules‘)) zur weiteren Verarbeitung in ein Array von Objekten und/oder Attributen. Eine beispielhafte geparste Abfrage (q') enthält:

• $q'= {V (),has, name, Hercule}$

Der Abfrageparser 202 kommuniziert die geparste Abfrage (q') an den Abfragevalidierer 204, den Abfragetracker 206 und den Vektorkonverter 208. In einigen Beispielen stellt der Abfrageparser 202 Mittel zum Parsen einer Abfrage zwischen einem ersten Format (z. B. einer Abfragefunktionsschnittstelle) und einem zweiten Format (z. B. einer Graphsprachsyntax) bereit.
Um zu bestimmen, ob die relationale Datenbank 106 eine Option zum Durchführen der Abfrage (z. B. der Abfrage 115 oder der geparsten Abfrage q') ist, validiert oder bestimmt der Abfragevalidierer 204, ob die Hybriddatenbank 102 oder der Hybriddatenbankgenerator 108 das Objekt (die Objekte) und/oder das Attribut (die Attribute) der geparsten Abfrage (q') enthält. Der Abfragevalidierer 204 ist zum Beispiel konfiguriert, um eine Liste von Objekten und/oder Attributen, die in der relationalen Datenbank 106 enthalten sind, zu durchsuchen, und kann das Objekt (die Objekte) und/oder das Attribut (die Attribute) der geparsten Abfrage (q') mit der Liste von Objekten und/oder Attributen der Hybriddatenbank 102 und/oder des Hybriddatenbankgenerators 108 vergleichen. Mithin bestimmt der Abfragevalidierer 204, ob das Objekt (die Objekte) und/oder das Attribut (die Attribute) der geparsten Abfrage (q') mit der Liste von Objekten und/oder Attributen der Hybriddatenbank 102 und/oder des Hybriddatenbankgenerators 108 korrespondieren/korrespondiert (z. B. mit ihr übereinstimmen/übereinstimmt). Wenn der Abfragevalidierer 204 bestimmt, dass das Objekt (die Objekte) und/oder das Attribut (die Attribute) der geparsten Abfrage (q') mit der Liste von Objekten und/oder Attributen der Hybriddatenbank 102 und/oder des Hybriddatenbankgenerators 108 korrespondieren/korrespondiert (z. B. mit ihr übereinstimmen/übereinstimmt), bestimmt er als Reaktion hierauf, dass die relationale Datenbank 106 für die Ausführung der geparsten Abfrage (q') verfügbar ist. Wenn der Abfragevalidierer 204 hingegen bestimmt, dass das Objekt (die Objekte) und/oder das Attribut (die Attribute) der geparsten Abfrage (q') mit der Liste von Objekten und/oder Attributen der Hybriddatenbank 102 und/oder des Hybriddatenbankgenerators 108 nicht korrespondieren/korrespondiert (z. B. nicht mit ihr übereinstimmen/übereinstimmt), bestimmt er als Reaktion hierauf, dass die relationale Datenbank 106 nicht für die Ausführung der geparsten Abfrage (q') verfügbar ist. In einigen Beispielen stellt der Abfragevalidierer 204 Mittel zum Bestätigen des Vorliegens von Informationen (z. B. Objekten und/oder Eigenschaften) in der relationalen Datenbank 106 bereit.
Der Abfragetracker 206 speichert geparste, durch das Abfrageauswahlsystem 100 (z. B. die Graphsprachabfrage 110) empfangene Abfragen (z. B. die geparste Abfrage q') ab. Der Abfragetracker 206 speichert zum Beispiel die geparsten Abfragen im Abfragedatenspeicher 220 ab. Die abgespeicherten Abfragen (z. B. die geparste Abfrage (q')) können vom Modelltrainer 212 zum Trainieren des Klassifikatormodells 210 genutzt werden, wie unten noch ausführlicher beschrieben wird. Der Abfragetracker 206 kann die Abfragen (z. B. frühere empfangene Abfragen) in einem beliebigen Format im Abfragedatenspeicher 220 abspeichern, etwa unter anderem im ursprünglichen Abfrageformat (z. B. als Zeichenfolge der Abfrage 115, die vom Benutzer 111 bereitgestellt wird), im Format einer Abfragefunktionsschnittstelle (q) (die z. B. durch die Graphsprachabfrage 110 bereitgestellt wird) oder im Format einer geparsten Abfrage (q'). In einigen Beispielen stellt der Abfragetracker Mittel zum Abspeichern und/oder Verfolgen der früheren, durch das Abfrageauswahlsystem 100 empfangenen Abfragen bereit.
Der Vektorkonverter 208 übersetzt die geparste Abfrage (q') in einen Merkmalsvektor zur Verarbeitung durch den Modellklassifikator 210. In dem veranschaulichten Beispiel konvertiert der Vektorkonverter 208 die geparste Abfrage (q') in eine eingebettete Abfrage (q*). Die eingebettete Abfrage (q*) kann maschinenlesbare, durch den Modellklassifikator 210 als Eingaben lesbare Werte (z. B. Zahlen, Zeichen oder Binärwerte) enthalten. Der Vektorkonverter 208 verwendet zum Beispiel Word2Vec, um die geparste Abfrage (q') in einen Merkmalsvektor (z. B. die eingebettete Abfrage (q*)) zu konvertieren. Word2Vec ist zum Beispiel ein neuronales Netz mit zwei Schichten, das eine auf Wörtern basierende Eingabe oder einen Textkorpus (z. B. die geparste Abfrage (q')) verarbeitet und eine Menge von Vektoren (z. B. Merkmalsvektoren), die repräsentativ für die Wörter des Textkorpus sind, ausgibt. Mit anderen Worten, der Vektorkonverter 208 (z. B. Word2Vec) konvertiert Text in ein Zahlenformat, das für den konvertierten Text, der durch ein neuronales Netz oder ein Machine-Learning-Modell verarbeitet werden kann, repräsentativ ist. In einigen Beispielen kann der Vektorkonverter 208 ein Übersetzer oder Konverter von einem beliebigen Typ sein, der eine Abfrage (z. B. die Abfrage q) und/oder eine geparste Abfrage (q') in eine Eingabe zur Nutzung durch ein Machine-Learning-Modell (z. B. einen Algorithmus oder ein neuronales Netz) konvertiert. Der Vektorkonverter 208 kommuniziert die eingebettete Abfrage (q*) an den Modellklassifikator 210, und der Modellklassifikator 210 empfängt die eingebettete Abfrage (q*) als Eingabe. In einigen Beispielen speichert der Vektorkonverter 208 die eingebettete Abfrage (q*) zur Nutzung durch den Modelltrainer 212 im Abfragedatenspeicher 220 ab. In einigen Beispielen stellt der Vektorkonverter 208 Mittel zum Konvertieren einer Abfrage aus einem ersten Format (z. B. Graphsprachsyntax oder Textformat) in ein zweites Format (z. B. Vektorformat, Zahlenformat, Binärformat oder maschinenlesbares Format) bereit.
Der Kontextbestimmer 218 holt, empfängt, bezieht, bestimmt und/oder enthält Kontextinformationen (C_t) (z. B. Parameter), die einem aktuellen Zustand des Abfrageauswahlsystems 100 und/oder der Hybriddatenbank 102 zugeordnet sind. Der Kontextbestimmer 218 wiederum kommuniziert die Kontextinformationen an den Modellklassifikator 210, und der Modellklassifikator 210 empfängt die Kontextinformationen (C_t) als Eingabewert. Kontextinformationen (C_t) sind zum Beispiel unter anderem die Engine-Belastung, Graphanalysedaten, die Systembelastung, der Cache und/oder jegliche sonstigen Parameter, die sich auf die Performance einer Abfrage auswirken können. Die Engine-Belastung enthält zum Beispiel Informationen zur Anzahl der in jeder Engine zu einem beliebigen Zeitpunkt gleichzeitig ausgeführten Abfragen. Diese Informationen können wichtig sein, denn selbst wenn zum Beispiel die für relationale Abfragen vorgesehene Engine 116 eine neue Abfrage unter normalen Bedingungen viel schneller ausführen könnte, könnte die Abfrage bei einer starken Engine-Belastung der für relationale Abfragen vorgesehenen Engine 116 hingegen schneller in der Graphabfrage-Engine 114 ausgeführt werden. In einigen Beispielen hält das Abfrageauswahlsystem 100 diese Informationen im Datenspeicher 118, im Abfragedatenspeicher 220 und/oder im Modelldatenspeicher 222. Die Graphanalysedaten enthalten zum Beispiel möglicherweise Metriken zu einem Graphen, die Informationen zur Datenverteilung und zur Tiefenlosigkeit von Datenbeziehungen bereitstellen. Diese Metriken enthalten zum Beispiel unter anderem eine Anzahl von Knoten und Kanten, eine zentrale Anordnung von Hauptknoten, einen Maximalgrad, einen Minimalgrad und einen Durchschnittsgrad von Knoten, das Knoten-Kanten-Verhältnis, einen Graphradius oder die Taillenweite. Die Systembelastung enthält Informationen oder Charakteristika eines Hauptprozessors (CPU) (z. B. einschließlich der Verarbeitungskapazität oder der Verarbeitungsleistung), Beschleunigerkarten, den CPU-Speicher, die Netzbandbreitenauslastung und/oder sonstige Parameter oder Charakteristika des Abfrageauswahlsystems 100, die sich auf die Abfrage-Performance der Graphabfrage-Engine 114 und/oder der für relationale Abfragen vorgesehenen Engine 116 auswirken können. Eine hohe Speicherauslastung oder die Nutzung mancher Beschleunigerkarten kann beispielsweise die Performance der für relationale Abfragen vorgesehenen Engine 116 stark beeinflussen. Der Kontext C_t kann Informationen enthalten, die vom Modellklassifikator 210 während einer durch den Modelltrainer 212 bereitgestellten Trainingsphase gelernt werden, wie unten noch ausführlicher beschrieben. Der Kontextbestimmer 218 stellt dem Modellklassifikator 210 die Kontextinformationen bereit, und der Modellklassifikator 210 empfängt die Informationen zum Kontext C_t als Eingabe. In einigen Beispielen stellt der Kontextbestimmer 218 Mittel zum Beziehen, Bestimmen oder Abrufen von Kontextinformationen (C_t) (z. B. Parametern), die einem aktuellen Zustand des Abfrageauswahlsystems 100 und/oder der Hybriddatenbank 102 zugeordnet sind, bereit.
Der Modellklassifikator 210 sagt basierend auf der eingebetteten Abfrage (q*) und dem Kontext (C_t) vorher, ob die Graphabfrage-Engine 114 oder die für relationale Abfragen vorgesehene Engine 116 für die Ausführung der geparsten Abfrage (q') optimal ist. Das Klassifikatormodell 210 sagt zum Beispiel vorher, ob die Graphabfrage-Engine 114 oder die für relationale Abfragen vorgesehene Engine 116 die Abfrage 115 (z. B. die geparste Abfrage q') am schnellsten verarbeiten kann. Sobald der Modellklassifikator 210 eine optimale Engine vorhergesagt hat, leitet er die Abfrage (z. B. die Abfragefunktionsschnittstelle q, die Abfrage 115 oder die geparste Abfrage q') entweder an die Graphabfrage-Engine 114, um die Abfrage unter Nutzung der Graphdatenbank 104 auszuführen, oder an die für relationale Abfragen vorgesehene Engine 116, um die Abfrage unter Nutzung der relationalen Datenbank 106 auszuführen. In einigen Beispielen stellt der Modellklassifikator 210 Mittel zum Vorhersagen einer optimalen Abfrage-Engine zum Ausführen einer empfangenen Abfrage bereit.
Um vorherzusagen, ob die Graphabfrage-Engine 114 oder die für relationale Abfragen vorgesehene Engine 116 für die Ausführung der Abfrage 115 optimal ist, verwendet der Modellklassifikator 210 ein LSTM-Modell (LSTM = Long-Short Term Memory) (z. B. einen Klassifikator). Das LSTM-Modell in dem veranschaulichten Beispiel ist ein sequenzbezogenes Modell, das die optimale (z. B. schnellste) Abfrage-Engine für eine empfangene Abfrage (z. B. die Abfrage 115 oder die Abfrageschnittstellenfunktion q) vorhersagt und die empfangene Abfrage (z. B. die Abfrage 115 oder die Abfrageschnittstellenfunktion q) an die vorhergesagte optimale Abfrage-Engine (z. B. die Graphabfrage-Engine 114 der für relationale Abfragen vorgesehenen Engine 116) leitet. Die durch das Modell in dem veranschaulichten Beispiel gelieferte Entscheidung oder Vorhersage ist ein sequenz- und kontextbezogenes Binärklassifikationsmodell, das auf dem Long-Short-Term-Memory-Modell basiert.
Im Folgenden findet sich eine schematische Abbildung des Modellklassifikators 210:
Der Modellklassifikator 210 liefert eine vorhergesagte Ausgabe (ŷ) (z. B. eine Binärausgabe), die repräsentativ für die Auswahl einer optimalen Abfrage-Engine ist. Ein erster Wert einer ersten Binärausgabe repräsentiert zum Beispiel die Graphabfrage-Engine 114, und ein zweiter Wert einer zweiten Binärausgabe repräsentiert die für relationale Abfragen vorgesehene Engine 116. Der Binärwert „0“ repräsentiert zum Beispiel eine „nicht ausgewählte“ Abfrage-Engine, und der Binärwert „1“ repräsentiert eine „ausgewählte“ Abfrage-Engine. In dem oben angeführten Beispiel ist die Binärausgabe {0, 1} repräsentativ für die Verwendung der für relationale Abfragen vorgesehenen Engine.
Der beispielhafte Modelltrainer 212 trainiert in Verbindung mit dem beispielhaften Modelltrainerverarbeiter 214 den Modellklassifikator 210 für die Vorhersage optimaler Such-Engines basierend auf früheren Abfragen und Inhalten, die durch den Kontextbestimmer 218 bereitgestellt wurden. Der Modelltrainer 212 in dem veranschaulichten Beispiel trainiert das Modell durch ein selbstüberwachtes Training und führt das Training durch, wenn das Abfrageauswahlsystem 100 offline ist. Das Abfrageauswahlsystem 100 kann zum Beispiel offline sein, wenn das Abfrageauswahlsystem 100 gerade keine Suche durchführt. In einigen Beispielen stellt der Modelltrainer 212 Mittel zum Trainieren eines Modells zum Vorhersagen einer optimalen Abfrage-Engine für eine empfangene Abfrage bereit.
Im Folgenden ist eine beispielhafte Trainingsprozedur, die vom Modelltrainer 212 verwendet wird, dargestellt:
Das Training wird mit Bezug auf die Trainingsprozedur unter Nutzung von Trainingsdaten durchgeführt. Der Modelltrainer 212 trainiert den Modellklassifikator 210 zum Beispiel, indem er einen Datensatz aus sortierten Batches früherer Abfragen (q) sowohl in der Graphdatenbank 104 als auch in der relationalen Datenbank 106 ausführt, um eine Grundwahrheit oder ein tatsächliches Ergebnis (y), das anzeigt, welche Abfrage-Engine die schnellste Abfrage ermöglicht, zu erhalten. Zum Beispiel wird jede Trainingsabfrage (q, q') in beiden Abfrage-Engines (z. B. in der Graphabfrage-Engine 114 und der für relationale Abfragen vorgesehenen Engine 116) laufen gelassen, und die Ausführungszeiten werden verglichen, um die Grundwahrheit zu erhalten. Die Informationen zum Kontext C_t zur Zeit der Ausführung werden vom Kontextbestimmer 218 gespeichert und dem Modelltrainer 212 als Trainingsdaten für das LSTM-Modell bereitgestellt. Darüber hinaus annotiert der Modelltrainer 212 jede Probeabfrage mit der schnellsten Abfrage.
Die Trainingsdaten in den hierin offenbarten Beispielen stammen aus dem Abfragedatenspeicher 220. Der Abfragedatenspeicher 220 enthält frühere Abfragen (q) und die geparsten Abfragen (q'), die vom Abfragetracker 206 im Abfragedatenspeicher 220 abgespeichert worden sind. Mit anderen Worten, der Abfragedatenspeicher 220 enthält frühere, durch das Abfrageauswahlsystem 100 empfangene Abfragen, die beim Training des Modellklassifikators 210 verwendet werden. Weil ein selbstüberwachtes Training genutzt wird, werden die Trainingsdaten beschriftet. Die Beschriftung wird vom Abfragetracker 206 und/oder vom Modelltrainer 212 auf die Trainingsdaten angewendet. Der Abfragetracker 206 beschriftet zum Beispiel frühere Abfragen als Batch von Probeabfragen, die vom Modelltrainer 212 zu verwenden sind. In einigen Beispielen stellt der Abfragedatenspeicher 220 Mittel zum Abspeichern früherer, durch das Abfrageauswahlsystem 100 empfangener Abfragen bereit.
Nachdem die Abfragen (q) an beiden Datenbanken durchgeführt worden sind und jede Probe mit der schnellsten Abfrage annotiert worden ist, trainiert der Modelltrainer 212 das LSTM-Modell (z. B. den Modellklassifikator 210) unter Verwendung der früheren Abfragen (q, q') aus dem Abfragedatenspeicher 220 und des aktuellen Kontextes C_t. Das LSTM-Modell wird bei der Trainingsprozedur zum Beispiel derart trainiert, dass es vorhersagen kann, welche Abfrage-Engine eine optimale (z. B. die schnellste) Performance aufweist (z. B. das prädiktive Ergebnis (ŷ)). Die aus dem Abfragedatenspeicher 220 bezogenen Trainingsabfragen können das Format einer Abfragefunktionsschnittstelle (q) und/oder das Format einer geparsten Abfrage (q') haben. Falls nötig, kann die in das Trainingsmodell eingegebene Abfrage zunächst geparst, zergliedert und (z. B. unter Nutzung von Word2Vec) in einen Merkmalsvektor (q*) konvertiert werden, wie oben beschrieben.
Der Kontext (C_t) spielt eine wichtige Rolle für die Abfrage-Engine-Performance, da er die Bedingungen vorgibt, unter denen eine Abfrage ausgeführt wird. Das LSTM-Modell (z. B. der Modellklassifikator 210) kann bei einer Berücksichtigung des Kontextes (C_t) als Eingabe (z. B. über den Modelltrainer 212) unterschiedliche Bedingungen, die zu Performance-Änderungen führen können, lernen und sagt ihre Weiterentwicklung im Verlauf der Zeit vorher. Darüber hinaus kann das LSTM-Modell infolge der Nutzung sortierter Mengen früherer Abfragen (q, q') die Effekte von Caching-Mechanismen lernen. Das Modell kann zum Beispiel ableiten, dass, wenn nach einer Abfrage bestimmte Daten in den Speicher für eine der Engines eingehen, dieser Caching-Effekt für eine neue ankommende Abfrage von Vorteil sein kann. Deshalb berücksichtigt der Modellklassifikator 210 die Performance-Auswirkungen, die der Abfrageverlauf auf aktuelle Abfragen hat.
Das LSTM-Modell ist als Funktion f_θ formalisiert, die durch die Gewichte θ parametriert wird. Das LSTM-Modell empfängt zum Beispiel als Eingabe die eingebettete Abfrage q*, den Kontext C und den vorherigen verborgenen Zustand h_t-1 und stellt die vorhergesagte, zur Verarbeitung einer Abfrage (q, q') zu nutzende Datenbank-Engine (ŷ) bereit. Gl. 3 ist ein beispielhafter Algorithmus, der durch das LSTM-Modell zur Vorhersage einer optimalen Abfrage-Engine verwendet werden kann. Das LSTM-Modell aktualisiert nach jeder Bewertung auch seinen verborgenen Zustand h. $\cdot {\hat{y} = f}_{θ} (q*,C,h)$
Während des Trainings vergleicht der Modellüberprüfer 214 die Abfrageergebnisse der Datenbanken (y) (also die tatsächlichen Ausgaben (z. B. die Binärausgabe y)) und die vorhergesagten Ausgaben (ŷ) (z. B. die vorhergesagte Binärausgabe ŷ), die durch das LSTM-Modell geliefert wurden, um die Genauigkeit des LSTM-Modells zu bestimmen. Die Ergebnisse der in der Graphdatenbank 104 und der relationalen Datenbank 106 laufen gelassenen oder ausgeführten Abfragen (z. B. die Binärausgabe (y)) werden mit den vorhergesagten, durch das LSTM-Modell gelieferten Ergebnissen (ŷ) (z. B. der vorhergesagten Binärausgabe (ŷ)) verglichen. Die tatsächlichen Ergebnisse (y) werden mit den vorhergesagten Ergebnissen (ŷ) verglichen, um die Unterschiede zwischen ihnen zu bestimmen. Diese Unterschiede werden bei Backpropagationen und zur Angleichung eines oder mehrerer Gewichte im LSTM-Modell genutzt. In einigen Beispielen stellt der Modellüberprüfer 216 Mittel zum Überprüfen der Ergebnisse des Modellklassifikators bereit.
Das Optimierungsziel beim Trainieren der auf dem LSTM-Modell basierenden Binärklassifikatorgewichte θ basiert zum Beispiel, wie in der Gleichung 4 unten ausgedrückt, auf einem Kreuzentropieverlust mit Regularisierung: $\cdot \underset{Kreuzentropie}{\underset{︸}{L (θ) = y log (\hat{y}) + (1 - y) log (1 - \hat{y}) +}} \underset{Regularisierung}{\underset{︸}{λ \sum_{i = 0}^{N} θ_{i}^{2}}}$
Der Kreuzentropieterm bestraft falsche Vorhersagen und liefert das Haupttrainingssignal. Der Regularisierungsterm bestraft große Parameterwerte, verhindert ein Overfitting und ermöglicht eine bessere Verallgemeinerung. Der Betrag der Regularisierung kann durch λ abgestimmt werden und ist anwendungsabhängig. Die Optimierung nutzt eine Backpropagation durch Zeit mit einem Zeitfenster T. Das Zeitfenster bestimmt die Anzahl der vorherigen Abfragen, die Einfluss auf die vorhergesagte Abfrage-Performance haben, und λ kann für jede einzelne Anwendung empirisch abgestimmt werden. Diese Optimierungsprozedur basiert auf Gradienten (die aus der Kostenfunktionsbewertung hervorgehen) und der Lernrate α. $\cdot θ' = θ_{i} + α \nabla_{θ} L (θ)$
In einigen Beispielen wird das Training so lange durchgeführt, bis in dem Batch keine Probeabfragen mehr vorhanden sind. In einigen Fällen erfolgt das Training unter Nutzung von Hyperparametern (z. B. einer Lernrate oder einer Anzahl von Schichten zur Nutzung im Machine-Learning-Modell), die regeln, wie das Lernen durchgeführt wird. Das Training kann in Form von zeitlich festgelegten Lernfenstern, in denen mehrere Abfragebatches ausgeführt werden, implementiert werden. In diesem Beispiel spielt die Lernrate α eine wichtige Rolle bei der Anpassung des Abfrageauswahlsystems 100 an Zeitfenster, die Einfluss auf die Performance haben. Bei einer hohen Lernrate kann eine schnellere Anpassung des Modellklassifikators 210 an Änderungen in der Dynamik der Abfrage-Performance erfolgen (z. B. Spitzenzeitbedingungen, unter denen mehrere Benutzer Abfragen gleichzeitig ausgeben).
Sobald das Training abgeschlossen ist, wird das Modell (z. B. das LSTM-Modell) zur Nutzung als ausführbares Konstrukt eingesetzt, das basierend auf dem Netz aus Knoten und Verbindungen, die im Modell definiert sind, eine Eingabe (z. B. eine Abfrage q' und einen Kontext C_t) verarbeitet und eine Ausgabe (z. B. eine vorhergesagte Binärausgabe ŷ) liefert. Das Modell wird im Modelldatenspeicher 222 abgespeichert. Danach kann das Modell (z. B. das LSTM-Modell) durch den Modellklassifikator 210 ausgeführt werden.
3 ist ein Blockschema des beispielhaften Hybriddatenbankgenerators 108 des beispielhaften Abfrageauswahlsystems 100 aus 1 zum Generieren der relationalen Datenbank 106 aus Informationen, die aus einer Graphdatenbank 104 bezogen werden. Der beispielhafte Hybriddatenbankgenerator 108 in dem veranschaulichten Beispiel enthält einen beispielhaften zum Generieren relationaler Modelle vorgesehenen Generator 302, einen beispielhaften Objekt-Eigenschaft-Analysator 304 und einen beispielhaften Tabellenauffüller 306.
Der Objekt-Eigenschaft-Analysator 304 in dem veranschaulichten Beispiel extrahiert Informationen aus der Graphdatenbank 104 zum Generieren der relationalen Datenbank 106. Genauer untersucht der Objekt-Eigenschaft-Analysator 304 in der Graphdatenbank 104 abgespeicherte Daten und identifiziert ein oder mehrere in der Graphdatenbank 104 abgespeicherte Objekte. Eine Ausgabe des Objekt-Eigenschaft-Analysators 304 ist zum Beispiel eine Liste von Objekten und Eigenschaften, die eine signifikante Repräsentation aufweisen. In einigen Beispielen stellt der Objekt-Eigenschaft-Analysator 304 Mittel zum Identifizieren und/oder Extrahieren von Informationen in der Graphdatenbank 104 bereit.
Um zu bestimmen, ob ein Objekt und die zugehörigen Eigenschaften des Objekts eine signifikante Repräsentation aufweisen, bestimmt der Objekt-Eigenschaft-Analysator 304 in dem veranschaulichten Beispiel, ob eine Anzahl von Instanzen der Objekte in der Graphdatenbank 104 einen Schwellenwert überschreitet. Der Schwellenwert ist zum Beispiel möglicherweise eine Zahl, die größer als zum Beispiel 5, 10, 15, 100 oder ein beliebiger anderer Wert ist. Die als Schwellenwert dienende Anzahl von Instanzen ist empirisch bestimmbar und/oder kann von den Rechenfähigkeiten des Abfrageauswahlsystems 100 und dem im Abfrageauswahlsystem 100 verfügbaren Speicherplatz abhängen. In einigen Beispielen stellt der Objekt-Eigenschaft-Analysator 304 Mittel zum Bestimmen einer Anzahl von Instanzen eines Objekts in der Graphdatenbank 104 bereit. In einigen Beispielen stellt der Objekt-Eigenschaft-Analysator 304 Mittel zum Vergleichen einer Anzahl von Instanzen eines Objekts in der Graphdatenbank 104 mit einem Schwellenwert bereit.
Wenn ein identifiziertes Objekt den Schwellenwert überschreitet, extrahiert der Objekt-Eigenschaft-Analysator 304 in dem veranschaulichten Beispiel eine oder mehrere gemeinsame Eigenschaften der unterschiedlichen Objekte, die durch den Objekt-Eigenschaft-Analysator 304 identifiziert wurden. Genauer sind die extrahierten Eigenschaften den identifizierten Objekten zugeordnet und sind als gemeinsame Eigenschaften in allen identifizierten Objekten vorhanden. Eigenschaften, die in nur einer Instanz der identifizierten Objekte vorhanden sind, werden bei der Generierung einer relationalen Datenbank verworfen (z. B. nicht genutzt). Der Objekt-Eigenschaft-Analysator 304 in dem veranschaulichten Beispiel kann eine Tiefensuche (Depth-First Search, DFS) und/oder eine Breitensuche (Breadth-First Search, BFS) durchführen, dabei handelt es sich um Tools oder gängige Algorithmen für die Graphtraversierung zum Analysieren und Extrahieren der Hauptelemente im Graphen. Zum Beispiel kann eine Überwachungsanwendung einen Graphen mit vielen Objekten vom Typ „Person“ oder „Auto“ als Knoten in dem Graphen auffüllen. Aufgrund der Häufigkeit dieser Objekte (die z. B. einen Schwellenwert überschreitet), folgert der Objekt-Eigenschaft-Analysator 304, dass eine Anwendung am meisten an diesen Objekten interessiert ist. Sobald ein Graph eine Anzahl von Elementen eines Objekts oder einer Klasse („Person“, „Auto“ etc.) aufweist, die verglichen mit Elementen von weniger wichtigen Objekten oder Klassen signifikant ist, werden die Eigenschaften dieser Objekte dazu genutzt, um Tabellen nach einem relationalen Modell zu erzeugen. In einigen Beispielen stellt der Objekt-Eigenschaft-Analysator 304 Mittel zum Extrahieren einer oder mehrerer Eigenschaften, die einem in einer Graphdatenbank 104 abgespeicherten Objekt zugeordnet sind, bereit.
Weil Anwendungen neue Informationen mithilfe von Push laufend an die Graphdatenbank 104 übertragen/aktualisieren, führt der Objekt-Eigenschaft-Analysator 304 periodische Analysen an Daten in der Graphdatenbank 104 durch. Die Häufigkeit der Analysen kann von der jeweiligen Auslastung des Abfrageauswahlsystems 100 (z. B. nur lesend oder sowohl lesend als auch schreibend) abhängen.
Der zum Generieren relationaler Modelle vorgesehene Generator 302 generiert (z. B. automatisch) Code (z. B. einen SQL-Code) zum Anlegen eines relationalen Modells (z. B. von Tabellen und Primärschlüsseln). Jedes der durch den Objekt-Eigenschaft-Analysator 304 extrahierten Objekte ist als Zeile in einer Objekttabelle repräsentiert oder formatiert, und jede Eigenschaft dieser Objekte ist in einer Spalte in der Objekttabelle repräsentiert oder formatiert. Der zum Generieren relationaler Modelle vorgesehene Generator 302 generiert so viele Objekttabellen, wie unterschiedliche Objekte in den Daten repräsentiert sind. Die Codegenerierung durch den zum Generieren relationaler Modelle vorgesehenen Generator 302 erfolgt durch eine Verkettung von Zeichenfolgen, die sich aus der durch den Objekt-Eigenschaft-Analysator 304 bereitgestellten oder extrahierten Liste von Objekten und Eigenschaften ergeben (z. B. nach der SQL-Syntax). Der generierte Code wird ausgeführt, und die relevanten Objekttabellen werden erzeugt. Der zum Generieren relationaler Modelle vorgesehene Generator 302 hält (z. B. verfolgt) oder speichert die erzeugten Objekttabellen in einem Speicher ab und stellt diese Informationen als Eingabe in den Kontextabfrageklassifikator 112 und/oder den Abfragevalidierer 204 bereit. Der Kontextabfrageklassifikator 112 bestimmt zum Beispiel eine Verfügbarkeit der für relationale Abfragen vorgesehenen Engine 116 basierend auf den Objekttabelleninformationen, die durch den zum Generieren relationaler Modelle vorgesehenen Generator 302 bereitgestellt werden. In einigen Beispielen bestimmt der Kontextabfrageklassifikator 112 eine Verfügbarkeit der für relationale Abfragen vorgesehenen Engine 116 basierend auf der Ausgabe der Liste von Objekten und Eigenschaften, die durch den Objekt-Eigenschaft-Analysator 304 bereitgestellt wurde. In einigen Beispielen stellt der zum Generieren relationaler Modelle vorgesehene Generator Mittel zum Generieren von Code zum Einrichten einer oder mehrerer Tabellen in der relationalen Datenbank 106 bereit. In einigen Beispielen stellt der Objekt-Eigenschaft-Analysator 304 Mittel zum Ausführen von Code oder zum Generieren von Tabellen (z. B. Objekttabellen) für die relationale Datenbank 106 bereit.
Der Tabellenauffüller 306 in dem veranschaulichten Beispiel verschiebt die Daten (z. B. die Objekte und ihre Eigenschaften) aus der Graphdatenbank 104 in die jeweiligen generierten relationalen Objekttabellen, die durch den zum Generieren relationaler Modelle vorgesehenen Generator 302 generiert wurden. Mithin füllt der Tabellenauffüller 306 die Objekttabellen, die durch den zum Generieren relationaler Modelle vorgesehenen Generator 302 erzeugt wurden, mit durch den Objekt-Eigenschaft-Analysator 304 identifizierten Objekten und Eigenschaften auf, um die relationale Datenbank 106 zu generieren. Der Tabellenauffüller 306 wahrt zudem die Konsistenz relationaler Datenbanken, indem er bestätigt, dass Schreiboperationen in der Graphdatenbank 104 in die jeweiligen Objekttabellen der relationalen Datenbank 106 richtig übernommen wurden. In einigen Beispielen führt der Tabellenauffüller 306 in jeder Objekttabelle eine Liste von Objekten und Eigenschaften. Bei jeder neuen Schreibabfrage erfolgt eine Prüfung der Abfrage auf Änderungen in den Eigenschaften oder Objekten, die in den Objekttabellen repräsentiert sind, und der Tabellenauffüller 306 propagiert diese Änderungen, falls nötig. In einigen Beispielen stellt der Tabellenauffüller 306 Mittel zum Auffüllen einer oder mehrerer Tabellen der relationalen Datenbank 106 mit Daten (z. B. Objekten und Eigenschaften) bereit.
In den 1-3 ist beispielhaft veranschaulicht, wie sich das Abfrageauswahlsystem 100 implementieren lässt, jedoch können eines oder mehrere der Elemente, einer oder mehrere der Prozesse und/oder eine oder mehrere der Einrichtungen, die in den 1-3 veranschaulicht sind, auch kombiniert, aufgeteilt, anders angeordnet, weggelassen, entfernt und/oder auf eine beliebige andere Weise implementiert werden. Ferner können die beispielhafte Hybriddatenbank 102, die Graphdatenbank 104, die beispielhafte relationale Datenbank 106, der beispielhafte Hybriddatenbankgenerator 108, die beispielhafte Graphsprachabfrage 110, der beispielhafte Kontextabfrageklassifikator 112, die beispielhafte Graphabfrage-Engine 114, die beispielhafte für relationale Abfragen vorgesehene Engine 116, der Übersetzer 117, der beispielhafte Datenspeicher 118, der beispielhafte Abfrageparser 202, der beispielhafte Abfragevalidierer 204, der beispielhafte Abfragetracker 206, der beispielhafte Vektorkonverter 208, das beispielhafte Klassifikatormodell 210, der beispielhafte Klassifikatormodelltrainer 212, der beispielhafte Machine-Leaming-Modelltrainerverarbeiter 214, der beispielhafte Modellüberprüfer 216, der beispielhafte Kontextbestimmer 218, der beispielhafte Abfragedatenspeicher 220, der beispielhafte Modelldatenspeicher 222, der beispielhafte zum Generieren relationaler Modelle vorgesehene Generator 302, der beispielhafte Objekt-Eigenschaft-Analysator 304, der beispielhafte Tabellenauffüller 306 und/oder allgemeiner das beispielhafte Abfrageauswahlsystem 100 aus den 1-3 durch Hardware, Software, Firmware und/oder eine beliebige Kombination aus Hardware, Software und/oder Firmware implementiert werden. Mithin könnten die beispielhafte Hybriddatenbank 102, die Graphdatenbank 104, die beispielhafte relationale Datenbank 106, der beispielhafte Hybriddatenbankgenerator 108, die beispielhafte Graphsprachabfrage 110, der beispielhafte Kontextabfrageklassifikator 112, die beispielhafte Graphabfrage-Engine 114, die beispielhafte für relationale Abfragen vorgesehene Engine 116, der Übersetzer 117, der beispielhafte Datenspeicher 118, der beispielhafte Abfrageparser 202, der beispielhafte Abfragevalidierer 204, der beispielhafte Abfragetracker 206, der beispielhafte Vektorkonverter 208, das beispielhafte Klassifikatormodell 210, der beispielhafte Klassifikatormodelltrainer 212, der beispielhafte Machine-Leaming-Modelltrainerverarbeiter 214, der beispielhafte Modellüberprüfer 216, der beispielhafte Kontextbestimmer 218, der beispielhafte Abfragedatenspeicher 220, der beispielhafte Modelldatenspeicher 222, der beispielhafte zum Generieren relationaler Modelle vorgesehene Generator 302, der beispielhafte Objekt-Eigenschaft-Analysator 304, der beispielhafte Tabellenauffüller 306 und/oder allgemeiner das beispielhafte Abfrageauswahlsystem 100 aus den 1-3 zum Beispiel durch eine oder mehrere analoge oder digitale logische Schaltungen, einen oder mehrere programmierbare Prozessoren, einen oder mehrere programmierbare Controller, einen oder mehrere Grafikprozessoren (GPU(s)), einen oder mehrere Digitalsignalprozessoren (DSP(s)), eine oder mehrere anwendungsspezifische integrierte Schaltungen (ASIC(s)), einen oder mehrere Logikbausteine (PLD(s)) und/oder einen oder mehrere vom Anwender programmierbare Logikbausteine (FPLD(s)) implementiert werden. Werden Vorrichtungs- oder Systemansprüche dieses Patents derart interpretiert, dass sie eine reine Software- und/oder Firmware-Implementierung abdecken, wird hiermit mindestens eines von der beispielhaften Hybriddatenbank 102, der Graphdatenbank 104, der beispielhaften relationalen Datenbank 106, dem beispielhaften Hybriddatenbankgenerator 108, der beispielhaften Graphsprachabfrage 110, dem beispielhaften Kontextabfrageklassifikator 112, der beispielhaften Graphabfrage-Engine 114, der beispielhaften für relationale Abfragen vorgesehenen Engine 116, dem Übersetzer 117, dem beispielhaften Datenspeicher 118, dem beispielhaften Abfrageparser 202, dem beispielhaften Abfragevalidierer 204, dem beispielhaften Abfragetracker 206, dem beispielhaften Vektorkonverter 208, dem beispielhaften Klassifikatormodell 210, dem beispielhaften Klassifikatormodelltrainer 212, dem beispielhaften Machine-Learning-Modelltrainerverarbeiter 214, dem beispielhaften Modellüberprüfer 216, dem beispielhaften Kontextbestimmer 218, dem beispielhaften Abfragedatenspeicher 220, dem beispielhaften Modelldatenspeicher 222, dem beispielhaften zum Generieren relationaler Modelle vorgesehenen Generator 302, dem beispielhaften Objekt-Eigenschaft-Analysator 304 und dem beispielhaften Tabellenauffüller 306 ausdrücklich als ein nichttransientes, computerlesbares, die Software und/oder Firmware enthaltendes Speicherelement oder eine nichttransiente, computerlesbare, die Software und/oder Firmware enthaltende Speicherplatte wie etwa ein Speicher, eine DVD (Digital Versatile Disk), eine CD (Compact Disk) oder eine Blu-ray Disc definiert. Darüber hinaus kann das Abfrageauswahlsystem 100 aus den 1-3 ein oder mehrere Elemente, einen oder mehrere Prozesse und/oder eine oder mehrere Einrichtungen entweder zusätzlich zu denjenigen, die in den 1-3 veranschaulicht sind, oder an ihrer Stelle enthalten und/oder kann mehr als nur eines von beliebigen oder allen der veranschaulichten Elemente, mehr als nur einen von beliebigen oder allen der veranschaulichten Prozesse bzw. mehr als nur eine von beliebigen oder allen der veranschaulichten Einrichtungen enthalten. Der Ausdruck „in Kommunikation“ sowie Varianten davon, wie hierin genutzt, bedeutet, dass eine direkte oder indirekte Kommunikation durch eine oder mehrere Zwischenkomponenten erfolgen kann, er bedeutet nicht, dass eine direkte physische (z. B. drahtgebundene) und/oder ständige Kommunikation erfolgen muss, und kann darüber hinaus bedeuten, dass eine selektive Kommunikation in periodischen Abständen, zeitlich festgelegten Abständen, aperiodischen Abständen und/oder in Form einmaliger Ereignisse erfolgt.
In den 4, 5, 6 und 7 sind Ablaufschemata gezeigt, die repräsentativ für eine beispielhafte Hardwarelogik, beispielhafte maschinenlesbare Befehle, beispielhafte in Hardware implementierte Zustandsmaschinen oder beliebige Kombinationen davon zum Implementieren des Abfrageauswahlsystems 100 aus den 1, 2 und 3 sind. Bei den maschinenlesbaren Befehlen handelt es sich möglicherweise um ein oder mehrere ausführbare Programme oder einen oder mehrere Teile eines ausführbaren Programms zur Ausführung durch einen Computerprozessor wie den Prozessor 1012, der in der beispielhaften Prozessorplattform 1000, die in Verbindung mit 10 unten erörtert wird, gezeigt ist. Das Programm kann in Software, die in einem nichttransienten, computerlesbaren Speichermedium, etwa auf einer CD-ROM, einer Diskette, einer Festplatte, einer DVD, einer Blu-ray Disc oder in einem dem Prozessor 1012 zugeordneten Speicher liegt, realisiert sein, jedoch könnten das ganze Programm oder Teile davon statt durch den Prozessor 1012 alternativ auch durch andere Elemente ausgeführt werden und/oder in Firmware oder dedizierter Hardware realisiert sein. Ferner wird das beispielhafte Programm zwar mit Bezug auf das in den 4, 5, 6 und 7 veranschaulichte Ablaufschema beschrieben, jedoch kommen alternativ noch viele weitere Verfahren zum Implementieren des beispielhaften Abfrageauswahlsystems 100 in Frage. Zum Beispiel kann die Reihenfolge der Ausführung der Blöcke geändert werden, und/oder einige der beschriebenen Blöcke können geändert, entfernt oder kombiniert werden. Darüber hinaus oder alternativ sind beliebige einzelne oder auch alle der Blöcke durch eine oder mehrere Hardwareschaltungen (z. B. diskrete und/oder integrierte analoge und/oder digitale Schaltungsbauteile, ein FPGA, einen ASIC, einen Komparator, einen Operationsverstärker (OpAmp) oder eine logische Schaltung), die so strukturiert sind, dass sie die korrespondierende Operation ohne Ausführung von Software oder Firmware durchführen, implementierbar.
Die hierin beschriebenen maschinenlesbaren Befehle können in einem oder mehreren komprimierten, verschlüsselten, fragmentierten, kompilierten, ausführbaren oder Paketformaten abgespeichert sein. Maschinenlesbare Befehle, wie hierin beschrieben, können als Daten (z. B. Abschnitte von Befehlen, Code oder Darstellungen von Code), die zum Erzeugen, Herstellen und/oder Produzieren maschinenlesbarer Befehle gebraucht werden können, abgespeichert sein. Die maschinenlesbaren Befehle sind zum Beispiel möglicherweise fragmentiert und in einem oder mehreren Speicherelementen und/oder einem oder mehreren Computergeräten (z. B. Servern) abgespeichert. Die maschinenlesbaren Befehle erfordern möglicherweise eine Installation und/oder Modifizierung und/oder Anpassung und/oder Aktualisierung und/oder Kombination und/oder Ergänzung und/oder Konfiguration und/oder Entschlüsselung und/oder Dekomprimierung und/oder Entpackung und/oder Verteilung und/oder Neuzuweisung und/oder Kompilierung etc., damit sie von einem Computergerät und/oder einer anderen Maschine direkt gelesen, interpretiert und/oder ausgeführt werden können. Die maschinenlesbaren Befehle können zum Beispiel in mehreren Teilen, die einzeln komprimiert, verschlüsselt und in separaten Computergeräten abgespeichert werden, abgespeichert sein, wobei die Teile, wenn sie entschlüsselt, dekomprimiert und kombiniert werden, einen Satz ausführbarer Befehle, die ein Programm wie das hierin beschriebene Programm implementieren, bilden.
In einem weiteren Beispiel sind die maschinenlesbaren Befehle möglicherweise in einem Zustand abgespeichert, in dem sie von einem Computer gelesen werden können, in dem jedoch zusätzlich, damit sie in einem bestimmten Computergerät oder sonstigen Gerät ausgeführt werden können, eine Bibliothek (z. B. eine Dynamic Link Library (DLL)), ein Software-Development-Kit (SDK) oder eine Anwendungsprogrammierschnittstelle (API) nötig ist. In einem weiteren Beispiel müssen die maschinenlesbaren Befehle möglicherweise erst konfiguriert werden (z. B. müssen Einstellungen abgespeichert, Daten eingegeben oder Netzadressen registriert werden), bevor die maschinenlesbaren Befehle und/oder das korrespondierende Programm (die korrespondierenden Programme) ganz oder teilweise ausgeführt werden können. Unter den maschinenlesbaren Befehlen und/oder dem korrespondierenden Programm (den korrespondierenden Programmen), wie hierin offenbart, sind mithin derartige maschinenlesbare Befehle und/oder ein derartiges korrespondierendes Programm (derartige korrespondierende Programme) unabhängig von ihrem jeweiligen Format oder Zustand zu verstehen, diese können etwa gerade abgespeichert sein oder an einer anderen Stelle liegen oder werden möglicherweise gerade übertragen.
Die hierin beschriebenen maschinenlesbaren Befehle sind durch eine beliebige frühere, aktuelle oder künftige Befehlssprache, Skriptsprache oder Programmiersprache darstellbar. Die maschinenlesbaren Befehle sind zum Beispiel unter Nutzung einer der folgenden Sprachen darstellbar: C, C++, Java, C#, Perl, Python, JavaScript, HyperText Markup Language (HTML), Structured Query Language (SQL), Swift etc.
Wie oben erwähnt, können die beispielhaften Prozesse aus den 4, 5, 6 und 7 unter Nutzung ausführbarer Befehle (z. B. computer- oder maschinenlesbarer Befehle) implementiert werden, die in einem nichttransienten, computer- oder maschinenlesbaren Medium, etwa auf einer Festplatte, in einem Flashspeicher, einem Festwertspeicher, auf einer CD, einer DVD, in einem Cache, einem Arbeitsspeicher oder einem beliebigen anderen Speicherelement oder einer beliebigen anderen Speicherplatte, in dem/der Informationen beliebig lang (z. B. über längere Zeitabschnitte, dauerhaft, kurz, vorübergehend bei einer Zwischenspeicherung und/oder bei einem Caching der Informationen) liegen können, abgespeichert sind. Der Begriff nichttransientes, computerlesbares Medium, wie hierin genutzt, wird ausdrücklich so definiert, dass er computerlesbare Speicherelemente und -platten von einem beliebigen Typ einschließt, die Ausbreitung von Signalen und Übertragungsmedien aber ausschließt.
Die Begriffe „enthalten“ und „umfassen“ (einschließlich aller Formen und Zeiten) sind hierin als offene Begriffe zu verstehen. Es versteht sich also, dass, immer wenn in einem Anspruch einer der Begriffe „enthalten“ oder „umfassen“ in irgendeiner Form (z. B. umfasst, enthält, umfassend, enthaltend oder aufweisend) im Oberbegriff oder innerhalb einer Anspruchsdefinition verwendet wird, weitere Elemente, Begriffe etc. zusätzlich vorhanden sein können, ohne dass hierbei der Schutzbereich des betreffenden Anspruchs oder der betreffenden Definition verlassen wird. Wenn der Ausdruck „mindestens“ hierin dazu genutzt wird, um Wörter zum Beispiel im Oberbegriff eines Anspruchs aneinanderzureihen, ist er ebenso wie die Begriffe „umfassen“ und „enthalten“ als offener Begriff aufzufassen. Wird das Konjunktionspaar „und/oder“ zum Beispiel in der Form A, B und/oder C genutzt, kann eine beliebige Kombination oder Teilmenge aus A, B, C, etwa (1) nur A, (2) nur B, (3) nur C, (4) A mit B, (5) A mit C, (6) B mit C oder (7) A mit B und mit C, gemeint sein. Im Zusammenhang mit der Beschreibung von Strukturen, Komponenten, Einzelteilen, Objekten und/oder Dingen bezieht sich die Formulierung „mindestens eines von A und B“, wie hierin genutzt, auf Implementierungen, die Folgendes einschließen: (1) mindestens ein Element A, (2) mindestens ein Element B und (3) mindestens ein Element A und mindestens ein Element B. Analog bezieht sich die Formulierung „mindestens eines von A oder B“, wie hierin genutzt, im Zusammenhang mit der Beschreibung von Strukturen, Komponenten, Einzelteilen, Objekten und/oder Dingen auf Implementierungen, die Folgendes einschließen: (1) mindestens ein Element A, (2) mindestens ein Element B und (3) mindestens ein Element A und mindestens ein Element B. Im Zusammenhang mit der Beschreibung der Durchführung oder Abarbeitung von Prozessen, Befehlen, Aktionen, Aktivitäten und/oder Schritten bezieht sich die Formulierung „mindestens eines von A und B“, wie hierin genutzt, auf Implementierungen, die Folgendes einschließen: (1) mindestens ein Element A, (2) mindestens ein Element B und (3) mindestens ein Element A und mindestens ein Element B. Analog bezieht sich die Formulierung „mindestens eines von A oder B“, wie hierin genutzt, im Zusammenhang mit der Beschreibung der Durchführung oder Abarbeitung von Prozessen, Befehlen, Aktionen, Aktivitäten und/oder Schritten auf Implementierungen, die Folgendes einschließen: (1) mindestens ein Element A, (2) mindestens ein Element B und (3) mindestens ein Element A und mindestens ein Element B.
Werden hierin Wörter, die die Einzahl ausdrücken, genutzt (z. B. „ein“, „eine“, „erster“ oder „zweiter“), wird hierdurch nicht ausgeschlossen, dass auch die Mehrzahl gemeint sein könnte. Wird hierin auf „eine“ Einheit Bezug genommen, können eine oder mehrere dieser Einheit gemeint sein. Formulierungen mit den Wörtern „ein“ (oder „eine“), „ein oder mehrere“ oder „mindestens eines“ sind hierin untereinander austauschbar. Des Weiteren ist eine Vielzahl von Mitteln, Elementen oder Verfahrensschritten, selbst wenn diese einzeln aufgeführt werden, z. B. durch eine einzige Einheit oder einen einzigen Prozessor implementierbar. Darüber hinaus stehen einzelne Merkmale möglicherweise in unterschiedlichen Beispielen oder Ansprüchen, sind aber trotzdem eventuell kombinierbar, denn dadurch, dass diese in unterschiedlichen Beispielen oder Ansprüchen stehen, wird nicht stillschweigend angedeutet, dass eine Kombination von Merkmalen nicht möglich und/oder vorteilhaft ist.
4 ist ein Ablaufschema, das für maschinenlesbare Befehle, die zum Implementieren des beispielhaften Abfrageauswahlsystems 100 aus 1 ausgeführt werden können, repräsentativ ist. Der beispielhafte Prozess 400 aus 4 beginnt, wenn das Abfrageauswahlsystem 100 eine Abfrage empfängt (Block 402). Der Start des Abfrageauswahlsystems 100 aus 1 erfolgt zum Beispiel dann, wenn die Graphsprachabfrage 110 die Abfrage 115 vom Benutzer 111 empfängt.
Das Abfrageauswahlsystem 100 konvertiert die empfangene Abfrage (Block 404). Die Graphsprachabfrage 110 konvertiert die empfangene Abfrage 115 zum Beispiel in eine Sprachsyntaxabfrage, zum Beispiel eine Funktionsabfrageschnittstelle (q). Die Graphsprachabfrage 110 identifiziert zum Beispiel eine Funktion der Abfrage 115 und die Eingabeargumente (z. B. „name“ oder „Hercules“), die der identifizierten Funktion zugeordnet sind. Die Eingabeargumente können zum Beispiel für Objekte (z. B. eine Klassifizierung nach dem Namen) und Eigenschaften (z. B. Hercules) der Objekte, die der Abfrage 115 zugeordnet sind, repräsentativ sein.
Das Abfrageauswahlsystem 100 identifiziert ein oder mehrere Objekte und/oder eine oder mehrere Eigenschaften, die der Abfrage zugeordnet sind (Block 406). Zum Beispiel identifiziert der Abfragevalidierer 204 des Kontextabfrageklassifikators 112 das Objekt und/oder die Eigenschaft aus der Funktionsabfrageschnittstelle (q).
Das Abfrageauswahlsystem 100 bestimmt, ob die der Abfrage 115 zugeordneten Objekte und Eigenschaften (z. B. die funktionalisierte Abfrage (q)) in der relationalen Datenbank 106 vorhanden sind (Block 408). Zum Beispiel vergleicht der Kontextabfrageklassifikator 112 (z. B. über den Abfragevalidierer 204) die Objekte und/oder Eigenschaften aus der Abfrage 115 mit der Liste von Objekttabellen, Objekten und/oder Eigenschaften, die vom Hybriddatenbankgenerator 108 (über den zum Generieren relationaler Modelle vorgesehenen Generator 302) geführt werden.
Bestimmt der Kontextabfrageklassifikator 112, dass für das Objekt oder die Eigenschaft der Abfrage 115 keine relationale Datenbank 106 generiert wird (Block 410 liefert das Ergebnis NEIN zurück), leitet der Kontextabfrageklassifikator 112 die Abfrage 115 an die Graphabfrage-Engine 114 (Block 412), und der Prozess 400 endet.
Bestimmt der Kontextabfrageklassifikator 112, dass für das Objekt oder die Eigenschaft der Abfrage 115 eine relationale Datenbank 106 generiert wird (Block 410 liefert das Ergebnis JA zurück), bestimmt der Kontextabfrageklassifikator 112 eine optimale Abfrage-Engine für die Abfrage 115 (Block 414). Der Modellklassifikator 210 empfängt zum Beispiel vom Vektorkonverter 208 die eingebettete Abfrage (q*) und vom Kontextbestimmer 218 die Informationen zum Kontext C_t und verarbeitet die eingegebenen Informationen unter Nutzung des LSTM-Modellklassifikators (LSTM = Long-Short Term Memory), um vorherzusagen, welche Such-Engine (z. B. die Graphabfrage-Engine 114 oder die für relationale Abfragen vorgesehene Engine 116) die effizienteste oder optimale Performance zum Ausführen der Abfrage 115 bietet. Die eingebettete Abfrage (q*) und die Informationen zum Kontext C_t liegen zum Beispiel übereinander und werden als Eingaben in den LSTM-Modellklassifikator bereitgestellt. Bei dieser Methode werden aktuelle und frühere Zustände des Abfrageauswahlsystems 100 wirksam berücksichtigt, und es wird eine kontextbezogene Klassifizierung durchgeführt, bei der die schnellste oder optimale Such-Engine für eine gegebene Abfrage und einen gegebenen Kontext C_t vorhergesagt wird.
Bestimmt der Kontextabfrageklassifikator 112, dass das relationale Modell nicht schneller ist (Block 416 liefert das Ergebnis NEIN zurück), leitet der Kontextabfrageklassifikator 112 die Abfrage 115 zur Verarbeitung oder Ausführung der Abfrage 115 unter Nutzung der Graphdatenbank 104 an die Graphabfrage-Engine 114, und der Prozess 400 endet.
Bestimmt der Kontextabfrageklassifikator 112, dass das relationale Modell schneller ist (Block 416 liefert das Ergebnis JA zurück), leitet der Kontextabfrageklassifikator 112 die Abfrage 115 zur Verarbeitung oder Ausführung der Abfrage 115 unter Nutzung der relationalen Datenbank 106 an die für relationale Abfragen vorgesehene Engine 116, und der Prozess 400 endet.
5 ist ein Ablaufschema, das für maschinenlesbare Befehle, die zum Implementieren des Modellklassifikators 210 (z. B. des sequenzbezogenen Modells (z. B. eines LSTM-Modells) des beispielhaften Abfrageauswahlsystems aus 1 und 2) ausgeführt werden können, repräsentativ ist. Der beispielhafte Prozess 500 aus 5 enthält eine Trainingsphase 501 und eine Arbeitsphase 502. Der Modellklassifikator 210 des Abfrageauswahlsystems 100 tritt in die Trainingsphase 501 ein, in der der beispielhafte Modelltrainer 212 ein Machine-Learning-Modell trainiert (Block 503). Ein beispielhafter Prozess zum Trainieren des Machine-Learning-Modells wird unten in Verbindung mit dem veranschaulichten Beispiel von 6 beschrieben. Ein Machine-Learning-Modell wird so trainiert, dass es eine optimale Such-Engine für eine empfangene Abfrage basierend auf Informationen des Abfrageauswahlsystems 100 zum Kontext C_t beim Ausführen der Abfrage vorhersagen kann.
Sobald das Training abgeschlossen ist, tritt der Modellklassifikator 210 in die Arbeitsphase 502 ein. Sobald der Kontextabfrageklassifikator 112 die Abfrage 115 (oder die Funktionsabfrageschnittstelle (q)) von der Graphsprachabfrage 110 empfangen hat, parst der Abfrageparser 202 die Abfrage 115 (oder die Funktionsabfrageschnittstelle (q)) und stellt eine geparste Abfrage (q') bereit (Block 504). Der Vektorkonverter 208 konvertiert die geparste Abfrage (q') in eine eingebettete Abfrage (q*) (z. B. ein Vektor-Array) zur Nutzung als Eingabe für den Modellklassifikator 210 (Block 506). Der Kontextbestimmer 218 bestimmt die Informationen zum Kontext C_t und stellt die Informationen zum Kontext zur Nutzung als Eingabe für den Modellklassifikator 210 bereit (Block 508). Der Modellklassifikator 210 führt basierend auf der geparsten Abfrage (q') und den Informationen zum Kontext C_t sowie unter Nutzung eines LSTM-Modells (LSTM = Long-Short Term Memory) eine Binärklassifikation durch (Block 510). Genauer führt der Modellklassifikator 210 eine Binärklassifikation dazu durch, um eine optimale (z. B. die beste oder schnellste) Datenbank-Engine zum Laufenlassen oder Ausführen der Abfrage 115 auszuwählen. Der verborgene LSTM-Zustand berücksichtigt die Wirkung früherer Abfragen sowie historischer Kontextinformationen. Genauer sagt der Modellklassifikator 210 eine Binärausgabe vorher (z. B. die Ausgabe ŷ = {0, 1)). Wenn der Modellklassifikator 210 vorhersagt, dass eine relationale Binärausgabe null ist (wenn der Block 512 das Ergebnis NEIN zurückliefert), bestimmt der Modellklassifikator 210, dass das relationale Modell schneller ist 514 (z. B. ist das relationale Modell optimal für die Ausführung der Abfrage 115 oder führt sie schneller aus). Wenn der Modellklassifikator 210 vorhersagt, dass eine relationale Binärausgabe null ist (wenn der Block 512 das Ergebnis JA zurückliefert), bestimmt der Modellklassifikator 210, dass das relationale Modell nicht schneller ist (Block 516) (z. B. ist das Graphenmodell optimal für die Ausführung der Abfrage 115 oder führt sie schneller aus).
6 ist ein Ablaufschema, das für maschinenlesbare Befehle, die zum Implementieren eines beispielhaften Modelltrainers 212 des beispielhaften Abfrageauswahlsystems aus 1 zum Trainieren eines Machine-Learning-Modells (z. B. eines LSTM-Modells) ausgeführt werden können, repräsentativ ist. Der Prozess 600 implementiert das Trainieren des sequenzbezogenen LSTM-Modells (Block 503) aus 5. Der Modelltrainer 212 initiiert das Training des Modellklassifikators 210 über den Machine-Learning-Modelltrainerverarbeiter 214 (Block 602). Der Modelltrainer 212 initiiert das Training des Modellklassifikators 210 zum Beispiel als Antwort auf die Detektion, dass das Abfrageauswahlsystem 100 offline ist, eine Anzahl von im Abfragedatenspeicher 220 abgespeicherten Abfragen einen Schwellenwert erreicht hat oder ein Trainingsablauf initiiert wird.
Während des Trainings bezieht oder ruft der Modelltrainer 212 frühere, im Abfragedatenspeicher 220 abgespeicherte Abfragen ab (Block 604). Der Modelltrainer 212 ruft zum Beispiel einen Batch früherer Abfragen ab, die während eines ersten Trainingsabschnitts zu verarbeiten sind.
Der Modelltrainer 212 empfängt oder ruft Informationen des Abfrageauswahlsystems 100 zum Kontext C_t ab (Block 606).
Der Modelltrainer 212 führt nach der Bestimmung oder Registrierung der C_t-Informationen eine frühere Abfrage unter Nutzung der Graphdatenbank 104 aus (Block 608). Der Modelltrainer 212 führt im Block 608 eine frühere Abfrage unter Nutzung der Graphdatenbank 104 aus, um eine Grundwahrheit für einen Vergleich mit dem vorhergesagten Ergebnis des LSTM-Modells zu ermitteln. Zum Beispiel verwendet der Modelltrainer 212 die Graphabfrage-Engine 114, um jeweilige abgerufene, frühere Abfragen über die Graphdatenbank 104 auszuführen. Der Modelltrainer 212 bestimmt oder registriert über einen Timer eine erste Ausführungszeit für die jeweiligen abgerufenen, früheren Abfragen (Block 610). Zum Beispiel bestimmt oder registriert der Modelltrainer 212 erste Ausführungszeiten für alle jeweiligen abgerufenen, früheren Abfragen, die durch die Graphabfrage-Engine 114 ausgeführt wurden. Darüber hinaus führt der Modelltrainer 212 die frühere Abfrage unter Nutzung der relationalen Datenbank 106 aus (Block 612). Zum Beispiel verwendet der Modelltrainer 212 die für relationale Abfragen vorgesehene Engine 116, um jeweilige abgerufene, frühere Abfragen über die relationale Datenbank 106 auszuführen. Der Modelltrainer 212 bestimmt oder registriert über den Timer eine zweite Ausführungszeit für die frühere Abfrage (Block 614). Zum Beispiel bestimmt oder registriert der Modelltrainer 212 zweite Ausführungszeiten für alle jeweiligen abgerufenen, früheren Abfragen, die durch die für relationale Abfragen vorgesehene Engine 116 ausgeführt wurden.
Der Modelltrainer 212 vergleicht nach der Ausführung der früheren Abfrage an der Graphdatenbank 104 und der relationalen Datenbank 106 die erste Ausführungszeit und die zweite Ausführungszeit (z. B. über einen Komparator) (Block 616) und bestimmt die Abfrage-Engine, aus der sich die schnellste Ausführungszeit ergeben hat (Block 618). Zum Beispiel bestimmt, analysiert oder vergleicht der Modelltrainer 212 (z. B. über einen Komparator) die erste Ausführungszeit und die zweite Ausführungszeit, um die Abfrage-Engine, aus der sich die schnellste Ausführungszeit ergeben hat, zu bestimmen. So ermittelt der Modelltrainer 212 eine Grundwahrheit (z. B. die oben genannte Binärausgabe (y)) für einen Vergleich mit dem vorhergesagten Ergebnis des LSTM-Modells. Der Modelltrainer 212 annotiert die frühere Abfrage mit dem Ergebnis der Abfrage-Engine, die die frühere Abfrage am schnellsten ausgeführt hat (Block 620).
Der Abfrageparser 202 parst die annotierte frühere Abfrage (Block 622). Der Vektorkonverter 208 übersetzt oder konvertiert die annotierte, geparste frühere Abfrage (z. B. über Word2Vec) zur Verarbeitung durch das LSTM-Modell (Block 624). Das LSTM-Modell empfängt und verarbeitet die konvertierte, annotierte, geparste frühere Abfrage und die C_t-Informationen im Modell (Block 626) (z. B. über die oben genannte Trainingsprozedur). Im Block 626 werden die annotierte, geparste frühere Abfrage und die C_t-Informationen dazu verwendet, um das LSTM-Modell zum Vorhersagen einer zu nutzenden Datenbank-Engine (z. B. der vorhergesagten Ausgabe (ŷ)) zu trainieren.
Der Modellüberprüfer 216 überprüft oder vergleicht das vorhergesagte Ergebnis (ŷ) mit der Grundwahrheit (y) (Block 628), um zu bestimmen, ob das vorhergesagte Ergebnis mit der Grundwahrheit übereinstimmt (Block 630). Wenn der Modellüberprüfer 216 bestimmt, dass das vorhergesagte Ergebnis (ŷ) nicht mit der Grundwahrheit (y) übereinstimmt (wenn der Block 630 das Ergebnis NEIN zurückliefert), weist der Modellüberprüfer 216 den Modelltrainer 212 zum Aktualisieren des LSTM-Modells an (Block 632). Zum Beispiel dient dem Modellüberprüfer 216 die Differenz zwischen dem vorhergesagten Ergebnis (ŷ) und der Grundwahrheit (y) für eine Backpropagation und das Angleichen eines oder mehrerer Parameter (z. B. von Gewichten) des LSTM-Modells. Darüber hinaus aktualisiert das LSTM-Modell nach jeder Bewertung (im Block 630 und im Block 632) (z. B. wenn der Block 630 das Ergebnis JA zurückliefert) den verborgenen Zustand (Block 634).
Nach der Aktualisierung des LSTM-Modells bestimmt der Modelltrainer 212, ob eine weitere Abfrage durchzuführen ist (Block 636). Wenn der Modelltrainer 212 bestimmt, dass eine weitere Abfrage durchzuführen ist (wenn der Block 636 das Ergebnis JA zurückliefert), wird beim Prozess 600 zum Block 604 zurückgekehrt. Der Modelltrainer 212 bestimmt zum Beispiel, dass die Durchführung einer weiteren Abfrage erforderlich ist, wenn eine oder mehrere frühere Abfragen im Batch der für ein Training vorgesehenen Abfragen noch zu verarbeiten sind, wenn ein Trainingsablauf-Zeitfenster noch nicht geendet hat oder wenn das Abfrageauswahlsystem 100 keine Abfrage (z. B. vom Benutzer 111) empfangen hat. Wenn der Modelltrainer 212 bestimmt, dass keine weitere Abfrage durchzuführen ist (wenn der Block 636 das Ergebnis NEIN zurückliefert), endet der Prozess 600. Der Modelltrainer 212 bestimmt zum Beispiel, dass keine Durchführung einer weiteren Abfrage erforderlich ist, wenn der Batch der für ein Training vorgesehenen Abfragen ganz verarbeitet worden ist, wenn ein Trainingsablauf-Zeitfenster geendet hat oder wenn das Abfrageauswahlsystem 100 eine Abfrage (z. B. vom Benutzer 111) empfangen hat.
7 ist ein Ablaufschema, das für maschinenlesbare Befehle, die vom Hybriddatenbankgenerator 108 zum Generieren der beispielhaften relationalen Datenbank 106 des beispielhaften Abfrageauswahlsystems 100 aus 1 aus Informationen, die aus der Graphdatenbank 104 bezogen werden, ausgeführt werden können, repräsentativ ist. Der Objekt-Eigenschaft-Analysator 304 führt eine Graphdatenbankanalyse durch (Block 702). In einigen Beispielen analysiert der Objekt-Eigenschaft-Analysator 304 Informationen oder Daten in der Graphdatenbank 104 periodisch. In einigen Beispielen analysiert der Objekt-Eigenschaft-Analysator 304 Informationen oder Daten in der Graphdatenbank 104 immer dann, wenn neue Informationen in die Graphdatenbank 104 geschrieben werden.
Der Objekt-Eigenschaft-Analysator 304 identifiziert neue Informationen in der Graphdatenbank 104 (Block 704). Wenn der Objekt-Eigenschaft-Analysator 304 keine neuen Informationen in der Graphdatenbank identifiziert (wenn der Block 704 das Ergebnis NEIN zurückliefert), wird bei dem Prozess 700 zum Block 702 zurückgekehrt. Wenn der Objekt-Eigenschaft-Analysator 304 neue Informationen in der Graphdatenbank identifiziert (wenn der Block 704 das Ergebnis JA zurückliefert), identifiziert der Objekt-Eigenschaft-Analysator 304 ein Objekt in der Graphdatenbank 104 (Block 706). Nach dem Identifizieren des Objekts in der Graphdatenbank 104 bestimmt der Objekt-Eigenschaft-Analysator 304, ob eine Anzahl von Instanzen des in der Graphdatenbank 104 wiedergegebenen Objekts einen Schwellenwert überschreitet (Block 708). Der Objekt-Eigenschaft-Analysator 304 vergleicht zum Beispiel eine Anzahl von Instanzen des identifizierten Objekts mit einem Schwellenwert (z. B. einem Wert, einem Prozentanteil, dem 10-Fachen oder dem 100-Fachen). Wenn der Objekt-Eigenschaft-Analysator 304 bestimmt, dass das identifizierte Objekt den Schwellenwert überschreitet (wenn der Block 708 das Ergebnis JA zurückliefert), extrahiert der Objekt-Eigenschaft-Analysator 304 Eigenschaften aus der Graphdatenbank 104, die dem identifizierten Objekt zugeordnet sind (Block 710).
Wenn der Objekt-Eigenschaft-Analysator 304 bestimmt, dass das identifizierte Objekt den Schwellenwert nicht überschreitet (wenn der Block 708 das Ergebnis NEIN zurückliefert), bestimmt der Objekt-Eigenschaft-Analysator 304, ob in der Graphdatenbank 104 ein weiteres zu berücksichtigendes Objekt vorhanden ist (Block 712). Wenn der Objekt-Eigenschaft-Analysator 304 ein weiteres zu berücksichtigendes Objekt identifiziert (wenn der Block 712 das Ergebnis JA zurückliefert), wird bei dem Prozess 700 zum Block 706 zurückgekehrt. Wenn der Objekt-Eigenschaft-Analysator 304 kein weiteres zu berücksichtigendes Objekt identifiziert (wenn der Block 712 das Ergebnis NEIN zurückliefert), vergleicht der Objekt-Eigenschaft-Analysator 304 die Eigenschaften des identifizierten Objekts (der identifizierten Objekte) (Block 714). Der Objekt-Eigenschaft-Analysator 304 vergleicht eine oder mehrere Eigenschaften, um zu detektieren, ob es gemeinsame, in allen identifizierten Objekten vorhandene Eigenschaften gibt (Block 716). Wenn der Objekt-Eigenschaft-Analysator 304 bestimmt, dass eine oder mehrere Eigenschaften nicht in allen Objekten vorhanden sind (wenn der Block 716 das Ergebnis NEIN zurückliefert), verwirft der Objekt-Eigenschaft-Analysator 304 die nicht gemeinsamen Eigenschaften (Block 728).
Wenn der Objekt-Eigenschaft-Analysator 304 bestimmt, dass eine oder mehrere Eigenschaften in allen Objekten vorhanden sind (wenn der Block 716 das Ergebnis JA zurückliefert), gibt der Objekt-Eigenschaft-Analysator 304 eine Liste von dem Objekt (den Objekten) zugeordneten, in allen Objekten vorhandenen Eigenschaften aus (Block 718).
Der zum Generieren relationaler Modelle vorgesehene Generator 302 generiert Code zum Anlegen einer oder mehrerer relationaler Tabellen zum Abspeichern der Objekte und der Eigenschaften, die in der durch den Objekt-Eigenschaft-Analysator 304 ausgegebenen Liste von Objekten und Eigenschaften identifiziert sind (Block 720). Nachdem der zum Generieren relationaler Modelle vorgesehene Generator 302 den Code zum Anlegen der relationalen Tabellen generiert hat, generiert der zum Generieren relationaler Modelle vorgesehene Generator 302 relationale Tabellen zum Abspeichern der durch den Objekt-Eigenschaft-Analysator 304 identifizierten Daten zu Objekten und Eigenschaften (Block 722). Darüber hinaus speichert der zum Generieren relationaler Modelle vorgesehene Generator 302 eine Liste von Objekten für die generierten Tabellen (Block 724) ab. Der Tabellenauffüller 306 füllt die generierten relationalen Tabellen, die durch den zum Generieren relationaler Modelle vorgesehenen Generator 302 generiert wurden, mit den Objekten und Eigenschaften aus der Graphdatenbank 104 auf, um die relationale Datenbank 106 zu generieren (Block 726).
10 ist ein Blockschema einer beispielhaften Prozessorplattform 1000, die so strukturiert ist, dass sie die Befehle aus den 4, 5, 6 und 7 zur Implementierung des Abfrageauswahlsystems 100 aus den 1, 2 und 3 ausführt. Die Prozessorplattform 1000 kann zum Beispiel ein Server, ein PC, eine Workstation, eine selbstlernende Maschine (z. B. ein neuronales Netz), ein Mobilgerät (z. B. ein Handy, ein Smartphone oder ein Tablet, etwa ein iPad™), ein Personal Digital Assistant (PDA), eine Internet-Appliance, eine Spielkonsole, eine Set-Top-Box, ein Headset, ein Wearable oder ein Computergerät von einem beliebigen anderen Typ sein.
Die Prozessorplattform 1000 in dem veranschaulichten Beispiel enthält einen Prozessor 1012. Der Prozessor 1012 in dem veranschaulichten Beispiel ist Hardware. Der Prozessor 1012 kann zum Beispiel durch eine oder mehrere integrierte Schaltungen, eine oder mehrere logische Schaltungen, einen oder mehrere Mikroprozessoren, eine oder mehrere GPUs, einen oder mehrere DSPs oder einen oder mehrere Controller aus einer beliebigen gewünschten Familie oder von einem beliebigen gewünschten Hersteller implementiert werden. Bei dem Hardwareprozessor kann es sich um ein Bauelement auf Halbleiterbasis (z. B. auf Siliciumbasis) handeln. In diesem Beispiel implementiert der Prozessor die beispielhafte Hybriddatenbank 102, die Graphdatenbank 104, die beispielhafte relationale Datenbank 106, den beispielhaften Hybriddatenbankgenerator 108, die beispielhafte Graphsprachabfrage 110, den beispielhaften Kontextabfrageklassifikator 112, die beispielhafte Graphabfrage-Engine 114, die beispielhafte für relationale Abfragen vorgesehene Engine 116, den beispielhaften Datenspeicher 118, den beispielhaften Abfrageparser 202, den beispielhaften Abfragevalidierer 204, den beispielhaften Abfragetracker 206, den beispielhaften Vektorkonverter 208, den beispielhaften Modellklassifikator 210, den beispielhaften Modelltrainer 212, den beispielhaften Machine-Leaming-Modelltrainerverarbeiter 214, den beispielhaften Modellüberprüfer 216, den beispielhaften Kontextbestimmer 218, den beispielhaften Abfragedatenspeicher 220, den beispielhaften Modelldatenspeicher 222, den beispielhaften zum Generieren relationaler Modelle vorgesehenen Generator 302, den beispielhaften Objekt-Eigenschaft-Analysator 304, den beispielhaften Tabellenauffüller 306 und/oder allgemeiner das beispielhafte Abfrageauswahlsystem 100 aus den 1-3.
Der Prozessor 1012 in dem veranschaulichten Beispiel enthält einen lokalen Speicher 1013 (z. B. einen Cache). Der Prozessor 1012 in dem veranschaulichten Beispiel ist mit einem Hauptspeicher, der einen flüchtigen Speicher 1014 und einen nichtflüchtigen Speicher 1016 enthält, über einen Bus 1018 in Kommunikation. Der flüchtige Speicher 1014 kann durch ein Synchronous Dynamic Random Access Memory (SDRAM), ein Dynamic Random Access Memory (DRAM), ein RAMBUS® Dynamic Random Access Memory (RDRAM®) und/oder einen Arbeitsspeicher von einem beliebigen anderen Typ implementiert werden. Der nichtflüchtige Speicher 1016 kann durch einen Flashspeicher und/oder ein Speicherelement von einem beliebigen anderen gewünschten Typ implementiert werden. Der Zugriff auf den Hauptspeicher 1014, 1016 wird durch einen Speichercontroller gesteuert.
Die Prozessorplattform 1000 in dem veranschaulichten Beispiel enthält auch eine Schnittstellenschaltung 1020. Die Schnittstellenschaltung 1020 kann durch einen beliebigen Schnittstellenstandard implementiert werden, etwa durch eine Ethernet-Schnittstelle, einen universellen seriellen Bus (USB), eine Bluetooth®-Schnittstelle, eine NFC-Schnittstelle (NFC = Near Field Communication) und/oder eine PCI-Express-Schnittstelle.
In dem veranschaulichten Beispiel sind ein oder mehrere Eingabegeräte 1022 mit der Schnittstellenschaltung 1020 verbunden. Ein Benutzer kann über das eine oder die mehreren Eingabegeräte 1022 Daten und/oder Anweisungen in den Prozessor 1012 eingeben. Das Eingabegerät/die Eingabegeräte kann/können zum Beispiel durch einen akustischen Sensor, ein Mikrofon, eine Kamera (eine Standbildkamera oder eine Videokamera), eine Tastatur, eine Taste, eine Maus, einen Touchscreen, ein Touchpad, einen Trackball, ein Isopoint-Gerät und/oder ein Spracherkennungssystem implementiert sein.
Mit der Schnittstellenschaltung 1020 in dem veranschaulichten Beispiel sind auch ein oder mehrere Ausgabegeräte 1024 verbunden. Das eine oder die mehreren Ausgabegeräte 1024 können zum Beispiel durch Anzeigegeräte wie z. B. eine Leuchtdiode (LED), eine organische Leuchtdiode (OLED), eine Flüssigkristallanzeige (LCD), ein CRT-Display (CRT = Cathode Ray Tube), ein IPS-Display (IPS = In-Place-Switching) oder einen Touchscreen implementiert sein. Die Schnittstellenschaltung 1020 in dem veranschaulichten Beispiel enthält mithin typischerweise eine Grafiktreiberkarte, einen Grafiktreiberchip und/oder einen Grafiktreiberprozessor.
Die Schnittstellenschaltung 1020 in dem veranschaulichten Beispiel enthält auch ein Kommunikationsteil wie einen Sender, einen Empfänger, einen Transceiver, ein Modem, ein Residential Gateway, einen Funkzugangspunkt und/oder eine Netzschnittstelle zum Ermöglichen des Datenaustausches mit externen Maschinen (z. B. Computergeräten beliebiger Art) über ein Netz 1026. Die Kommunikation kann zum Beispiel über eine Ethernet-Verbindung, eine DSL-Verbindung (DSL = Digital Subscriber Line), eine Telefonleitungsverbindung, ein Koaxialkabelsystem, ein Satellitensystem, ein drahtloses System mit Sichtverbindung oder ein Mobiltelefonsystem erfolgen.
Die Prozessorplattform 1000 in dem veranschaulichten Beispiel enthält auch einen oder mehrere Massenspeicher 1028 zum Abspeichern von Software und/oder Daten. Massenspeicher 1028 sind beispielsweise Diskettenlaufwerke, Festplatten, CD-Laufwerke, Blu-ray-Disc-Laufwerke, RAID-Systeme (RAID = Redundant Array of Independent Disks) oder DVD-Laufwerke (DVD = Digital Versatile Disk). In einigen Beispielen implementiert der Massenspeicher 1028 die beispielhafte Graphdatenbank 104 und/oder die beispielhafte relationale Datenbank 106.
Die maschinenausführbaren Befehle 1032 aus den 4, 5, 6 und 7 können im Massenspeicher 1028, im flüchtigen Speicher 1014, im nichtflüchtigen Speicher 1016 und/oder auf einem wechselbaren, nichttransienten, computerlesbaren Speichermedium wie einer CD oder DVD abgespeichert sein.
Aus der obigen Beschreibung geht hervor, dass beispielhafte Verfahren, Vorrichtungen und Erzeugnisse offenbart worden sind, um eine relationale Datenbank basierend auf bestimmten Daten, die aus einer Graphdatenbank bezogen werden, zu generieren und eine Datenbank, die effizientere Ergebnisse schneller liefert (z. B. eine optimale Abfrage-Performance), vorherzusagen und/oder auszuwählen. Die offenbarten Verfahren, Vorrichtungen und Erzeugnisse verbessern die Effizienz der Nutzung eines Computergeräts dadurch, dass die Abfrageausführung verbessert wird. Mit den offenbarten Verfahren, Vorrichtungen und Erzeugnissen wird demnach auf eine oder mehrere Verbesserungen der Funktionsweise eines Computers abgezielt.
Folgende weitere Beispiele und Kombinationen kommen in Betracht:
Beispiel 1 enthält ein System mit einem Prozessor für Folgendes: Analysieren einer Graphdatenbank; Identifizieren jeweiliger der Graphdatenbank zugeordneter Objekte; Beziehen von den Objekten zugeordneten Eigenschaften; Identifizieren gemeinsamer, in den jeweiligen Objekten vorhandener Eigenschaften; als Antwort auf das Bestimmen der gemeinsamen, in den identifizierten Objekten vorhandenen Eigenschaften Ausgeben einer Liste der gemeinsamen, mit den jeweiligen Objekten korrespondierenden Eigenschaften; Generieren einer Tabelle für die gemeinsamen Eigenschaften und die jeweiligen Objekte; und Auffüllen der Tabelle mit den gemeinsamen Eigenschaften und den jeweiligen Objekten aus der Graphdatenbank, um eine relationale Datenbank einzurichten. Das System enthält ferner einen Machine-Learning-Modellklassifikator zum Ermöglichen des Suchens durch Abfragen relationaler Datenbanken über die relationale Datenbank.
Beispiel 2 enthält das System aus Beispiel 1, wobei der Prozessor zum Beziehen von den Objekten zugeordneten Eigenschaften für Folgendes vorgesehen ist: Bestimmen, ob die jeweiligen Objekte einen Schwellenwert einhalten; und als Antwort darauf, dass die jeweiligen Objekte den Schwellenwert einhalten, Beziehen von den Objekten zugeordneten Eigenschaften.
Beispiel 3 enthält das System aus einem der Beispiele 1-2, wobei der Prozessor zum Bestimmen, ob die jeweiligen Objekte einen Schwellenwert einhalten, für Folgendes vorgesehen ist: Bestimmen einer Anzahl von Instanzen der jeweiligen in der Graphdatenbank vorhandenen Objekte; und Vergleichen der Anzahl von Instanzen und des Schwellenwerts.
Beispiel 4 enthält das System aus einem der Beispiele 1-3, wobei der Prozessor dafür vorgesehen ist, die Objekte in einem Listenformat in einem Speicher abzuspeichern.
Beispiel 5 enthält das System aus einem der Beispiele 1-4, wobei der Machine-Learning-Modellklassifikator dafür vorgesehen ist vorherzusagen, ob eine Abfrage-Performance unter Nutzung einer Graphabfrage-Engine, die der Graphdatenbank zugeordnet ist, oder unter Nutzung einer für relationale Abfragen vorgesehenen Engine, die der relationalen Datenbank zugeordnet ist, schneller ist.
Beispiel 6 enthält das System aus einem der Beispiele 1-5, wobei der Machine-Learning-Modellklassifikator eine Architektur für künstliche Intelligenz zum Vorhersagen der Abfrage-Performance verwendet.
Beispiel 7 enthält das System aus einem der Beispiele 1-6, wobei der Prozessor dafür vorgesehen ist, die relationale Datenbank als Antwort auf eine Vorhersage durch die Architektur für künstliche Intelligenz, dass die Abfrage-Performance unter Nutzung der für relationale Abfragen vorgesehenen Engine schneller als unter Nutzung der Graphabfrage-Engine ist, zu nutzen.
Beispiel 8 enthält das System aus einem der Beispiele 1-7, wobei der Machine-Learning-Modellklassifikator ein sequenz- und kontextbezogenes Binärklassifikationsmodell, das auf einem Long-Short-Term-Memory-Modell basiert, enthält.
Beispiel 9 enthält das System aus einem der Beispiele 1-8, das ferner einen Modelltrainer zum Trainieren des Machine-Learning-Modellklassifikators zum Vorhersagen der Abfrage-Performance durch Verwendung früherer, durch das Abfrageauswahlsystem empfangener Abfragen und von Kontextinformationen des Abfrageauswahlsystems enthält.
Beispiel 10 enthält ein nichttransientes, computerlesbares Speichermedium, das Befehle umfasst, die, wenn sie ausgeführt werden, bewirken, dass eine Maschine Folgendes durchführt: Analysieren einer Graphdatenbank; Identifizieren jeweiliger der Graphdatenbank zugeordneter Objekte; Beziehen von den Objekten zugeordneten Eigenschaften; Identifizieren gemeinsamer, in den jeweiligen Objekten vorhandener Eigenschaften; als Antwort auf das Bestimmen der gemeinsamen, in den identifizierten Objekten vorhandenen Eigenschaften Ausgeben einer Liste der gemeinsamen, mit den jeweiligen Objekten korrespondierenden Eigenschaften; Generieren einer Tabelle für die gemeinsamen Eigenschaften und die jeweiligen Objekte; Auffüllen der Tabelle mit den gemeinsamen Eigenschaften und den jeweiligen Objekten aus der Graphdatenbank, um eine relationale Datenbank einzurichten; und Ermöglichen des Suchens durch Abfragen relationaler Datenbanken über die relationale Datenbank.
Beispiel 11 enthält das computerlesbare Speichermedium aus Beispiel 10, wobei die Befehle zum Beziehen von den Objekten zugeordneten Eigenschaften bewirken, dass die Maschine Folgendes durchführt: Bestimmen, ob die jeweiligen Objekte einen Schwellenwert einhalten; und als Antwort darauf, dass die jeweiligen Objekte den Schwellenwert einhalten, Beziehen von den Objekten zugeordneten Eigenschaften.
Beispiel 12 enthält das computerlesbare Speichermedium aus einem der Beispiele 10-11, wobei die Befehle bewirken, dass die Maschine Folgendes durchführt: Bestimmen, ob die jeweiligen Objekte einen Schwellenwert einhalten; und Bestimmen einer Anzahl von Instanzen der jeweiligen in der Graphdatenbank vorhandenen Objekte; und Vergleichen der Anzahl von Instanzen und des Schwellenwerts.
Beispiel 13 enthält das computerlesbare Speichermedium aus einem der Beispiele 10-12, wobei die Befehle bewirken, dass die Maschine die Listenobjekte in einem Speicher abspeichert.
Beispiel 14 enthält das computerlesbare Speichermedium aus einem der Beispiele 10-13, wobei die Befehle bewirken, dass die Maschine vorhersagt, ob eine Abfrage-Performance unter Nutzung einer Graphabfrage-Engine, die der Graphdatenbank zugeordnet ist, oder unter Nutzung einer für relationale Abfragen vorgesehenen Engine, die der relationalen Datenbank zugeordnet ist, schneller ist.
Beispiel 15 enthält das computerlesbare Speichermedium aus einem der Beispiele 10-14, wobei die Befehle bewirken, dass die Maschine die relationale Datenbank als Antwort auf eine Vorhersage durch die Architektur für künstliche Intelligenz, dass die Abfrage-Performance unter Nutzung der für relationale Abfragen vorgesehenen Engine schneller als unter Nutzung der Graphabfrage-Engine ist, nutzt.
Beispiel 16 enthält das computerlesbare Speichermedium aus einem der Beispiele 10-15, wobei die Befehle bewirken, dass die Maschine den Machine-Learning-Modellklassifikator zum Vorhersagen der Abfrage-Performance durch Verwendung früherer, durch das Abfrageauswahlsystem empfangener Abfragen und von Kontextinformationen des Abfrageauswahlsystems trainiert.
Beispiel 17 enthält ein Verfahren, das Folgendes enthält: Analysieren einer Graphdatenbank; Identifizieren jeweiliger der Graphdatenbank zugeordneter Objekte; Beziehen von den Objekten zugeordneten Eigenschaften; Identifizieren gemeinsamer, in den jeweiligen Objekten vorhandener Eigenschaften; als Antwort auf das Bestimmen der gemeinsamen, in den identifizierten Objekten vorhandenen Eigenschaften Ausgeben einer Liste der gemeinsamen, mit den jeweiligen Objekten korrespondierenden Eigenschaften; Generieren einer Tabelle für die gemeinsamen Eigenschaften und die jeweiligen Objekte; Auffüllen der Tabelle mit den gemeinsamen Eigenschaften und den jeweiligen Objekten aus der Graphdatenbank, um eine relationale Datenbank einzurichten; und Ermöglichen des Suchens durch Abfragen relationaler Datenbanken über die relationale Datenbank.
Beispiel 18 enthält das Verfahren aus Beispiel 17, wobei das Verfahren zum Beziehen von den Objekten zugeordneten Eigenschaften Folgendes enthält: Bestimmen, ob die jeweiligen Objekte einen Schwellenwert einhalten; und als Antwort darauf, dass die jeweiligen Objekte den Schwellenwert einhalten, Beziehen von den Objekten zugeordneten Eigenschaften.
Beispiel 19 enthält das Verfahren aus einem der Beispiele 17-18, wobei das Bestimmen, ob die jeweiligen Objekte den Schwellenwert einhalten, Folgendes enthält: Bestimmen einer Anzahl von Instanzen der jeweiligen in der Graphdatenbank vorhandenen Objekte; und Vergleichen der Anzahl von Instanzen und des Schwellenwerts.
Beispiel 20 enthält das Verfahren aus einem der Beispiele 17-19, das ferner Folgendes enthält: Abspeichern der Listenobjekte in einem Speicher.
Beispiel 21 enthält das Verfahren aus einem der Beispiele 17-20, das ferner Folgendes enthält: Vorhersagen, ob eine Abfrage-Performance unter Nutzung einer Graphabfrage-Engine, die der Graphdatenbank zugeordnet ist, oder unter Nutzung einer für relationale Abfragen vorgesehenen Engine, die der relationalen Datenbank zugeordnet ist, schneller ist.
Beispiel 22 enthält das Verfahren aus einem der Beispiele 17-21, das ferner Folgendes enthält: Nutzen der relationalen Datenbank als Antwort auf eine Vorhersage, dass die Abfrage-Performance unter Nutzung der für relationale Abfragen vorgesehenen Engine schneller als unter Nutzung der Graphabfrage-Engine ist.
Beispiel 23 enthält das Verfahren aus einem der Beispiele 17-22, das ferner Folgendes enthält: Trainieren eines Machine-Learning-Modellklassifikators zum Vorhersagen der Abfrage-Performance durch Verwendung früherer, durch das Abfrageauswahlsystem empfangener Abfragen und von Kontextinformationen des Abfrageauswahlsystems.
Hierin sind einige beispielhafte Verfahren, Vorrichtungen und Erzeugnisse offenbart worden, jedoch ist der Schutzbereich dieses Patents nicht auf sie begrenzt. Vielmehr deckt dieses Patent sämtliche Verfahren, Vorrichtungen und Erzeugnisse ab, die bei Anlegung angemessener Maßstäbe in den Schutzbereich der Ansprüche dieses Patents fallen.
Die folgenden Ansprüche werden durch diese Bezugnahme hiermit als Bestandteil der ausführlichen Beschreibung in sie aufgenommen, wobei jeder Anspruch als separate Ausführungsform der vorliegenden Offenbarung für sich stehen kann.

Claims

Abfrageauswahlsystem, das Folgendes umfasst: einen Prozessor für Folgendes: Analysieren einer Graphdatenbank; Identifizieren jeweiliger der Graphdatenbank zugeordneter Objekte; Beziehen von den Objekten zugeordneten Eigenschaften; Identifizieren gemeinsamer, in den jeweiligen Objekten vorhandener Eigenschaften; als Antwort auf das Bestimmen der gemeinsamen, in den identifizierten Objekten vorhandenen Eigenschaften Ausgeben einer Liste der gemeinsamen, mit den jeweiligen Objekten korrespondierenden Eigenschaften; Generieren einer Tabelle für die gemeinsamen Eigenschaften und die jeweiligen Objekte; Auffüllen der Tabelle mit den gemeinsamen Eigenschaften und den jeweiligen Objekten aus der Graphdatenbank, um eine relationale Datenbank einzurichten; und einen Machine-Learning-Modellklassifikator zum Ermöglichen des Suchens durch Abfragen relationaler Datenbanken über die relationale Datenbank.
System nach Anspruch 1, wobei der Machine-Learning-Modellklassifikator dafür vorgesehen ist vorherzusagen, ob eine Abfrage-Performance unter Nutzung einer Graphabfrage-Engine, die der Graphdatenbank zugeordnet ist, oder unter Nutzung einer für relationale Abfragen vorgesehenen Engine, die der relationalen Datenbank zugeordnet ist, schneller ist.
System nach Anspruch 2, wobei der Machine-Learning-Modellklassifikator eine Architektur für künstliche Intelligenz zum Vorhersagen der Abfrage-Performance verwendet.
System nach Anspruch 3, wobei der Prozessor dafür vorgesehen ist, die relationale Datenbank als Antwort auf eine Vorhersage durch die Architektur für künstliche Intelligenz, dass die Abfrage-Performance unter Nutzung der für relationale Abfragen vorgesehenen Engine schneller als unter Nutzung der Graphabfrage-Engine ist, zu nutzen.
System nach Anspruch 3, wobei der Machine-Learning-Modellklassifikator ein sequenz- und kontextbezogenes Binärklassifikationsmodell, das auf einem Long-Short-Term-Memory-Modell basiert, enthält.
System nach einem der Ansprüche 1-5, wobei der Prozessor zum Beziehen von den Objekten zugeordneten Eigenschaften für Folgendes vorgesehen ist: Bestimmen, ob die jeweiligen Objekte einen Schwellenwert einhalten; und als Antwort darauf, dass die jeweiligen Objekte den Schwellenwert einhalten, Beziehen von den Objekten zugeordneten Eigenschaften.
System nach einem der Ansprüche 1-5, wobei der Prozessor zum Bestimmen, ob die jeweiligen Objekte einen Schwellenwert einhalten, für Folgendes vorgesehen ist: Bestimmen einer Anzahl von Instanzen der jeweiligen in der Graphdatenbank vorhandenen Objekte; und Vergleichen der Anzahl von Instanzen und des Schwellenwerts.
System nach einem der Ansprüche 1-5, wobei der Prozessor dafür vorgesehen ist, die Objekte in einem Listenformat in einem Speicher abzuspeichern.
System nach einem der Ansprüche 1-5, das ferner Folgendes enthält: einen Modelltrainer zum Trainieren des Machine-Learning-Modellklassifikators zum Vorhersagen der Abfrage-Performance durch Verwendung früherer, durch das Abfrageauswahlsystem empfangener Abfragen und von Kontextinformationen des Abfrageauswahlsystems.
Nichtflüchtiges, computerlesbares Speichermedium, das Befehle umfasst, die, wenn sie ausgeführt werden, bewirken, dass eine Maschine mindestens Folgendes durchführt: Analysieren einer Graphdatenbank; Identifizieren jeweiliger der Graphdatenbank zugeordneter Objekte; Beziehen von den Objekten zugeordneten Eigenschaften; Identifizieren gemeinsamer, in den jeweiligen Objekten vorhandener Eigenschaften; als Antwort auf das Bestimmen der gemeinsamen, in den identifizierten Objekten vorhandenen Eigenschaften Ausgeben einer Liste der gemeinsamen, mit den jeweiligen Objekten korrespondierenden Eigenschaften; Generieren einer Tabelle für die gemeinsamen Eigenschaften und die jeweiligen Obj ekte; Auffüllen der Tabelle mit den gemeinsamen Eigenschaften und den jeweiligen Objekten aus der Graphdatenbank, um eine relationale Datenbank einzurichten; und Ermöglichen des Suchens durch Abfragen relationaler Datenbanken über die relationale Datenbank.
Computerlesbares Speichermedium nach Anspruch 10, wobei die Befehle bewirken, dass die Maschine vorhersagt, ob eine Abfrage-Performance unter Nutzung einer Graphabfrage-Engine, die der Graphdatenbank zugeordnet ist, oder unter Nutzung einer für relationale Abfragen vorgesehenen Engine, die der relationalen Datenbank zugeordnet ist, schneller ist.
Computerlesbares Speichermedium nach Anspruch 11, wobei die Befehle bewirken, dass die Maschine die relationale Datenbank als Antwort auf eine Vorhersage durch eine Architektur für künstliche Intelligenz, dass die Abfrage-Performance unter Nutzung der für relationale Abfragen vorgesehenen Engine schneller als unter Nutzung der Graphabfrage-Engine ist, nutzt.
Computerlesbares Speichermedium nach Anspruch 11, wobei die Befehle bewirken, dass die Maschine einen Machine-Learning-Modellklassifikator zum Vorhersagen der Abfrage-Performance durch Verwendung früherer Abfragen und von Kontext-informationen eines Abfrageauswahlsystems trainiert.
Computerlesbares Speichermedium nach einem der Ansprüche 10-13, wobei die Befehle zum Beziehen von den Objekten zugeordneten Eigenschaften bewirken, dass die Maschine Folgendes durchführt: Bestimmen, ob die jeweiligen Objekte einen Schwellenwert einhalten; und als Antwort darauf, dass die jeweiligen Objekte den Schwellenwert einhalten, Beziehen von den Objekten zugeordneten Eigenschaften.
Computerlesbares Speichermedium nach einem der Ansprüche 10-13, wobei die Befehle bewirken, dass die Maschine Folgendes durchführt: Bestimmen, ob die jeweiligen Objekte einen Schwellenwert einhalten; und Bestimmen einer Anzahl von Instanzen der jeweiligen in der Graphdatenbank vorhandenen Objekte und Vergleichen der Anzahl von Instanzen und des Schwellenwerts.
Computerlesbares Speichermedium nach einem der Ansprüche 10-13, wobei die Befehle bewirken, dass die Maschine Folgendes durchführt: Abspeichern der Listenobjekte in einem Speicher.
Verfahren zum Bereitstellen einer Abfrageauswahl, wobei das Verfahren Folgendes enthält: Analysieren einer Graphdatenbank; Identifizieren jeweiliger der Graphdatenbank zugeordneter Objekte; Beziehen von den Objekten zugeordneten Eigenschaften; Identifizieren gemeinsamer, in den jeweiligen Objekten vorhandener Eigenschaften; als Antwort auf das Bestimmen der gemeinsamen, in den identifizierten Objekten vorhandenen Eigenschaften Ausgeben einer Liste der gemeinsamen, mit den jeweiligen Objekten korrespondierenden Eigenschaften; Generieren einer Tabelle für die gemeinsamen Eigenschaften und die jeweiligen Obj ekte; Auffüllen der Tabelle mit den gemeinsamen Eigenschaften und den jeweiligen Objekten aus der Graphdatenbank, um eine relationale Datenbank einzurichten; und Ermöglichen des Suchens durch Abfragen relationaler Datenbanken über die relationale Datenbank.
Verfahren nach Anspruch 17, das ferner Vorhersagen, ob eine Abfrage-Performance unter Nutzung einer Graphabfrage-Engine, die der Graphdatenbank zugeordnet ist, oder unter Nutzung einer für relationale Abfragen vorgesehenen Engine, die der relationalen Datenbank zugeordnet ist, schneller ist, enthält.
Verfahren nach Anspruch 18, das ferner Nutzen der relationalen Datenbank als Antwort auf eine Vorhersage, dass die Abfrage-Performance unter Nutzung der für relationale Abfragen vorgesehenen Engine schneller als unter Nutzung der Graphabfrage-Engine ist, enthält.
Verfahren nach Anspruch 18, das ferner Trainieren eines Machine-Learning-Modellklassifikators zum Vorhersagen der Abfrage-Performance durch Verwendung früherer Abfragen und von Kontextinformationen eines Abfrageauswahlsystems enthält.
Verfahren nach einem der Ansprüche 17-20, das ferner Abspeichern der Listenobjekte in einem Speicher enthält.
Verfahren nach einem der Ansprüche 17-20, wobei das Verfahren zum Beziehen von den Objekten zugeordneten Eigenschaften Folgendes enthält: Bestimmen, ob die jeweiligen Objekte einen Schwellenwert einhalten; und als Antwort darauf, dass die jeweiligen Objekte den Schwellenwert einhalten, Beziehen von den Objekten zugeordneten Eigenschaften.
Verfahren nach Anspruch 22, wobei das Bestimmen, ob die jeweiligen Objekte den Schwellenwert einhalten, Folgendes enthält: Bestimmen einer Anzahl von Instanzen der jeweiligen in der Graphdatenbank vorhandenen Objekte; und Vergleichen der Anzahl von Instanzen und des Schwellenwerts.
Abfrageauswahlsystem, das Folgendes umfasst: Mittel zum Extrahieren von Informationen aus einer Graphdatenbank, wobei das Mittel zum Extrahieren für Folgendes vorgesehen ist: Identifizieren jeweiliger der Graphdatenbank zugeordneter Objekte; Beziehen von den Objekten zugeordneten Eigenschaften; Identifizieren gemeinsamer, in den jeweiligen Objekten vorhandener Eigenschaften; als Antwort auf das Bestimmen der gemeinsamen, in den jeweiligen Objekten vorhandenen Eigenschaften Ausgeben einer Liste der gemeinsamen, mit den jeweiligen Objekten korrespondierenden Eigenschaften; Mittel zum Generieren einer Tabelle für die gemeinsamen Eigenschaften und die jeweiligen Objekte; Mittel zum Auffüllen der Tabelle mit den gemeinsamen Eigenschaften und den jeweiligen Objekten aus der Graphdatenbank, um eine relationale Datenbank einzurichten; und Mittel zum Suchen zum Ermöglichen des Suchens durch Abfragen relationaler Datenbanken über die relationale Datenbank.
System nach Anspruch 24, das ferner Folgendes enthält: Mittel zum Vorhersagen, ob eine Abfrage-Performance unter Nutzung einer Graphabfrage-Engine, die der Graphdatenbank zugeordnet ist, oder unter Nutzung einer für relationale Abfragen vorgesehenen Engine, die der relationalen Datenbank zugeordnet ist, schneller ist.
System nach Anspruch 25, das ferner Folgendes enthält: Mittel zum Trainieren des Mittels zum Vorhersagen, wobei das Mittel zum Vorhersagen dafür vorgesehen ist, die Abfrage-Performance durch Verwendung früherer Abfragen und eines Kontextes des Abfrageauswahlsystems vorherzusagen.
System nach Anspruch 25, wobei das Mittel zum Vorhersagen dafür vorgesehen ist, die relationale Datenbank als Antwort darauf, dass das Mittel zum Vorhersagen bestimmt, dass die Abfrage-Performance unter Nutzung der für relationale Abfragen vorgesehenen Engine schneller als unter Nutzung der Graphabfrage-Engine ist, zu nutzen.
System nach Anspruch 25, wobei das Mittel zum Vorhersagen ein sequenz- und kontextbezogenes Binärklassifikationsmodell, das auf einem Long-Short-Term-Memory-Modell basiert, enthält.
System nach einem der Ansprüche 24-28, wobei das Mittel zum Extrahieren zum Beziehen von den Objekten zugeordneten Eigenschaften dafür vorgesehen ist zu bestimmen, ob die jeweiligen Objekte einen Schwellenwert einhalten, und als Antwort darauf, dass die jeweiligen Objekte den Schwellenwert einhalten, den Objekten zugeordnete Eigenschaften zu beziehen.
System nach Anspruch 29, wobei das Mittel zum Extrahieren zum Bestimmen, ob die jeweiligen Objekte den Schwellenwert einhalten, dafür vorgesehen ist, eine Anzahl von Instanzen der jeweiligen in der Graphdatenbank vorhandenen Objekte zu bestimmen und die Anzahl von Instanzen und den Schwellenwert zu vergleichen.