Ein kurzer Überblick über die Datenbanklandschaft

Die Softwarelizenzierung ist, um es vorsichtig auszudrücken, komplex. Nicht nur die Rechte am geistigen Eigentum (dazu empfehle ich Besen & Raskinds „An Introduction to the Law and Economics of Intellectual Property“ und Rosens Open Source Licensing: Software Freedom and Intellectual Property Law), sondern vor allem, warum Sie sich um eine Lizenz kümmern sollten und um Trends in der Open-Source-Datenbanklandschaft, die Auswirkungen auf Ihr Unternehmen haben.

Bereit?

Lassen Sie uns zunächst über die Lizenzen sprechen

Alle Softwarelizenzen unterliegen Regeln und Vorschriften für die Nutzung der Technologie, die Sie einhalten müssen. Das bedeutet, dass die Lizenzen der Software, die Sie einsetzen, einen spürbaren Einfluss auf Ihre Geschäftsabläufe haben können. Das Ignorieren oder Verstoßen dieser Regeln kann Sie einem rechtlichen Risiko und finanziellen Verlusten aussetzen und, offen gesagt, den Ruf Ihres Unternehmens schädigen. Unabhängig davon, ob Sie Software kaufen oder Open-Source-Technologien einsetzen, wird die Lizenz letztlich die Nutzung des Codes in gewissem Umfang einschränken. Seien Sie sich dieser Einschränkungen bewusst, wenn Sie Ihr Produkt entwickeln, um längerfristige rechtliche Risiken zu mindern.

Denken Sie auch daran, dass Lizenzen nicht fest sind. Tatsächlich sind viele Unternehmen, die Open-Source-Datenbankprojekte unterstützen, dabei, ihre Datenbanklizenzen zu ändern, um sie restriktiver zu gestalten. Je nach Anwendungsfall kann dies bedeuten, dass Sie, wenn Sie bisher eine Datenbank kostenlos genutzt haben, nun möglicherweise rechtlichen Schritten ausgesetzt sind. Das soll Sie nicht verunsichern, sondern nur sicherstellen, dass Sie wachsam bleiben. Angesichts dieser Veränderungen ist es wichtig, angemessen zu reagieren. In einigen Fällen kann eine Lizenzänderung eine neue Architektur eines Services, die Einführung einer anderen Datenbank oder den Abschluss einer kommerziellen Vereinbarung mit dem Anbieter erfordern.

Lasst uns diesen Problembereich etwas genauer untersuchen.

Wer Hacker News oder TechCrunch regelmäßig besucht, dem ist die Diskussion über Open Source und kommerzielle Datenbanksoftware nicht fremd. Hier die Kernaussage: In den letzten drei Jahren ist aufgrund einer Reihe von Faktoren, wie dem Wachstum großer Public-Cloud-Anbieter und dem Markterfolg – oder dessen Ausbleiben – von Open-Source-zentrierten Datenbankanbietern, eine Debatte entbrannt.

Davon abgesehen ist die Beziehung zwischen freier Software und proprietärer Software nicht binär – sie ist auf jeden Fall ein Spektrum:

Hinweis: Die dargestellte Entfernung ist nicht wissenschaftlich, die Relativität ist wichtiger.

Betrachtet man das Spektrum oben, so gibt es ganz links kommerzielle oder proprietäre Datenbanksoftwarelizenzen wie Oracle, IBM Db2 und Microsoft SQL Server. Dies sind leistungsstarke, funktionsreiche Technologien, die Workloads in allen Branchen unterstützen. Wenn Sie diese Software von einem Anbieter oder als Cloud-Service erwerben, zahlen Sie einen Aufpreis, um Zugriff auf Folgendes zu erhalten:

• Support auf Code-Ebene

• Ein robustes Ökosystem von Werkzeugen

• Professionelle Dienstleistungen und Berater

• Sichtbarkeit und Einfluss auf die Roadmap dieser Datenbank

Auf der rechten Seite gibt es Public-Domain-Software. Diese Software unterliegt keinerlei Urheberrecht, d. h. sie kann ohne Einschränkung verändert, verbreitet oder verkauft werden. Projekte am rechten Ende des Spektrums werden oft von den Standards einer unparteiischen und unvoreingenommenen dritten Partei geregelt, wie z. B. der Apache Software Foundation oder der Linux Foundation.

Die Open Source Initiative (OSI) führt eine allgemein anerkannte Liste dessen, was eine Open-Source-Lizenz ist und was nicht. Im Allgemeinen zeichnet sich Open-Source-Software durch die Fähigkeit aus, den Code zu teilen. Das bedeutet, dass Sie den Code nach Belieben ändern oder bearbeiten können, wenn die Ausrichtung des Projekts (Software) mit Ihren Anforderungen oder Wünschen nicht übereinstimmt.

Die Verwendung einer Open-Source-Technologie ist besonders überzeugend, da keine Lizenzkosten entstehen, die Entwicklung transparent ist und die Innovation von einer Vielfalt von Stakeholdern, Maintainern und Problembereichen ausgeht. Im Vergleich zu kommerzieller Software verzichtet man bei Open-Source-Software auf Einflussnahme auf die Roadmap, Garantien für Fehlerbehebungen oder Sicherheitspatches sowie Verträge und erhält dafür eine Null-Anbieterbindung und eine verbesserte Flexibilität im Geschäftsbereich. (Sie sehen, dass dies ein Kompromiss ist, den Sie und Ihr Team sorgfältig abwägen müssen.)

Folgt man der Reise in der obigen Grafik von links nach rechts, gibt es unterschiedliche Stufen der Lizenzfreizügigkeit wie Apache 2.0, MPL und GPL 3.0.

Beispiele für Datenbanken, die Lizenzen zugeordnet sind

• Apache 2.0 Apache Cassandra, Apache CouchDB

• Mozilla Public License: RabbitMQ

• BSD: Redis

• GPL 3.0: Neo4j

• Proprietär: IBM Db2, Microsoft SQL Server

Ein bisschen Geschichte für den Kontext

In den späten 2000er Jahren steuerten die meisten aufstrebenden Datenbankanbieter darauf zu, ihre Datenbanken als „Open Source“ zu vermarkten, um einen einfachen Zugang zur Akzeptanz und die Aufmerksamkeit der Entwickler zu gewinnen. Unternehmen aus diesem Bereich sind Ihnen vielleicht bekannt, wie Mongo Inc., Redis Labs und Elastic. Diese Unternehmen entwickelten Community-Projekte wie MongoDB, Redis und Elasticsearch, wollten diese Investitionen aber mit Enterprise-Lizenzversionen, verwalteten Cloud-Implementierungen oder professionellen Services monetarisieren.

Der Paradigmenwechsel beim Cloud Computing hat dieses Geschäftsmodell jedoch prekär gemacht, da große Anbieter diese Technologien problemlos als erstklassigen, plattformnativen Managed Service anbieten können. Diese Angebote werden mit überzeugenden Integrationen für Sicherheit, Compliance, Überwachung und Protokollierung in ihren jeweiligen Clouds bereitgestellt, ohne eine garantierte Vergütung für die Entwickler der Software zu bieten.

In den letzten Jahren haben Unternehmen ihren Weg zur Markteinführung neu bewertet. Jetzt sehen wir, dass sie Lizenzierungsmodelle einführen, die ihre Entwicklungsinvestitionen schützen. So habenMongoDB, Redis Labs und Confluent – mit unterschiedlichem Schweregrad – die Lizenzen von Teilen des Codes geändert, um zu verhindern, dass andere Unternehmen sie ohne Entschädigung als Service betreiben.

„Also, Josh, was ist Ihr Rat?“ Gute Frage.

Es gibt gute Gründe, sowohl kommerzielle als auch Open-Source-Datenbanken zu verwenden. Wichtig ist, dass Sie wissen, worauf Sie sich und Ihr Unternehmen einlassen. Überprüfen Sie die Lizenz, bevor Sie eine Anwendung erstellen, um sicherzustellen, dass Ihr Projekt konform ist, und wenn Sie stattdessen eine Lizenz für ein Open-Source-Projekt auswählen möchten, besuchen Sie die Github-Seite „Wählen Sie eine Lizenz“.
Ein wichtiger Aspekt sind also die Lizenzen, denn niemand möchte verklagt werden. Die andere Gruppe sind die Datenmodellfamilien, allerdings aus einem anderen Grund. Beim Erstellen einer Anwendung hilft Ihnen die Kenntnis der verschiedenen Datenmodelltypen dabei, das richtige Werkzeug für die jeweilige Aufgabe auszuwählen.

Nachdem Sie sich nun um die Lizenzen gekümmert haben, wollen wir über einen weiteren wichtigen Aspekt bei der Auswahl Ihrer Datenbank sprechen: die Datenmodelle.

Als ich bei IBM i mich schnell einarbeiten, also griff ich auf Martin Fowlers NoSQL Distilled zurück.

In seinen Texten und in der gesamten Branche werden Datenbanken tendenziell in fünf „Datenmodell“-Familien eingeteilt: Dokument, Schlüsselwert, Diagramm, relational und breitspaltig. Hier finden Sie einen kurzen Überblick über die einzelnen Funktionen, einschließlich Anwendungsfälle und datenbankspezifische Beispiele. Auf diese Weise können Sie auf der Grundlage Ihrer Datensätze und Geschäftsanforderungen bestimmen, welche Datenbank Sie benötigen.

1. Dokument

In diesem Fall werden die Daten in JSON-ähnlichen Dokumenten und nicht in Zeilen und Spalten modelliert. Bei diesen Datenbanken ist die Verfügbarkeit naturgemäß wichtiger als transaktionale Konsistenz. Dokumentdatenbanken eignen sich für Einfachheit und Skalierbarkeit sowie für eine schnelle Iteration in der Entwicklung.

Geschäftsanwendungsfälle:

• Mobile Apps, die schnelle Iterationen erfordern

• Event-Protokollierung, Online-Shopping, Content Management und tiefgreifende analytische Verarbeitung

• Einzelhandel-Kataloge mit Produktattributen

Beispiele:

• MongoDB

• Apache CouchDB

• Firebase

2. Schlüsselwert 

Dieser Modelltyp stellt die einfachste Art von nicht-relationaler Datenbank dar, bei der jedes Element in der Datenbank als Attributname (auch Schlüssel genannt) mit dem entsprechenden Wert gespeichert wird.

Geschäftsanwendungsfälle:

• Benutzerpräferenzen und Profil speichern

• Produktempfehlungen basierend auf Browserdaten

• Warenkörbe

Beispiele:

• DynamoDB

• Redis

• etcd

3. Diagramm

Die Daten werden hier als Scheitelpunkte und Edges (Werte und Verbindungen) modelliert. Ähnlich wie Menschen denken und Informationen verarbeiten, erinnern sich Diagrammdatenbanken an die Beziehungen zwischen einzelnen Dateneinheiten. Diese Datenbanken machen die Persistenz, Erkundung und Visualisierung von Daten und Beziehungen intuitiver.

Geschäftsanwendungsfälle:

• Betrugserkennung

• Empfehlungsmaschinen in Echtzeit

• Master Data Management

• Netzwerk- und IT-Betrieb

• Identitäts- und Zugriffsmanagement

Beispiele:

• Neo4j

• JanusGraph

• AWS Neptune

4. Relational 

Das relationale Modell , eingeführt von R.F. Codd in seiner Zeit hier bei IBM, ist der Titan der Branche. Daten werden in Tabellen als Zeilen und Spalten gespeichert und verfügen oft über komplexe Abfrage-Engines für Analysen und Untersuchungen. Relationale Datenbanken unterstützen Transaktionsgarantien und die Einhaltung der ACID-Prinzipien (Atomarität, Konsistenz, Isolation und Dauerhaftigkeit), während die meisten Datenbanken der anderen vier Familien letztendlich konsistent sind.

Geschäftsanwendungsfälle:

• E-Commerce

• Enterprise Resource Planning

• Kundenbeziehungsmanagement

Beispiele:

• PostgreSQL

• IBM Db2

5. Breitspaltig

Familien von Spaltenspeichern ermöglichen einen sehr schnellen Datenzugriff mithilfe eines Zeilenschlüssels, eines Spaltennamens und eines Zeitstempels der Zelle. Das flexible Schema dieser Art von Datenbanken bedeutet, dass die Spalten nicht für alle Datensätze einheitlich sein müssen, und Sie können eine Spalte zu bestimmten Zeilen hinzufügen, ohne sie zu jedem einzelnen Datensatz hinzufügen zu müssen. Breite Spaltendarstellungen sind aus Googles BigTable- Paper abgeleitet. Diese Datenmodelle sollten nicht mit spaltenorientierten Speichermodellen verwechselt werden, die aufgrund der verbesserten Komprimierung der Daten auf der Festplatte und der effizienteren Nutzung der CPU für Data-Warehousing-Technologien und analytische Zugriffsmuster relevanter sind.

Geschäftsanwendungsfälle:

• Wertpapier- und Börsenanalytik

• Clickstream analytics

• IoT und Telemetrie

Beispiele:

• Apache Cassandra

• DataStax Enterprise

• Google Cloud BigTable

Kurz gesagt: Jedes primäre Datenmodell hat Vor- und Nachteile (und wir haben hier kaum an der Oberfläche gekratzt). Aber im Zweifelsfall sollten Sie sich für etwas Bewährtes und Allgegenwärtiges wie PostgreSQL entscheiden. Um mehr über den Archetyp der Datenmodellfamilie zu erfahren, schauen Sie sich Martin Fowlers Buch NoSQL Distilled an, insbesondere die Kapitel 8–11.

Sind Sie bereit, mehr über Datenbanken zu erfahren?

Puh! Ich habe hier schon ein wenig über den Tellerrand geschaut, aber wenn Sie unbedingt mehr erfahren möchten, finden Sie hier einige Vorschläge, die auf dem Zeitaufwand basieren:

• 15 Minuten: „How to Choose a Database“ von Ben Anderson

• 15 Minuten: „SQL vs. NoSQL Databases: What’s the Difference?“ von Ben Anderson und Brad Nicholson

• Drei Stunden: Jepsen analyses of distributed systems safety

• Eine Woche: Designing Data-Intensive Applications von Martin Kleppman.

Möchten Sie mit dem Aufbau beginnen? Die IBM Cloud verfügt über eine breite Palette von Managed Databases Services, die Ihrem Team helfen, schnell voranzukommen.