Datenbanken Online Lexikon TH Köln, Campus Gummersbach
Aktuelle Änderungen - Suchen:
Datenbanken /

Verteilte Datenbanksysteme

Verteilte Datenbanksysteme sind Datenbanksysteme, die auf mehreren Rechnern ausgeführt werden und die dort auch die Daten verteilt speichern. Verteilte Systeme werden eingesetzt, wenn "Ein-Server-Datenbanksysteme" an ihre Grenzen stoßen.

  • Das Volumen der zu speichernden Daten ist so groß, dass die Speicherkapazität nicht mehr ausreicht.
  • Das Volumen der zu speichernden Daten oder die Anzahl der Anwender ist so groß, dass die Antwortzeiten bei einem "Ein-Server-System" nicht mehr akzeptable für die Anwender sind. Bei der Zugriffsbelastung ist zu beachten, dass Anwender oft zu bestimmten Zeiten enorme Lastspitzen erzeugen, so dass sich extreme Anforderungen an die '''Skalierbarkeit solcher Systeme ergibt.
  • Aus Sicherheitsgründen (Verfügbarkeit) sollen die Daten nicht nur auf einem Server gespeichert werden. Fällt dieser aus, dann fallen auch alle Geschäftsprozesse auf ggf. unbestimmte Zeit aus. Werden die Daten nun auf mehrere Rechner verteilt, dann stehen bei einem Rechnerausfall immer noch die übrigen Daten der anderen Rechner zur Verfügung, also lieber Teilausfälle statt Totalausfall.
  • Wird eine größere Datensicherheit sprich Verfügbarkeit angestrebt, so wird in Rechnernetzen mit replizierten Daten gearbeitet.

In ihren Anfängen handelte es sich bei den verteilten Datenbanksystemen in der Regel um eine fest definierte Anzahl an Servern. Skalierung wurde im wesentlichen durch eine vertikale Skalierung ("scale-up") erreicht, die bei mehr Last davon ausgeht, dass die Server mit "mehr Technik" (CPU, Hauptspeicher, Netz, Platten, ...) aufgebessert werden.

Werden relationale Datenbanksysteme auf diesen verteilten Rechnernetzen ausgeführt, kristallisiert sich sehr schnell die Konsistenzanforderung mit dem zugehörigen Transaktionskonzept und den ACID-Eigenschaften? als Flaschenhals heraus.

  • In relationalen Systemen werden gerade geänderte Datensätze gesperrt für andere lesende und manipulierende Zugriffe. Sperren bedeuten bei Anfragen immer Wartezeiten für die Anwender.
  • In verteilten Systemen und replizierten Daten kommt bei Datenänderungen erschwerend hinzu, dass auf verschiedenen Rechnern ein Konsenz gefunden werden muss, damit die manipulierten Werte auf die Replikate verteilt werden können. Da müssen Nachrichten zum Aufbau der Sperre verschickt werden, Nachrichten für den geänderten Wert und dann auch wieder Nachrichten für
  • Und bei Ausfällen von Rechnern im Verbund insbesondere des Master-Rechners bei replizierten Daten wird es ganz schwierig, da die Programmierung verteilter Aplikationen in der Regel auf einer nicht variablen Rechneranzahl basiert.

Aufgrund der neuen Anforderungen, die sich aus dem Web2.0-Zeitalter für die zu verarbeitenden Datenmengen (Tera- und Peta-Byte-Bereich), für die Anzahl der Anwender (Hunderttausende und Millionen) und für die Antwortzeiten (Millisekundenbereich) auch zu Zeiten größer Auslastung ergeben, haben sich mittlerweile bei verteilten Systemen die Ideen der horizontalen Skalierung ("scale-out") durchgesetzt.

  • Grundidee, um den großen Anwenderzahlen und dem großen Speicherbedarf gerecht zu werden, ist ein Rechnerverbund von mehreren Hundert oder Tausend-Servern auf denen die verteilten Datenbanksysteme ausgeführt werden.
  • Statt hoch- und höchstwertiger Hardware wird nur mit "Standard"-Hardware gearbeitet, was enorme Kosten spart. Dafür sind Ausfälle und das Einstellen neuer Hardware gerade auch bei der großen Serverzahl alltäglich. Die neuen Datenbanksysteme müssen somit auf einem sehr dynamischen Rechnernetz stabil ausgeführt werden.

Gerade die neuen Datenbanksysteme der NoSQL-Familie haben sich in besonderer Weise auf diese neuen Anforderungen eingestellt.

Der Begriff der verteilten Datenbanksysteme wird hier nur vor dem Hintergrund der Abgrenzung zwischen relationalen und NoSQL-Systemen im Überblick diskutiert. Eine andere und vertiefende Perspektive findet sich z.B. bei Wikipedia.

Quellen:

  • Brewer, E.A.: "Towards Robust Distributed Systems", Folien zur Keynote des 19. ACM SIGACT-SIGOPS Symposium on Principles of Distributed Computing, Portland, Oregon, USA, 2000
  • Brown, J.: "Brewer's CAP Theorem", 11.01.2009, Stand: 25.05.2011
  • Elmasri, Ramez/Navathe, Shamkant B.: "Grundlagen von Datenbanksystemen" , Pearson Studium, München, 2002, ISBN 3-8273-7021-3
  • Gilbert, S., Lynch, N.: "Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web-Services", ACM Transactions on Computer Systems, 1986
  • Edlich, Friedland, Hampe, Brauer: „NoSQL – Einstieg in die Welt der nichtrelationalen Web2.0- Anwendungen“, Hanser-Verlag, 2010, ISBN 978-3-446-42355-8
  • Kemper, Alfons/Eickler, André: "Datenbanksysteme", Oldenbourg, München, 2009, 978-3-486-59018-0
  • Oracle: "Technical Comparison of Oracle Database vs. IBM DB2 UDB: Focus on Performance", Oracle White Paper, Februar 2002
  • Saake, Gunter/Sattler, Kai-Uwe/Heuer, Andreas: "Datenbanken - Konzepte und Sprachen", mitp-Verlag, Redline GmbH, Heidelberg, 2007, ISBN 3-8266-1664-2
  • Vossen, Gottfried: "Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme", Oldenbourg, München, 2008, ISBN 978-3-486-27574-2

Weiterführende Literatur:

  • Frey, M.: „Etablierte Datenmodelle der NoSQL-Familie und ihre spezifischen Eigenschaften im Kontext von Cloud-Datenbanken“, Bachelorarbeit, FH Köln, Institut für Informatik, 08/2010
  • Kossmann, D., Kraska T.: „Data Management in the Cloud: Promises, State- of-the-art and Open Questions“, in „Datenbanken und Cloud-Computing“, Datenbank Spektrum, Band 10 Heft 3, Springer-Verlag, 12.2010, S. 121-129

Weiterführende Links:

Kategorie: Neue DB-Entwicklungen, Grundlagen, NoSQL, V, D