© Excellent backgrounds/Shutterstock.com
Java Magazin
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.

Rodion Alukhanov


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 ServerServer im gleichen lokalen NetzServer 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.

Abb. 1: Eine Anfrage an MySQL-Server in unterschiedlichen Locations

Beim zweiten Vergleich wurde errechnet, wann es sich lohnt, di...

Java Magazin
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.

Rodion Alukhanov


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 ServerServer im gleichen lokalen NetzServer 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.

Abb. 1: Eine Anfrage an MySQL-Server in unterschiedlichen Locations

Beim zweiten Vergleich wurde errechnet, wann es sich lohnt, di...

Neugierig geworden?


    
Loading...

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