Die neue Art, Open-Source-Datenbanken zu verwalten

Vor nicht allzu langer Zeit bestand die Datenbankbranche aus einer Handvoll Anbietern. Datenbanken waren hauptsächlich relational und liefen auf einzelnen Maschinen. Die Hochverfügbarkeit wurde über Aktiv-Standby-Cluster implementiert. Bei einem vertikalen „Scale-Up“-Modell ging es hauptsächlich um gemeinsam genutzten Speicher (SAN oder DRBD) oder die asynchrone Replikation von Protokollen, um den Status mit einem Standby-Knoten zu synchronisieren. Als ich 2001 anfing, mit NDB Cluster (später MySQL Cluster) zu arbeiten, war das Konzept, eine ganze Datenbank im Hauptspeicher zu halten, seltsam – „Was wäre, wenn Sie den Server ausschalten?“. Die Verteilung einer Datenbank auf mehrere Server war besorgniserregend – „Sie haben hier und da Datenstücke“. Und die ganze Idee einer Open-Source-Datenbank für unternehmenskritische Workloads war lächerlich.

Spulen Sie 15 Jahre vor und wir haben jetzt Dutzende von Datenbankanbietern auf dem Markt – meist Open Source, verschiedene Modelle (Schlüsselwert, Dokument, Grafik, …) und standardmäßig verteilt. Speicherresidente Daten sind so ziemlich die Norm, um eine hohe Leistung und niedrige Latenz zu erreichen. Drei der Top 5 der beliebtesten Datenbanken (laut Ranking von db-engines) sind Open Source (MySQL, PostgreSQL und MongoDB). Heutzutage verwalten Sie eher eine Flotte von Datenbankservern, die über verschiedene Rechenzentren verteilt sind. Möglicherweise lassen Sie sogar einige Ihrer Datenbanken von einem Cloud-Drittanbieter verwalten.

Wie ist es also, Datenbanken im Jahr 2018 zu verwalten?

AUTOMATISIERUNG

Bei so vielen zu verwaltenden Aufgaben und nur so vielen Stunden am Tag wäre man verrückt, Dinge manuell zu erledigen.

Automatisierung ist eine großartige Möglichkeit, Dinge zu erledigen. Als wir nur wenige Datenbanken zu verwalten hatten, war der Betrieb der Datenbank sehr praktisch, mit einigen Aufgaben, die in etwas wie Bash oder Perl geschrieben wurden - z. B. ein Skript zum Sichern der Datenbank, ein anderes zum Verschieben von Sicherungsdateien an einen Ort. Das Failover würde manuell erfolgen, und wir würden sogar darüber diskutieren, ob es automatisiert werden sollte oder nicht.

Heutzutage ist Automatisierung ein Kinderspiel. Es gibt eine Reihe von IT-Automatisierungs- oder Konfigurationsmanagementsystemen, die genutzt werden können – Puppet, Chef, Ansible und Salt bieten alle universelle Frameworks, die zum Erstellen von Automatisierungen für verschiedene Datenbanktopologien verwendet werden können. Cluster-Management-Software, die speziell für die Verwaltung von Datenbank-Setups geschrieben wurde, umfasst MongoDB Ops Manager und ClusterControl. Sie ermöglichen den Betriebsteams, ihre Cluster mit etwas zu verwalten, das sofort verfügbar ist. Der Aufbau eines Cluster-Verwaltungssystems mithilfe eines Konfigurationsverwaltungssystems von Grund auf ist keine Kleinigkeit. Es erfordert erhebliche Fachkenntnisse im Automatisierungstool sowie ein Verständnis für Verwaltungsvorgänge wie Backup-Planung und -Verifizierung, automatisches Failover mit anschließender Neukonfiguration von Systemen, Rollout von Konfigurationsänderungen, Patches, Versions-Upgrade oder -Downgrade usw.

Und natürlich gibt es den Aufstieg von DBaaS-Serviceplattformen, bei denen Bereitstellung, Zustand, Failover, Backups usw. allesamt von Software gesteuert werden. Cloud-Anbieter sind in der Tat sehr gut in der Automatisierung. Amazon RDS ist ein großartiges Beispiel für Datenbankautomatisierung im großen Maßstab – es automatisiert Bereitstellung, Patch-Upgrades, Backups, Point-in-Time-Wiederherstellung, Skalierung von Replikaten und Hochverfügbarkeit/Failover.

HAUSTIERE gegen RINDER

In den 90er Jahren und bis zum Dotcom-Boom und der Pleite machten Sun Microsystems und Oracle ein Vermögen mit dem Verkauf von Scale-up-Datenbanken auf großer SMTP-Hardware. Fügen Sie noch etwas SAN-Speicher und Veritas-Failover-Software hinzu, und Sie hätten einen hochmodernen Aktiv-Standby-Failover-Cluster für hohe Verfügbarkeit. Datenbankserver waren relativ wenige, aber leistungsstark, da sie vertikal wachsen würden. Sie erhielten Namen (so wie Sie Ihren Haustieren Namen geben!) und wurden von DBAs betreut.

Heutzutage sind Datenbanken billig und laufen gut auf handelsüblicher Hardware. Es gibt viele von ihnen, und wir geben ihnen Nummern – genau wie Rinder. Wenn einer kaputt geht, können wir einfach einen neuen bekommen.

Es ist auch eine neue Rinderrasse – Open-Source-Rinder! Drei der Top-5-Datenbanken sind laut db-engines alle Open Source – sie fressen langsam aber sicher den Marktanteil der beiden proprietären Anbieter auf. Open Source ist der neue Rechenzentrumsstandard, nicht nur für Betriebssysteme, sondern auch für Datenbanken.

Was bedeutet das für Sie? Nun, in Zukunft werden Sie eher eine Open-Source-Datenbank verwalten – oder sogar mehrere für Anwendungen, die heterogene Datensammlungen verwenden. In einer Welt der mehrsprachigen Persistenz und Microservices wird der zugrunde liegende Datenspeicher jetzt von der Art der Daten bestimmt. Aus architektonischer Sicht weichen Einzelinstanzdatenbanken mit festplattenbasierter Hochverfügbarkeit Clustern, die potenziell über mehrere Rechenzentren verteilt sind.

Brauchen wir einen DBA?

Die DBA-Rolle ist eine spezialisierte - es braucht jahrelange Erfahrung, um eine zu werden. In der Vergangenheit, als nur wenige proprietäre Datenbankanbieter zur Auswahl standen, hatten Sie spezialisierte DBAs mit bestimmten Fähigkeiten und Erfahrungen. Es war auch erforderlich – Datenbanken wie Oracle oder SQL Server verfügen über riesige Feature-Sets, die über Jahrzehnte aufgebaut wurden. Sie sind nicht einfach zu handhaben. Sie wurden in der Regel als einzige Datenbank für eine Anwendung bereitgestellt und mussten überwacht, Daten gesichert und alle auftretenden Probleme behandelt werden. Genau auf diese Aufgaben sollten sich die DBAs hier konzentrieren.

In den letzten zehn Jahren ist jedoch eine ganz neue Datenbankbranche entstanden – mit Dutzenden von Open-Source-Datenbanken sowie Cloud-Datenbankdiensten. Wie wir bereits gesehen haben, ist es nicht ungewöhnlich, dass eine Anwendung mehrere verschiedene Datenspeicher verwendet. Aber Unternehmen haben selten einen DBA für diese Datenspeicher, die sie verwenden. Wo finden Sie eine MongoDB oder Cassandra oder DBA mit mehr als 5 Jahren Produktionserfahrung? Man kann argumentieren, dass die neue Generation von NoSQL-Datenbanken viel einfacher ist als ihre Closed-Source-Vorgänger und daher nicht die gleiche Lernkurve erfordern würde.

Ihre Verwaltung wäre nur eine weitere Aufgabe, die der Todo-Liste des SysAdmin- oder DevOps- oder Site Reliability Engineering (SRE)-Teams hinzugefügt wird. Und wir sehen heute, dass viele Unternehmen keine Vollzeit-DBAs haben. Die Verantwortung wird stattdessen auf Teams verteilt, wobei Automatisierungstools zunehmend verwendet werden, um alltägliche Routineaufgaben zu erledigen. Bei Datenbanken, die in die Cloud verlagert wurden, werden die operativen Aspekte der Datenspeicherung vollständig an den Cloud-Anbieter ausgelagert. Anstatt daran zu arbeiten, wie Daten gespeichert werden, kann sich das Operations-Team nun auf die Verwendung der Daten konzentrieren.

Datenbanklebenszyklus

Der durchschnittliche Lebenszyklus einer Datenbank war früher viel länger als heute. Sobald Sie sich für eine Datenbankplattform entschieden haben, war es das. Die Entscheidung würde zwischen zwei oder drei relationalen Datenbanken getroffen, normalerweise vom DBA oder jemand höher in der Organisation. Das Unternehmen würde das Geld finden, um unbefristete Lizenzen zu erwerben. Nachdem die Entscheidung gefallen war, mussten Sie nun die nächsten 10+ Jahre damit leben. Datenbanken waren monolithisch, und Anwendungen verwendeten normalerweise eine einzige gemeinsam genutzte Datenbank.

Heutzutage ist es in einer Welt von Containern, Clouds, Microservices und CI/CD-Pipelines nicht ungewöhnlich, dass Entwickler die Technologieentscheidungen treffen – insbesondere, wenn es sich um eine Open-Source-Datenbank handelt, die einfach heruntergeladen oder als Dienst angeboten werden kann. ohne mit einem Vertriebsmitarbeiter sprechen oder Budget vom Management einholen zu müssen. Unternehmen stehen vor der Herausforderung, schneller Werte zu schaffen, daher ist die Änderungsrate der Infrastruktur/Anwendungen dramatisch gestiegen. Monolithische Datenbanken sind jetzt in mehrere kleine Datenbanken aufgeteilt, wobei jede Datenbank Domänendaten für einen einzelnen Microservice verwaltet. Mit der Vielfalt an Datenbankprodukten, die heute im Open-Source-Ökosystem verfügbar sind, haben Teams die Wahl und Freiheit, auf einen besseren Datenspeicher umzusteigen. Wenn Dienste in Betrieb genommen und außer Betrieb genommen werden, folgen auch Datenbanken – obwohl die Daten selbst möglicherweise archiviert oder in einen Data Lake verschoben werden. In einer heute viel dynamischeren Infrastrukturlandschaft stellen wir fest, dass unsere Datenbanken immer kürzer leben.

DBA-ROLLE

Der DBA, traditionell sowohl Wächter als auch Torwächter der Datenbank, würde die Datenbankanforderungen verschiedener Anwendungs-/Infrastrukturteams in der Organisation bedienen. Alle Änderungen, die einen Zugriff oder Änderungen an der Datenbank erfordern, erfordern die Dienste des DBA. Widersprüchliche Prioritäten und fehlende DBA-Verfügbarkeit könnten jedoch dazu führen, dass das Projekt blockiert/verzögert wird und unvermeidliche Reibungen folgen.

Hohe Kosten für die Zusammenarbeit und schnelle Innovation/kurze Time-to-Market passen nicht gut zusammen. Wie wir bereits gesehen haben, sind Microservices ein Beispiel dafür, wie Infrastruktur- und Anwendungsservices jetzt so gestaltet sind, dass sie so weit wie möglich entkoppelt sind. Datenbanken werden zunehmend automatisiert und die Kontrolle über die Datenbank verlagert sich auf Entwickler oder Projektteams. Sogar Dinge wie Schemaänderungen sind nicht mehr so ​​schwer wie früher. Sie waren im Kontext einer zentralen Datenbank für eine monolithische Anwendung viel schwieriger. Da Daten zwischen verschiedenen Komponenten ausgetauscht werden, müssten Schemaänderungen koordiniert und sorgfältig geplant werden – normalerweise Monate im Voraus. DBAs spielten eine Schlüsselrolle beim Verständnis und der Durchführung von Änderungen. Die Dynamik ist heute anders, wo die Änderungsgeschwindigkeit viel schneller ist. Es ist nicht ungewöhnlich, dass Entwicklungsteams wöchentlich oder täglich Codeänderungen in der Produktion vorantreiben – oder sogar mehrmals am Tag! Datenbanken müssen ständig aktualisiert werden, um mit Anwendungsänderungen Schritt zu halten, und diese werden von Entwicklern durchgeführt. Einige der neueren Datenbanken wie MongoDB machen es sogar sehr einfach, indem sie ein schemaloses Modell haben. Dies bedeutet effektiv, dass das Datenbankschema in den Anwendungscode verschoben wird.

Wenn also alle gängigen Kernaufgaben wegautomatisiert werden, was passiert dann mit der DBA-Rolle in der Zukunft? Anstatt sich auf administrative Aufgaben zu konzentrieren, wird der DBA eher als Mentor für andere Teams in der Organisation fungieren. Organisationen müssen verstehen, welche Daten sie haben und wie diese Daten genutzt werden können. Schließlich sind Daten am wertvollsten, wenn sie geteilt und mit anderen Ressourcen kombiniert und nicht nur gespeichert werden. Schemalos klingt großartig, aber wir müssen unsere Daten trotzdem im Auge behalten – entweder in der Datenbank oder im Code. Sicherheit ist eine Herausforderung, und Datenschutzverletzungen werden immer schlimmer. Wenn wir also Daten wieder großartig machen wollen, muss der DBA zu einer horizontalen Berater-/Enabler-Rolle wechseln, die sich über Teams erstreckt. Aus Kompetenzperspektive muss der moderne DBA verstehen, wie man verteilte Hochverfügbarkeitssysteme entwirft und effiziente Automatisierungssysteme einführt, um die alltäglichen Aufgaben zu erledigen. Da Unternehmen Infrastrukturen in Cloud- oder sogar Containerumgebungen bereitstellen, wird das Verständnis, wie hochverfügbare und skalierbare Datenbanken auf diesen Plattformen erstellt werden, das Überleben des DBA sichern.

Zusammenfassung

Wir befinden uns an einem faszinierenden Wendepunkt in der Geschichte der Datenbankbranche, die in den letzten zwei Jahrzehnten einen massiven Wandel durchlaufen hat. Die folgende Tabelle versucht es zusammenzufassen.

Mich würde interessieren, was Sie über das Open-Source-Datenbankmanagement denken und ob Sie die gleichen Trends gesehen haben? Wie sahen Ihre Kämpfe oder Erfolge mit OSDBs in den letzten Jahren aus? Und was erwarten Sie nächstes Jahr?

Wir bei Multiplenines werden natürlich weiterhin daran arbeiten, die Verwaltung und Automatisierung Ihrer Open-Source-Datenbanken im nächsten Jahr und darüber hinaus zu erleichtern. Bleiben Sie also auf dem Laufenden für Updates dazu ab nächsten Januar.

Aber lassen Sie mich in der Zwischenzeit Ihre Meinung wissen und bis 2019!

Fotos von SoRad (Shutterstock) &Die Simpsons; andere Fotos sind von ihren jeweiligen Besitzern.