Bei der Entwicklung der InterSystems IRIS Data Platform haben wir viele der Leistungsmerkmale übernommen, die unsere Kunden schon an Caché und Ensemble geschätzt haben. In diesem Artikel werden wir jedoch auf eine komplett neue Funktion der Plattform eingehen: SQL-Sharding, ein wichtiges neues Leistungsmerkmal für optimale Skalierbarkeit.
Vertikale und horizontale Skalierung
Ob Millionen gehandelter Aktien verarbeitet oder Zehntausende von Patienten am Tag behandelt werden sollen: Eine Datenplattform, mit der sich solche Abläufe erledigen lassen, sollte diese Datenmengen auf transparente Art und Weise unterstützen. Transparent bedeutet dabei, dass sich Entwickler und Anwender keine Gedanken über die Größenordnungen machen müssen und sich auf ihre zentralen Geschäftsprozesse und Anwendungen konzentrieren können, während die Plattform im Hintergrund dafür Sorge trägt, dass auch bei wachsenden Datenvolumina keine Leistungseinbuße zu verzeichnen ist.
Caché unterstützt schon seit Jahren den Aspekt der vertikalen Skalierbarkeit. Dabei werden Verbesserungen der Hardwareaustattung von der Software transparent genutzt, um von extrem vielen Prozessorkernen und riesigen RAM-Mengen zu profitieren. Eine angemessene Bedarfsschätzung der benötigten Infrastruktur im Vorfeld kann zwar zu einem perfekt auf die jeweiligen Anforderungen abgestimmten System beitragen, doch gibt es grundsätzliche Begrenzungen dessen, was sich mit einem einzelnen System auf kosteneffektive Weise erreichen lässt.
Hier kommt nun horizontale Skalierbarkeit ins Spiel. Hier wird die Nutzlast (engl. Workload) nicht auf einem einzelnen Server ausgeführt, sondern auf unterschiedliche Server verteilt und diese in einem Cluster zusammengefasst. InterSystems Caché unterstützt ECP-Anwendungsserver als Methode zur horizontalen Skalierung schon länger; jetzt bietet InterSystems IRIS mit SQL-Sharding jedoch eine zusätzliche, wichtige Funktionalität.
Was ist neu daran?
Was also ist der Unterschied zwischen ECP-Anwendungsservern und der neuen Sharding-Funktion? Lassen Sie uns einen genaueren Blick auf Nutzlasten werfen, um den Unterschied zu verstehen. Eine Nutzlast kann Zehntausende kleiner Geräte beinhalten, die kontinuierlich kleine Mengen von Daten in eine Datenbank schreiben. Eine Nutzlast kann aber auch aus Analyseabfragen bestehen, die jedes Mal Daten im GB-Bereich produzieren. Welche Nutzlast ist größer? Das lässt sich genauso schwer beantworten wie z. B. die Frage, ob eine Angelrute oder ein Bierfass größer ist. Nutzlasten haben mehr als nur eine Dimension, was bedeutet, dass man etwas Geschick benötigt, um sie angemessen skalieren zu können.
Sehen wir uns grob vereinfacht die folgenden zwei Komponenten der Nutzlast einer Anwendung an: N steht für die Anzahl der Benutzer und Q für die Größe einer Abfrage. In unserem Beispiel von eben weist die erste Nutzlast („viele kleine Geräte“) einen hohen N- und gleichzeitig einen niedrigen Q-Wert auf, während bei der zweiten Nutzlast („Analyseabfrage“) N niedrig und Q hoch ist. ECP-Anwendungsserver eignen sich gut für hohe N-Werte, da sie eine Aufteilung der Anwendungsbenutzer auf verschiedene Server erlauben. Dies hilft allerdings nur begrenzt, wenn Datensätze sehr groß werden und die insgesamt benötigten Daten nicht mehr in den Arbeitsspeicher eines einzelnen Rechners passen. Mit Sharding lassen sich große Q-Werte bewältigen, da man Datensätze auf verschiedene Server verteilen und Aufgaben so weit wie möglich nach unten an so genannte Shard-Server weitergeben können.
SQL-Sharding
Und was geschieht beim Sharding wirklich? Dabei handelt es sich um eine SQL-Funktionalität, mit der die Daten einer geshardeten Tabelle in disjunkte Gruppen von Datensätzen aufgeteilt werden, die auf den Shard-Servern gespeichert werden. Wenn man sich zum Shard-Master verbindet, wird nur eine Tabelle angezeigt, die sämtliche Daten enthält; Abfragen an diese Tabelle werden jedoch in lokale Shard-Abfragen aufgeteilt, welche an die Shard-Server gesendet werden. Jeder Shard-Server berechnet die Ergebnisse auf Grundlage jener Daten, die er lokal gespeichert hat, und sendet die Ergebnisse zurück an den Shard-Master. Der Shard-Master fasst die Resultate zusammen, führt eine eventuell notwendige Kombinationslogik aus und sendet die Ergebnisse zurück an die Anwendung.
Bei einer einfachen SELECT * FROM-Tabelle ist das System noch ziemlich einfach nachzuvollziehen. Doch auch komplexere Szenarien sind dank der eingebauten Logiken umsetzbar. Sie sorgen dafür, dass Sie (fast) jede SQL-Abfrage nutzen können und ein möglichst großer Teil der Nutzlast auf Shards verteilt wird, um maximale Parallelverarbeitung zu erreichen. Der Shard-Schlüssel, der darüber bestimmt, welche Zeilen wohin gehören, kann genutzt werden, um die gängigsten Abfragen schon im Vorfeld zu optimieren. Wenn Sie sicherstellen, dass Tabellen, die oft geJOINed werden, mit den gleichen Schlüsseln geshardet werden, lassen sich diese JOINs bereits auf der Shard-Ebene komplett auflösen. Dadurch erhalten Sie die Performance, die Sie benötigen.
Selbstverständlich ist das nur eine kleine Kostprobe, und es gibt deutlich mehr zu entdecken. Das Wesentliche ist jedoch in der Darstellung oben enthalten: SQL-Sharding ist ein neues Rezept im Kochbuch für hochskalierbare Gerichte, die sich mit InterSystems IRIS zaubern lassen. Dieses Element ergänzt ECP-Anwendungsserver und ist vor allem für anspruchsvolle Datenmengen gemacht. Damit eignet sie sich perfekt für viele Anwendungsfälle im Bereich Datenauswertung. Ähnlich wie ECP-Anwendungsserver ist SQL-Sharding für die Anwendung vollkommen transparent und verfügt über weitere kreative Architektur-Variationen für sehr spezifische Szenarien.
