MySQL HeatWave – OLTP, OLAP und ML für MySQL
Mit Erscheinen des für Frühling 2024 angekündigten Oracle MySQL Long Term Support Releases geht MySQL in sein 30. "Lebensjahr". Und auch heute noch ist MySQL für die meisten Webseiten die Basis, um dynamische Webauftritte zu gestalten [1]. Allerdings haben sich die Anforderungen an Datenbanken seit dem ersten MySQL-Release im Jahr 1995 deutlich erhöht. Natürlich werden heute sehr viel mehr Daten von sehr viel mehr gleichzeitigen Verbindungen gelesen, geschrieben oder verändert. Zusätzlich wird heute aber erwartet, dass eine Datenbank die Daten sicher verarbeitet. Unter dem Oberbegriff "Sicherheit" hat sich seit den frühen Versionen viel getan: Verstand man anfangs unter "Sicherheit" nur die Transportverschlüsselung, wurde praktisch jede neue MySQL-Version um zahlreiche Sicherheitsfunktionen erweitert. Darunter fallen nicht nur Funktionen zur Auditierung, TDE (Verschlüsselung der Datenbankdaten auf Dateiebene), Authentifizierung/Berechtigung, sondern auch vierteljährliche Patches. Für einen sicheren MySQL-Betrieb empfiehlt sich daher die Anwendung von Standards und Richtlinien, wie sie zum Beispiel im CIS-Benchmark beschrieben sind [2].
Obwohl MySQL nach wie vor sehr einfach aufzusetzen und zu verwalten ist, wird mittlerweile ein Großteil der obigen Aufgaben im Rahmen eines Cloud-Betriebs einfach dem Cloud-Anbieter übertragen und der MySQL-Service des Anbieters übernommen.
Auch Oracle stellt mit seiner Oracle-Cloud-Infrastruktur neben zahlreichen IaaS, PaaS und SaaS einen MySQL-Service zur Verfügung. Oracle, seit 2010 Eigentümer von MySQL, erweitert diesen Service jedoch um zusätzliche Anwendungsfälle und nennt diese Produktfamilie MySQL HeatWave. Die Versionen MySQL Community und MySQL Enterprise Edition werden unter den bekannten Namen für On-Premise-Nutzer weitergeführt.
MySQL HeatWave (Core)
Im einfachsten Fall handelt es sich bei MySQL HeatWave um einen vollständig verwalteten MySQL-Datenbank-Service. Eine MySQL-HeatWave-Instanz wird in Schritten von zwei ECPUs (zwei ECPUs entsprechen einem CPU-Core mit zwei Threads und 16GB Arbeitsspeicher) angeboten. Typische MySQL-Funktionalitäten, wie zum Beispiel Group Replication (Hochverfügbarkeit), Backup (PITR), Inbound/Outbound-Replikation (Channels), my.cnf (Configurations) und einen Abfragebeschleuniger (HeatWave, s. nächster Absatz), können sehr einfach ausgewählt werden. Oracle unterscheidet zwecks Vereinfachung zwei Anwenderszenarien – "Development or Testing" und "Production". Die Vorlagen unterscheiden sich nur über unterschiedliche Voreinstellungen, die bei Bedarf zu- oder abgewählt werden können.
Kleiner Tipp: Die Verwendung des Database-Managements (kostenfreies Monitoring der Datenbank) empfiehlt sich eigentlich immer. Das Database-Management ist optisch am MySQL-Enterprise-Monitor angelegt und umfasst ähnliche Funktionen. Die Auswahl dieses Services verlängert zwar die Zeit bis zur ersten Erreichbarkeit der Datenbank auf etwa 10 Minuten, aber die Analysen der Metriken und der Abfragen via Performance Hub veranschaulichen den Datenbankbetrieb erheblich.
Nachdem eine MySQL-HeatWave-Instanz aufgesetzt wurde, kann man diese Instanz mittels der Funktion Read Replicas sehr einfach klonen und MySQL-Replikationsfarmen von bis zu 18 (Lese-)Replicas aufbauen.
Ebenfalls erst nach dem Aufsetzen einer MySQL-HeatWave-Instanz kann man (etwas umständlich) den direkten Zugriff aus dem Internet über einen kostenfreien Loadbalancer ermöglichen und auf Wunsch sehr granular konfigurieren [3].
Bis hierhin unterscheidet sich MySQL HeatWave praktisch nicht von einer lokalen MySQL-Installation. Nur entfallen bei MySQL HeatWave servicebedingt das Tuning, Backup, evtl. die Hochverfügbarkeit und weitere Konfigurationen, da diese von Oracle selbst vorgenommen werden.
MySQL HeatWave
Über den MySQL-Betrieb hinaus hat Oracle bereits 2020 eine weitere nützliche Komponente in MySQL HeatWave integriert, welche seit Anfang 2024 standardmäßig mit MySQL HeatWave (Core) angeboten wird.
Bei der MySQL-HeatWave-"Funktion" handelt es sich um einen integrierten In-Memory-Abfragebeschleuniger, der SQL-Abfragen erheblich beschleunigt und maschinelles Lernen auf Basis der MySQL-Daten sehr einfach ermöglicht. Technisch betrachtet handelt es sich hierbei um eine neue zusätzliche Storage-Engine (RAPID), die automatisiert im Hintergrund betrieben wird. MySQL wird seit jeher als OLTP-Datenbank angesehen, mit MySQL HeatWave können nun zusätzlich auch OLAP-Anwendungsfälle (ohne ETL-Prozesse) abgebildet werden [4]. Für die MySQL-Anwendung erfolgt die Unterscheidung komplett transparent. Es ist keine Änderung an der Abfrage selbst oder in der Applikation nötig.
Mit der HeatWave-Technologie hat Oracle auch ein neues Tool zur Automatisierung von MySQL-Aufgaben bereitgestellt.
Das folgende Beispiel bezieht sich auf MySQL HeatWave Version 8.0.36 "Production Template", 8 ECPU/64 GB (alles default, aber ohne PITR). Nehmen wir zur Veranschaulichung der Funktion das Beispiel aus dem MySQL-HeatWave-User-Guide (Quickstart)[5]. Für dieses Beispiel wurde der TPC-H SF10 Benchmark verwendet (etwa 10GB). Um eine Referenz für die Ausführungszeit (MySQL) zu bekommen, werden wir zunächst Query 1 vom TPCH ausführen.
Query 1, TPCH SF10 – MySQL HeatWave (ohne HeatWave-Funktion)
MySQL tpch_10 SQL > SELECT l_returnflag, l_linestatus, sum(l_quantity) as sum_qty, sum(l_extendedprice) as sum_base_price, sum(l_extendedprice * (1 - l_discount)) as sum_disc_price, sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge, avg(l_quantity) as avg_qty, avg(l_extendedprice) as avg_price, avg(l_discount) as avg_disc, count(*) as count_order FROM lineitem WHERE l_shipdate <= date '1998-12-01' - interval '90' day GROUP BY l_returnflag, l_linestatus ORDER BY l_returnflag, l_linestatus; +--------------+--------------+--------------+------------------+--------------------+----------------------+-----------+--------------+----------+-------------+ | l_returnflag | l_linestatus | sum_qty | sum_base_price | sum_disc_price | sum_charge | avg_qty | avg_price | avg_disc | count_order | +--------------+--------------+--------------+------------------+--------------------+----------------------+-----------+--------------+----------+-------------+ | A | F | 377518399.00 | 566065727797.25 | 537759104278.0656 | 559276670892.116819 | 25.500975 | 38237.151009 | 0.050007 | 14804077 | | N | F | 9851614.00 | 14767438399.17 | 14028805792.2114 | 14590490998.366737 | 25.522448 | 38257.810660 | 0.049973 | 385998 | | N | O | 743124873.00 | 1114302286901.88 | 1058580922144.9638 | 1100937000170.591854 | 25.498076 | 38233.902923 | 0.050001 | 29144351 | | R | F | 377732830.00 | 566431054976.00 | 538110922664.7677 | 559634780885.086257 | 25.508385 | 38251.219274 | 0.049997 | 14808183 | +--------------+--------------+--------------+------------------+--------------------+----------------------+-----------+--------------+----------+-------------+ 4 rows in set (1 min 26.8547 sec)
Die Abfrage wurde in 87 Sekunden ausgeführt. Dies dient uns als Referenzwert. Bevor wir die Abfrage erneut durchführen, wollen wir prüfen, ob der HeatWave-Service verfügbar ist.
MySQL tpch_10 SQL > SHOW STATUS LIKE 'rapid_service_status'; +----------------------+--------+ | Variable_name | Value | +----------------------+--------+ | rapid_service_status | ONLINE | +----------------------+--------+ 1 row in set (0.0015 sec)
Mit der Einführung der HeatWave-Technologie hat Oracle auch ein neues Tool zur Automatisierung von MySQL-Aufgaben bereitgestellt. Die Autopilot-Funktionen werden hierbei über Prozeduren aufgerufen und können über SQL sehr einfach gesteuert werden. Auch die Überwachung von HeatWave und Autopilotfunktionen erfolgt über MySQL-typische Techniken, wie das Performance-Schema, MySQL Logging oder SQL-Aufrufe.
In diesem Release (MySQL 8.0.36) müssen Schemata (oder Teile davon) noch manuell geladen werden. Mit dem kommenden MySQL 8.4 (HeatWave Load 2.0) ist dieser Schritt voraussichtlich vollständig automatisiert. Die Daten (hier tpch_10) werden über den Aufruf der folgenden Prozedur einmalig geladen [6]:
MySQL tpch_10 SQL > CALL sys.heatwave_load (JSON_ARRAY("tpch_10"),NULL);
+-------------------------------------------------------------------------------+
| LOAD SUMMARY |
+-------------------------------------------------------------------------------+
| |
| SCHEMA TABLES TABLES COLUMNS LOAD |
| NAME LOADED FAILED LOADED DURATION |
| ------ ------ ------ ------- -------- |
| `tpch_10` 8 0 61 1.02 min |
| |
+-------------------------------------------------------------------------------+
6 rows in set (0.0149 sec)Die Daten werden nun vektorisiert, spaltenorientiert, komprimiert und verschlüsselt im HeatWave-Backend "in Memory" gespeichert. Alle folgenden Änderungen in der Tabelle tpch_10 werden ab diesem Zeitpunkt automatisch mit der In-Memory-Kopie synchronisiert (change_propagation). Neue Daten müssen nicht erneut geladen werden.
Für das HeatWave-Backend stehen standardmäßig entweder 32GB oder 512GB Arbeitsspeicher (verfügbarer Speicher für Daten = 1.5x Arbeitsspeicher) zur Verfügung. Die Anzahl der Instanzen im Hintergrund kann automatisiert bis auf 64 Instanzen erweitert werden (max. ~50TB).
MySQL tpch_10 SQL > SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME = 'rapid_change_propagation_status'; +----------------+ | VARIABLE_VALUE | +----------------+ | ON | +----------------+ 1 row in set (0.0009 sec)
Der Status der geladenen Daten und der Status des verwendeten Speichers kann im Performance-Schema abgefragt werden:
MySQL tpch_10 SQL > SELECT NAME, LOAD_STATUS from performance_schema.rpd_tables,performance_schema.rpd_table_id where rpd_tables.ID = rpd_table_id.ID; +------------------+---------------------+ | NAME | LOAD_STATUS | +------------------+---------------------+ | tpch_10.lineitem | AVAIL_RPDGSTABSTATE | | tpch_10.region | AVAIL_RPDGSTABSTATE | | tpch_10.nation | AVAIL_RPDGSTABSTATE | | tpch_10.customer | AVAIL_RPDGSTABSTATE | | tpch_10.part | AVAIL_RPDGSTABSTATE | | tpch_10.supplier | AVAIL_RPDGSTABSTATE | | tpch_10.partsupp | AVAIL_RPDGSTABSTATE | | tpch_10.orders | AVAIL_RPDGSTABSTATE | +------------------+---------------------+ 8 rows in set (0.0007 sec) MySQL tpch_10 SQL > SELECT ID, MEMORY_USAGE, MEMORY_TOTAL, BASEREL_MEMORY_USAGE FROM performance_schema.rpd_nodes; +----+--------------+--------------+----------------------+ | ID | MEMORY_USAGE | MEMORY_TOTAL | BASEREL_MEMORY_USAGE | +----+--------------+--------------+----------------------+ | 0 | 9303312312 | 515396075520 | 9034876718 | +----+--------------+--------------+----------------------+ 1 row in set (0.0010 sec)
MySQL kann nun für eine Query die zu erwartenden Kosten (Ressourcen) abschätzen und die Abfrage entweder auf MySQL "nativ" oder in das MySQL-HeatWave-Backend "verschieben". Diese Bewertung übernimmt der MySQL-Optimizer im Rahmen der Query-Normalisierung. Der Prozess kann auf expliziten Wunsch beeinflusst werden. Hierzu kann eine Abfrage via einem SQL-Kommentar übergeben werden (/*+ SET_VAR(use_secondary_engine = off/on/FORCED) */).
Für unser Beispiel überlassen wir die Entscheidung MySQL. Wenn wir die obige Abfrage erneut ausführen, geschieht dies nun nicht mehr auf MySQL, sondern automatisiert im HeatWave-Backend:
Query 1, TPCH SF10 – MySQL HeatWave (mit HeatWave-Funktion)
MySQL tpch_10 SQL > SELECT l_returnflag, l_linestatus, sum(l_quantity) as sum_qty, sum(l_extendedprice) as sum_base_price, sum(l_extendedprice * (1 - l_discount)) as sum_disc_price, sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge, avg(l_quantity) as avg_qty, avg(l_extendedprice) as avg_price, avg(l_discount) as avg_disc, count(*) as count_order FROM lineitem WHERE l_shipdate <= date '1998-12-01' - interval '90' day GROUP BY l_returnflag, l_linestatus ORDER BY l_returnflag, l_linestatus; +--------------+--------------+--------------+------------------+--------------------+----------------------+-----------+--------------+----------+-------------+ | l_returnflag | l_linestatus | sum_qty | sum_base_price | sum_disc_price | sum_charge | avg_qty | avg_price | avg_disc | count_order | +--------------+--------------+--------------+------------------+--------------------+----------------------+-----------+--------------+----------+-------------+ | A | F | 377518399.00 | 566065727797.25 | 537759104278.0656 | 559276670892.116819 | 25.500975 | 38237.151008 | 0.050006 | 14804077 | | N | F | 9851614.00 | 14767438399.17 | 14028805792.2114 | 14590490998.366737 | 25.522448 | 38257.810660 | 0.049973 | 385998 | | N | O | 743124873.00 | 1114302286901.88 | 1058580922144.9638 | 1100937000170.591854 | 25.498075 | 38233.902923 | 0.050000 | 29144351 | | R | F | 377732830.00 | 566431054976.00 | 538110922664.7677 | 559634780885.086257 | 25.508384 | 38251.219273 | 0.049996 | 14808183 | +--------------+--------------+--------------+------------------+--------------------+----------------------+-----------+--------------+----------+-------------+ 4 rows in set (0.3759 sec)
Die Abfrage der Query 1 wurde in rund 0,37sec ausgeführt und damit im Vergleich zum vorherigen Test etwa 230mal schneller. Jedoch werden nicht alle TPC-H-Abfragen schneller ausgeführt. Für einfachere Abfragen arbeitet MySQL wie bisher. Typischerweise ist die Query 9 des TPC-H die am längsten laufende Query, während einige andere Abfragen praktisch genauso schnell auch ohne HeatWave-Funktionalitäten ausgeführt werden (Query 2, 15, 17).
Wenn die Daten aus dem InnoDB-Buffer gelesen werden können, steigen die Ausführungszeiten der ersten Abfrage linear mit dem Datenwachstum. Werden für das Ausführen der Abfrage zusätzlich auch Daten aus den Datenfiles (Diskzugriff) benötigt, steigt die Abfragezeit ungleich an. Für einen TPC-H SF70 Benchmark ergibt sich bereits ein Unterschied in der Ausführungszeit von ~250x (t(SF70-HW) 697s vs t(SF70+HW) 2,79s). Andere, komplexere Benchmarks (z. B. TPC-DS), zeigen bedingt durch komplexe Join-Operationen noch weit größere Unterschiede in der Ausführungszeit (>>1000x).
Die Idee hinter den HeatWave-Funktionen ist also recht einfach: Der MySQL-HeatWave-Service bietet über eine optionale Engine die Möglichkeit, bestehende Abfragen bzw. Applikationen teilweise sehr deutlich zu beschleunigen. OLTP- und OLAP-Anwendungsfälle können gemeinsam in einer MySQL-Datenbank verwendet und Daten auch ohne ETL-Prozesse analysiert werden. Sehr häufig wird die Technologie als "hybride transaktionale und analytische Verarbeitung (HTAP)" bezeichnet.
MySQL-HeatWave-Auto-Machine-Learning
Auf Basis der zuvor genannten HeatWave-Funktionalitäten erweiterte Oracle diese um Machine-Learning-Funktionalitäten. Wie bei HeatWave werden die ML-Funktionalitäten über Autopilot-Prozeduren zur Verfügung gestellt. Alle für den ML-Prozess notwendigen Interaktionen erfolgen über MySQL und entsprechende SQL-Befehle. Alle Befehle sind auch für ML weitestgehend automatisiert und können mit einer minimalen Anzahl an erforderlichen Parametern ohne fortgeschrittene ML-Kenntnisse umgesetzt werden. Auch für ML-Prozesse entfallen jegliche Datenimport/-export bzw. ETL-Prozesse.
AutoML unterstützt das überwachte maschinelle Lernen. Das heißt, es wird ein maschinelles Lernmodell erstellt, indem eine Tabelle in MySQL analysiert wird. Hierbei erkennt HeatWave Muster, die es ermöglichen, Merkmale eines neuen Datensatzes oder ganzer Tabellen vorherzusagen. HeatWave unterstützt dabei verschiedene Modelle. Wie zuvor fokussieren wir uns in diesem Beispiel auf MySQL 8.0.36. Die Konzentration liegt bei diesem Release zunächst auf den Classification- als auch Regressions-Modellen. Ein Klassifikationsmodell sagt diskrete Werte voraus (eine E-Mail ist Spam, Genehmigung, Kreditantrag). Ein Regressionsmodell sagt kontinuierliche Werte voraus (Wartezeiten von Kunden, erwartete Umsätze oder Immobilienpreise). Ebenso können bereits jetzt weitere Modelle umgesetzt werden (Time Series Forecasting, Anomaly Detection, Recommendation).
HeatWave AutoML gliedert den Prozess in fünf Schritte: Train Model, Load Model, Evaluate Model, Generate Inference und Explain Model.
Nehmen wir hier erneut ein Beispiel aus der MySQL-HeatWave-Dokumentation (Example Data/Direct Marketing/Banking Products) [7]: In diesem Beispiel liegen uns die Gesprächsdaten und Kontaktdetails der Angerufenen eines Callcenters im Auftrag einer Bank vor. Wir suchen nach Mustern, die zu einem erfolgreichen Abschluss eines Bankproduktes geführt haben könnten. Uns liegen hierfür die Gesprächsdaten von etwa 32.000 Anrufen in der Tabelle heatwaveml_bench.bank_marketing_train vor. Diese verwenden wir als Trainingsdaten.
Um das ML-Modell zu trainieren, müssen wir letztlich nur die MySQL-Tabelle (*train), die Zielspalte (y), einen Namen für das Trainingsmodell (model_bank) und die gewünschte ML-Zielaufgabe (Classification) mitgeben. Wenn der Trainingsvorgang abgeschlossen ist, wird das Trainingsmodell der Sitzungsvariablen @model_bank zugewiesen und im Modellkatalog gespeichert.
MySQL heatwaveml_bench SQL > CALL sys.ML_TRAIN('heatwaveml_bench.bank_marketing_train', 'y', JSON_OBJECT('task', 'classification'), @model_bank);
Query OK, 0 rows affected (8 min 47.8440 sec)Das neue Modell wird erstellt und im Model Catalog abgelegt. Um das gelernte Modell verwenden zu können, müssen wir es nun laden:
MySQL heatwaveml_bench SQL > CALL sys.ML_MODEL_LOAD(@model_bank, null); Query OK, 0 rows affected (0.7470 sec)
Bevor Sie Modelle in der Produktion einsetzen, sollten Sie diese evaluieren und testen. Hierfür verwenden wir eine zweite Tabelle (Faktentabelle mit bestehen Ergebnissen, *test), welche wir für einen Vergleich mit unserer Prognose für die Spalte y auf Basis einer Score Metric (accuracy, f1-score, balanced_accuracy u. a.) einsetzen.
MySQL heatwaveml_bench SQL > CALL sys.ML_SCORE('heatwaveml_bench.bank_marketing_test', 'y', @model_bank, 'accuracy', @score_bank, null);
MySQL heatwaveml_bench SQL > SELECT @score_bank;
+--------------------+
| @score_bank |
+--------------------+
| 0.9041580557823181 |
+--------------------+
1 row in set (0.0006 sec)
Query OK, 0 rows affected (2.3470 sec)Accuracy ist ein Maß für die Bewertung von Klassifizierungsmodellen. Es wird über die Division der richtigen Prognosen und Anzahl der Prognosen gebildet. In unserem Beispiel sind 90,4 Prozent aller Prognosen für die verglichene Referenztabelle richtig. Eine Optimierung und die Bewertung können bei Bedarf aber auch auf anderen Metriken basieren, wie z. B. Minimierung falsch-positiver oder falsch-negativer Vorhersagen.
Als letzten Schritt kann man nun das Trainingsmodell auf eine Tabelle anwenden oder, wie in unserem Beispiel, einen einzelnen Datensatz berechnen lassen.
MySQL heatwaveml_bench SQL > SET @row_input = JSON_OBJECT("age", "30", "job", "services", "marital", "married","education", "secondary","default1", "no", "balance", "7032", "housing", "no", "loan", "no","contact", "cellular", "day", "17", "month", "jul", "duration", "402","campaign", "1", "pdays", "-1","previous", "0", "poutcome", "unknown");
MySQL heatwaveml_bench SQL > SELECT sys.ML_PREDICT_ROW(@row_input, @model_bank, NULL);
+---------------------------------------------------------------------------------------+
sys.ML_PREDICT_ROW(@row_input, @model_bank, NULL)
+---------------------------------------------------------------------------------------+
| {"age": 30.0, "day": 17.0, "job": "services", "loan": "no", "month": "jul", "pdays": -1.0, "balance": 7032.0, "contact": "cellular", "housing": "no", "marital": "married", "campaign": 1.0, "default1": "no", "duration": 402.0, "poutcome": "unknown", "previous": 0.0, "education": "secondary", "Prediction": "no", "ml_results": "{\"predictions\": {\"y\": \"no\"}, \"probabilities\": {\"no\": 0.8799999952316284, \"yes\": 0.11999999731779099}}"} |
+--------------------------------------------------------------------------------------+
1 row in set (0.1664 sec)Für das hier gegebene Beispiel lautet die ML-Prognose auf Basis des trainierten Modells zu 88 Prozent "no" bzw. 12 Prozent "yes". In einem weiteren Schritt können wir nun schauen, wie die einzelnen Felder des Datensatzes dem Ergebnis "⁄" zu- oder entgegengearbeitet haben.
MySQL 192.168.1.97:3306 ssl heatwaveml_bench SQL > SELECT sys.ML_EXPLAIN_ROW(@row_input, @model_bank,JSON_OBJECT('prediction_explainer', 'permutation_importance'));
+_-------------------------------------------------------------------------------------------+
| sys.ML_EXPLAIN_ROW(@row_input, @model_bank,JSON_OBJECT('prediction_explainer', 'permutation_importance')) +--------------------------------------------------------------------------------------------+
| {"age": 30, "day": 17, "job": "services", "loan": "no", "Notes": "age (30.0) had the largest impact towards predicting no, whereas duration (402.0) contributed the most against predicting no", "month": "jul", "pdays": -1, "balance": 7032, "contact": "cellular", "housing": "no", "marital": "married", "campaign": 1, "default1": "no", "duration": 402, "poutcome": "unknown", "previous": 0, "education": "secondary", "Prediction": "no", "ml_results": "{'attributions': {'age': 0.28, 'balance': -0.05, 'campaign': 0.01, 'contact': -0.03, 'day': 0.1, 'default1': 0.0, 'duration': -0.12, 'education': 0.0, 'housing': -0.02, 'job': -0.03, 'loan': -0.01, 'marital': 0.01, 'month': 0.14, 'pdays': 0.0, 'poutcome': 0.01, 'previous': 0.01}, 'predictions': {'y': 'no'}, 'notes': 'age (30.0) had the largest impact towards predicting no, whereas duration (402.0) contributed the most against predicting no'}", "age_attribution": 0.28, "day_attribution": 0.1, "job_attribution": -0.03, "loan_attribution": -0.01, "month_attribution": 0.14, "pdays_attribution": 0, "balance_attribution": -0.05, "contact_attribution": -0.03, "housing_attribution": -0.02, "marital_attribution": 0.01, "campaign_attribution": 0.01, "default1_attribution": 0, "duration_attribution": -0.12, "poutcome_attribution": 0.01, "previous_attribution": 0.01, "education_attribution": 0} |
+--------------------------------------------------------------------------------------------+
1 row in set (4.9243 sec)Auf Basis dieser Daten haben das Alter (0.28), die Dauer des Anrufes (402.0) und der Anrufmonat (0.14) den größten Einfluss auf die Entscheidung. Auf letzteres hätten wir leicht einwirken können. Wenn wir den Kunden im März (statt Juli) angerufen hätten, ergibt sich ein (leicht) positives Ergebnis für einen erfolgreichen Abschluss.
MySQL heatwaveml_bench SQL > SELECT sys.ML_PREDICT_ROW(@row_input, @model_bank, NULL);
+----------------------------------------------------------------------------------------+
| sys.ML_PREDICT_ROW(@row_input, @model_bank, NULL)
+---------------------------------------------------------------------------------------+
| {"age": 30.0, "day": 17.0, "job": "services", "loan": "no", "month": "mar", "pdays": -1.0, "balance": 7032.0, "contact": "cellular", "housing": "no", "marital": "married", "campaign": 1.0, "default1": "no", "duration": 402.0, "poutcome": "unknown", "previous": 0.0, "education": "secondary", "Prediction": "yes", "ml_results": "{\"predictions\": {\"y\": \"yes\"}, \"probabilities\": {\"no\": 0.4699999988079071, \"yes\": 0.5299999713897705}}"} |
+---------------------------------------------------------------+
1 row in set (0.1639 sec)
Zwischenfazit
Mit MySQL HeatWave wurden die Kernfunktionen der Datenbank nicht nur erweitert. Der ursprüngliche Anwendungsfall der Datenbank mit Fokus auf OLTP kann nun sehr einfach auch für sehr große Datenmengen angewendet werden. Auch OLAP/Analytische Funktionalitäten in Verbindung mit Machine-Learning-Funktionen können nun sehr unkompliziert realisiert werden.
Im kommenden Artikel werden wir uns mit zwei weiteren Erweiterungen mit MySQL HeatWave beschäftigen. Diese fokussieren sich auf die Analyse von Daten auf Basis eines Object Storage (MySQL HeatWave Lakehouse und MySQL HeatWave AI).
- DB-Engines: Rangliste der Popularität von Datenbankmanagementsystemen
- MySQL: CIS Benchmark for MySQL Enterprise Edition
- Oracle: Network Load Balancer
- OLTP vs. OLAP: Was ist der Unterschied und wie werden sie verwendet?
- MySQL: HeatWave Quickstarts
- MySQL: MySQL HeatWave User Guide
- GitHub: HeatWave ML Code for Performance Benchmarks
Github: oracle-samples / heatwave-ml
