© fatmawati achmad zaenuri/Shutterstock.com
PHP Magazin
NoSQL für anspruchsvolle Datenbanklösungen

Sag ja zu NoSQL!

Wer heute eine datenbankgetriebene Applikation erzeugt, greift meist zu einer SQL-Datenbank. Dies funktioniert anfangs gut, die Abfragesprache ist nahezu jedem Entwickler zumindest peripher geläufig. Haarig wird es, wenn die Menge der zu verarbeitenden Daten oder die Konsistenzsansprüche ansteigen. In diesem Fall schaffen NoSQL-Datenbanksysteme Abhilfe. Ihre Nutzung setzt - je nach verwendetem Modell - mehr oder weniger Umdenken auf Seiten des Entwicklers voraus: Eine NoSQL-Datenbank lässt sich nicht per „Cut and Paste“ in eine existierende Lösung integrieren.

Tam Hanna


Gleich zu Beginn: Es ist unmöglich, in einem einzelnen Artikel eine komplette Übersicht über die Welt des NoSQL zu geben. Unter dem Sammelbegriff tummelt sich eine Vielzahl verschiedener Ansätze: Vom KV-Speicher bis zu immens komplexen Datenbanksystemen gibt es so gut wie nichts, was nicht vertreten ist. Manche Autoren bieten tausendseitige Lehrbücher an, die nur an der Oberfläche des Themas kratzen.

Für die folgenden Schritte wollen wir uns auf eine vergleichsweise einfache Definition einigen: Eine NoSQL-Datenbank ist ein Datenbanksystem, das die Interaktion zwischen Applikation und im Remanentspeicher befindlichen Informationen unter einer Abfragesprache abwickelt, die nicht auf SQL basiert. Dass es hierbei oft textuelle Sprachen gibt, die SQL mehr oder weniger stark ähnlich sind, folgt aus der Logik. Das von MySQL bzw. Qt verwendete Modell der dualen Lizenzierung findet sich auch in der Welt der NoSQL-Datenbanken. In ziemlich allen Fällen gibt es eine kostenlose und quelloffene Basisversion der Datenbank. Wer allerdings fortgeschrittene Funktionen wie beispielsweise komplexe Skalierungen oder Hochverfügbarkeitsfunktionen nutzen möchte, ist meist dazu verpflichtet, eine kommerzielle Lizenz zu lösen. Die dabei anfallenden Preise unterscheiden sich von Anbieter zu Anbieter, sollten aber auf keinen Fall unterschätzt werden.

Mit der Kraft des Dokuments

Wer eine SQL-basierte Datenbankapplikation realisiert, beginnt mit der Definition des Datenbankschemas. Es handelt sich dabei um eine Beschreibung, die festlegt, in welchem Format die von der Datenbank zu verarbeitenden Daten vorliegen werden. Diese Vorgehensweise erweist sich in der Praxis insofern als „bissig“, als man bei der Deklaration des Schemas das Problem hat, dass man nicht alle Bedürfnisse von vornherein absehen kann. Ein schönes Beispiel dafür wäre eine Datenbank, die Oszillografen und ihre Eingangskanäle verwaltet.

Bis zum Erscheinen von Danahers Achtkanal-Oszilloskopen – wir wollen Yokogawas nur im Energietechnikbereich relevanten Geräte hier ignorieren – hätte es ausgereicht, ein Schema anzulegen, das für vier Kanäle Informationen vorhält. Muss man einen Zweikanaloszilloskopen speichern, so lässt man die beiden Felder für die Kanäle drei und vier leer. Seit der Einführung des Achtkanälers muss man in diesem Fall sechs Felder freilassen, beim Vierkanäler schleppt die Datenbank vier unbenötigte Felder mit. Dieses in kleinen Datenbanken unproblematische Vorgehen erweist sich spätestens dann als krit...

PHP Magazin
NoSQL für anspruchsvolle Datenbanklösungen

Sag ja zu NoSQL!

Wer heute eine datenbankgetriebene Applikation erzeugt, greift meist zu einer SQL-Datenbank. Dies funktioniert anfangs gut, die Abfragesprache ist nahezu jedem Entwickler zumindest peripher geläufig. Haarig wird es, wenn die Menge der zu verarbeitenden Daten oder die Konsistenzsansprüche ansteigen. In diesem Fall schaffen NoSQL-Datenbanksysteme Abhilfe. Ihre Nutzung setzt - je nach verwendetem Modell - mehr oder weniger Umdenken auf Seiten des Entwicklers voraus: Eine NoSQL-Datenbank lässt sich nicht per „Cut and Paste“ in eine existierende Lösung integrieren.

Tam Hanna


Gleich zu Beginn: Es ist unmöglich, in einem einzelnen Artikel eine komplette Übersicht über die Welt des NoSQL zu geben. Unter dem Sammelbegriff tummelt sich eine Vielzahl verschiedener Ansätze: Vom KV-Speicher bis zu immens komplexen Datenbanksystemen gibt es so gut wie nichts, was nicht vertreten ist. Manche Autoren bieten tausendseitige Lehrbücher an, die nur an der Oberfläche des Themas kratzen.

Für die folgenden Schritte wollen wir uns auf eine vergleichsweise einfache Definition einigen: Eine NoSQL-Datenbank ist ein Datenbanksystem, das die Interaktion zwischen Applikation und im Remanentspeicher befindlichen Informationen unter einer Abfragesprache abwickelt, die nicht auf SQL basiert. Dass es hierbei oft textuelle Sprachen gibt, die SQL mehr oder weniger stark ähnlich sind, folgt aus der Logik. Das von MySQL bzw. Qt verwendete Modell der dualen Lizenzierung findet sich auch in der Welt der NoSQL-Datenbanken. In ziemlich allen Fällen gibt es eine kostenlose und quelloffene Basisversion der Datenbank. Wer allerdings fortgeschrittene Funktionen wie beispielsweise komplexe Skalierungen oder Hochverfügbarkeitsfunktionen nutzen möchte, ist meist dazu verpflichtet, eine kommerzielle Lizenz zu lösen. Die dabei anfallenden Preise unterscheiden sich von Anbieter zu Anbieter, sollten aber auf keinen Fall unterschätzt werden.

Mit der Kraft des Dokuments

Wer eine SQL-basierte Datenbankapplikation realisiert, beginnt mit der Definition des Datenbankschemas. Es handelt sich dabei um eine Beschreibung, die festlegt, in welchem Format die von der Datenbank zu verarbeitenden Daten vorliegen werden. Diese Vorgehensweise erweist sich in der Praxis insofern als „bissig“, als man bei der Deklaration des Schemas das Problem hat, dass man nicht alle Bedürfnisse von vornherein absehen kann. Ein schönes Beispiel dafür wäre eine Datenbank, die Oszillografen und ihre Eingangskanäle verwaltet.

Bis zum Erscheinen von Danahers Achtkanal-Oszilloskopen – wir wollen Yokogawas nur im Energietechnikbereich relevanten Geräte hier ignorieren – hätte es ausgereicht, ein Schema anzulegen, das für vier Kanäle Informationen vorhält. Muss man einen Zweikanaloszilloskopen speichern, so lässt man die beiden Felder für die Kanäle drei und vier leer. Seit der Einführung des Achtkanälers muss man in diesem Fall sechs Felder freilassen, beim Vierkanäler schleppt die Datenbank vier unbenötigte Felder mit. Dieses in kleinen Datenbanken unproblematische Vorgehen erweist sich spätestens dann als krit...

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