Projekt Norsu: Ersetzen von JCR in Magnolia durch einen (ele)fantastischen neuen Inhaltsspeicher

Magnolia DXP verwendet JCR als zugrundeliegende Speicherlösung, aber diese Entscheidung bringt eine gewisse Komplexität mit sich, die es schwieriger macht, Leistung und Skalierbarkeit in der Cloud zu gewährleisten.

Also machte sich das Magnolia-Entwicklungsteam daran, eine bessere Lösung zu entwickeln und startete ein Projekt, das als Projekt Norsu bekannt wurde. Aleksandr (Sasha) Pchelintcev, Engineering Manager bei Magnolia, sprach auf den Magnolia DevDays im Oktober 2022 über das Projekt Norsu, und es war eines der beliebtesten Themen der Konferenz.

Deshalb habe ich ihn gebeten, ein weiteres Gespräch über Norsu zu führen. In diesem Interview wird er erklären, warum das Projekt wichtig ist, und einige Fragen der Zuhörer beantworten.

Sandra: Hallo Sasha, lass uns gleich einsteigen. Was ist Norsu?

Sasha: Also, wenn Sie nach dem Wort fragen: Es bedeutet "Elefant" auf Finnisch. Als ich nach einem Namen suchte, hatten wir bereits beschlossen, eine Postgres-Datenbank als Nachfolger für die JCR-Inhaltsspeicherung zu verwenden. Warum also nicht etwas verwenden, das mit Elefanten zu tun hat? Da ich in Finnland lebe, wählte ich 'norsu'.

Sandra: Und was ist das Projekt Norsu?

Sasha: Es handelt sich um eine schlanke Java-API und ein SDK, das auf einem Postgres-Datenbankschema aufbaut. Wie Sie wissen, hat Magnolia JCR und Jackrabbit als Inhaltsspeicher verwendet. Aber es gab eine gewisse Nachfrage, dies durch etwas anderes zu ersetzen.

Nach unseren Recherchen haben wir uns für eine Lösung mit PostgreSQL entschieden. Das Hauptziel des Projekts ist es, Magnolia-Entwicklern eine einfache API zur Verfügung zu stellen, mit der sie ihre Inhalte besser speichern können.

Sandra: Sie sagen, dass es "gewisse Forderungen" gab, die JCR zu ersetzen. Warum?

Sasha: JCR ist eine ziemlich eigenartige Technologie. Sie ist sehr ausgereift, und meiner persönlichen Meinung nach ist sie ziemlich brillant. Aber es gibt viele Gründe, sie zu ersetzen.

Die Verwaltung von JCR-basierten Lösungen ist aus verschiedenen Gründen ziemlich kompliziert, z. B. weil der Index separat gespeichert wird, es Probleme mit der Skalierbarkeit gibt und Jackrabbit ein In-Memory-System ist. Wir mussten uns mit Fragen der Infrastruktur, der Verwaltung, der Leistung und sogar der Programmierung befassen.

Auch wenn man all diese Probleme überwinden kann, werden sie in der Cloud noch verstärkt. Anstatt uns mit JCR durchzukämpfen, haben wir beschlossen, eine einfachere Lösung zu entwickeln, die auf Technologien basiert, die besser für die Cloud geeignet sind. Das ist, kurz gesagt, der Grund.

Sandra: Ok, es gab also mehrere Gründe, warum Sie JCR ersetzen wollten. Warum haben Sie sich für eine Postgres-Datenbank entschieden?

Sasha: Wir haben recherchiert und mehrere Kandidaten für den Nachfolger des Inhaltsspeichers in Betracht gezogen. Wir haben uns für Postgres entschieden, weil es alle Kriterien erfüllt.

Natürlich gab es auch andere Optionen für unstrukturierte oder flexible Inhaltsverwaltung. Wir dachten an eine NoSQL-Lösung. Aber wenn man sich ein wenig näher mit der Funktionsweise von NoSQL-Datenbanken befasst, stellt man fest, dass es sich um Nischenlösungen handelt. Man muss genau wissen, mit welcher Art von Daten man arbeitet, um die Vorteile einer NoSQL-Lösung voll ausschöpfen zu können, und wir wollten unsere Inhalte flexibel halten.

NoSQL-Datenbanken verfügen nicht über Joins, sie verfügen in der Regel nicht über ACID-Transaktionen, und die Indizierung von NoSQL-Daten ist sehr spezifisch. Eine NoSQL-Datenbank ist also eigentlich eine ziemlich rohe Datenbank, die viele Aufgaben auf die Entwickler abwälzt. Viele Dinge müssten auf der Ebene der Anwendungsschicht erledigt werden, was ein gewisses Fachwissen voraussetzt.

Wir mussten sicherstellen, dass die Datenbank Dokumente problemlos speichern, indizieren und verwalten kann, ohne uns auf eine Nischenlösung zu beschränken. Postgres erfüllt diese Aufgabe für uns. Es ist Open Source und sehr leistungsfähig. Sie bietet sowohl relationale Funktionen wie Constraints, Integrität und ACID-Transaktionen als auch viele NoSQL-Funktionen wie die Unterstützung komplexer Strukturen wie JSON. Und sie ermöglicht es uns, beides durch Funktionen zu kombinieren, die selbst in der relationalen Datenbanklandschaft ziemlich einzigartig sind, wie z. B. die Unterstützung für hierarchische Datentypen.

So konnten wir eine API entwickeln, die das tut, was JCR für Magnolia getan hat, aber auf einer Datenbank basiert, die in der Branche heute weit verbreitet ist und in Bezug auf die Akzeptanz und die Community boomt. Außerdem wird sie von allen Cloud-Anbietern standardmäßig unterstützt. Wir sind also mit dem Trend gegangen und gleichzeitig pragmatisch geblieben.

Sandra: Ok. Das ist also der Grund, warum Norsu auf Postgres aufbaut. Ich frage mich, ob Sie Postgres von Anfang an verwenden und dann die API darauf aufbauen?

Sasha: Ja. Wir versuchen, innerhalb des Standards zu bleiben. Wir schreiben keine bestimmte Version oder Verteilung vor. Im Moment verwenden wir eine von AWS verwaltete Lösung, weil wir AWS in einigen anderen Projekten einsetzen.

Norsu setzt eine Standard-Postgres-Datenbank mit ihrer Schemaspezifikation ein. Es enthält einige API-Funktionen auf Datenbankebene, mit denen Sie dieses Schema bedienen können. Die Java-API setzt darauf auf.

Wir verwenden eine ausgefallene Technologie, mit der wir die Bindungen generieren können. Wir nehmen die API auf Datenbankebene und verwenden dieses Tool zur Codegenerierung, um die entsprechenden Java-Funktionen zu erzeugen, die Sie in Ihrem Code verwenden können.

Dann fügen wir eine zusätzliche API-Ebene hinzu, um diese Funktionen zu beschönigen und den Entwicklern die Bedienung zu erleichtern. Derzeit arbeitet die API mit JDBC, Sie benötigen also einen Verbindungspool, um sie zu nutzen. In Zukunft werden wir vielleicht andere Protokolle in Betracht ziehen, um das SDK von der Datenbank zu trennen.

Sandra: Wenn Sie die Vorteile von Norsu gegenüber JCR zusammenfassen sollten, was wären Ihre Top 5?

Sasha: Norsu ist einfacher zu bedienen. Es ist genauso einfach, Norsu einzusetzen, wie eine Postgres-Datenbank in einem Container zu installieren. Alles wird zusammen gespeichert, auch die eigentlichen Daten und Indizes. Auch das Sichern und Wiederherstellen, Manipulieren und Prüfen ist einfach. Sie können also einfach Ihr Verwaltungstool starten und damit arbeiten. Und dann erhalten Sie einfach die Java-API darüber hinaus.

Norsu ist besser skalierbar, insbesondere was die Leseleistung betrifft. Postgres kann mit Standby-Replikaten sofort skaliert werden, und Cloud-Anbieter verringern die Bedenken noch mehr, indem sie verwaltete Lösungen wie AWS Aurora anbieten. So erhalten Sie einen Cluster, der mit der Nachfrage skalieren kann. Im Vergleich zu Jackrabbit ist es also ziemlich robust.

Norsu verfügt über maßgeschneiderte APIs, die wir unter Berücksichtigung der Anforderungen von Magnolia entwickelt haben. Wir haben nicht einfach eine generische Lösung genommen, sondern die API zu einem Bürger erster Klasse gemacht. Wir haben mit bekannten Anwendungsfällen begonnen und die API kann sich mit Magnolia weiterentwickeln. Unser SDK ist also schlanker und einfacher zu handhaben und zu entwickeln als das von Jackrabbit.

Norsu hat bessere Indizierungsmöglichkeiten, was meiner Meinung nach ein großer Vorteil ist. Wie Sie wissen, kommt Jackrabbit mit Lucene. Und wie ich bereits erwähnt habe, müssen Sie den Lucene-Index an einem anderen Ort speichern als den persistenten Speicher. Lucene ist zwar ein großartiger Index, aber mit Norsu ist alles an einem Ort gespeichert, und es ist viel, viel einfacher zu bedienen und performanter.

Norsu ist offener. Es legt den Inhalt offen und lässt Sie mit Standardwerkzeugen arbeiten. Das öffnet sehr interessante Türen für Integrationen. Nehmen wir zum Beispiel an, Sie nehmen den Inhalt, der in Postgres gespeichert ist, und füttern damit eine Indexierungsmaschine wie Elastic. Ich denke, dass das mit Jackrabbit nicht so einfach möglich wäre. Eine offene Lösung ermöglicht eine bessere Integration mit dem Rest der Technologiewelt.

Sandra: Während Ihrer Präsentation auf den Magnolia DevDays sprachen Sie speziell über Knoten, die ein wichtiges Konzept in Norsu sind. Was sind Nodes und warum haben Sie sie entwickelt?

Sasha: Jeder, der mit JCR vertraut ist, weiß um Knoten als Bausteine für Inhalte. Norsu übernimmt dieses Konzept, wenn auch etwas anders.

Der Hauptunterschied besteht darin, dass in JCR ein Knoten ein Container für eine Liste von Eigenschaften ist. Ein JCR-Knoten stellt also einen flachen Inhalt dar. Wenn Sie einen komplexen Inhalt, z. B. eine Webseite, erstellen möchten, müssen Sie eine Reihe von Knoten, wie Bereiche und Komponenten, in einer Hierarchie verschachteln.

Aus der JCR-Perspektive sind dies einzelne Knoten, aus der Magnolia-Perspektive gehören sie zu einer einzigen Entität, der Seite. Dies stellt eine mentale und technische Belastung dar.

Norsu wiederum behandelt Knoten als eine Einheit, unabhängig davon, wie komplex sie unter der Haube ist. In Norsu wird eine Seite durch einen einzigen Knoten dargestellt, hinter dem sich eine komplexe, verschachtelte Inhaltsstruktur verbirgt. Komponenten und Bereiche verlieren ihre Individualität.

Sandra: Wie werden diese Knoten in Postgres dargestellt?

Sasha: Aus Sicht der Datenbank ist ein Knoten ein Datensatz mit einer ID, wie eine UUID in JCR, und einem Versionsbezeichner, der aus einem JSON-Objekt und einem Zeiger auf eine frühere Version besteht. Mit diesem einfachen Aufbau lässt sich die gesamte Historie des Knotens verfolgen.

Der Kerngedanke ist, dass Norsu wie ein reiner App-Speicher funktioniert, in den Sie Ihre Inhalte pushen, so dass Sie die Historie der Änderungen durchsuchen und zu einer bestimmten Version zurückkehren können.

Sandra: Cool. Lassen Sie uns ein paar Fragen aus Ihrer Präsentation auf den DevDays ansprechen. Die erste Frage bezieht sich auf Sitzungen in JCR im Vergleich zu Norsu. Wie geht Norsu mit sitzungsübergreifenden Transaktionen um?

Sasha: Das JCR-Repository verwendet das Konzept einer Sitzung. Sie können eine Sitzung abrufen - Magnolia folgt dem sogenannten Session-per-Request-Muster - um eine Reihe von Änderungen an verschiedenen Knoten vorzunehmen und dann Ihre Sitzung wieder zusammenzuführen. Das ist ein sehr bequemes Muster, aber es hat seinen Preis in der Komplexität: Sitzungen neigen dazu, veraltet zu sein, und es gibt Probleme wie die Gleichzeitigkeit.

Wenn Sie sich den typischen Ablauf der Inhaltsbearbeitung in Magnolia ansehen, arbeiten Sie nur mit einigen wenigen Entitäten gleichzeitig. Wenn Sie zum Beispiel mit Content Apps arbeiten, wählen Sie den Eintrag, den Sie ändern möchten, klicken auf Bearbeiten und ändern einige Eigenschaften und vielleicht einige verschachtelte Teile. Das Gleiche gilt für Seiten usw. So funktioniert auch Ihr Gehirn.

Die Tatsache, dass Sie umfangreiche Änderungen vornehmen, ist hauptsächlich auf die Art und Weise zurückzuführen, wie JCR komplexe Strukturen darstellt, wie wir bereits besprochen haben.

Wie wäre es also, wenn Sie Ihre Seite und ihren komplexen Inhalt als eine Einheit betrachten?

Es gibt nur eine ID an der Spitze, unabhängig davon, was unter der Haube passiert. Vielleicht ist es komplex, vielleicht verschachtelt, vielleicht verzweigt, es ist immer noch derselbe Inhalt. Und wann immer Sie diesen Inhalt aktualisieren, handelt es sich um eine Transaktion.

Der typische Ablauf ist, dass Sie alle komplexen Inhalte abrufen, mit ihnen als JSON-Objekt in Ihrem Java-Code arbeiten und dann einfach eine neue Version dieser Inhalte an Norsu zurückschicken. Das ist Ihre Transaktion.

Anstatt also eine ganze Reihe von Knoten in einer Transaktion zu aktualisieren, aktualisieren Sie den komplexen Inhalt eines einzelnen Knotens in einer Transaktion. Und das ist mit einer relationalen Datenbank wie Postgres sehr einfach zu handhaben.

Da wir Versions-IDs beibehalten, ist es auch möglich, optimistisches Sperren zu verwenden. Wenn ich zum Beispiel meinen Inhalt von Version x auf Version y aktualisieren möchte. Die Datenbank kann leicht feststellen, dass die Version x nicht die aktuelle Version ist, sondern die Version z.

Da diese Aktualisierung mit den Änderungen eines anderen Benutzers kollidieren würde, kann Magnolia eine Konfliktmeldung auslösen. Ich glaube, das ist heute viel stabiler als früher.

Sandra: Okay. Als Nutzer von Magnolia würde ich mir das wirklich wünschen.

Nun zu einer weiteren Frage aus Ihrer Sitzung: Wird es einen Migrationspfad von JCR zu Norsu geben?

Sasha: Im Moment ist Norsu auf neue SaaS-Implementierungen ausgerichtet, und wir bieten keinen Migrationspfad aus der Box heraus.

Wir haben bereits Werkzeuge für einfache Anwendungsfälle, die einen gewissen Automatisierungsgrad erreichen können. Wir werden dies neu überdenken müssen, sobald Norsu für unser PaaS oder das selbst gehostete Bereitstellungsmodell verfügbar ist.

Sandra: Die nächste Frage aus Ihrem Vortrag bezieht sich auf die Indizierung von Inhalten, über die Sie bereits kurz gesprochen haben. Die Frage lautet: Kann man Inhalte für Elasticsearch indizieren?

Sasha: Ja, ich hatte ein Offline-Gespräch über dieses Thema. Das Unternehmen baut eine Handelslösung mit Magnolia auf, und sie wollten eine erweiterte Suche haben.

Sie wollen Inhalte aus Norsu übernehmen und in Elasticsearch indizieren, damit ihre Anwendung von diesem Index profitieren kann. Anders als bei JCR gibt es keinen konzeptionellen Blocker, der sie daran hindern würde, sich von einem Elasticsearch-Cluster aus mit der Postgres-Datenbank zu verbinden. Moderne Cloud-Anbieter wie Azure oder AWS bieten die Möglichkeit, relationale Datenbanken über serverlose Funktionen mit anderen Diensten zu verbinden.

Sandra: Welche Art von Nutzern müsste eigentlich über Magnolias Speicherlösung Bescheid wissen?

Sasha: In erster Linie Entwickler. Sie müssen mit den neuen APIs mit anderen Funktionen arbeiten. Wenn sie bereits mit Magnolia arbeiten, müssen ihre Lösungen wahrscheinlich neu entwickelt werden.

Für Autoren, die über Magnolia-Apps interagieren, wie z. B. die Seiten- oder Inhaltstyp-Apps, ist die zugrunde liegende Speicherung transparent. Das Backend ist anders, aber ansonsten sind die Funktionalität und das Nutzererlebnis dieselben.

Sandra: Frontend-Entwickler würden doch weiterhin die Delivery-API verwenden, oder?

Sasha: Genau. Der Prozess ist (fast) transparent für Entwickler, die Headless-Lösungen auf Magnolia aufbauen. Der Verbrauch komplexer Inhalte wird etwas anders sein, und die Definitionen werden sich ein wenig ändern, aber die Ausgabe der Delivery API wird sehr ähnlich sein.

Wir wollen auch Abwärtskompatibilität für die Ausgabe der Delivery-API bieten, so dass sie wie die Ausgabe von JCR aussieht, so dass unsere Nutzer ihren Frontend-Code nicht ändern müssen. Das Team, das unsere Frontend-Helfer, die Bibliotheken, die Magnolia an verschiedene Frontend-Frameworks anbinden, pflegt, musste sie nicht großartig ändern, damit sie mit Norsu funktionieren.

Aber die Hardcore-Backend-Entwickler, die Erweiterungen für Magnolia mit JCR-APIs erstellen, werden sich anpassen müssen.

Sandra: Eine weitere Frage aus Ihrer Sitzung bezieht sich ebenfalls auf die Delivery API: Wie passt GraphQL zu Norsu?

Sasha: Normalerweise spricht GraphQL nicht direkt mit einer Datenbank. Es macht in der Regel keine direkten Datenbankabfragen, sondern sitzt auf einer Anwendungsschicht und aggregiert die Antworten von verschiedenen Speichern und APIs über sogenannte Datenabrufer. Das macht es so leistungsfähig.

Um diese Funktionalität bereitzustellen, müssen Sie einen GraphQL-Server implementieren, zum Beispiel mit einem GraphQL-Java-Framework. Der Java-Code verbindet die Datenabrufer mit Ihrem Backend, und die Norsu-API passt genauso gut wie JCR in dieses Szenario. Der GraphQL-Java-Server holt Ihre Daten über die Java-API von Norsu, zerlegt ein Content Slice Set entsprechend der GraphQL-Abfrage und liefert die Ausgabe im gleichen Format wie bei Jackrabbit.

Es wäre interessant, eine besonders leistungsfähige Implementierung zu haben, die eine GraphQL-Abfrage direkt in eine SQL-Abfrage übersetzt und sie auf Datenbankebene ohne den Zwischenhändler ausführt, so dass jeglicher Leistungs-Overhead entfällt. Theoretisch ist das möglich, aber es könnte dem ganzen Zweck von GraphQL in Bezug auf die Typsicherheit widersprechen. Schauen wir mal.

Sandra: Interessanter Gedanke. Danke.

Schneller Kontextwechsel zum Digital Asset Management (DAM): Wird Norsu in Magnolia gehostete Assets, wie z. B. Bilder, speichern?

Sasha: Unsere bisherigen Erfahrungen mit Jackrabbit zeigen, dass es eine gute Idee ist, Binärdateien von Inhalten zu trennen, und wir glauben, dass es bessere Wege gibt, Assets zu speichern. Norsu ist also dazu gedacht, strukturierte Webinhalte zu speichern und wird wahrscheinlich auch als Speicher für Asset-Metadaten dienen. Es wird also alle Informationen über Assets hosten, während die eigentlichen Binärdateien anderswo gehostet werden, zum Beispiel in S3.

Sandra: Okay, großartig. Lassen Sie uns eine letzte Frage stellen: Was sind die nächsten Schritte im Projekt Norsu?

Sasha: Norsu wird der primäre Inhaltsspeicher für die Magnolia SaaS sein. Er ist auch eng damit verbunden, wie sich Magnolia in Zukunft weiterentwickeln wird, wenn wir mehr Erkenntnisse gewinnen.

Es ist wichtig zu verstehen, dass die Abschaffung von JCR und die Verbesserung der Leistung und Skalierbarkeit von Magnolia nicht unsere einzige Sorge ist. Wir denken auch an unsere bestehenden Kunden und daran, wie wir ihnen den Übergang so reibungslos wie möglich gestalten können. Das erschwert die Aufgabe erheblich. Bleiben Sie also dran.

Sandra: Vielen Dank, Sasha.

Sasha: Vielen Dank.

Wenn Sie mehr über das Projekt Norsu erfahren möchten, können Sie sich Sashas DevDays-Vortrag hier ansehen: