en
de

Skalierung von Datenbanken

13 August 2013
| |
Lesezeit: 3 Minutes

In unserem letzten Beitrag Datenbanken in der Cloud haben wir den Aspekt der Skalierung kurz erwähnt und dabei zwischen vertikaler und horizontaler Skalierung unterschieden. Wir möchten nun dieses Thema etwas eingehender beleuchten. Eigentlich halten wir die Begriffe Scale-Up und Scale-Out für geeigneter, da sie treffender sind und nicht verwechselt werden können. Deshalb verwenden wir im Weiteren nur noch diese Begriffe.

Grenzen überwinden

Disk-Space und Rechnerkapazität bilden zwei physikalische Grenzen, welche den Durchsatz und die Antwortzeit der Datenbank beeinflussen. Stossen wir mit unserer Datenbank irgendwann an die Kapazitäts- und Leistungsgrenzen, können wir diesen mit den erwähnten Skalierungstechniken entgegnen.

Beim Scale-Up rüsten wir einen einzelnen Server auf und investieren in leistungsfähigere Hardware. Unter Scale-Out verstehen wir mehrere Rechner zu einem Cluster zusammenzuschalten. Bei Datenbanken ist es üblich eine Scale-Up Strategie zu fahren. Doch wie lässt sich eine Leistungssteigerung durch Scale-Out erreichen? Grundsätzlich bieten sich hierbei zwei Konzepte an: Sharding und Replication.

Sharding

Beim Sharding teilt man die Daten anhand eines Kriteriums so auf, dass sich möglichst gleich grosse Datentöpfe ergeben. Ein daraus entstehender Datentopf bildet einen sogenannten Shard. Die einzelnen Shards werden dann auf die verschiedenen Knoten in einem Cluster verteilt. Hierzu ein Beispiel: Wenden wir dieses Prinzip auf einer Kunden-Datenbank an, wären zum Beispiel die Kunden A-M auf dem ersten Shard und die Kunden N-Z auf dem Zweiten.

Scaling_Sharding

Figure 1 Sharding

Sharding lässt sich auch mit konventionellen RDBMS wie Oracle oder Microsoft SQL Server realisieren. Konzepte wie Federated DB Servers und Distributed Partitioned Views sind Beispiele, wie ein Sharding mit Microsofts SQL Server realisiert werden kann. Ein Software-Entwickler oder Datenbankadministrator muss sich allerdings selber darum kümmern wie die Daten verteilt und verwaltet werden. Wenn sich im Laufe der Zeit ungleich grosse Shards ergeben oder eine der Datenbanken wieder an die Leistungsgrenze stösst, muss ein Resharding mit angepassten Kriterien durchgeführt werden. Dies kann zu längeren Unterbrüchen führen, insbesondere wenn die Applikation selber auch noch angepasst werden muss.

NoSQL Datenbanken wie MongoDB, Cassandra und andere Hersteller bieten Auto-Sharding und -Resharding an, d.h. die Datenbank bildet und verwaltet die Shards selbständig. Die Shards werden bei Bedarf automatisch umverteilt und auch das Hinzufügen eines zusätzlichen Knoten im Cluster wird zum Kinderspiel.

Mit Sharding kann man nun die Last verteilen, analog dem klassischen Load-Balancing. Sharding allein hat aber ein grosser Nachteil. Fällt ein Rechner aus,  sind alle Shards auf diesem Rechner nicht mehr verfügbar.

Replication

Anders als beim Sharding werden durch Replication Duplikate der Daten erstellt. Dieselben Daten werden auf mehrere Server kopiert. Wie beim Sharding wird dadurch die Last auf mehrere Rechner verteilt. Daraus resultieren ein höherer Durchsatz und kürzere Antwortzeiten. Durch die Duplikate ist die Datenbank ausfallsicher.

Scaling_Replication

Figure 2 Replication

Allerdings führt dies zu einem neuen Problem. Ändern sich die Daten, müssen sie zwischen den verschiedenen Knoten synchronisiert werden. Bis sie vollständig abgeglichen sind, bestehen Inkonsistenzen. Das heisst, die Replikate sind für eine kurze Zeit nicht mehr identisch. Für solche Fälle haben wir grundsätzlich zwei Möglichkeiten damit umzugehen.

  1. Am naheliegendsten ist es, Inkonsistenzen zu vermeiden, indem während der Synchronisation keine Zugriffe auf die Daten zugelassen werden. Dadurch können keine Konflikte auftreten, aber die Antwortzeiten werden länger, da Zugriffe nur auf vollständig replizierte Daten erfolgen.
  2. Alternativ lassen wir Konflikte zu, wodurch wir keine oder nur kurze Wartezeiten in Kauf nehmen und somit die Performance erhöhen. Das bedingt aber, dass die Applikation mit den Inkonsistenzen und den daraus potentiell entstehenden Problemen umgehen muss.

Die Beispiele bilden die beiden Extreme im Umgang mit der Konsistenz. Selbstverständlich gibt es Konzepte, wie man Verfügbarkeit und Konsistenz den Bedürfnissen entsprechend ausbalancieren kann.

Fazit

Durch das Scale-Out Verfahren erreichen wir eine höhere Kapazität und Performance. Dies beeinflusst jedoch die Datenkonsistenz, weshalb gut abgewägt werden muss, welche Skalierungstechniken sich auf den konkreten Anwendungsfall eignen.

In einem unserer nächsten Beiträge werden wir die Frage der Konsistenz eingehender beleuchten und auf die Konzepte und Features aufzeigen, wie sich NoSQL-Datenbanken diesbezüglich feinjustieren lassen.

Kommentare (0)

×

Updates

Schreiben Sie sich jetzt ein für unsere zwei-wöchentlichen Updates per E-Mail.

This field is required
This field is required
This field is required

Mich interessiert

Select at least one category
You were signed up successfully.

Erhalten Sie regelmäßige Updates zu neuen Blogartikeln

Jetzt anmelden

Oder möchten Sie eine Projektanfrage mit uns besprechen? Kontakt aufnehmen »