Datenbank-How-to für App-Entwickler

Erfolgreiche Apps brauchen die richtige Datenbank.
dotshock | shutterstock.com



App-Entwickler können sich bei der Datenbankwahl auf möglicherweise Bias-behaftete Empfehlungen von Anbietern verlassen oder einfach auf eine zufällig bereits existierende Lösung zurückzugreifen. Zielführender ist es allerdings, zunächst einen Blick auf den angestrebten Zweck und die grundlegenden Anforderungen an den Datenspeicher zu werfen.



Dazu sollten sich Developer die folgenden 13 Fragen stellen – und diese möglichst ehrlich beantworten. Anderenfalls riskieren sie, ihr Projekt mit einer ungeeigneten und/oder überteuerten Datenbanklösung anzugehen. Das kann sich in vielfacher Hinsicht negativ auswirken, zum Beispiel auf die App-Performance und -Programmierbarkeit. 



1. Welche Datenmengen wollen Sie speichern?



Wenn Sie Daten im Gigabyte-Umfang (oder weniger) speichern möchten, können Sie nahezu jede Datenbank (DB) einsetzen, um Ihre Informationen zu verarbeiten – im Regelfall auch In-Memory-DBs. Selbst wenn Sie sich eher im Terabyte-Bereich bewegen, stehen Ihnen diverse Datenbankoptionen offen.



Geht es hingegen um Petabytes (oder mehr), schwindet die Optionsvielfalt – und Sie dürfen mit erheblichen Storage-Kosten rechnen (entweder für On-Premises-Lösungen oder für den Betrieb einer Cloud-Lösung). Wenn Sie sich in diesen Größenordnungen bewegen, empfiehlt sich ein Stufen-basiertes Storage-Modell, das ermöglicht, „Live“-Daten zu Gunsten der Geschwindigkeit über In-Memory-Lösungen oder lokale SSDs abzufragen. Der vollständige Datensatz liegt dabei aus wirtschaftlichen Gründen auf gewöhnlichen Festplatten.



Falls Sie mit einem Datenvolumen von mehreren hundert Petabytes oder etlichen Exabytes planen, stehen Ihnen nur noch wenige, (brauchbare) Datenbankoptionen offen. Deshalb ist es umso wichtiger, Lösungen für den Exabyte-Bereich besonders gründlich zu evaluieren. Sie bringen enorme finanzielle Verpflichtungen mit sich und können nur noch schwer verändert werden, wenn die Daten einmal eingeladen sind.   



Einige Unternehmen kombinieren Data-Lake- (für alle Daten) mit Data-Warehouse-Lösungen (für Teilmengen der Daten) – andere setzen auf eine Data-Lakehouse-Architektur, wie sie Databricks oder Dremio anbieten. Wieder andere verwenden Datenbanken, die aus dem ursprünglichen Google-Spanner-Whitepaper (PDF) abgeleitet wurden. Dazu zählen beispielsweise:




Google Cloud Spanner (SQL und NoSQL),



HBase (NoSQL),



Cassandra (NoSQL),



DataStax (NoSQL),



ScyllaDB (NoSQL),



CockroachDB (SQL) oder auch



„Sharded Extensions“ von SQL-Datenbanken wie Vitess und PlanetScale.




2. Wie viele User sollen simultan bedient werden?



Die Last einzuschätzen, die durch viele simultane Benutzer entsteht, wird in vielen Fällen als „Server Sizing Exercise“ betrachtet, der kurz vor der Installation der Produktionsdatenbank Rechnung getragen wird. Unglücklicherweise sind viele Datenbanken aufgrund von Skalierungsproblemen nicht dazu in der Lage, Tausende von Benutzern zu händeln, die Daten in Teraybyte- oder Petabyte-Umfang abfragen.



Im Fall einer nicht-öffentlichen, internen Datenbank, die von Mitarbeitern eines Unternehmens genutzt wird, ist es wesentlich einfacher, die Zahl der parallelen Benutzer einzuschätzen. Öffentlich zugängliche DBs sollten zudem bei unerwarteten Lastspitzen über mehrere Server skalieren. Leider unterstützen nicht alle Datenbanklösungen eine horizontale Skalierung ohne (zeitaufwändiges) manuelles Sharding großer Tabellen.



Datenbankindizes mit Read/Write-Zugriff können die Anzahl gleichzeitiger Abfragen in transaktionalen SQL-Datenbanken begrenzen. In einigen Fällen werden transaktionale DBs auch mit analytischen kombiniert, um dieses Problem zu umgehen (mehr dazu unter Punkt 7).



3. Wie sehen Ihre Anforderungen aus?



Zu den Anforderungsbereichen gehören:




Verfügbarkeit,



Skalierbarkeit,



Latenz,



Durchsatz und



Datenkonsistenz.




Im Folgenden betrachten wir diese im Einzelnen.



Die Verfügbarkeit ist oft ein Schlüsselkriterium für transaktionale Datenbanken – insbesondere, wenn die zugrunde liegende Applikation rund um die Uhr (stabil) laufen soll. Einige wenige Cloud-Datenbanken können eine Availability von 99,999 Prozent realisieren – sofern sie in mehreren Verfügbarkeitszonen betrieben werden.



In der Vergangenheit war Skalierbarkeit – insbesondere auf horizontaler Ebene – eher eine Sache für NoSQL-DBs. Inzwischen holen SQL-Datenbanken in diesem Bereich auf. Dynamisch zu skalieren, lässt sich innerhalb einer Cloud-Umgebung deutlich einfacher bewerkstelligen und gewährleistet, den Durchsatz auf die Anzahl der parallelen Nutzer abzustimmen.



Die Latenz(zeit) bezieht sich sowohl darauf, wie lange die Datenbank braucht um zu antworten, als auch auf die „End-to-End“-Antwortzeit der Applikation. Idealerweise bewegen sich die Antwortzeiten bei User-Interaktionen in einem Bereich von unter einer Sekunde. Die DB muss einfache Transaktionen also in weniger als 100 Millisekunden beantworten. Analytische Abfragen können hingegen oft mehrere Sekunden oder Minuten in Anspruch nehmen. Das lässt sich abmildern, indem komplexe Queries im Hintergrund abgearbeitet werden.



Der Durchsatz wird im Fall einer OLTP-Datenbank normalerweise in Transaktionen pro Sekunde gemessen. Je höher der Throughput einer Datenbank, desto mehr User können parallel bedient werden.



Die Datenkonsistenz ist bei SQL-Datenbanken in der Regel „strong“, was bedeutet, dass alle Lesevorgänge aktuelle Daten zurückgeben. Bei NoSQL-Datenbanken kann die Datenkonsistenz zwischen „eventual“ und „strong“ variieren. Ist sie weniger ausgeprägt, kann das in geringeren Latenzzeiten resultieren. Dann besteht allerdings auch das Risiko, dass veraltete Daten zurückgegeben werden. 



4. Wie stabil sind Ihre Datenbankschemata?



SQL-Datenbanken sind eine gute Wahl, wenn es eher unwahrscheinlich ist, dass sich Ihre Datenbankschemata im Laufe der Zeit verändern. Und Sie Wert darauf legen, dass die Mehrzahl der Felder konsistente Typen aufweist. 



Anderenfalls fahren Sie möglicherweise mit einer Lösung aus dem NoSQL-Bereich besser. Diese Datenbanken unterstützen in manchen Fällen gar keine Schemata. Wie immer bestätigen auch hier Ausnahmen die Regel: So ermöglicht etwa die Datenbanklösung Rockset SQL-Abfragen, ohne den importierten Daten ein festes Schema oder konsistente Typen aufzuerlegen.



5. Wie sind die User geografisch verteilt?



Wenn Ihre Datenbankbenutzer über die ganze Welt verteilt sind, kann bereits das Netzwerk zu Verzögerungen im Bereich von mehreren Hundert Millisekunden führen. Es sei denn, Sie stellen zusätzliche Server in den entsprechenden Regionen bereit. Dieser Aspekt erschwert es (zusätzlich), eine Balance zwischen Konsistenz und Latenz zu finden. Einige Datenbanken bieten Support für Read-Write-Server, andere offerieren verteilte Read-Only-Server, bei der alle Schreibvorgänge über einen Master Server laufen.



Das Gros der DBs, die global verteilte Knoten und ausgeprägte Konsistenz unterstützen, nutzt Consensus Groups, um Schreibvorgänge zu beschleunigen, ohne dabei die Konsistenz maßgeblich zu beeinträchtigen. Dabei kommt im Regelfall der Paxos– (PDF) oder Raft-Algorithmus zur Anwendung. 



Verteilte NoSQL-Datenbanken, deren Konsistenz „eventual“ ist, verwenden in der Regel eine Peer-to-Peer-Replikation ohne Konsensverfahren. Das kann zu Konflikten führen, wenn zwei Replikate gleichzeitig Schreibzugriff auf denselben Datensatz erhalten, wobei diese in der Regel heuristisch gelöst werden.



6. Wie sieht Ihr Data Shape aus?



SQL-Datenbanken speichern traditionellerweise stark typisierte Daten in Tabellen mit Zeilen und Spalten. Dabei:




stützen sie sich auf definierte Beziehungen zwischen Tabellen,



verwenden Indizes, um ausgewählte Abfragen zu beschleunigen, und



nutzen JOINS, um mehrere Tabellen gleichzeitig abzufragen.




Im NoSQL-Bereich speichern Dokumentdatenbanken in der Regel schwach typisierte JSON-Daten, die Arrays und verschachtelte Dokumente enthalten können. Graph-Datenbanken speichern entweder Vertexes, Edges, Triples oder Quads. Weitere NoSQL-Datenbankkategorien sind Key-Value- und Columnar-Stores.



Manchmal werden die Daten in einer Form generiert, die auch für Analysezwecke geeignet ist. Wenn nicht, müssen sie transformiert werden. Dabei ist wichtig zu wissen, dass manche Datenbanken auf anderen aufbauen. Key-Value-Stores können beispielsweise nahezu jeder Art von Datenbank zugrunde liegen.



7. OLTP, OLAP – oder beides?



Um diese Frage beantworten zu können, sollten Sie wissen, ob Ihre Applikation eine Datenbank für Echtzeit-Transaktionen (OLTP), für Datenanalysen (OLAP) oder für beides benötigt. Dabei gilt es zu berücksichtigen: 




Schnelle Transaktionen bedeuten eine hohe Schreibgeschwindigkeit und minimale Indizes.



Datenanalysen benötigen eine hohe Lesegeschwindigkeit und eine Vielzahl von Indizes.




Hybride Systeme versuchen durch verschiedene Tricks beide Anforderungen zu erfüllen – beispielsweise mit primären Transaktionsspeichern, die per Datenreplikation einen sekundären Analysespeicher speisen.



8. Welche Read/Write-Ratio erwarten Sie?



Einige Datenbanken performen besser bei Lesevorgängen und Queries, andere bei Write-Prozessen. Sie tun deshalb gut daran, Ihre Auswahlkriterien in Sachen Datenbank um das Read/Write-Verhältnis zu erweitern, dass Sie für Ihre Anwendung erwarten.



Geht es um die Wahl des optimalen Index Type, kommt es darauf an, ob Ihre Applikation besonders lese- (im Regelfall ein B-Tree) oder schreibintensiv (oft ein LSM-Tree) ist. 



9. Geografische oder Full-Text-Queries?



Wenn Sie geografische oder geometrische Daten effizient abfragen wollen, um Objekte innerhalb eines definierten Bereichs zu finden, benötigen Sie andere Indizes als bei „typischen“, relationalen Daten. Die bevorzugte Wahl für Geospatial-Daten ist im Regelfall ein R-Tree. Es stehen jedoch mehrere andere Datenstrukturen für räumliche Indizes zur Verfügung. Unterstützt werden sie von ein paar Dutzend Datenbanken – in den allermeisten Fällen spielt dabei der Standard des Open Geospatial Consortium eine Rolle.



Auch eine effiziente Volltextsuche in Textfeldern erfordert „andere“ Indizes. In der Regel wird dazu ein invertierter Listenindex mit tokenisierten Wörtern erstellt und durchsucht, um einen kostenintensiven Tabellenscan zu vermeiden.



10. Welche Programmiersprachen bevorzugen Sie?



Zwar unterstützen die allermeisten Datenbanken diverse Programmiersprachen über APIs. Dennoch kann die von Ihnen bevorzugte Sprache die Wahl der Datenbank beeinflussen.



JSON ist zum Beispiel das natürliche Datenformat für JavaScript. Für eine JavaScript-Anwendung sollten Sie demnach möglichst eine Datenbank wählen, die den JSON-Datentyp unterstützt. Wenn Sie eine stark typisierte Programmiersprache nutzen, sollten Sie entsprechend auch eine stark typisierte Datenbank wählen.



11. Gibt es budgetäre Beschränkungen



Das Preisspektrum bei Datenbanken reicht von kostenlos bis extrem teuer und deckt diverse Versionen und verschiedene Serviceausprägungen ab. 



Falls Ihre Wahl auf eine kostenlose Open-Source-Datenbank fällt, sollten Sie sich bewusst sein, dass Sie möglicherweise auf (Anbieter-)Support verzichten müssen. Sie sollten das hierfür nötige Knowhow also selbst mitbringen.



Auf der anderen Seite kann es sich mit Blick auf die Produktivität als förderlich erweisen, sich auf die Anwendung zu fokussieren und Datenbank-Management- sowie -Wartungsaufgaben einem (Cloud-)Anbieter zu überlassen.



12. Gibt es rechtliche Einschränkungen?



Geht es um Datenschutz und Datensicherheit, kommen diverse Gesetze zur Anwendung. In Europa hat in erster Linie die Datenschutzgrundverordnung (DSGVO/GDPR) weitreichende Auswirkungen, in den USA beispielsweise HIPAA, GLBA oder CCPA.  



Diverse Datenbanklösungen versprechen, Daten so zu verarbeiten, dass einige oder auch alle dieser Regelwerke eingehalten werden (wenn bestimmte Best Practices zur Anwendung kommen). Andere DBs weisen Sicherheitslücken auf, die sie für die Arbeit mit personenbezogenen Daten unbrauchbar machen.



13. SQL oder NoSQL?



Um diese Frage zu beantworten, werfen wir einen Blick auf zwei (extreme) Beispielfälle:




Sie benötigen sehr niedrige Latenzzeiten und einen hohen Durchsatz, die kurzfristige Konsistenz ist Ihnen egal, solange die Daten nach ein paar Minuten konsistent aussehen. Ihre Daten werden durch Key-Value-Datensätze angemessen repräsentiert und Sie legen Wert auf umfassende, horizontale Skalierbarkeit. In diesem Fall steht außer Zweifel, dass Sie auf eine NoSQL-Key-Value-Datenbank setzen sollten.



Sie tracken Finanztransaktionen und müssen die ACID-Eigenschaften für alle Transaktionen gewährleisten, selbst wenn diese mehrere Tabellen in geografisch verteilten Regionen betreffen. Alle anderen Überlegungen, wie niedrige Latenzzeiten und hoher Durchsatz, sind schön und gut, aber mit Blick auf zuverlässige, genaue Transaktionen zweitrangig. In diesem Fall sollten Sie auf eine – vorzugsweise verteilte – SQL-Datenbank zurückgreifen.




Natürlich gibt es diverse Fälle, die zwischen diesen Extrembeispielen liegen – zu viele, um sie in diesem Rahmen aufzuführen. Welche Datenbank für Ihre Fälle die Richtige ist, ergibt sich im Wesentlichen aus Ihren Antworten auf die vorangegangenen zwölf Fragen.



Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!



Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.