Optimierung des Persistenzlayers durch multi-tenancy

Datum 06/2019 – …
Projekt Plattform zum Versand von Nachrichten
Branche Handel
Tätigkeit Architektur, Implementierung
Beschreibung Eine existierende Plattform zum Versand von Nachrichten wird durch eine Nachrichtenagnostische Komponente aus einigen Microservices (Abonnement Dienste) mit Anwendungsfall spezifischen Ereignissen zur Generierung von Nachrichten versorgt.
Der Abonnementspeicherdienst ist für die Persistenz von unbekannten Events (im Json-Format) zuständig. Die Events werden durch die Definition eines Anwendungsfalls (Thema) im Themenverwaltungsdienst definiert und von Kafka gelesen und samt ihrer eindeutigen Themenkennung in einer PostgreSQL gespeichert. Der Abonnementverarbeitungsdienst verarbeitet zeitgesteuert die verschiedenen Themen durch Anfragen an den Abonnementspeicherdienst. Dabei reichert er die Daten mittels Anfragen an weitere Dienste an und leitet sie an die zentrale Nachrichtenplattform zum Versand weiter.
Durch die Zunahme der Anwendungsfälle ist ein erheblicher Zuwachs des Datenvolumens (etwa 250 Mio. Zeilen) zu verzeichnen wodurch die Ausführung der DB-Abfragen zunehmend langsamer wird. Nachdem alle Zugriffsoptimierungen ausgeschöpft waren, entschlossen wir uns die Daten aufzuteilen und eine multi tenancy Architektur in der Persistenzschicht einzuführen. Als tenant dient hierbei ein Thema. Da die Anzahl der Themen zunehmend wächst ist die dedizierte Zuordnung einer DB-Instanz je Thema nicht möglich. Daher wird je Thema ein eigenes DB-Schema benutzt um die Indizes für die Abfragen klein zu halten.
Die Hauptanforderung an die multi tenancy Komponente ist eine möglichst einfache Integration in den bestehenden Abonnementspeicherdienst. Dabei griff ich auf die Unterstützung von Hibernate zurück die mittels AspectJ an Annotations zur Selektion des Tenants gebunden habe. Dabei integriert sich alles weitgehend automatisch in Spring Boot.
Nach der Datenmigration zeigten erste Vergleiche der Ausführungsgeschwindigkeiten der Abfragen hierbei eine Steigerung von mindestens Faktor 10.
Ausführung Linux (Ubuntu)
Java 8/11, Spring, Spring Boot
Amazon AWS, EC2
Docker
REST, Jackson
Hibernate 5, PostgreSQL, H2, redis, RabbitMQ (AMQP), Kafka (Nakadi)
Cloud
Mockito
Junit 4/5, Hamcrest, AssertJ
IDE: IntelliJ 2018
Vorgehensmodell: Scrum
Tools: Maven, GitHub Enterprise
VCS: git