© Excellent backgrounds/Shutterstock.com
Datenbanken in moderner Cloud-Infrastruktur

SQL Server und Big Data


SQL Server sind in jeder IT-Umgebung und beinah in jeder zweiten Hosentasche zu finden. Obwohl SQL als Sprache seit 1992 kaum verändert wurde, gibt es heutzutage nur wenige Anwendungen, die sich bei der Datenverarbeitung nicht auf SQL stützen.

Big-Data-Umgebungen haben in Bezug auf die Datenverarbeitung viele Besonderheiten, wenn man sie z. B. mit einem klassischen CMS vergleicht. Hier sind die wichtigsten:

  • Der Datenbankserver ist immer von dem Application Server getrennt, befindet sich nicht auf der gleichen Maschine und manchmal nicht einmal auf dem gleichen Kontinent.

  • Es werden Read-only-Kopien von der gleichen Datenbank betrieben. Lese- und Schreibzugriffe müssen oft getrennt programmiert werden.

  • Großflächige Locks (wie Tablelocks) betreffen tausende von Nutzern.

  • Mehrere Entwicklerteams arbeiten zusammen. Oft haben die Frontend-Entwickler keinen direkten Kontakt mit dem Datenverarbeitungsteam.

Im Folgenden sollen einige Empfehlungen und Tricks gezeigt werden.

Wenige Requests

Wie alle Anfragen übers Netz ist die Kommunikation mit der Datenbank mit Latenzen verbunden. Bei einer Cloud-Anwendung lässt es sich von Anfang an nicht immer vorhersagen, wie weit die Datenbank vom Application Server entfernt wird. Bei einer lokal installierten Datenbank sind die Mehrkosten für eine zusätzliche SQL-Anfrage vernachlässigbar. Sie liegen deutlich unter einer Millisekunde. Eine Datenbank im gleichen Netz kostet um die zwei Millisekunden pro Abfrage. Sollte es dazu kommen, dass der Server in einem anderen Rechenzentrum steht, steigern sich die Kosten um mehr als das Zehnfache.

Bei einer verteilten Anwendung sollte man immer davon ausgehen, dass sich eine Datenbank über die Zeit in einem anderen Rechenzentrum befinden kann. Wenn man das nicht tut, kann es dazu kommen, dass bei einem Ausfall oder Update einer Komponente gleich das ganze Rechenzentrum aus dem Betrieb genommen werden muss.

Oft ist es günstiger, mehr Daten zu laden, als eine zusätzliche Anfrage zu starten. Sollten z. B. für einen gegebenen Abteilungsleiter der Vorgesetzte und alle Mitarbeiter geladen werden, ist es sinnvoll, die ganze Belegschaft der Firma zu laden und die Zuständigkeiten zwischen Kollegen in der Businessschicht lösen. So ähnlich funktioniert ein MapReduce-Verfahren [1]. Es wurden drei Tests durchgeführt, bei denen die Daten von drei MySQL-Servern gelesen wurden:

  • Lokal installierter Server

  • Server im gleichen lokalen Netz

  • Server im AWS-Rechenzentrum in Irland

Ich konzentriere mich auf zwei Diagramme. In Abbildung 1 sieht man, dass es sich grob um Faktor 100 handelt, wenn man die Konfigurationen 1 und 3 vergleicht.

alukhanov_sqlserver_1.tif_fmt1.jpgAbb. 1: Eine Anfrage an MySQL-Server in unterschiedlichen Locations

Beim zweiten Vergleich wurde errechnet, wann es sich lohnt, die Daten in größeren Mengen zu laden, um die Anzahl von Requests zu reduzieren. Es wurden in allen drei Konfigurationen zwei Use Cases verglichen:

  • drei nacheinander durchgeführte JDBC-Requests

  • eine Anfrage, die das Zehnfache von Daten lädt

Die Ergebnisse sind in den Abbildungen 2 bis 4 präsentiert. In allen drei Umgebungen bleibt das Laden des Zehnfachen an Daten bis zu einer Datenmenge von etwa 10 KB bis 50 KB an Nettodaten (0,1 MB bis 0,5 MB „brutto“) günstiger, als diese Daten in drei Requests abzuholen.

alukhanov_sqlserver_2.tif_fmt1.jpgAbb. 2: Mehrere Requests vs. zu viele Daten; lokale Installation
alukhanov_sqlserver_3.tif_fmt1.jpgAbb. 3: Mehrere Requests vs. zu viele Daten; gleiches LAN
alukhanov_sqlserver_4.tif_fmt1.jpgAbb. 4: Mehrere Requests vs. zu viele Daten; entferntes Rechenzentrum

Besonders im Team lässt sich nicht immer kontrollieren, ob die Kommunikation mit dem Datenserver optimal verläuft. Als Abhilfe empfehle ich, die Datenzugangsfunktionen möglichst „gierig“ zu entwickeln. Beispielsweise kann man auf DAO-Ebene gar keine Funktionen anbieten, die einzelne Elemente laden. Statt public Customer loadCustomer(String customerCode) muss man nur die Methode public Set<Customer> loadCustomers(Set<String> customerCodes) zu Verfügung stellen. Es wird indirekt den Kollegen anleiten, das Laden von mehreren Ob...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang