Oracle Sharding: Eine neue Oracle Architektur

von Sebastian Solbach

Sharding bezeichnet eine Funktionalität große Datenmengen auf verschiedene Server zu verteilen. Hierzu werden die Daten einzelner Tabellen in unabhängige, benutzerdefinierte Teilmengen aufgeteilt, den sogenannten Shards. Das Besondere bei Sharding ist, dass sich die einzelnen Shards nicht auf einem Server und in einer Datenbank, sondern in komplett unterschiedlichen Datenbanken befinden. Die einzelnen Datenbanken haben dabei keine gemeinsamen Komponenten - weder verwenden Sie dieselbe Software, noch die gleiche Hardware.

Letztendlich können die einzelnen Shards komplett unabhängig voneinander operieren, allerdings nur auf denen für Sie zugewiesenen Daten. Diese Eigenschaft ist bei Sharding der größte Vorteil, allerdings gleichzeitig auch die größte Restriktion.

Oracle Sharding: Architektur, Funktionalitäten und Begrifflichkeiten

Oracle stellt nun zum ersten mal mit der Version 12.2 offiziell die Sharding Architektur und Funktionalität zur Verfügung. Hintergrund ist eine erhebliche Minimierung des administrativen Aufwands mit Oracle Sharding gegenüber einer manuellen Implementierung. Dazu gehört das automatische Anlegen von Hunderten von Shards durch einfache SQL Syntax inklusive der Absicherung einzelner Shards durch Active Data Guard, Golden Gate und/oder RAC.

Dies funktioniert über eine zentrale Definition der Tabellen, die die sharded Architektur ausmachen. Eine automatische Verteilung der Daten ist ebenso integriert, wie ein Lifecycle Management, sollten Änderungen an den Tabellen notwendig sein. Ebenso bietet Oracle Sharding eine zentrale Zugriffsebene auf die einzelnen Shards um auch Abfragen zu erlauben, bei denen im Vorfeld nicht bekannt ist, in welchem Shard bzw. in welchen Shards (mehrere Shards überspannend) die Daten liegen. Auch wenn letztere Abfragen nicht empfohlen sind.

Welche neuen Begrifflichkeiten und Architekturen gibt es nun im Umfeld von einer Sharded Datenbank kurz SDB (nicht zu verwechseln mit Single Instanz DB)?

Zuerst einmal gibt es die einzelnen Shards. Dies sind die einzelnen unabhängigen Datenbanken mit eigenem CPU, Memory und dazugehörigem Storage aus denen die Sharded Datenbank besteht. Innerhalb eines Shards existieren abhängige Tabellen. Diese Tabellen können entweder verteilte Tabellen (sogenannte Sharded Tables) oder duplizierte Tabellen (Duplicated Tables) die in jeder einzelnen Datenbank repliziert vorliegen.

Damit auf eine Sharded Datenbank zugegriffen werden kann, muss es einen oder mehrere zentrale Koordinatoren geben, der bzw. die die initiale Weiterleitung zum richtigen Shard übernehmen. Diese Aufgabe übernehmen die Shard Directors oder kurz GSM (Global Service Managers). GSM führen in diesem Zusammenhang auch den Globalen Service ein, nichts anderes als eine Erweiterung der bestehenden Datenbank Services. So kennen Global Services auch Eigenschaften wie Netzwerk Latenzen, Replikationslag und Regionsabhängigkeiten.

Diese und weitere Informationen über Services und deren Verteilung liegen in einer weiteren Datenbank, dem Shard Katalog. Zusätzlich dient dieser auch als eine zentrale Verwaltungseinheit, die das Anlegen der einzelnen Shards überwacht, anstößt, die Tabellendefinitionen und die Desaster Recovery Mechanismen der einzelnen Shards enthält und das Lifecycle Management übernimmt.

Oracle Sharding Datenmodell und Applikationsanforderungen

Sharded Tabellen basieren auf einer Ursprungstabelle, die Ihre Eigenschaften auf die einzelnen Tabellen innerhalb eines Shards vererben. Wichtig ist, dass jede dieser Sharded Tabellen einen Sharding Schlüssel (Sharding Key) enthalten muss und dies muss die führende Spalte im Primärschlüssel sein. Dieser Sharding Schlüssel ist allen Sharded Tabellen gemein. Anhand dieses Sharding Schlüssels übernimmt Oracle auch das Anlegen der einzelnen Shards und verteilt die Daten dementsprechend - vergleichbar mit dem Partitionierungsschlüssel bei der Partitionierung. Alle abhängigen Partitionen (Tabellen mit gleichem Sharding Schlüssel Wert) werden hierbei als "Chunk" bezeichnet. Dies ist gleichzeitig die Einheit in der einzelne Partitionen im Falle eines "Resharding" neu verteilt werden können.

Auf Basis dieses Sharding Schlüssels unterstützt Oracle 12.2 zwei Arten der Datenverteilung: System Managed (konsistenter Hash) und einen zusammengesetzten Range-Hash oder List-Hash. Überlässt man die Datenverteilung einfach einem konsistenten Hash so werden die Daten uniform über alle Shards der Sharded Datenbank verteilt. Die einzelnen Chunks werden dabei relativ klein und sind dabei gleich groß. Allerdings hat der Administrator dadurch keinen Einfluss auf die Lokalität der Daten. Aus diesem Grund gibt es das Composite Sharding, welches letztendlich eine Zusammensetzung von 2 Shard Schlüsseln ist: Einem führenden Super-Shard Key, der zum Beispiel die Lokation angibt (wie Amerika, Europa, Asien) und dem oben erwähnten Shard Schlüssel für den konsistent Hash. Damit kann die Lokation der Daten gesteuert werden. Logischerweise sind dadurch die einzelnen Chunks aber nicht mehr zwingend gleich groß, da dies nun abhängig von den Daten ist.

Die größte Änderung stellt Sharding aber hinsichtlich der Applikationsentwicklung dar. Denn Applikationen müssen mit dem Wissen programmiert worden sein, dass diese mit einer sharded Datenbank arbeiten. An einem einfachen Beispiel wird dies sofort ersichtlich: So ist ein direktes Update auf den Shard Schlüssel nicht möglich. Es gibt nämlich keinen Automatismus beim Update, der einen Datensatz in einen anderen Chunk bzw. Shard verschieben kann, falls dies erforderlich wäre. Bei sharded Datenbanken erfordert dies ein Löschen und neu Anlegen des Datensatzes. Was sich im ersten Augenblick einfach und selbstverständlich anhört, wird komplex wenn viele abhängige Datensätze vorhanden sind, bei denen sich dann ebenfalls der Wert des Sharding Schlüssels ändert.

Ebenso profitieren Applikationen am meisten wenn diese nur innerhalb eines Shards arbeiten und auch beim Zugriff bereits mitteilen, mit welchem Shard gearbeitet werden soll. Hierzu sollten Applikationen bereits bei der Verbindung zur Sharded Datenbank den Wert des Sharding Schlüssels angeben. Oracle integrierte Connections Pools (UCP, OCI, ODP.NET, JDBC) kennen diese Anforderungen und halten auch Verbindungen zu den jeweiligen Shards vor. Hierbei ist nur bei der Initiierung des Connection Pools oder neuen Verbindung eine Information vom Sharding Katalog notwendig. Danach werden die entsprechenden Session-Attribute im Connection Cache gehalten und direkt an die jeweilige Applikation ausgegeben. Nur wenn eine Neuverteilung der Shards ansteht, werden die Connections neu initialisiert.

Falls es der Applikation nicht möglich ist, den Sharding Schlüssel zu spezifizieren oder Abfragen über mehrere Shards erforderlich sind, so tritt das Proxy Routing auf den Plan. Dann wird über den Sharding Katalog die jeweiligen Shards ermittelt und die Abfragen an die jeweiligen Shards weitergegeben. Dies führt zu einer schlechteren Performance, da die Sharding Directors am Ende auch die Datenaggregation übernehmen müssen.

Ausfallsicherheit

Die Verfügbarkeit der einzelnen Shards kann über 3 Mechanismen bewerkstelligt werden: Die jeweilige Konfiguration funktioniert automatisch und wird beim Anlegen der Shards aus dem Sharding Katalog heraus gesteuert. Die einfachste Variante ist, jedem Shard eine Active Data Guard Standby Datenbank mit Fast-Start Failover zur Seite zu stellen. Damit dies bei der Erstellung automatisch erzeugt werden kann, wurde übrigens der Database Configuration Assistant (DBCA) erweitert und unterstützt mit 12.2 nun auch das Anlegen von Standby Datenbanken. Allerdings ist diese Konfiguration rein Activ/Passiv so dass es bei Ausfall eines Shards durchaus zu kleineren Verzögerungen kommen kann. Die beste Lösung ist die Nutzung von Oracle Golden Gate: Dabei können sowohl ganze Shards oder auch nur einzelnen Chunks jeweils in ein anderes Shard repliziert werden. Hierbei kann die Redundanz angegeben werden, so dass ein Chunk auch in mehrere Shards repliziert wird. Die Golden Gate Sharding Regeln sorgen für eine automatische Konflikterkennung und Lösung, sollten unterschiedliche Prozesse auf denselben Chunks in unterschiedlichen Shards arbeiten.

Kombinieren lassen sich beide Lösungen noch mit Oracle Real Application Cluster, der jeweils Hochverfügbarkeit für einzelne Datenbanken (Shards) gewährleistet.

Fazit

Den Vorteilen disjunkter einzelner Shards die unabhängig voneinander operieren und deshalb Flexibilität in Bezug auf Update und Verfügbarkeit bietet, steht eine Applikationsanpassung und die gestiegenen Anforderungen an die Shard Directors und des Sharding Katalogs gegenüber.

Eine funktionierende lokale, zentrale 2 Knoten RAC Cluster Datenbank durch eine sharded Architektur abzulösen macht sicherlich weniger Sinn, als eine große global operierende OLTP Applikation auf mehrere Shards zu verteilen, soweit es das Applikationsmodell zulässt.

Nichts desto trotz bietet Oracle Sharding eine ideale Möglichkeit verteilte Datenbanken bereitzustellen und automatisiert zu administrieren. Dennoch muss nicht auf die sonstigen Merkmale einer relationalen Datenbank verzichten werden, wie Verfügbarkeit, funktionierende Desaster Recovery Konzepte, Performance Tuning und Sicherheit. Lediglich die Multitenant Architektur wird als Shard im Moment noch nicht unterstützt. Jedes einzelne Shard profitiert sonst aber von integrierten Oracle Technologien, wie z.B. In-Memory Datenbank, Verschlüsselung und Komprimierung.

Hinweis zur Lizenzierung

Bei bis zu 3 Shards genügt es die Shards mit Oracle Enterprise Edition zu lizenzieren. Hochverfügbarkeit erhält man aber nur mit Active Data Guard und Golden Gate Lizenz. Bei mehr als 3 Shards muss für alle Shards eine Active Data Guard oder Golden Gate Lizenz zusätzlich zur Enterprise Edition vorhanden sein.

Weitere Informationen

Zurück zum Anfang des Artikels

Zurück zur Community-Seite