Discover millions of ebooks, audiobooks, and so much more with a free trial

Only $11.99/month after trial. Cancel anytime.

NoSQL Einführung: CouchDB, MongoDB und Regis
NoSQL Einführung: CouchDB, MongoDB und Regis
NoSQL Einführung: CouchDB, MongoDB und Regis
Ebook82 pages49 minutes

NoSQL Einführung: CouchDB, MongoDB und Regis

Rating: 0 out of 5 stars

()

Read preview

About this ebook

NoSQL - also nicht-relationale Datenbanken - rücken in jüngster Zeit immer stärker in den Fokus. Gerade datenintensive Applikationen mit häufigen Schreib- und Lesezugriffen profitieren vom NoSQL-Ansatz. Oliver Kurowski informiert Sie in diesem shortcut über die zugrundeliegenden Prinzipien und stellt die drei bekannten OpenSource-Vertreter CouchDB, MongoDB und Redis vor.
LanguageDeutsch
Release dateMar 16, 2012
ISBN9783868024104
NoSQL Einführung: CouchDB, MongoDB und Regis

Read more from Oliver Kurowski

Related to NoSQL Einführung

Titles in the series (16)

View More

Related ebooks

Computers For You

View More

Related articles

Reviews for NoSQL Einführung

Rating: 0 out of 5 stars
0 ratings

0 ratings0 reviews

What did you think?

Tap to rate

Review must be at least 10 words

    Book preview

    NoSQL Einführung - Oliver Kurowski

    Oliver Kurowski

    NoSQL Einführung

    CouchDB, MongoDB und Redis

    ISBN: 978-3-86802-410-4

    © 2012 entwickler.press

    Ein Imprint der Software & Support Media GmbH

    1 NoSQL – Eine Bereicherung für SQL

    Als im Jahr 2009 Johan Oskarsson, zur damaligen Zeit ein Entwickler von last.fm, eine Tagung über Techniken für verteilte nicht-relationale Datenbanken veranstaltet [1], ahnte er noch nicht, dass aus dem Begriff „NoSQL eine ganze Bewegung wird, die schließlich auch den Programmiermainstream erreichen würde. Auf dieser Tagung ging es um die Grenzen von relationalen Datenbanken bezüglich der Skalierung für Tausende von Abfragen, wie sie im Web nicht unüblich sind. Stand NoSQL am Anfang noch für eine klare Abgrenzung von SQL als Abfragesprache, so ist Johan Oskarsson heute mit diesem Begriff nicht mehr so glücklich und sieht in dem „No SQL eher ein „Not Only SQL".

    Man mag es sehen, wie man will, aber vielleicht ist gerade diese radikale Wortwahl wie NoSQL ein Grund für den momentanen Hype um diese Art von Datenhaltung und -Abfrage, die im Einzelnen nichts Neues darstellt. Erinnern wir uns doch mal an die Kombination aus XML, JavaScript und asynchronen Server-Requests. Wurde das letztendlich nicht auch durch den Begriff AJAX zu einer greifbaren Technik? So ähnlich kann man auch die momentane NoSQL-Bewegung sehen. Die Techniken selbst sind nicht neu, es handelt sich dabei um eine Kombination aus alten Verfahren wie die Speicherung mit selbstdefinierten Schlüsseln und alternative Abfragetechniken, aber erst durch ein Wort ist diese Technik in das Bewusstsein gelangt. Falls Sie von NoSQL bislang noch nicht mehr als Überschriften in News gelesen haben, versuche ich hier eine Definition. Sollten Sie mit NoSQL vertraut sein, so entschuldigen Sie die Wiederholung bzw. die Ähnlichkeit zu anderen Definitionen. NoSQL beschreibt eine Datenbankstruktur ohne festes Datenschema mit alternativen Abfragemechanismen im Gegensatz zu herkömmlichen relationalen Datenbanksystemen, die über SQL abgefragt werden. Am ehesten verwandt sind die NoSQL-Datenbanken noch mit objektorientierten Datenbanken bzw. den XML-Datenbanken. Nötig geworden sind Alternativen zu den bisherigen tabellenorientierten Datenbanken durch die Anforderungen im Internet. Datendurchsatzstarke Dienste wie Onlineshops, Blogs, News und Foren und natürlich in erster Linie Suchmaschinen und soziale Netzwerke sind gierig nach riesigen Datenmengen und flexiblen Strukturen, die einem steten Wandel unterliegen. Firmensoftware, deren erste Gebote die Sicherheit und Integrität der Daten und die Abläufe im Betrieb darstellen, sind sicherlich nicht die Kernzielgruppe für die NoSQL-Bewegung.

    Freiheit für das Schema

    Aber worin liegt nun genau der Unterschied bzw. der Vorteil von schemafreien Datenbanken? Betrachten wir zuerst einmal, wie in herkömmlichen Datenbanksystemen die Entwicklung vonstattengeht: Die Anforderungen an die Software werden gesammelt und ganz klassisch als Pflichtenheft festgehalten. Danach werden die Datenstrukturen entwickelt und für eine relationale Datenbank aufbereitet und normiert. Nachdem die Datenbanktabellen festgelegt sind, geht die Spezifikation an die Anwendungsentwickler. Diese Entwickler setzten sich nun einerseits mit den Abfragen der Datenbank mittels SQL, andererseits mit der Entwicklung des Programms auseinander. Am Ende entsteht ein Programm mit fest definiertem Umfang und Datenstrukturen. Was aber passiert, wenn ein kleiner aber wesentlicher Bestandteil der Anforderungen geändert oder ergänzt wird? Was muss alles angepasst werden, wenn ein Nachrichtensystem nicht nur eine einzelne Nachricht übersenden soll, sondern nun auch noch unbestimmte Anhänge (Bilder, Listen, Verbindungen zu anderen Nachrichten) bereit stellen können muss? Die Datenbankdesigner passen die Tabellen an, geben die neuen Strukturen und Spezifikationen an die Anwendungsprogrammierer, und alles geht von vorne los. Ein konkretes Beispiel: Eine Handelsplattform ermöglicht den Nachrichtenaustausch zwischen den Lieferanten und Kunden. Sämtliche Änderungen am Produktsortiment sollen damit kommuniziert werden. Die dafür benötigte Tabelle NACHRICHTEN könnte also so aussehen:

    Id | Sender_id | Empfaenger_id | Nachrichtentext | Datum |

      Status

    Nun wollen wir aber nicht nur in Textform mitteilen, dass sich das Sortiment erweitert hat, sondern die entsprechenden Artikelinformationen gleich mitliefern. Dafür benötigen wir nun eine weitere Tabelle:

    NACHRICHTENARTIKEL

    Nachrichten_id | Artikelnummer

    Ach ja, es gibt natürlich auch Fälle, in denen wir sagen, dass ein Artikel durch einen anderen ersetzt wird. Da können wir mit einer einfachen Liste zwischen alt und neu nicht unterscheiden. Also erweitern wir die Liste durch eine zweite Artikelnummer und einem Status, der uns die Verbindung zwischen den beiden Artikeln erklärt:

    NACHRICHTENARTIKEL

    Nachrichten_id | Artikelnummer_1 | Artikelnummer_2 |

      Beziehungsstatus

    Die Kosten der Flexibilität sind natürlich leere Einträge von Artikelnummer_2 und Beziehungsstatus.

    Enjoying the preview?
    Page 1 of 1