Massive Skalierbarkeit mit der Datenplattform InterSystems IRIS

Laden Sie den Technology Guide herunter

Angesichts der enormen und stetig wachsenden Datenmengen, die weltweit generiert werden, müssen Softwarearchitekten besonderes Augenmerk auf die Skalierbarkeit ihrer Lösungen legen. Sie müssen Systeme entwickeln, die bei Bedarf viele Tausend gleichzeitige Nutzer verkraften können. Auch wenn es nicht einfach ist, ist eine Architektur für massive Skalierbarkeit heute für die meisten Unternehmen unverzichtbar. Ob zur Unterstützung von Echtzeit-Analysen, Machine Learning, großen Sprachmodellen, Retrieval-Augmented Generation (RAG) oder vernetzten Anwendungen - Datensysteme müssen mit wachsenden Mengen, Geschwindigkeiten und Komplexität umgehen können.

Softwarearchitekten können skalierbare Systeme auf verschiedene Weise entwickeln. Sie können vertikal skalieren, indem sie größere Maschinen mit Dutzenden von Rechenkernen einsetzen. Sie können Techniken zur Datenverteilung (Replikation) verwenden, um für eine wachsende Zahl von Benutzern horizontal zu skalieren. Und sie können ihr Datenvolumen horizontal skalieren, indem sie ihre Daten partitionieren. In der Praxis setzen Softwarearchitekten mehrere dieser Techniken gleichzeitig ein, wobei sie je nach Bedarf zwischen Hardwarekosten, Codekomplexität und einfacher Bereitstellung abwägen.

Dieser Leitfaden konzentriert sich auf die Mechanismen der vertikalen und horizontalen Skalierung von Benutzer- und Datenvolumen unter Berücksichtigung von Leistung, Kosten und Architektur. Er zeigt verschiedene Möglichkeiten zur Verteilung und Partitionierung von Daten und/oder Benutzeraufkommen auf und erläutert, in welchen Szenarien sich die jeweilige Option besonders anbietet. Der Leitfaden zeigt, wie InterSystems, ein weltweit führendes Unternehmen für innovative Datentechnologien, und InterSystems IRIS® die Konfiguration, Bereitstellung und den Betrieb verteilter Systeme durch skalierbare Architekturen vereinfachen können.

Die einfachste Art der Skalierung ist die "vertikale" Skalierung - "nach oben skalieren" und auf einem größeren Rechner mit mehr CPU-Kernen und Speicher einsetzen. Die meisten modernen Datenplattformen unterstützen die parallele Verarbeitung kritischer Anwendungen und enthalten Technologien zur Optimierung der Nutzung von CPUs in Multicore-Maschinen. Vertikale Skalierung erweitert eine bestehende Infrastruktur, ohne die zugrunde liegende Computing-Architektur zu verändern. Sie bietet eine einfache Architektur, geringere Latenzzeiten – da die Bereitstellung auf einem einzelnen System mit nur begrenzten Anforderungen an das Netzwerk erfolgt – sowie eine leichtere Kompatibilität mit Legacy-Systemen.

Allerdings lässt sich das Potenzial vertikaler Skalierung in der Praxis nicht unbegrenzt ausschöpfen. So kann selbst das leistungsstärkste verfügbare System die enormen Datenmengen und Workloads moderner Anwendungen irgendwann nicht mehr bewältigen und stößt bei der weiteren Aufrüstung unweigerlich an technische Obergrenzen. Hinzu kommt, dass leistungsstarke High-End-Systeme schnell sehr teuer werden können. Für viele Unternehmen ist es wirtschaftlicher, etwa vier Server mit jeweils 16 Kernen zu beschaffen als ein einzelnes System mit 64 Kernen.

Gleichzeitig ist die Kapazitätsplanung für Single-Server-Architekturen oft schwierig, vor allem bei Lösungen mit stark variierenden Workloads. Die Fähigkeit, Spitzenlasten zu bewältigen, kann zu einer verschwenderischen Unterauslastung in den Nebenzeiten führen. Umgekehrt kann eine zu geringe Zahl an Kernen dazu führen, dass die Leistung in Zeiten hoher Auslastung drastisch nachlässt. Außerdem setzt die Erhöhung der Kapazität einer einzelnen Serverarchitektur den Kauf einer komplett neuen Maschine voraus. Eine Kapazitätserweiterung "on the fly" ist nicht machbar. Darüber hinaus ist ein einzelner Server für das Gesamtsystem ein Single Point of Failure.

Kurz gesagt: So wichtig es auch ist, dass Software das volle Potenzial der eingesetzten Hardware nutzt, reicht vertikale Skalierung allein nur für weitgehend konstante Workloads aus.

Aus all diesen Gründen werden die meisten Unternehmen, die eine massive Skalierbarkeit anstreben, auf vernetzten Systemen arbeiten und Arbeitslasten und/oder Datenmengen "horizontal" skalieren, indem sie die Arbeit auf mehrere Server verteilen. In der Regel besteht ein solches Netzwerk aus kostengünstigen Servern. Falls erforderlich, lassen sich jedoch auch größere, leistungsfähigere Systeme einsetzen, um zusätzlich von vertikaler Skalierung zu profitieren (siehe „Hybride vertikal-horizontale Skalierung“ weiter unten).

Die horizontale Skalierung bietet mehrere Vorteile, die bei modernen datenintensiven Anwendungen heute nahezu unverzichtbar sind. Solche elastischen Systeme können dynamisch und wirtschaftlich mit dem Bedarf wachsen oder schrumpfen, wobei Standardhardware und Cloud-Ressourcen bedarfsgerecht skaliert werden. Darüber hinaus erhöht horizontale Skalierung die Ausfallsicherheit: Ein System mit mehreren Knoten bleibt auch dann funktionsfähig, wenn ein einzelner Knoten ausfällt. Horizontale Skalierung bildet die Grundlage für cloud-native und verteilte Systeme und ermöglicht massive Skalierung sowie Fehlertoleranz.

So unverzichtbar sie im Zeitalter von Big Data auch ist, ist sie dennoch nicht ohne Herausforderungen. Sie erfordert eine sorgfältige Orchestrierung, Lastverteilung und Datenverteilung. Die Sicherstellung der Datenkonsistenz über mehrere Knoten hinweg und die gleichzeitige Minimierung von Netzwerklatenzen stellen insbesondere in Echtzeitsystemen erhebliche Herausforderungen dar. Für horizontal verteilte Architekturen setzt das CAP-Theorem (Consistency, Availability, Partition Tolerance) klare Grenzen. Zielkonflikte sind unvermeidlich und erfordern eine sorgfältige Abwägung zwischen den primären und den nachgelagerten Zielen.

Softwarearchitekten wissen, dass kein Workload dem anderen gleicht. Auf einige moderne Anwendungen greifen gleichzeitig Hunderttausende Nutzer zu, wodurch eine sehr hohe Anzahl kleiner Transaktionen pro Sekunde entsteht. Andere haben vielleicht nur eine Handvoll Nutzer, fragen aber Daten im Petabyte-Bereich ab. Beides sind sehr anspruchsvolle Workloads, erfordern jedoch deutlich unterschiedliche Skalierungsansätze. Wir betrachten jedes dieser Szenarien als eigenständigen Anwendungsfall.

Um auch bei wachsender Skalierung eine hohe Performance sicherzustellen, setzen Datenbanken häufig auf Caching: Dabei wird eine schnelle, temporäre Ebene für häufig abgerufene Daten geschaffen, sodass wiederholte Datenbankabfragen für dieselben Informationen vermieden werden. Um eine sehr große Zahl gleichzeitiger Benutzer oder Transaktionen zu unterstützen und nach Benutzeraufkommen zu skalieren, hat InterSystems mit dem Enterprise Cache Protocol (ECP) eine eigene Implementierung entwickelt.

Innerhalb eines Servernetzwerks wird ein Server als Datenserver konfiguriert, auf dem die Daten dauerhaft gespeichert werden. Die anderen werden als Anwendungsserver konfiguriert. Auf jedem Applikationsserver läuft eine Instanz von InterSystems IRIS, die der Anwendung die Daten so zur Verfügung stellt, als wären sie in einer lokalen Datenbank gespeichert. Auf den Applikationsservern werden keine Daten dauerhaft gespeichert. Stattdessen stellen diese Server Cache und CPU-Rechenleistung bereit.

Die Benutzersitzungen werden – in der Regel über einen Load Balancer – auf die Applikationsserver verteilt, und Anfragen werden nach Möglichkeit aus dem lokalen Cache des jeweiligen Applikationsservers bedient. Die Anwendungsserver rufen die Daten nur bei Bedarf vom Datenserver ab. ECP synchronisiert automatisch die Daten zwischen allen Cluster-Teilnehmern.

Da die Rechenarbeit von den Anwendungsservern erledigt wird, kann sich der Datenserver hauptsächlich der Speicherung von Transaktionsergebnissen widmen. Je nach Workload können Applikationsserver problemlos zum Cluster hinzugefügt oder daraus entfernt werden. Ein typisches Beispiel ist der Einzelhandel: Um die außergewöhnlich hohe Last rund um den Black Friday zu bewältigen, können zusätzliche Applikationsserver zugeschaltet und nach dem Ende des Saisongeschäfts wieder abgeschaltet werden. Applikationsserver eignen sich besonders für Anwendungen mit sehr vielen Transaktionen, bei denen jede einzelne Transaktion nur einen relativ kleinen Teil des gesamten Datenbestands betrifft.

Wenn Abfragen – meist analytische Abfragen – auf große Datenmengen zugreifen müssen, kann die Datenmenge, die für eine effiziente Verarbeitung im Cache vorgehalten werden müsste, die Speicherkapazität eines einzelnen Systems überschreiten. Eine leistungsstarke Technik zur Bewältigung solch großer Datenmengen ist das Sharding, bei dem große Datenbanktabellen physisch auf mehrere Serverinstanzen aufgeteilt werden. Anwendungen greifen weiterhin auf eine einzige logische Tabelle auf einer Instanz zu, die als Shard-Master bezeichnet wird. Der Shard-Master teilt eingehende Abfragen auf und leitet sie an die Shard-Server weiter, von denen jeder einen eigenen Teil der Tabellendaten sowie die zugehörigen Indizes vorhält. Die Shard-Server verarbeiten die jeweils lokalen Abfragen parallel und senden ihre Ergebnisse zur Aggregation an den Shard-Master zurück.

Die Daten werden auf Basis eines Shard-Schlüssels auf die Shard-Server verteilt. Dieser kann entweder automatisch vom System verwaltet oder vom Softwarearchitekten anhand ausgewählter Tabellenspalten festgelegt werden. Durch die sorgfältige Auswahl der Shard-Schlüssel lassen sich Tabellen, die häufig miteinander verknüpft werden, gemeinsam sharden. Dadurch werden Zeilen aus diesen Tabellen, die in der Regel zusammen abgefragt werden, auf demselben Shard-Server gespeichert. Durch diese gemeinsame Unterbringung können die Tabellen lokal auf jedem Shard-Server zusammengeführt werden, wodurch Parallelisierung und Leistung maximiert werden. Wenn das Datenvolumen wächst, können problemlos weitere Shards hinzugefügt werden. Sharding ist für die Anwendung und die Benutzer völlig transparent.

Nicht alle Tabellen müssen gesharded werden. In analytischen Anwendungen sind Faktentabellen – zum Beispiel Bestellungen im Einzelhandel – meist sehr groß und werden daher auf Shards verteilt. Die wesentlich kleineren Dimensionstabellen, etwa zu Produkten oder Verkaufsstellen, werden dagegen nicht geshardet. Nicht-geshardte Tabellen werden auf dem Shard-Master persistiert. Wenn eine Abfrage Joins zwischen geshardeten und nicht geshardeten Tabellen erfordert oder Daten aus unterschiedlichen Shards verknüpft werden müssen, nutzt die InterSystems-Technologie einen hoch effizienten ECP-basierten Mechanismus, um die Anfrage korrekt und effizient zu erfüllen. In diesen Fällen werden nur die tatsächlich benötigten Zeilen zwischen den Shards ausgetauscht, anstatt – wie bei vielen anderen Technologien – ganze Tabellen über das Netzwerk zu übertragen. Die InterSystems-Technologie verbessert durch Sharding transparent die Effizienz und Performance von Big-Data-Abfragen, ohne die Bandbreite der unterstützten Abfragen einzuschränken.

InterSystems-Architekturen ermöglichen komplexe Joins über mehrere Tabellen hinweg auch bei Abfragen auf verteilten, partitionierten Datenbeständen – ohne dass Co-Sharding, Datenreplikation oder die Übertragung vollständiger Tabellen über das Netzwerk erforderlich sind.

Moderne Datenlösungen müssen oft gleichzeitig eine hohe Transaktionsrate (Benutzeraufkommen) und die Analyse großer Datenmengen unterstützen. Ein Beispiel dafür ist eine Private-Wealth-Management-Anwendung, die Dashboards bereitstellt, welche die Portfolios und Risikoprofile von Kunden in Echtzeit auf Grundlage aktueller Marktdaten zusammenfassen.

Die Technologie von InterSystems ist insofern besonders, als sie analytische Abfragen und die Verarbeitung eingehender Transaktionen gleichzeitig unterstützt. Sie ermöglicht solche Hybrid Transactional and Analytical Processing (HTAP)- beziehungsweise translytischen Anwendungen, indem Applikationsserver und Sharding kombiniert eingesetzt werden können. Anwendungsserver können der Architektur hinzugefügt werden (siehe Abbildung 2), um die Arbeitslast auf dem Shard-Master zu verteilen. Arbeitslasten und Datenvolumen können unabhängig voneinander skaliert werden, je nach den Anforderungen der Anwendung.

Wenn Anwendungen ein Höchstmaß an Skalierbarkeit erfordern (z. B. wenn ein Vorhersagemodell jeden Datensatz in einer großen Tabelle bewerten muss, während gleichzeitig neue Datensätze eingelesen und abgefragt werden), kann jeder einzelne Datenshard als Datenserver in einem ECP-Modell fungieren. Wir bezeichnen die Anwendungsserver, die sich die Arbeitslast auf Daten-Shards teilen, als Query-Shards. In Verbindung mit den transparenten Mechanismen zur Sicherstellung einer hohen Verfügbarkeit eines InterSystems-IRIS-Clusters erhalten Lösungsarchitekten damit alles, was sie brauchen, um die spezifischen Anforderungen ihrer Lösung an Skalierbarkeit und Zuverlässigkeit zu erfüllen.

Viele moderne Systeme kombinieren vertikale und horizontale Skalierung. So kann beispielsweise eine Datenbank auf leistungsstarken, vertikal skalierten Knoten laufen, während die Abfragen auf horizontal skalierte Anwendungsserver verteilt werden. Hybride Modelle bieten Flexibilität und Ausfallsicherheit und können gezielt auf spezifische Workloads und Anforderungen zugeschnitten werden.

Effektive Skalierung erfordert eine durchdachte Architektur, die die Skalierung prägt und zugleich von ihr geprägt wird:

• Die Datenpartitionierung, insbesondere durch Sharding- und Replikationsstrategien, unterstützt die effiziente Verwaltung großer Datenbestände (siehe oben „Horizontale Skalierung nach Datenvolumen: Sharding“).
• Die Wahl zwischen zustandslosen und zustandsbehafteten Services hat maßgeblichen Einfluss auf die Skalierungsstrategie. Zustandslose Dienste sind leichter horizontal zu skalieren.
• Der Lastausgleich verteilt den Datenverkehr gleichmäßig auf die einzelnen Knoten, so dass kein Knoten überlastet wird.
• Mandantenstrategien legen fest, wie verschiedene Nutzer eine Datenplattform und gegebenenfalls auch deren Infrastruktur gemeinsam nutzen, ohne dass die logische Trennung ihrer jeweiligen Daten aufgehoben wird.
• Konsistenzmodelle, die durch das CAP-Theorem (Konsistenz, Verfügbarkeit und Partitionstoleranz) geprägt sind, bestimmen die Zielkonflikte in verteilten Systemen.

Skalierbare Datenplattformen sind ein entscheidender Erfolgsfaktor in den Branchen, in denen InterSystems Kunden bei der Lösung ihrer Herausforderungen unterstützt. Von besonderer Bedeutung ist dabei der Bereich Gesundheitsdaten, in dem InterSystems häufig in sehr großem Maßstab tätig ist – etwa bei der Verwaltung von Patientenakten, medizinischer Bildgebung, weiteren diagnostischen Daten sowie Echtzeit-Monitoring in einer Vielzahl medizinischer Informatikanwendungen.

Darüber hinaus ist InterSystems auch in anderen datenintensiven Einsatzfeldern aktiv, darunter im Finanzwesen – beispielsweise bei der Verarbeitung von Transaktionen, der Betrugserkennung und dem regulatorischen Reporting – sowie in der Supply Chain, etwa bei der Sendungsverfolgung, der Optimierung von Auslieferungen und dem Bestandsmanagement.

In all diesen Branchen hat InterSystems dazu beigetragen, Datenlösungen zu realisieren, mit denen Unternehmen ihre Anforderungen an Datenmanagement, Performance und Zuverlässigkeit auch in großem Maßstab erfüllen können.

Gleichzeitig entwickelt sich die Landschaft skalierbarer Datenplattformen kontinuierlich weiter, da fortlaufend neue Datenanwendungen und Systeme entstehen:

• Cloud-native Architekturen, wie Kubernetes und serverlose Modelle, vereinfachen die horizontale Skalierung.
• KI-gesteuerte Skalierung mit prädiktiven Algorithmen optimiert die Ressourcenzuweisung.
• Edge Computing verteilt die Verarbeitung näher an den Datenquellen und verringert so die Latenzzeit.
• Data Mesh und föderierte Architekturen fördern dezentrales Dateneigentum und Skalierbarkeit.
• Data-Fabric-Architekturen überwinden Datensilos und Fragmentierung.

Massive Skalierbarkeit ist für moderne Datenanwendungen keine Option mehr, sondern eine Notwendigkeit. ine solche Skalierung ist insbesondere für HTAP-Anwendungen erforderlich, die gleichzeitig große Workloads und hohe Datenvolumina bewältigen müssen – gegebenenfalls bei einer großen Zahl gleichzeitiger Nutzer.

Vertikale Skalierung bietet Einfachheit und hohe Performance für kleinere Systeme, während horizontale Skalierung die für Anwendungen im großen Maßstab unverzichtbare Elastizität und Ausfallsicherheit liefert. Spezialisierte Architekturen erlauben es, den Systembetrieb gezielt auf verschiedene Kombinationen aus Anforderungen und Prioritäten abzustimmen. Wer die Stärken und Grenzen der einzelnen Ansätze versteht, kann Datenarchitekturen entwickeln, die heutige Anforderungen erfüllen und zugleich auf künftiges Wachstum ausgelegt sind.