Zephyrnet-Logo

DevOps und Daten: Lektionen, die Teams über die Verwaltung von Datenbanken lernen können – DATAVERSITY

Datum:

Nach Angaben des Bureau of Labor Statistics sehen die Aussichten für Stellen rund um die Verwaltung von Datenarchitekturen und Datenbanken ziemlich gut aus: Die Zahl der Fachkräfte mit Rollen rund um die Verwaltung von Daten steigt wegen wachsen von 2022 bis 2032 um acht Prozent. Doch während die Zahl der Rollen, die mit Daten arbeiten, zunimmt, nimmt allein die Position des Datenbankadministrators (DBA) tatsächlich ab. Stattdessen wurde die Rolle des DBA-Spezialisten durch den Site Reliability Engineer (SRE) der DevOps-Welt ersetzt. 

Die SRE-Rolle hat sich bei Google entwickelt und ihre Fähigkeiten im Bereich Website-Management und -Betrieb auf andere Technologiebereiche übertragen. SREs haben einen viel größeren Aufgabenbereich als ein DBA und decken die gleichen Arten von Aufgaben wie Betriebsmanagement, Verfügbarkeit, Systemredundanz und Sicherheit ab, jedoch für die gesamte IT-Infrastruktur, nicht nur für die vorhandenen Datenbanken. Die von DBAs ausgeführten Aufgaben haben jedoch nicht abgenommen, und es gibt Nuancen, die DBAs möglicherweise verstehen, die andere Mitarbeiter jedoch nicht verstehen.

Mit welchen Problemen sind Datenbankadministratoren konfrontiert? 

Während die Mehrheit der SREs in der Lage sein wird, Datenbankinstanzen zu verwalten und am Laufen zu halten, werden sie nicht über die Tiefe an Erfahrung und Wissen verfügen, die jemand haben wird, der sich auf Datenbanktheorie und -management konzentriert. Wenn etwas Außergewöhnliches passiert, müssen SREs verstehen, was vor sich geht und ob sie das Problem beheben können oder ob sie möglicherweise einen Experten hinzuziehen müssen.

Ein gutes Beispiel hierfür ist die Einrichtung und Verwaltung Strukturierte Abfragesprache, oder SQL. SQL ist zwar die beliebteste Sprache des IEEE im Jahr 2023, verfügt jedoch über eine komplizierte Syntax, deren Beherrschung sich nur relativ wenige widmen. Viele Entwickler sind nicht mit dem Schreiben effektiver und effizienter SQL-Abfragen vertraut, sodass sie am Ende möglicherweise Anfragen mit schlechter Leistung erhalten, deren Ergebnisse länger dauern. Alternativ wenden sich Entwickler oft an Object-Relational Mapper (ORMs), um ihre SQL-Anfragen für sie zu bearbeiten. Während ORMs die Situation für Entwickler möglicherweise einfacher machen, können sie unter der gleichen schlechten Leistung und dem schlechten Abfragedesign leiden wie das Schreiben Ihres eigenen SQL-Codes, gepaart mit der Notwendigkeit, den ORM selbst zu aktualisieren und zu verwalten. Diese Kombination geht oft mit der Vorliebe einher, Transaktionen mit langer Laufzeit zu verwenden, die die Leistung beeinträchtigen. 

Für Datenbankadministratoren gehörte es zu ihrer Vollzeitaufgabe, diese Probleme zu erkennen und zu beheben. Allerdings können SREs, die mit der Datenbankleistung nicht vertraut sind, diese langsamen Transaktionen als „so wie die Dinge sind“ und nicht als Symptom dafür akzeptieren, dass etwas nicht stimmt. Alternativ können Entwickler versuchen, mehr Ressourcen für die Lösung des Problems einzusetzen, indem sie größere Maschinen oder Cloud-Instanzen kaufen, um sie auszuführen.

Neben dem Abfragedesign waren DBAs auch für die Einrichtung von Datenindizes in ihren Datenbanken verantwortlich. Das Indizieren von Daten ist für viele eine dunkle Kunst im Harry-Potter-Stil, die entweder zu viel oder zu wenig indiziert, was zu einer schlechten Leistung führt. In der Vergangenheit suchten Datenbankadministratoren nach redundanten Indizes, die nicht mehr verwendet wurden, oder nach beliebten Abfragen, die nicht indiziert waren, und korrigierten dann die Datenbank, um eine bessere Leistung zu erzielen. 

Schließlich wären die Datenbankadministratoren dafür verantwortlich, Abfragen selbst auszuführen, um die Leistung im Laufe der Zeit mithilfe von ANALYZE TABLE zu verfolgen. Dadurch bleiben die Statistiken für den Optimierer aktuell und werden alle Bereiche markiert, in denen Änderungen oder Ergänzungen Auswirkungen auf das Leistungsniveau hatten. Ohne diese Erkenntnisse können SREs Indizes belassen, die im besten Fall nicht mehr benötigt werden oder die sich im schlimmsten Fall negativ auf die Leistung auswirken. 

Planen Sie im Voraus

Auch auf der betrieblichen Seite von Datenbanken gibt es Lehren, die neu gelernt werden müssen. Es gibt zum Beispiel ein altes Sprichwort, dass ein DBA immer nur so gut war wie sein letztes Backup. Auch wenn Sie hoffen, dass Sie nach einem Problem nie wieder Daten wiederherstellen müssen, ist es dennoch unerlässlich, für jede kritische Datei ein funktionierendes und vollständig getestetes Backup zu haben. In der Welt der Datenbanken verlassen sich viele SREs mittlerweile darauf, dass ihr Cloud-Anbieter diese für sie ausführt. Reicht dies jedoch aus, um angemessen zu sein? 

Sie können zwar auf die Angaben in Ihrer Service-Level-Vereinbarung zu einem Sicherungs- und Wiederherstellungsprozess verweisen, diese geben jedoch möglicherweise nicht genau wieder, wie schnell Sie nach einem Problem wieder einsatzbereit sind. Erstens hängt dieses SLA davon ab, dass Ihr Backup in Ordnung ist und Sie in der Lage sind, es vollständig wiederherzustellen. Solange Sie nicht tatsächlich ein Backup geladen und diese Daten wieder verwendet haben, können Sie nicht sicher sein, dass Sie Ihre Abläufe vollständig geschützt haben. Zweitens kann sich Ihre SLA-Zeit stark von der Zeit unterscheiden, die Sie sich leisten können, um offline zu sein und nicht zu verarbeiten. Früher war es die Pflicht des DBA, Datenverluste zu erkennen und sie in einen guten Zustand zu versetzen. Ein Cloud-Dienstanbieter kann Ihnen zwar sagen, wie hoch sein SLA für Ihre Daten ist, er wird Ihnen jedoch nicht unbedingt alles bieten, was Sie zur Erfüllung Ihrer internen Serviceanforderungen benötigen.

Ebenso erfordert die Strukturierung von Datenbanktabellen viel Wissen darüber, wie Daten verwaltet werden. Während Entwickler möglicherweise verstehen, wie Datenbanken zum Speichern, Sortieren und Zurückgeben von Daten verwendet werden können, die sie für ihre Anwendungen benötigen, gibt es einige Nuancen bei der richtigen Ausrichtung von Tabellen, um im Laufe der Zeit das Beste aus diesen Daten herauszuholen. Darüber hinaus hilft Ihnen ein gutes Verständnis des relationalen Modells zu verstehen, dass die Unterteilung von Daten in separate Tabellen zu einer schlechten Leistung führt. Es gibt auch datenbankspezifische Tricks, die Sie im Rahmen der direkten Verwaltung dieser Instanzen lernen – viele wissen beispielsweise nicht, dass MySQL jetzt möchte, dass Sie Primärschlüssel für jede Tabelle haben, oder dass PostgreSQL möglicherweise Tabellen auffüllen muss, wenn dies bei Spalten der Fall ist passt nicht gut auf eine Acht-Byte-Grenze. 

Die Zukunft des Datenmanagements

Daten werden in Unternehmen immer wichtiger. Es bildet die Grundlage für eine effiziente Kundenbetreuung, ist aber auch das Herzstück neuer Geschäftsdienstleistungen oder Deep-Analytics-Projekte, die in neuen Produkten zum Einsatz kommen. Ohne diese Daten existieren diese Produkte – und die damit erzielten Einnahmen – entweder nicht oder bieten nicht den Wert, den sie bieten sollen.

Gleichzeitig verschwinden die Fähigkeiten rund um das Datenmanagement aus Organisationen, werden in umfassenderen Rollen zusammengefasst oder an Dienstleister übergeben. Wenn alles funktioniert, ist das in Ordnung. Wenn jedoch ein Problem auftritt, benötigen Sie dieses fundierte Wissen, um das Problem zu lösen und sicherzustellen, dass es nicht noch einmal auftritt. Das bedeutet auch, dass Sie mehr ausgeben können, als Sie benötigen, um die von Ihnen gespeicherten Daten zu pflegen und entsprechende Arbeiten durchzuführen.

Während die Rolle des DBA von neueren Positionen rund um DevOps und SRE übernommen wurde, liegen die mit dieser Rolle verbundenen Aufgaben weiterhin bei uns. Für SRE- und DevOps-Experten kann die Kenntnis Ihrer Datentheorie den Unterschied zwischen Geldausgaben für die Infrastruktur und Einsparungen bei der Leistung ausmachen.

spot_img

Neueste Intelligenz

spot_img