Steigerung der Skalierbarkeit und Performance von Webanwendungen durch den Einsatz einer Redis Datenbank

Transkript

1 Steigerung der Skalierbarkeit und Performance von Webanwendungen durch den Einsatz einer Redis Datenbank Abschlussarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) an der Hochschule für Technik und Wirtschaft Berlin Fachbereich Wirtschaftswissenschaften II Studiengang Angewandte Informatik 1. Prüfer: Prof. Dr. Christin Schmidt 2. Prüfer: Dipl.-Kfm. Andreas Richter Eingereicht von Fabian Kirstein Berlin, 13. August 2012 Kontakt:

2 Zusammenfassung Eine der größten Herausforderung im Zeitalter des Web 2.0 ist es, mit immer größeren Datenmengen und Nutzerzahlen umzugehen. Betreiber von Webanwendungen müssen für diese Herausforderung Lösungen finden und diese in kürzester Zeit umsetzen. Diese Bachelorarbeit evaluiert, ob und in welchem Maße die Performance und Skalierbarkeit einer Webanwendung unter Einsatz einer Redis Datenbank gesteigert werden kann. Grundlage stellt eine bestehende Webanwendung dar, welche eine MySQL Datenbank einsetzt. Die Anwendung wurde hinsichtlich ihrer Qualität bezüglich Performance und Skalierbarkeit bewertet. Im Anschluss wurde die Anwendung um eine Datenhaltungsschicht auf Basis der Key-Value- Datenbank Redis erweitert, welche als generische Cache-Ebene parallel zur MySQL Datenbank agiert. Die Schnittstellen der Datenhaltungsschicht blieben dabei unverändert. Die Performance und Skalierbarkeit der erweiterten Fassung der Anwendung wurde dann ebenfalls bewertet und mit dem Ausgangszustand verglichen. Sowohl Performance, als auch Skalierbarkeit konnten durch den Einsatz der Redis Datenbank gesteigert werden. In der Testumgebung hat sich der Durchsatz um ein Viertel erhöht und die Anwendung war besser in der Lage mit einer steigenden Anzahl gleichzeitiger Nutzer umzugehen. Zusätzlich zur Steigerung dieser Werte, wurde durch die Redis Datenbank auch die Grundlage gelegt, die Performance und Skalierbarkeit mit wenig Aufwand weiter zu steigern. Durch die einfache Struktur und das simple Key-Value Prinzip der Redis Datenbank, fällt eine horizontale Skalierung besonders leicht. Schlüssel können mit Hilfe von Hashwerten einfach auf mehrere Server verteilt werden. Eine horizontale Skalierung einer MySQL Datenbank durch Replikation oder Sharding ist dagegen für die überschaubare Beispielanwendung aufwendiger umzusetzen. Die Performance und Skalierbarkeit einer Webanwendung kann unter Einsatz einer Redis Datenbank in jedem Fall gesteigert werden, wenn die Datenstrukturen der Anwendung überschaubar sind und eine unbedingte Konsistenz der Daten nicht notwendig ist. I

3 Inhaltsverzeichnis 1 Einleitung Betriebliches Umfeld Projekt Understandr Motivation Aufgabenbeschreibung Inhalt und Aufbau der Arbeit Grundlagen Web 2.0 und Soziale Netzwerke Performance Skalierbarkeit Relationale Datenbanken Performance von MySQL Skalierbarkeit von MySQL NoSQL Datenbanken Definition und Kategorien Redis Consistent Hashing Objekt-relationales Mapping Analyse und Vorgehen Abgrenzung Vorgehen Technisches Umfeld Anforderungen II

4 INHALTSVERZEICHNIS Funktionale Anforderungen Nicht-funktionale Anforderungen Technische Anforderungen Testdesign und Kapazitätsplanung Use Cases und Verteilung Entwurf der Testdaten Page Views und Nutzerzahlen Testdesign im Überblick Testumgebung Software für die Messung Datenbank befüllen Testaufbau, Qualität und Messgrößen Test der Performance Test der Skalierbarkeit Profiling Integrations- und Unittests Analyse und Test des Ist-Zustandes Profiling Performance Skalierbarkeit Testfälle Beurteilung Entwurf Das PlistaModel Datenhaltung und Berechnungen Verwendung von Redis Generische Cache-Ebene Redis-Datenmodell Denormalisierung Sonderfall Suche III

5 INHALTSVERZEICHNIS 6 Implementierung Cache-Ebene verwenden Datenverarbeitung im Detail Die Models im Detail Transparenz Probleme und Schwierigkeiten Weitere Implementierungen Analyse und Test der neuen Version Profiling Performance Skalierbarkeit Testfälle Beurteilung Zusammenfassung und Ergebnis Zusammenfassung Allgemeingültigkeit Ausblick A Stack Overflow SQL Abfragen 61 B Beispielhafter Aufbau einer XML-Konfigurationsdatei 63 C Übersicht und Ergebnisse der Tests 64 C.1 PHPUnit Tests der Model C.2 Selenium Tests C.3 PHPUnit Tests der Erweiterung D Inhalt der CD-ROM 67 IV

6 Abkürzungen CPU Central Processing Unit CSS Cascading Style Sheets DOM Document Object Model HTML Hypertext Markup Language HTW Hochschule für Technik und Wirtschaft I/O Input/Output MVC Model View Controller RDBMS Relationale Datenbankmanagementsysteme SQL Structured Query Language V

7 Abbildungsverzeichnis 1.1 Ausschnitt der Understandr Oberfläche Hinzufügen und Entfernen von Servern aus Edlich et al. 2010, S Deployment-Diagramm des technischen Umfelds Use Cases der Anwendung Understandr Traffic für 2 Tage des DE-CIX Internetknoten (de-cix.net, ) Testdaten Übersicht Testanfragen Übersicht Screenshot JMeter mit Testplan Anwortzeit gegenüber Anzahl gleichzeitiger Nutzer im Ist-Zustand Durchsatz gegenüber Anzahl gleichzeitiger Nutzer im Ist-Zustand Grundsätzlicher Aufbau einer MVC-Anwendung (CakePHP 2012) Klassendiagramm der Plista Klassenbibliothek für Objekt-relationales Mapping mit den wichtigsten Klassen und Methoden Entity-Relationship-Modell des bestehenden MySQL-Implementierung Klassendesign der Redis Cache Ebene Anwortzeit gegenüber Anzahl gleichzeitiger Nutzer im Vergleich zwischen alter und neuer Version Durchsatz gegenüber Anzahl gleichzeitiger Nutzer im Vergleich zwischen alter und neuer Version VI

8 Tabellenverzeichnis 2.1 Beispieltabelle Personen Auszug aus der Beispieltabelle Personen nach der Manipulation Verteilung der sieben Performance-Test Aktivitäten über die Kapitel dieser Arbeit Übersicht der nicht-funktionalen Anforderungen Verteilung der Anzahl an Antworten auf Stack Overflow Verteilung der Stimmanzahl auf Stack Overflow Ergebnis des Profiling des Ist-Zustandes Ergebnisse des Performance-Tests des Ist-Zustandes Elemente einer XML-Konfigurationsdatei der Redis DataSource Ergebnis des Profiling mit Redis-Cache Ergebnisse des Performance-Tests mit Redis-Cache VII

9 Kapitel 1 Einleitung Die nachfolgende Bachelorarbeit beschäftigt sich mit der Möglichkeit und der Durchführung, die Skalierbarkeit und Performance einer Webanwendung durch den Einsatz der nicht-relationalen Datenbank Redis zu steigern. Dafür wird eine bereits bestehende Webanwendung, welche die relationale Datenbank MySQL zur Datenhaltung einsetzt, als Grundlage verwendet. Diese Anwendung wird hinsichtlich ihrer Qualität in Performance und Skalierbarkeit untersucht. Im nächsten Schritt wird eine Erweiterung der Anwendung auf Basis einer Redis Datenbank modelliert und funktionsfähig umgesetzt. Abschließend wird die neue Version der Anwendung mit der ursprünglichen Fassung verglichen und eine Bewertung der Anforderungen durchgeführt. Insbesondere wird das Ergebnis hinsichtlich traditionelleren Verfahren zur Erhöhung der Performance und Skalierbarkeit einer Webanwendung auf Basis einer MySQL Datenbank bewertet. Das in dieser Arbeit beschriebene Vorgehen soll dabei nicht nur Gültigkeit für die Beispielanwendung haben, sondern auch als Ideenanstoß für die Verbesserung der Performance und Skalierbarkeit von Webanwendungen durch die Verwendung einer Redis Datenbank, aber auch ähnlicher, nicht-relationaler Datenbanken, dienen. 1.1 Betriebliches Umfeld Die Anfertigung dieser Abschlussarbeit wurde bei der plista GmbH in Berlin durchgeführt. Das Unternehmen ist Betreiber eines online Werbenetzwerkes im deutschen Raum mit über 40 Millionen Besuchern auf tausenden Webseiten. 1 Die plista GmbH wurde im Jahr 2008 gegründet und hat 70 Mitarbeiter in den Bereichen IT, Marketing, Personalwesen und Management. 1 Die Schlüsseltechnologie Cross-Domain Collaborative Filtering 2 ermöglicht eine leistungsfähige Auslieferung von Werbekampagnen. (plista GmbH 2012) Der Gegenstand dieser Arbeit steht nicht unmittelbar mit dieser Kerntätigkeit in Verbindung, sondern hat vielmehr ein gänzlich neues Projekt des Unternehmens als Grundlage. 1 Stand: April Werbeanzeigen und Empfehlungen werden über Domaingrenzen hinweg ausgeliefert und die individuellen Themen der Anzeigen werden aus den Interessen aller Benutzer gefiltert. 1

10 KAPITEL 1. EINLEITUNG 1.2 Projekt Understandr Die plista GmbH plant als Nebenprojekt die Veröffentlichung einer interaktiven und kollaborativen Internetplattform. Ziel des Projektes ist es, die Meinungsbildung und den Meinungsaustausch der Menschen zu fördern. Das Projekt verfolgt dabei keine wirtschaftlichen Interessen und soll zukünftig als eigenständiges Open-Source Projekt publiziert werden. Die Anwendung heißt Understandr und stellt im Wesentlichen eine Transformation der klassischen Idee einer Pro- und Contraliste in eine soziale Anwendung dar. Nutzer können eine kurze Aussage bzw. ein Statement 1 erstellen, welches durch alle Nutzer mit Argumenten und Gegenargumenten unterstützt bzw. abgelehnt wird. Den Argumenten kann einzeln von jedem Nutzer zugestimmt werden, wodurch den Argumenten mehr Gewicht verliehen wird. Aus diesen Stimmen wird die Meinung der Nutzer zu einer Aussage ermittelt. Jedem Nutzer wird zusätzlich seine persönliche Meinung zu einer Aussage präsentiert, welche sich aus der Anzahl seiner Stimmen zusammensetzt. Die Meinung wird dabei in Prozent für jeweils pro und contra angegeben. Um den Nutzer direkt in seiner Meinungsbildung zu unterstützen, werden zusätzlich verschiedene Statistiken präsentiert. Dazu zählen zunächst generelle Analysen, wie Auflistungen von kontroversen oder viel diskutierten Aussagen, aber auch persönliche Empfehlungen. Dem Nutzer werden aufgrund seines Lese- und Stimmverhaltens relevante Diskussionen empfohlen, um ihn dadurch zu weiteren Aktivitäten auf der Plattform zu animieren. Es existiert bereits ein lauffähiger Prototyp (siehe Abbildung 1.1), welcher Gegenstand und Grundlage dieser Arbeit darstellt. Dieser Prototyp wurde vom Autor dieser Arbeit im Rahmen eines dreimonatigen Praktikums implementiert. Die beschriebenen Grundfunktionalitäten sind bereits vollständig integriert. Darüber hinaus verfügt der Prototyp über weitere Merkmale. Dazu zählt insbesondere ein Schlagwortsystem 2, mit dessen Hilfe die Aussagen kategorisiert und sortiert werden und der Nutzer einen schnellen Zugriff auf bestimmte Themengebiete erhält. Eine Suchfunktion vervollständigt die Möglichkeiten Aussagen zu entdecken und den Nutzer zu aktivieren. Weiterführende Informationen befinden sich insbesondere in den Kapiteln und Motivation Die plista GmbH verfolgt bei der Entwicklung von Understandr mehrere Ziele. Zum einen soll eine übersichtliche Möglichkeit geschaffen werden, die Meinung zu einer konkreten Fragestellung zu erfahren. Dem Konzept stehen dabei klassische Umsetzungen, wie zum Beispie Online- Diskussionsforen gegenüber. Bei einem Forum ist es in der Regel notwendig, sich mehrere Beiträge zu einer Fragestellung durchzulesen, um eine passende oder korrekte Antwort zu finden. Dagegen ermöglicht das Pro-Contra-Konzept besonders schnell die Meinung der beteiligten Nutzer abzulesen. Konkrete Aussagen, in Form der Argumente, können dann zusätzlich studiert werden. Ein weiteres Ziel ist es, die Nutzer aktiv bei Ihrer persönlichen Meinungsbildung zu unterstützen. 1 Im Laufe dieser Ausarbeitung werden die Begriffe Statement und Aussage im Zusammenhang mit der Beispielanwendung gleichbedeutend verwendet 2 Der Begriff Schlagwort wird im folgenden gleichbedeutend mit dem Begriff Tag verwendet. 2

11 KAPITEL 1. EINLEITUNG Abbildung 1.1: Ausschnitt der Understandr Oberfläche Dafür sollen in erster Linie die Empfehlungen und Verlinkungen auf andere Aussagen verantwortlich sein, welche unter anderem durch kollaboratives Filtern ermittelt werden. Der Nutzer wird dadurch auf neue Problemstellungen aufmerksam und erfährt zusätzlich welche Argumente und Gegenargumente es bereits gibt. Die gesamte Plattform ist demzufolge hoch interaktiv und lebt ausschließlich von Inhalten, die die Nutzer selbst generieren. Dieser Aspekt des Projektes ist charakteristisch für eine Web 2.0 Anwendung (Shuen 2008, S. 1) und führt zu weiteren Schlussfolgerungen bezüglich der zukünftigen Nutzung von Understandr. Die Art der Plattform hat das Potential, einen positiven, direkten Netzwerkeffekt zu generieren. Der Mehrwert einer Web 2.0 Plattform erhöht sich umso mehr Nutzer die Plattform verwenden, was wiederum die Attraktivität für neue Nutzer erhöht. (Shuen 2008, S. 32) Die plista GmbH rechnet daher mit der Möglichkeit eines schnellen Anstiegs der Nutzerzahlen und damit einhergehend einer hohe Anzahl an gleichzeitigen Zugriffen auf den Dienst. Daher soll bereits vor der Veröffentlichung die Qualität der Anwendung im Umgang mit solchen Szenarien ermittelt werden. Im betrieblichen Umfeld werden bereits erfolgreich Redis Datenbanken bei der Auslieferung von Werbeanzeigen verwendet. Daher soll geprüft werden, ob die geforderte Qualität durch den Einsatz einer solchen Datenbank erreicht werden kann und inwieweit die Nutzung praktikabel und sinnvoll ist. 3

12 KAPITEL 1. EINLEITUNG 1.4 Aufgabenbeschreibung Die Aufgabe der Bachelorarbeit leitet sich unmittelbar von den Anforderungen der plista GmbH an die neue Webplattform ab. Die bestehende prototypische Implementierung soll bezüglich Performance und Skalierbarkeit evaluiert werden, um den konkreten Bedarf und Umfang einer Umgestaltung zu ermitteln. Eine Steigerung der Performance und Skalierbarkeit soll dann durch den Einsatz einer Redis Datenbank erfolgen, welche parallel zur bereits bestehenden Datenbank MySQL verwendet werden soll. Das Unternehmen geht davon aus, dass die geforderte Qualität dadurch erreicht werden kann. Ein zentraler Aspekt der Aufgabe ist dabei, dass die Implementierung der Erweiterung transparent 1 zu erfolgen hat. Nur relevante Teile sollen umgestaltet werden und sämtliche Schnittstellen sollen nach Möglichkeit erhalten bleiben und können somit weiterhin identisch verwendet werden. 1.5 Inhalt und Aufbau der Arbeit Diese Bachelorarbeit teilt sich in sieben Abschnitte. Im ersten Abschnitt der Arbeit werden die notwendigen theoretischen Grundlagen für das Verständnis und die Analyse der Aufgabenstellung gelegt. Im Mittelpunkt steht dabei die klare Definition der Begriffe Performance und Skalierbarkeit, sowie die gegenseitige Abgrenzung. Es werden problembezogene Informationen zum Thema MySQL vermittelt und eine Einführung in das Gebiet der nicht-relationalen Datenbanken mit Schwerpunkt auf Redis Datenbanken gegeben. Auch auf speziellere Themen wie Consistent Hashing und Objekt-relationale Mapper wird eingegangen, da sie ebenfalls Grundlagen für die nachfolgenden Kapitel darstellen. Darüber hinaus werden die allgemeinen und technischen Herausforderungen von Web 2.0 Anwendungen und sozialen Netzwerken betrachtet, um eine Verständnis für die Motivation dieser Arbeit zu schaffen. Im nächsten Abschnitt wird die Aufgabe analysiert. Dazu gehört das technische Umfeld und die funktionalen und nicht-funktionalen Anforderungen festzuhalten. Der Schwerpunkt dieses Abschnittes liegt bei der Ausarbeitung eines hinreichenden Analyseverfahrens, um die Ausgangsbedingungen quantitativ messen zu können. Dafür enthält der Abschnitt eine detaillierte Kapazitätsplanung, Beschreibung von Testaufbau und Testverfahren und ein Konzept zur Qualitätssicherung. Der dritte Abschnitt greift das erarbeitete Testverfahren auf und führt es an der bestehenden Version durch. Die Performance und Skalierbarkeit von Understandr wird in Zahlen gefasst und damit der Ist-Zustand für einen späteren Vergleich festgehalten. Der nächste Abschnitt beschäftigt sich mit dem Entwurf der Erweiterung. Dabei wird die bestehende Implementierung analysiert und verschiedene Ansätze, das existierende System mit einer Redis Datenbank zu erweitern, diskutiert. Schwerpunkt dabei ist, die Erweiterung möglichst transparent zu gestalten und eine Steigerung der Performance und Skalierbarkeit auch durch ein geeignetes Datenmodell zu unterstützen. Eine konkrete Lösung wird anschließend entworfen, bewertet und in ein Klassendesign umgesetzt. 1 Der Begriff Transparenz wird in dieser Arbeit in seiner informationstechnischen Bedeutung verwendet. Er beschreibt, dass der interne Aufbau eines Systems von außen nicht sichtbar ist. 4

13 KAPITEL 1. EINLEITUNG Der vierte Abschnitt beschreibt die tatsächliche Implementierung des vorangegangenen Entwurfs. Dabei wird aufgezeigt, inwieweit der Entwurf praktikabel ist und an welchen Stellen sich Probleme ergeben haben. Im nächsten Abschnitt wird eine Analyse der erweiterten Version der Anwendung durchgeführt und ihre Leistung bezüglich Performance und Skalierbarkeit in Zahlen gefasst. Darüber hinaus wird auf die funktionale Qualität der neuen Version eingegangen. Im letzten Abschnitt werden die Ergebnisse zusammengefasst und bewertet. Darüber hinaus wird geprüft, ob das beschriebene Verfahren allgemeingültig anwendbar ist. 5

14 Kapitel 2 Grundlagen 2.1 Web 2.0 und Soziale Netzwerke Für den Begriff des Web 2.0 existiert keine einheitliche und einfache Definition. (Governor et al. 2009, S. 1) Im September 2005 veröffentlichte Tim O Reilly 1 ein Paper, um den Begriff Web 2.0 genauer zu definieren. Bis heute ist es die am weitesten verbreitete Erklärung des Begriffes. Dabei gibt O Reilly keine feste Definition vor, sondern erläutert den Begriff anhand von Beispielen von existierenden Webseiten und Technologien. (Governor et al. 2009, S. 2) Daraus abgeleitet sind Web 2.0-Entwurfsmuster entstanden, welche wesentliche Merkmale einer Web 2.0 Anwendung beschreiben. Für diese Ausarbeitung besonders relevant sind dabei Users Add Value (engl. für Nutzer erhöhen Mehrwert) und Data is the Next Intel Inside (engl. für Daten sind das nächste Intel Inside). Aus den Titeln dieser Muster lässt sich bereits erkennen, dass Daten einen zentralen Aspekt einer Web 2.0 Anwendung darstellen. (O Reilly 2005) Bekannten Web 2.0 Vertretern wie Flickr, YouTube oder Facebook haben alle gemeinsam, dass sie große Datenmengen verarbeiten und diese einer sehr großen Menge an Nutzern gleichzeitig zur Verfügung stellen. Einige Zahlen der populären Web 2.0 Anwendung Facebook veranschaulichen die enormen Datenmengen und Nutzerzahlen. Im Juni 2010 hatte Facebook 400 Millionen aktive Nutzer, welche jede Woche 5 Milliarden Inhalte (Status Updates, Kommentare, Uploads, Nachrichten und weiteres) teilen und 3 Milliarden Fotos im Monat hochladen. Tausende Cache-Server mit jeweils mehreren Terabyte Speicher ermöglichen diese hohen Kapazitäten. (highscalability.com 2012) Diese Zahlen zeigen, dass bei populären Webseiten mit vom Nutzer generierten Inhalten und einem positiven Netzwerkeffekt die Datenverarbeitung eine ganz neue Herausforderung darstellt. Die betroffenen Unternehmen müssen teilweise gänzlich neue Wege für die Entwicklung ihrer technischen Infrastruktur finden. So entwickelte Facebook 2008 das verteilte und skalierbare Datenbanksytem Cassandra oder den PHP-Compiler HipHop, um die Ausführungsgeschwindigkeit ihrer Software zu erhöhen. Etablierte technische Lösungen schienen, den neuen und erhöhten Anforderungen nicht gerecht zu werden. Entwickler einer neuen Web 2.0 Plattform sollten sich also diesen neuen Herausforderungen bewusst sein und ihre Web 2.0 Anwendungen für die Verarbeitung großer Nutzerzahlen und Datenmengen zu optimieren. Darüber hinaus muss aufgrund eines möglichen 1 Softwareentwickler und Gründer des O Reilly Verlages 6

15 KAPITEL 2. GRUNDLAGEN Netzwerkeffektes immer von einem schnellen Anstieg der Werte ausgegangen werden. Auch darauf sollte eine moderne Web 2.0 Anwendung in jedem Fall vorbereitet sein. 2.2 Performance Der Begriff Performance ist in der Informationstechnik gleichzusetzen mit Leistungsfähigkeit. Es ist möglich, Performance zu messen und zu vergleichen. Die Kriterien zur Bewertung von Performance ergeben sich aus dem zu bewertenden System. (ITWissen 2012) Verschiedene Kennzahlen können bei der Bewertung verwendet werden. Diese Ausarbeitung beschäftigt sich mit der Performance einer Webanwendung. Dabei sind besonders die Kennzahlen Antwortzeit, Durchsatz und Ressourcenauslastung relevant. (Meier 2007, S. 24) Antwortzeit Die Zeit, die ein System benötigt um auf eine Anfrage zu reagieren wird als Antwortzeit bezeichnet. Sie wird häufig in Sekunden angegeben. Ein gängiges Beispiel ist der Aufruf einer beliebigen Webseite. Die Zeit, die vergeht bis die Seite im Browser erscheint, ist in diesem Fall die Antwortzeit. Die Angabe dieser Zeit kann in mehrere Komponenten zerlegt werden. Im Fall einer Webseite wäre das die Antwortzeit des Browsers, die Netzwerkzeit und die Zeit, die der Server zum Bearbeiten der Anfrage benötigt. (Menascé et al. 2004, S. 13) Die Antwort wird häufig als wichtiges Qualitätskriterium für eine Webanwendung gesehen, da Nutzer bei langen Antwortzeiten die Anfrage abbrechen. Durchsatz Die Anzahl an Arbeitseinheiten, die in einer bestimmen Zeiteinheit von einem System verarbeitet werden kann, wird als Durchsatz bezeichnet. Beispiele sind Anfragen pro Sekunde, Aufrufe am Tag oder Hits pro Sekunde.(Meier 2007, S. 26) Die verwendete Angabe ergibt sich aus dem Kontext. Im Fall von Webanwendungen wird häufig von Anfragen auf die Webseite pro Sekunde oder Minute gesprochen. (Menascé et al. 2004, S. 14) Ressourcenauslastung Welche Ressourcen eines Systems in welchem Maße bei einer Anfrage verwendet werden wird als Ressourcenauslastung bezeichnet. Die wichtigsten Ressourcen dabei sind Prozessor, Arbeitsspeicher, Festplatten Input/Output (I/O) und Netzwerk I/O. (Meier 2007, S. 25) 2.3 Skalierbarkeit Ein System wird als skalierbar bezeichnet, wenn es in der Lage ist, mit einer erhöhten Auslastung umzugehen, ohne dass die Performance negativ beeinflusst wird. (Meier 2007, S. 26) Cal Henderson (2006, S. 246) beschreibt eine skalierbares System genau mit drei Charakteristiken: Ein System kann sich an eine erhöhte Nutzung anpassen Ein System kann sich an einen erhöhten Datenbestand anpassen Ein System ist wartbar 7

16 KAPITEL 2. GRUNDLAGEN Der Begriff der Skalierbarkeit muss ganz klar vom Begriff Performance getrennt werden. Ein System mit sehr guter Performance muss nicht zwangsläufig auch gut skalierbar sein. Beispielsweise ist eine Webanwendung mit einer sehr guten Antwortzeit mit 1000 Nutzern und 1 GB an Daten nur dann skalierbar, wenn sie die Antwortzeit bei der zehnfachen Anzahl an Nutzern halten kann. (Henderson 2006, S. 246) Vertikale Skalierung Durch das Hinzufügen von Ressourcen zu einem System, kann die Skalierbarkeit dieses erhöht werden. Dieses Verfahren wird als vertikale Skalierung bezeichnet. Gängige Ressourcen sind Arbeitsspeicher oder Prozessor. Zum Beispiel kann ein Webserver, dessen Kapazitäten an die Grenzen gestoßen sind, durch einen leistungsfähigeren Server ersetzt werden. Sollten die Kapazitäten des neuen Servers ebenfalls nicht mehr ausreichen, würde dieser wieder ersetzt werden. Der offensichtliche Nachteil dieses Verfahrens ist, dass der Skalierung eine Obergrenze gesetzt ist, wenn keine bessere Hardware auf dem Markt verfügbar ist. Darüber hinaus sind die Kosten für Hardware nicht linear, sondern exponentiell. Etwas leistungsfähigere Hardware kann oft ein Vielfaches an Mehrkosten verursachen. Die Stärke der vertikalen Skalierung liegt beim einfachen Softwaredesign. Die Software kann einfach auf die neue Hardware portiert werden, ohne die Implementierung anzupassen. (Henderson 2006, S ) Horizontale Skalierung Das zweite Konzept, ein System zu skalieren, basiert ebenfalls auf dem Hinzufügen von Hardware. Im Gegensatz zur vertikalen Skalierung wird bestehende Hardware nicht modifiziert, sondern einfach um weitere Hardware ergänzt. Im Fall eines einzelnen Webservers, würde im Zuge eines Wachstums, ein zweiter Server dem System hinzugefügt werden. Der Vorteil dieser Methode ist, dass es möglich ist, reguläre Hardware für das System zu verwenden. Man ist nicht auf leistungsfähige Serverhardware angewiesen. Dadurch ist es theoretisch möglich die Hardwarekosten zu senken. Dem gegenüber steht allerdings der erhöhte Administrationsaufwand für die Wartung und Installation mehrerer Rechner. Allerdings ist der Aufwand nicht linear, da man davon ausgehen kann, dass alle Rechner mit der gleichen Basissoftware ausgestattet sind. Nachteil und Herausforderung der horizontalen Skalierung ist die Software, welche in der Lage sein muss, mit einem System, bestehend aus vielen Rechnern, umzugehen. Die Software muss in der Lage sein, mit der Hardware zu skalieren. (Henderson 2006, S ) 2.4 Relationale Datenbanken Das relationale Datenbankmodell wurde 1970 von Edgar Codd entwickelt und hat sich bis heute als das Wichtigste, noch im Einsatz befindliche, Datenbankmodell etabliert. Grundlage ist die Darstellung von Daten in Tabellen und die Beziehung der Tabellen zueinander. Durch diese Relationen lassen sich echte Gegebenheiten in der Datenbank nachbilden. Als Relationale Datenbankmanagementsysteme (RDBMS) werden alle Datenbanken bezeichnet, die diese Systematik verwenden. Für dem Zugriff auf die Daten wird häufig die Structured Query Language (SQL) eingesetzt. (Pröll et al. 2011, S ) In dieser Arbeit steht das seit 1995 entwickelte, freie Datenbanksystem MySQL im Mittelpunkt, welches zu den RDBMS zählt und SQL verwendet. Der nächste Abschnitt beschäftigt sich mit Performance und Skalierbarkeit von MySQL und theoretischen Möglichkeiten, diese zu steigern. 8

17 KAPITEL 2. GRUNDLAGEN Performance von MySQL Wie performant eine MySQL-Installation sein kann wird von verschiedensten Faktoren beeinflusst. Einer der wichtigsten Faktoren ist, ob die angefragten Daten von der Festplatte geladen werden müssen oder sie sich schon in einem Puffer befinden. MySQL verfügt über ein Query- Cache, in dem die Ergebnisse bereits ausgeführter Abfragen zwischengespeichert werden und bei erneuter Anfrage das Ergebnis sofort zurückgegeben wird. (Pröll et al. 2011, S ) Der Query-Cache liegt im Arbeitsspeicher und ist daher sehr schnell. Allerdings unterliegt die Nutzung des Caches einigen Einschränkungen bezüglich zulässiger Select-Anweisungen, welche zwischengespeichert werden können. So können keine Abfragen, die Teil anderer Abfragen sind, oder Abfragen mit Variablen verwendet werden. Die zwischengespeicherten Daten werden jedes Mal gelöscht, wenn eine Änderung auf eine betreffende Tabelle durchgeführt wird. (Pröll et al. 2011, S ) Daneben wird die Performance immer beeinflusst, wenn die Datenbank auf Ressourcen, wie Prozessor, Arbeitsspeicher oder Festplatte, wartet. Aber auch andere Tabellen stellen Ressourcen dar, welche eventuell durch weitere Anfragen blockiert sind. Auch das Design der Abfragen und der Tabellen hat maßgebliche Auswirkungen auf die Leistungsfähigkeit der Datenbank. Die genaue Performance kann im Einzelfall durch entsprechende Messungen und Analysen erfolgen. MySQL bietet für diesen Zweck eigene Benchmark- und Profilingbefehle, um individuelle Schwachstellen zu finden. (Pröll et al. 2011, S ) Zusätzlich existieren verschiedene Methoden zur Abfrageoptimierung, unter anderem das Slow-Query-Log, mit dessen Hilfe sich langsame Abfragen schnell ermitteln und optimieren lassen. Das Anlegen von Indizes, um häufig abzufragende Werte in separaten Index-Tabellen effektiv zu verwalten und schnell zugänglich zu machen, gehört ebenfalls dazu. (Pröll et al. 2011, S ) Zusammengefasst lässt sich festhalten, dass die Bewertung der Performance von MySQL individuell betrachtet werden muss und eine pauschale Aussage nicht zu treffen ist. Optimal konfiguriert, kann eine auf MySQL Datenbank eine sehr gute Performance aufweisen. Auf der anderen Seite kann in speziellen Anwendungsfällen die Performance von MySQL nicht ausreichend sein und es ist notwendig auf alternative Systeme zurückzugreifen. Siehe dazu Kapitel Skalierbarkeit von MySQL Bei der Betrachtung der Skalierbarkeit von MySQL soll an dieser Stelle nur auf horizontale Skalierung eingegangen werden. Diese Art der Skalierung stellt eine Herausforderung da, für die sich verschiedene Lösungsansätze entwickelt haben. Einige der wichtigsten Konzepte werden in diesem Kapitel näher betrachtet. Eine vertikale Skalierung ist problemlos möglich, unterliegt aber den in Kapitel 2.3 diskutierten Einschränkungen. Replikation Webanwendungen weisen häufig weit mehr lesende als schreibende Operationen auf, oftmals in einem Verhältnis von 10 zu 1. Von diesem Umstand profitiert das Konzept der Replikation, welches von MySQL nativ unterstützt wird. Es ist dem Begriff zu entnehmen, dass dabei Daten auf ein oder mehr Rechner repliziert werden, um dadurch eine höhere Lesekapazität zu erhalten. Dabei wird zwischen Master und Slave unterschieden. Eine MySQL-Installation kann ein Slave von genau einem Master sein. Umgekehrt kann eine Installation ein Master von keinem oder vielen Slaves sein. Sämtliche Schreibopera- 9

18 KAPITEL 2. GRUNDLAGEN tionen werden nur an einen Master-Server gesendet, der alle Operationen wie gewöhnlich ausführt und zusätzlich in einer Logdatei alle Operationen protokolliert. Ein verbundener Slave-Server liest diese Datei und führt die Operationen aus. Auf diesem Weg wird er in exakt den gleichen Zustand versetzt. Ein Master mit einem Slave hätte dann die doppelte Lesekapazität usw. Die Schreibkapazität bleibt bei einem Master allerdings konstant. (Henderson 2006, S ) Clustering Um sowohl die Lesekapazitäten, als auch Schreibkapazitäten zu skalieren kann eine MySQL Datenbank in sogenannte Cluster aufgeteilt werden. In der einfachsten Form werden beim Clustering die verschiedenen Tabellen einer Datenbank auf mehrere Server verteilt. Dabei müssen sich Tabellen, auf denen Joins angewendet werden sollen auf einem Server befinden. Joins über Rechnergrenzen hinweg sind nicht ohne Weiteres möglich. Durch diese Einschränkung ist Clustering im möglichen Leistungsgewinn limitiert. (Henderson 2006, S ) Sharding Um diese Limitierung zu überwinden, ist es notwendig, die eigentlichen Tabellen ebenfalls aufzuteilen. Dieses Verfahren wird als Sharding oder auch Federation bezeichnet. Dabei werden Tabellen anhand ihrer Zeilen aufgeteilt und auf verschiedene Server verteilt. Die Implementierung dieser Methode ist außerordentlich kompliziert. Um Operationen auf den Tabellen auszuführen, müssen die Teile über mehrere Server hinweg zusammengeführt werden und Joins werden unpraktikabel aufwendig. Für die Bewältigung diese Art der Verteilung, wäre in jedem Fall die Nutzung einer Middleware notwendig. (Henderson 2006, S ) Die Software MySQL Cluster 1 bietet mittlerweile diese Funktionalität. Unter der Bezeichnung Auto-Sharding ist es möglich Tabellen auf beliebig vielen Server zu verteilen und dabei bleibt der Zugriff absolut transparent. Realisiert wird die Funktion durch eine Hash-Funktion auf den Primärschlüssel (siehe dazu auch 2.6). Auch Joins sind weiterhin wie gewohnt einsetzbar. Ziel ist es, den Nachteil der Replikation auszugleichen und auch Schreiboperationen zu skalieren. (Oracle 2012, S. 5-6) Die verschiedenen Verfahren zeigen, dass es möglich ist MySQL zu skalieren. Unter Nutzung des MySQL Clusters sind sogar beachtliche Werte möglich. Der Hersteller gibt über eine Milliarde Schreiboperationen pro Minute bei 30 Servern an. (Oracle 2012, S. 9) Für den konkreten Anwendungsfall sollte die zweckmäßigste Methode gewählt werden und eventuelle Limitationen ermittelt werden. 2.5 NoSQL Datenbanken Der Begriff NoSQL vereint eine ganze Reihe von Datenbanksystemen, welche sich alle das Ziel gesetzt haben, die existierenden Nachteile der etablierten, relationalen Datenbanksysteme, auszugleichen. (Gull 2011, S. 18) Obwohl der Begriff und die neuen Datenbanksysteme erst in den letzten Jahren massiv an Popularität gewonnen haben, geht die Geschichte der NoSQL- Datenbanksysteme bis in das Jahr 1979 zurück. In diesem Jahr entwickelte Ken Thompson 2 1 Der Begriff ist an dieser Stelle verwirrend, da wesentlich mehr als einfaches Clustering zur Verfügung steht. 2 Mitentwickler des UNIX-Betriebssystems und der Programmiersprache C 10

19 KAPITEL 2. GRUNDLAGEN bereits eine Key-Hash-Datenbank namens DBM. Es folgten in den 80er Jahren verschiedene NoSQL-Systeme, wie Lotus Notes, BerkeleyDB und GT.M. (Edlich et al. 2010, S. 1) Im Jahr 1998 wurde dann zum ersten Mal den Begriff NoSQL, im Zusammenhang mit einer Open-Source- Datenbank von Carlo Strozzi, verwendet. (Gull 2011, S. 188) Obwohl dieses System immer noch auf einem relationalen Datenbankmodell basierte, stand keine SQL-API mehr zur Verfügung. Erst seit der Jahrtausendwende, durch die Entstehung des Web 2.0 und der Tendenz immer größere Datenmengen zu generieren, begann die NoSQL Bewegung. Seit 2006 werden die heute üblichen NoSQL-Systeme, wie HBase/Hypertable, CouchDB, Cassandra, Voldemort, Dynamo/Dynomite, MongoDB, Redis und viele mehr 1 entwickelt. (Edlich et al. 2010, S. 1) Der eigentliche Begriff NoSQL tauchte aber erst Anfang 2009 bei einem Treffen zum Thema strukturierte, verteilte Datenspeicher auf. Johan Oskarsson bereichnete damit Datenbanken, die nicht relational sind, auf verteilten Systemen liegen und meistens auf ACID-Eigenschaften 2 verzichten. (Gull 2011, S. 188) Definition und Kategorien Eine offizielle Definition des Begriffes NoSQL existiert nicht. Das NoSQL-Archiv (nosql-databases.org 2012) gibt an, dass ein Datenbanksystem, welches einige der folgenden Eigenschaften aufweist, als NoSQL Datenbank gilt: nicht relational, verteilt und horizontal skalierbar Open-Source schemafrei einfache Replikationsunterstützung einfache API Konsistenzmodell BASE 3 Unterstützung für sehr große Datenmengen Das NoSQL-Archiv listet derzeit mehr als 120 NoSQL-Kernsysteme 4, welche sich in vier wichtige Kategorien gliedern und von Edlich et al. (2010, S. 7) wie folgt beschrieben werden. Key-Value-Systeme Diese Kategorie stellt ein einfaches Schema, bestehend aus Schlüssel und Wert zur Verfügung. Oft können die Schlüssel in Namensräumen sortiert werden und Werte Atomicity, Consistency, Isolation, Durability (engl. für Atomarität, Konsistenz, Isolation, Beständigkeit) 3 Basically Available, Soft state, Eventual consistency - NoSQL Datenbanken achten nicht streng auf Konsistenz der Daten, da Performance und Verfügbarkeit dadurch sinken. Die Datenkonsistenz wird zum Beispiel, von einer nachfolgenden Operation wieder hergestellt. Ein konsistenter und inkonsistenter Zustand wechseln sich somit ständig ab. (Gull 2011, S. 18) 4 Es wird zwischen Kernsystemen und nachgelagerten Systemen unterschieden, wobei die erst genannten direkt aus den Bedürfnissen des Web 2.0 entstanden sind und Letztere erst später entstanden sind. 11

20 KAPITEL 2. GRUNDLAGEN bestimmten Datentypen zugeordnet sein, wie Hashes oder Listen. Durch dieses einfache Schema ist eine schnelle und effiziente Datenverarbeitung möglich. Als Nachteile gelten die nur einfachen Abfragemöglichkeiten. Als größter Vorteil der Key-Value-Systeme gilt die einfache Skalierbarkeit. In traditionellen Datenbanken sind die Daten relational miteinander verbunden, wodurch eine Skalierung oft erschwert wird. Eben diesen Nachteil haben die Key-Value-Systeme nicht. Jedes Schlüssel- Wert Paar steht zunächst nur für sich und lässt sich deshalb viel unproblematischer auf verschiedene Rechner verteilen. (Edlich et al. 2010, S. 131) Bekannte Vertreter: Redis, Voldemort, Scalaris, MemcacheDB, Riak Column-Family-Systeme Diese Systeme ähneln klassischen Tabellen, wobei ein Schlüssel auf eine unterschiedliche Anzahl an Key-Value Daten zeigt. Einer solchen Spalte können jederzeit weitere Datenpaare hinzugefügt werden. Bekannte Vertreter: HBase, Cassandra, Hypertable Document Stores Diese Datenbanken speichern strukturierte Daten in verschiedenen Formaten und verweisen über eine ID auf diese. Häufig verwendete Formate sind JSON, YAML oder RDF. Bekannte Vertreter: CouchDB, MongoDB Graphendatenbanken Die letzte Kategorie speichert Daten in Graph- oder Baumstrukturen und stellt dadurch die Beziehung von Daten untereinander dar. Die Einsatzmöglichkeiten von Graphendatenbanken sind vielfältig und in den letzten Jahren hat ihre Bedeutung stark zugenommen. Durch das Verbinden von Informationen im Internet mit Geodaten, Pfadsuche oder Molekülmodellierung. Jede Graphendatenbank verwendet unterschiedliche Arten von Graphen. Die Wichtigsten sind derzeit die Property-Graphen. Bekannte Vertreter: Neo4j, SonesDB, FlockDB Redis Redis ordnet sich in die Kategorie der Key-Value-Systeme ein und wurde Anfang 2009 von Salvatore Sanfillippo als Open-Source Projekt gestartet. Der Begriff Redis leitet sich vom Wort Redistribute (engl. für umverteilen) und von Remote Dictionary Service (engl. for entfernter Wörterbuchdienst) ab. Redis gilt als Nachfolger von Memcached 1. Alle Daten werden im Arbeitsspeicher gespeichert und gleichen sich nach und nach auf die Festplatte ab. Mit leichten Geschwindigkeitseinbußen können die Daten auch unmittelbar auf die Festplatte geschrieben werden. Es gilt demzufolge, dass alle Daten einer Redis Datenbank in den Arbeitsspeicher passen müssen. (Edlich et al. 2010, S. 132) Die Unterstützung für virtuellen Speicher gilt als überholt. (Seguin 2012, S. 7) Die Datenbank ist sehr schnell. Um die Zugriffe pro Sekunde sind gängige Werte. Schreiboperationen sind in der Regel schneller als Leseoperationen. (Offizielle Redis Webseite 2012) Redis stellt fünf verschiedene Datenstrukturen zur Verfügung. Jeder Wert in der Datenbank kann aus einer dieser Strukturen bestehen. 1 Cache-Server zum Ablegen von Daten in den Arbeitsspeicher 12