Freitag, 23. August 2024

Content-Less Language Model (CLLM) - oder wo Perplexity zurzeit scheitert

In diesem Beitrag geht es um die Verbesserung, oder Neuerfindung der klassischen Internet-Suche. Also jener Suche, welche relevante Resultate aus dem öffentlichen Internet liefert. Bis vor nicht all zu langer Zeit funktionierte stark vereinfacht formuliert so, dass man einen oder mehrere Suchbegriffe eintippte und im Anschluss eine lange Liste von Links auf Internetseite mit Vorschau bekam. Vereinzelt wurden Resultate berechnet, bspw. wenn man 4 + 1 als Suchterm erfasste, bekam man neben den üblichen Links zuoberst auch gleich das Resultat 5.

Die Firma OpenAI präsentierte mit ChatGPT gegen Ende 2022 ein Produkt, mit welchem man auf natürliche Art und Weise textlich (Chat) kommunizieren konnte und welches scheinbar alles wusste. Der Rest ist Geschichte.

Google, welche bis dahin eigentlich in Sache KI in der Forschung und Entwicklung als kommerzielle Firma als führend galt - und tatsächlich beruhte dieses ChatGPT mindestens auch auf Forschungsarbeit von Google (mehr zu Transformer später) - geriet unter Zugzwang und präsentierte nach dem einen oder anderen Stolpern mit Shakespeare Gemini als ernst zu nehmendes Konkurrenzprodukt.

Es gibt bis heute unzählige Beiträge und Studien zu diesen LLM-Produkten. Ich habe an dieser Stelle relativ früh, bereits im Dezember 2022, über erste Erfahrungen von ChatGPT geschrieben (Link). Seither ist einiges gegangen.

Obwohl die Modelle immer besser werden, eines blieb bis heute: Sie halluzinieren. Sowohl ChatGPT wie auch Gemini erzählen einfach manchmal wortwörtlich Märchen und tun so, als seien es Fakten.

Und damit zurück zur Einleitung. Es geht hier in diesem Beitrag um die klassische Internet-Suche. Also um die Suche nach Fakten. Nicht im Fokus sind die Fähigkeiten, kreativ zu sein. Geschichten zu erzählen. Individuelle Briefe zu schreiben. Oder neue Ideen für ein Projekt zu generieren. Bei solchen Tätigkeiten ist Halluzination ja durchaus hilfreich, wenn nicht gar erwünscht und die Modelle erfüllen durchaus den Zweck.

Die meisten Benutzer wissen, dass sie Antworten von ChatGPT, Gemini & Co. überprüfen müssen, wenn es wichtig ist, dass diese korrekt sind. Ich habe hier in einem LinkedIn-Kommentar zu diesem Verhalten das neue Verb "nachgooglen" vorgestellt. Es widerspiegelt die Tatsache die notwendig ist, wenn man solche Werkzeuge für wichtige Dinge nutzt.

Perplexity ist ein junges Startup aus den USA, gegründet 2022. Die beiden bekanntesten Investoren sind die Firma NVIDIA und der Amazon-Gründer Jeff Bezos. Perplexity fokussiert sich nach eigenen Angaben in erster Linie (aber nicht nur) genau auf die Internet-Suche und geht dabei, ebenfalls nach eigenen Angaben, einen neuen Weg.

Die grossen Sprachmodelle (Large Language Model, kurz LLM), sind, wie es der Name schon sagt, Modelle der Sprache. Sie konstruieren aus den Trainingsdaten anhand der Abfragen, sogenannte Prompts, Antworten. Dabei sind diese meist sprachlich "perfekt", aber inhaltlich nicht selten unpräzis bis komplett falsch. Die Modelle halluzinieren wie bereits erwähnt. Die Kombination von klassischer Suche mit einem LLM-Chatbot führt zu einem unbefriedigenden Gesamtergebnis. Dies nicht zuletzt deshalb, weil die Aussagen, die das LLM generiert, nicht immer mit den Aussagen übereinstimmen, welche die Quellen machen, welche die klassische Suche als relevant ausgegeben hat. Gemini bietet die Funktion an, dass man die Ergebnisse überprüfen kann. Das ist automatisiertes "nachgooglen". Eine nette Funktion die mindestens mir häufig anzeigt, dass zu gemachten Aussagen keine relevanten Referenzen gefunden wurden. Im Fachjargon nennt man den Prozess des automatisierten Nachprüfen von Ergebnissen eines Modells auch "Grounding". Man verifiziert die Aussagen gegenüber Quellen, die man als verlässlich einstuft. Dieser Grounding-Prozess ist wichtig für die Qualitätssicherung.

Exkurs Transformers: Die heutigen LLM basieren meist auf sogenannten Transformer. Diese Transformer hat Google Bain (das Team wurde 2023 in die Firma DeepMind integriert) 2017 erstmals der Öffentlichkeit präsentiert. Das Grundlagenpapier mit dem Titel "Attention Is All You Need" hat dabei gerade mal 15 Seiten: https://arxiv.org/pdf/1706.03762 - Reduce to the max! Das Georgia Institut Of Technology (Georgia Tech) hat eine Anwendung publiziert, welche diese Transformer-Architektur visualisiert: https://poloclub.github.io/transformer-explainer/

Damit zurück zu Perplexity und deren Ansatz.

Mein Verständnis der Funktionsweise von Perplexity ist wie folgt: Zuerst wird 1) mittels Sprachmodell und weiteren linguistischen Methoden der Kontext der Suche - des Prompts - interpretiert. Mit diesem erweiterten Kontext, man könnte wohl sagen, generierte Abfrage - werden im klassischen Sinne 2) die relevanten Quellen gesucht. Wie es scheint, sind für Perplexity jeweils maximal die ersten 8 Ergebnisse relevant. Das scheint empirisch zu sein, zumindest deckt sich dies mit meiner Erfahrung, dass ich in den meisten Fällen die gesuchte Information in den ersten 8-10 Ergebnisse finden. Ich muss selten weiterblättern. Diese 8 Quellen (manchmal sind es auch weniger) werden sodann 3) mit Hilfe von LLM (und weiteren Funktionen?) zusammengefasst.

Dadurch entstehen auf den ersten Blick scheinbar drei Vorteile:
  1. Die 8 (oder weniger) Quellen stehen direkt zur Verfügung, die ersten 3 direkt ganz oben wie bei einer klassischen Suche. Es sind verfügbare Quellen, deren Link funktioniert (bei mir hat jedenfalls bislang keiner nicht funktioniert).
  2. Die Zusammenfassung deckt sich insgesamt mit dem Inhalt aller Quellen (zusammen).
  3. Die Ergebnisse sind nicht halluziniert, da sie eine Zusammenfassung aus einer überschaubaren Anzahl an Quellen sind.
Dass Perplexity die Zusammenfassung in real-time anhand der Quellen macht zeigt sich zum einen daran, dass man Quellen entfernen kann und im Anschluss eine neu berechnete Zusammenfassung bekommt. Zum anderen kann man ihm eine bisher unbekannte URL angeben und Perplexitiy beantwortet die Frage umgehend anhand dieser Website.

Exkurs RAG: Das Vorgehen von Perplexity wird in allgemeiner Form auch als RAG, Retrieval Augmented Generation, bezeichnet. Durch Retrieval (klassische Suche/Erschliessung) gefütterte/angereicherte Text-Generierung. Perplexity geht in seiner Umsetzung meiner Ansicht nach weiter, als dass allgemein unter RAG verstanden wird. Man könnte es vielleicht als extended RAG bezeichnen.

Die rote Pille
Das klingt bis jetzt vielversprechend. Die rote Pille schluckt man, wenn man eine ihm bisher unbekannte Quelle angibt und dazu Fragen stellt oder einfach eine Zusammenfassung möchte. Und sie ist wirklich rot. Denn das Problem ist, dass die neue Quelle nicht gelernt (trainiert) wird. Sie wird offensichtlich einzig dazu verwendet, den sog. Prompt für ein Transformer-LLM zu füttern. Und die Visualisierung der Georgia Tech zeigt schön auf, weshalb das für neue Informationen nicht funktionieren kann. Schauen wir uns dazu ein konkretes Beispiel an. Die von mir entwickelte Python-Library Papys ist unbekannt und war kaum in den Trainingsdaten gängiger LLM und damit ein gutes Beispiel, da sie einen neuen deklarativen Ansatz für die Definition von Rest-API anbietet:


Die erste Antwort von Perplexity ist erwartungsgemäss unzutreffend. Perplexity könnte hier allenfalls den Hinweis geben, dass er keine solche Library gefunden hat mit der Frage, ob ich anstelle von Papys vielleicht die Library PaPy meinte. Ich gebe ihm also den Link auf GitHub zur Library, die ich meine:


Netter Versuch, aber was Perplexity da zu Papys schreibt, ist komplett unzutreffend. Man ist versucht zu glauben, dass er die gegebene URL komplett ignoriert hat. Versuchen wir es also mit einer Pro-Suche, der besten Suche von Perplexity (die nach Angabe von Perplexity auch Code analysieren kann):


Jetzt hat man das Gefühl, dass er real-time auf das Repository zugreift, er extrahiert den Namen "asderix" als Benutzer. Die Beschreibung passt aber nach wie vor nicht auf das gegebene Repository.

Im Code liegt Wahrheit. Schauen wir, ob Perplexity ein korrektes Code-Beispiel erstellen kann. Denn das würde bedeuten, dass Perplexity die neue Quelle wirklich verstanden hat:


Der Code ist falsch, die API-Syntax ist nicht jene von Papys, mehr FastAPI/Flask. 

Und genau an diesem Beispiel sieht man gut, dass die Wahrscheinlichkeiten des nächsten Token aus dem Transformer zum Prompt aus dem GitHub-Repository zu einem FastAPI/Flask-Code führt, weil es dafür jede Menge Trainingsdaten gab. Die Papys-Syntax ist dem Modell dagegen völlig unbekannt (man könnte auch interpretieren, dass mein Rest-API-Ansatz wirklich neu ist. Aber das ist ein anderes Thema).

Diese Problematik zieht sich durch bei LLM, man sieht sie auch bei anderen Produkten. Bspw. ChatGPT:


ChatGPT hatte wohl überaus viele Flask-Trainingsdaten. Nicht einmal der Import ist korrekt.

Man merke: Ein Transformer-LLM kann keinen Text zusammenfassen, welcher komplett neue Informationen enthält. Die Zusammenfassung basiert immer auf dem gelernten (trainierten) Content. Für Texte, welche so oder in ähnlicher Form trainiert wurden, funktioniert es verblüffend gut. Was schon gar nicht funktioniert ist, dieses neue Wissen -  aus dem Prompt, resp. der neuen Quelle - selber anzuwenden (dazu müsste es wieder zuerst umfassend trainiert werden). 

Das ist generell ein Problem, welches bei RAG beobachtet werden kann. Die Prompts werden besser, die Ergebnisse aber nicht, wenn auch die besten Prompts nicht helfen.

Die menschliche Intelligenz funktioniert in Sache Sprache dahingehend anders, als dass Menschen eine wesentlich stärkere Abstraktion von Inhalt und Sprache im engeren Sinne habe. Zum einen können neue Informationen sofort verwendet werden und zum anderen kann mit der neue Information differenziert im Verhältnis zum bestehenden Wissen umgegangen werden. Das zeigt sich bspw. bei Kindern, die einen gelesenen Text zusammenfassen müssen. Sie können den Text auf 10 Sätze kürzen, auch wenn der Inhalt für sie neu ist und sie den Inhalt selber nicht abschliessend verstanden haben. Und dennoch vermischen sie dabei in der Regel die neuen Informationen nicht mit den alten und brauchen um den Text mit neuen Informationen zusammen zu fassen auch nicht dutzende, hunderte oder tausende Trainingsdaten - der eine Text reicht. Da ist etwas, dass es uns Menschen ermöglicht, bekannte Begriffe im neuen Kontext zu verwenden, ohne dass dabei die bisherig bekannte Information anstelle der neuen Information wiedergegeben wird. Kurz: Die Transformer liefern zwar erstaunliche Ergebnisse, kommen beim Sprachgebrauch aber nicht an die menschlichen Fähigkeiten der Sprach-Abstraktion heran. "Attention" scheint nicht alles zu sein, was man braucht.

Content-Less Language Model - CLLM
Perplexity scheitert zurzeit mit ihrem Ansatz, weil sie für den wichtigen Teil Transformer-LLM verwenden, welche gerade für diesen Teil nicht so geeignet sind. Mir gefällt grundsätzlich den Ansatz, so wie ich ihn verstanden habe. Die beiden Probleme der aktuellen LLM: Halluzination und Context bezogene Sprachverwendung, kommen aber auch bei Perplexity zum Vorschein.

Damit der Ansatz von Perplexity funktioniert, bräuchte es ein Sprachmodell, welches Texte zusammenfassen und Informationen extrahieren kann, ohne diese (inhaltlich) mit bestehenden Informationen zu vermischen. Kurz: Es bräuchte ein Content-Less Language Model, CLLM.

Mini-Modelle
Ein alternativer (allenfalls temporärer) Ansatz könnte sein, dass verstärkt auf Mini-Modelle gesetzt wird. Diese Mini-Modelle werden real-time mit wenigen Quellen trainiert und für die Informationsextraktion verwendet. LLM kommen im Anschluss zum Einsatz, um die Mini-Model-Ergebnisse textuell aufzubereiten. Dabei braucht es ein Supervisor-Model/Prozess, welcher das LLM befähigt, bspw. neue Begriffe aus dem Mini-Modell, zu integrieren. Dies kann durch ergänzende NLP-Prozesse erfolgen, welche solche Begriffe klassieren und mit Attributen wie der Wortart und Stemming etc. ergänzen.

Es bleibt spannend, die Weiterentwicklung von AI weiter zu verfolgen. Ich bin aktuell überzeugt, dass es keine grossen Sprünge mehr gibt in den aktuellen Problemfeldern, in dem man die Transformer-LLM einfach weiter vergrössert. Es braucht einen neuen grossen Wurf wie die Transformer 2017, oder eine weitere Verbesserung dahingehend, dass die LLM besser mit weitern Modellen/Ansätzen kombiniert und ergänzt werden können. Dies immer mit der Perspektive auf das Finden und Anwenden von Fakten. Wie erwähnt gibt es durchaus Anwendungsfälle, in denen Halluzination erwünscht ist. RAG ist aktuell in aller Munde. Wer weiss, hilft diese Motivation für einen nächsten grossen Sprung.

Disclaimer:
Die Aussagen in diesem Artikel zur Funktionsweise von einzelnen Produkten und Systemen beruhen auf meinen Beobachtungen und Einschätzungen. Sie wurden weder wissenschaftlich verifiziert noch von den jeweiligen Hersteller bestätigt oder dementiert.



Freitag, 16. August 2024

FIPS 203, 204 und 205 - NIST publiziert (endlich) quantensichere Verschlüsselungsverfahren

Quelle: Wikipedia

Es ist schon längst bekannt, dass Quantencomputer dereinst heute bestehende Verschlüsselungsalgorithmen in nützlicher Zeit brechen können. Damit werden sie in Zukunft unsicher sein. Insbesondere die asymmetrischen Verfahren, die auf dem Problem der Primafaktorzerlegung beruhen.

Wann es Quantencomputer gibt, die dazu in der Lage sind, weiss niemand. Die Forschung und Entwicklung macht stetig Fortschritte. Die Firma IONQ vertreibt erste Chips, welche eine kommerzielle Nutzung ermöglichen: https://ionq.com/technology

Erst diese Woche wurde ein solcher Chip an QuantumBasel geliefert.

Dabei sind Quantencomputer auch in der Theorie keine Wundermittel für alles. Mit ihnen lassen sich bestimmte mathematische Aufgaben, für die ein klassischer Chip sehr viele Rechenschritte braucht, sehr viel effizienter lösen.

In Bezug auf die Verschlüsselung sind das schlechte und gute Neuigkeiten zugleich:
  • Schlecht: Die heute verbreiteten asymmetrische Verschlüsselungsalgorithmen setzen auf mathematische Problemstellungen, welche ein Quantencomputer - theoretisch - sehr viel schneller lösen kann. Damit wird die Verschlüsselung unsicher.
  • Gut: Es gibt Problemstellungen die für eine (asymmetrische ) Verschlüsselung verwendet werden können, mit welchen auch ein Quantencomputer - theoretisch - Mühe hat.
"Theoretisch" ist hier wichtig als Einschränkung. Niemand kann die Entwicklung sicher voraussagen und solange es keine stabil funktionierenden Quantencomputer im grossen Massstab gibt, bleibt es Theorie. Dazu muss man wissen, dass man Quantencomputer, um sie effizient nutzen zu können, anders Programmieren muss als die heute verwendeten. Anders bedeutet, einerseits, dass man mehr deklarativ programmiert (gibt es heute schon) und vor allem auch, dass man andere Algorithmen verwendet. Und genau bei diesen Algorithmen besteht in Bezug auf die Verschlüsselung auch ein Risiko. Niemand kann mit Sicherheit sagen, dass nicht künftig jemand einen Algorithmus entdeckt, mit welchem ein Quantencomputer auch ein bisher als sicher geglaubtes Verschlüsselungsverfahren genügend schnell brechen kann.

Dennoch ist es wichtig, dass man heute anfängt sensible Daten so zu verschlüsseln, dass sie aus heutiger Sicht auch vor Quantencomputern sicher sind.

Die Herausforderung dabei ist, dass man ein Verfahren hat, dass nicht nur Quantencomputer sicher ist, es muss natürlich nach wie vor auch für klassische Computer nicht in nützlicher Frist lösbar sein.

Bislang war das Problem dabei, dass es zwar verschiedene Verfahren gab, diese aber nicht standardisiert waren. Bei der Verschlüsselung sollte man aber unbedingt Standards verwenden, damit man einerseits gut geprüfte Verfahren einsetzt, aber andererseits auch sicherstellen kann, dass es auch in Zukunft Software gibt, welche diese Verfahren unterstützen.

Die bekannteste Organisation, welche solche Standards herausgibt, ist das NIST (National Institute of Standards and Technology, eine US Bundesbehörde des Handelsministeriums mit Sitz in Maryland). Das NIST hat sich bislang Zeit gelassen, Empfehlungen für quantensichere Verschlüsselungsverfahren zu publizieren. Am 13. August 2024 war es nun soweit. Das NIST hat 3 Verfahren als final publiziert:

FIPS 203 - Module-Lattice-Based Key-Encapsulation Mechanism, kurz: ML-KEM (Link):
Spezifiziert einen kryptografischen Mechanismus, der auf der Module-Lattice-Problematik basiert. Das Module-Lattice-Problem ist ein Teil der Gittertheorie. Stark vereinfacht besteht es darin, dass  es extrem schwierig ist, in einem mehrdimensionalen Gitterraum mit Punkten, die Punkte auf dem Gitter zu finden, wenn man nur unvollständige Informationen über den Gitterraum selber und die Punkte hat.

FIPS 204 - Module-Lattice-Based Digital Signature Standard, kurz: ML-DSA (Link):
Basiert wie FIPS 203 auf dem Module-Lattice-Problematik, definiert aber die Verwendung für digitale Signaturen.

FIPS 205 - Stateless Hash-Based Digital Signature Standard, Kurz: SLA-DSA (Link):
Ist eine Weiterentwicklung vom Spincs+-Algorithmus. Als Hash basiertes Verfahren ist die Grundlage kein spezifisches mathematisches Problem. Die Sicherheit kommt viel mehr von der "Einwegigkeit": Aus AB kann man nur C machen, aber aus C kann man nicht auf AB schliessen. Für eine Verschlüsselung ist das ungeeignet, für eine digitale Signatur reicht das aber aus. FIPS 205 wurde vom NIST als "Backup-Verfahren" für FIPS 204 publiziert, falls dieses gebrochen werden kann.

Das NIST hat auch für FIPS 203 noch im Jahr 2024 ein "Backup-Verfahren" in Aussicht gestellt.

Wie den Verfahren zu entnehmen ist, betrifft das "Quantencomputer-Risiko" hauptsächlich asynchrone Verschlüsselungsverfahren, wie sie bspw. im Public-Key-Verfahren angewendet werden, welches bspw. Teil der klassischen TLS-Verschlüsselung ist oder im Bereich der digitalen Signaturen zum Einsatz kommen. Solche Verfahren wie RSA oder Diffie-Hellman könnten durch Quantencomputer mittels dem Shor-Algorithmus kompromittiert werden. Stand heute nicht, resp. viel weniger, betroffen sind starke symmetrische Verschlüsselungsverfahren wie bspw. AES-256 und höher.

Ich empfehle allen CISO, sich mit den Standards vertraut zu machen und zeitnah zu evaluieren, wann diese produktiv eingesetzt werden können.

Donnerstag, 15. August 2024

Reverse ETL: Google BigQuery nach Spanner in der Pre-GA

Meistens hat man eine transaktionale Datenbank, die im operativen Betrieb dazu dient, die Daten zu persistieren und als "master" fungiert. Das heisst, die neusten täglichen Daten werden in dieser Datenbank verwaltet. Um die Geschäftsdaten optimal analysieren zu können, werden die Daten aus dieser transaktionalen Datenbank täglich, oder täglich mehrmals, in ein analytisches Datawarehouse (DWH) gespeichert. Klassisch verwendet ein solches DWH bislang technisch häufig dieselbe Datenbanksoftware wie die transaktionale Datenbank, die Datenstruktur ist aber anders, für Datenanalyse optimiert und daher auch oftmals denormalisiert. Vermehrt kommen für das DWH aber technisch spezialisierte Lösungen wie BigQuery zum Einsatz. Diesen Lade- oder Transferprozess nennt man ETL (extract transform load).

Nun gibt es Use Cases in denen das DWH der Master ist. Es sind Situationen, in denen man bspw. externe Daten täglich lädt, diese historisiert und damit verschiedene Analysen durchführt. Für diese analytischen Funktionen eigenen sich moderne DWH-Technologien wie Google BigQuery hervorragend. Daten können schnell geladen und sehr performant analysiert werden.

Kommen in solchen Architekturen Use Cases dazu, dass man einzelne Daten aus dem DWH auf eine "transaktionale" Art und Weise nutzen muss, also mit tiefer Latenz einzelne Records abfragen, zeigen DWH-Lösungen oftmals etwas ihre Schwächen. Für solche Szenarien sind sie nicht konzipiert. Ist also die Abfrage-Performance von einzelnen Records essentiell, stellt sich die Frage, welche Optimierungs-Möglichkeiten man hat.

Hier kommt als eine Möglichkeit Google Spanner auf den Plan. Spanner ist eine hoch performante Datenbank mit tiefer Latenz, optimiert für den Einsatz als transaktionale Datenbank. Robust, sicher, schnell.

Google hat nun eine hilfreiche Funktion in BigQuery in der Vorschau verfügbar, die genau diesen Use Case adressiert: Daten von BigQuery nach Spanner zu exportieren und dies auf sehr einfache Art und Weise. Da die Daten in die andere als übliche Richtung gehen, spricht man auch von reverse ETL:


Mit BigQuery und Spanner hat man das beste aus beiden Welten: Ein skalierbares und performantes DWH für die grosse Datenspeicherung und Analytics, und für jene Daten, die man performant mit tiefer Latenz transaktional abfragen will, eine hoch verfügbare performante Datenbank mit tiefer Latenz.

Und dank der neuen Funktion von BigQuery, ist der reverse ETL-Prozess äusserst einfach und schnell umgesetzt.

Sicher nicht ganz die alltäglichste Situation, wo genau diese Konstellation sinnvoll ist. Aber es gibt sie. Und für solche Situationen ist es hilfreich zu wissen, dass es Funktionen gibt, welche die Umsetzung so vereinfachen, dass es sich auch für kleinere Use Cases lohnt, auf die tiefe Latenz und hohe Geschwindigkeit von Spanner zu setzen.

Mittwoch, 14. August 2024

GCP Cloud SQL Studio nun allgemein verfügbar

Mit dem Cloud SQL Studio können Sie direkt in der GCP Konsole auf die verwalteten Datenbanken von Cloud SQL (PostgreSQL, MySQL und MS SQL) zugreifen: https://cloud.google.com/sql/docs/mysql/manage-data-using-studio?hl=de

Es gibt verschiedene etablierte gute Datenbank-Management Tools mit wesentlich mehr Features als Cloud SQL Studio. Weshalb sollte man es (trotzdem) nutzen?

Ich sehen den Vorteil klar in der Sicherheit in einem Zero-Trust Setup. Möglichst sicher können Sie mit einem Datenbank-Management Tool ihrer Wahl nur auf eine Cloud SQL-Datenbank zugreifen, wenn Sie in einem dedizierten Organisations-Netzwerk sind, welches Sie mittels VPN mit der GCP verbunden haben. Dieser Setup ist für Administratoren in grösseren Organisationen sicher hilfreich, aber für vieles nicht unbedingt notwendig.

Google bietet mit Chrome Enterprise Premium, vormals vor allem BeyondCorp (Umbenennung ist noch nicht konsequent erfolgt) - Link: https://cloud.google.com/beyondcorp-enterprise/docs/overview?hl=de, eine sehr gute Zero-Trust Lösung, welche ohne VPN auskommt und daher vor allem in der Verwaltung einfacher ist. Dies insbesondere im Zusammenhang mit "New Work", wo sich längst nicht mehr alle Mitarbeiter in einem Firmennetzwerk befinden.

Mit Chrome Enterprise Premium hat man jedoch nur via Browser (auf die GCP Konsole) Zugriff auf GCP. Das bedeutet, ich kann nicht über diese gesicherte Einrichtung auf eine Cloud SQL Datenbank mit meinem Datenbank-Management Tool zugreifen. Anmerkung: Umständlich wäre es via Cloud Shell möglich (pq CLI).

Und genau hier kommt Cloud SQL Studio ins Spiel. Mit dem Zugriff auf meine Datenbank via GCP Konsole, kann ich jetzt möglichst sicher von überall (je nach Policy in Chrome Enterprise Premium natürlich) auf meine Datenbank in Cloud SQL zugreifen.

Obwohl Cloud SQL Studio in Sache Funktionen bekannten Datenbank-Management Tools hinterher ist, bin ich überzeugt, dass man damit 80-100 % der benötigten Aufgaben erfüllen kann.

Damit ist Cloud SQL Studio ein sehr hilfreiches und willkommenes Werkzeug in der GCP Konsole.

Mittwoch, 7. August 2024

Cloud Serie: Google Spanner Graph - Ein "must read" für Software-Entwickler und Daten-Analysten

Für jedes Problem sollte das optimale Werkzeug verwendet werden. Wer nur einen Hammer hat, für den sieht bekanntlich jedes Problem wie ein Nagel aus. So sieht die heile Welt aus. In der Realität gilt es abzuwägen, ob sich der Aufwand tatsächlich lohnt. Jedes Werkzeug muss evaluiert, eingeführt, geschult und gewartet werden. Im schlimmsten Fall verkompliziert die Einführung eines neuen Werkzeuges den ganzen IT-Stack und der erhoffte Nutzen und kehrt sich insgesamt in einem Mehraufwand um.

Graphendatenbanken bieten hervorragende Eigenschaften in der Datenanalyse. Natürlich kann man die Graphen-Theorie auch auf relationale oder Dokumenten basierte (NoSQL-) Datenbanken "ummünzen". Die effizienten Algorithmen der Graphen-Theorie kann man jedoch nicht anwenden, wenn man einen "Graphen" via SQL-Abfrage implementierten muss, weil die Daten in einer relationalen Datenbank gespeichert sind.

Bislang gab es beim Einsatz von Graphendatenbanken jedoch zwei grosse Hindernisse:
  1. Bis vor kurzem gab es keine standardisierte Abfragesprache wie ISO SQL. Damit wird man stark Anbieter abhängig und die Verbreitung einer spezifischen, teilweise sogar proprietären Sprache, ist entsprechend gering. Das erschwert auch die Suche nach Entwicklern, welche die Sprache beherrschen. Das Problem besteht im Übrigen auch bei NoSQL-Datenbanken. Dieses Problem wurde diesen Frühling mit der Veröffentlichung vom ISO-Standard:  ISO/IEC 39075:2024 Information Technology – Database languages – GQL behoben. Link. Klar, gibt es jetzt nicht automatisch schon eine Menge Experten dieser Sprache, aber die Voraussetzung ist geschaffen.
  2. Das eigentlich noch grössere Problem ist, dass Graphendatenbanken eigene, also separate, Datenbanken sind. In der Regel hat man die transaktionalen Daten in einer relationalen Datenbank oder allenfalls Dokument basierten Datenbank gespeichert. Die ganze Business-Logik baut auf einer oder beiden Datenbanken auf. Wenn nun für spezifische Analysen eine Graphendatenbank sinnvoll wäre, stellt sich die Fragen, ob sich der Aufwand lohnt eine solche zu betreiben, mit all dem Aufwand des Betriebs und der Datendublizierung aus den anderen Datenbanken etc. Anders sieht es natürlich aus, wenn der Hauptzweck, wie bspw. bei einer Fahrplan-Applikation, aus Graphen besteht. Das trifft für viele Unternehmens-Applikationen in der Regel aber nicht zu.
Diese zwei Gründe sind meines Erachtens verantwortlich, dass Graphendatenbanken heute eine sehr geringe Verbreitung haben. Für viele Anwendungsfälle lohnt sich der Aufwand insgesamt einfach nicht.

Umso erfreuter war ich von der Publikation von Google, dass die relationale Datenbank Spanner mit Graphen-Funktionen erweitert wurde. Genau gesagt ist Spanner nun GQL-kompatibel.

Das Beste aus beiden Welten! Das erste Problem wurde durch den ISO-Standard behoben und das zweite nun von Google für GCP-Kunden.

Ich glaube, dass vielen Entwicklern und Datenanalysten noch nicht klar ist, welche Möglichkeiten sich damit eröffnen. Plötzlich lohnt es sich, auch für eigentlich kleine Anwendungsfälle die Daten auf Grundlage der Graphentheorie mittels GQL zu nutzen.

Google adressiert genau die bisherigen Probleme und liefert eine passende Lösung dazu. Da hat jemand einen super Job gemacht!

Bei aller Euphorie, seien hier noch folgende Informationen gegeben:
  • Die Funktion ist derzeit in Preview, das heisst, noch nicht definitiv öffentlich verfügbar mit SLA.
  • Die Funktion ist nur in den Spanner Editions Enterprise und Enterprise Plus verfügbar (die neuen Editionen gibt es ab dem 24.09.2024).
  • Mit den neuen Editionen ändert auch das Preismodell von Spanner. Wie ich gesehen habe, kostet die günstigste Konfiguration mit GQL-Funktionalität um die CHF 1'000 p.M. Also eher ungeeignet um klein anzufangen und nur etwas auszuprobieren.
Die Ankündigung von Google findet ihr hier.

Ich empfehle allen Backend-Entwicklern und Datenanalysten, sich GQL und die diesbezüglichen Funktionen von Spanner einmal anzusehen.