Volgens het Bureau of Labor Statistics zien de vooruitzichten voor banen rond het beheren van data-architectuur en databases er redelijk goed uit: het aantal professionals met rollen rond het beheren van data is vanwege groeien tussen 2022 en 2032 met acht procent. Terwijl het aantal rollen dat zich met data bezighoudt toeneemt, neemt alleen al de positie van databasebeheerder (DBA) feitelijk af. In plaats daarvan is de rol van DBA-specialist vervangen door de Site Reliability Engineer (SRE) van de DevOps-wereld. 

De SRE-rol is ontwikkeld bij Google, waarbij hun vaardigheden op het gebied van websitebeheer en -activiteiten worden toegepast op andere technologische gebieden. SRE's hebben een veel breder takenpakket dan dat van een DBA en bestrijken dezelfde soorten taken als operationeel beheer, beschikbaarheid, systeemredundantie en beveiliging, maar dan voor de hele IT-infrastructuur, en niet alleen voor de aanwezige databases. De taken die door DBA's worden uitgevoerd, zijn echter niet verminderd, en er zijn nuances die DBA's wellicht begrijpen en die andere werknemers niet begrijpen.

Met welke problemen worden DBA's geconfronteerd? 

Hoewel de meerderheid van de SRE's database-instances kunnen beheren en draaiende kunnen houden, zullen ze niet over de diepgaande ervaring en kennis beschikken die iemand die zich heeft geconcentreerd op databasetheorie en -beheer zal hebben. Als er iets ongewoons gebeurt, zullen SRE's moeten begrijpen wat er aan de hand is en of ze het probleem kunnen oplossen, of dat ze misschien een deskundige moeten inschakelen.

Een goed voorbeeld hiervan is het opzetten en beheren Structured Query Languageof SQL. SQL is misschien wel de meest populaire taal van de IEEE in 2023, maar het heeft een moeilijke syntaxis waar relatief weinig mensen zich aan wijden. Veel ontwikkelaars zijn niet bekend met het schrijven van effectieve en efficiënte SQL-query's, waardoor ze uiteindelijk slecht presterende verzoeken kunnen krijgen, waardoor het langer duurt voordat er resultaten worden geretourneerd. Als alternatief wenden ontwikkelaars zich vaak tot Object-Relational Mappers (ORM's) om hun SQL-verzoeken voor hen af ​​te handelen. Hoewel ORM's de situatie voor ontwikkelaars eenvoudiger kunnen maken, kunnen ze last hebben van dezelfde slechte prestaties en een slecht queryontwerp als het schrijven van uw eigen SQL-code, gekoppeld aan de noodzaak om de ORM zelf bij te werken en te beheren. Deze combinatie wordt vaak gezien naast een voorliefde voor het gebruik van langlopende transacties die de prestaties ondermijnen. 

Voor DBA's was het opsporen en corrigeren van deze problemen een onderdeel van hun fulltime baan. Voor SRE's die niet bekend zijn met databaseprestaties kunnen deze trage transacties echter worden geaccepteerd als 'hoe de zaken zijn' in plaats van als een symptoom dat er iets mis is. Als alternatief kunnen ontwikkelaars proberen meer middelen aan het probleem te besteden door grotere machines of cloudinstanties te kopen om in te draaien.

Naast het ontwerp van query's waren DBA's ook verantwoordelijk voor het opzetten van gegevensindexen in hun databases. Het indexeren van gegevens is voor velen een Harry Potter-achtige duistere kunst, die óf te veel óf te weinig indexeert, wat tot slechte prestaties leidt. In het verleden zochten DBA's naar overtollige indexen die niet langer werden gebruikt of naar populaire zoekopdrachten die niet waren geïndexeerd, en corrigeerden vervolgens de database voor betere prestaties. 

Ten slotte zouden DBA's zelf verantwoordelijk zijn voor het uitvoeren van query's om de prestaties in de loop van de tijd bij te houden met behulp van ANALYZE TABLE. Hierdoor blijven de statistieken voor de optimalisatie actueel en worden gebieden gemarkeerd waar wijzigingen of toevoegingen de prestatieniveaus hadden beïnvloed. Zonder dit inzicht kunnen SRE's indexen laten staan ​​die in het beste geval niet langer nodig zijn, of die in het slechtste geval de prestaties negatief beïnvloeden. 

Vooruit plannen

Er zijn ook lessen die opnieuw moeten worden geleerd aan de operationele kant van databases. Er is bijvoorbeeld een oud gezegde dat een DBA slechts zo goed was als de laatste back-up. Hoewel u misschien hoopt dat u na een probleem nooit gegevens hoeft te herstellen, is het hebben van een werkende en volledig geteste back-up voor elk kritiek bestand essentieel. In de wereld van databases vertrouwen veel SRE's nu op hun cloudprovider om dit voor hen uit te voeren. Is dit echter voldoende om voldoende te zijn? 

Hoewel u kunt verwijzen naar wat er in uw Service Level Agreement staat over een back-up- en herstelproces, geeft dit mogelijk niet accuraat weer hoe snel u na een probleem weer aan de slag kunt. Ten eerste is deze SLA afhankelijk van de vraag of uw back-up goed is en of u er volledig van kunt herstellen. Totdat u daadwerkelijk een back-up hebt geladen en die gegevens opnieuw bent gaan gebruiken, kunt u er niet zeker van zijn dat u uw activiteiten volledig hebt beschermd. Ten tweede kan uw SLA-tijd heel anders zijn dan de hoeveelheid tijd die u zich kunt veroorloven om offline te zijn en niet te verwerken. Vroeger was het de taak van de DBA om gegevensverlies op te sporen en deze in goede staat te herstellen. Hoewel een cloudserviceprovider u kan vertellen wat hun SLA is voor uw gegevens, zullen ze niet noodzakelijkerwijs alles bieden wat u nodig heeft om aan uw interne servicevereisten te voldoen.

Op dezelfde manier vereist het structureren van databasetabellen veel kennis over hoe gegevens worden beheerd. Hoewel ontwikkelaars misschien begrijpen hoe databases kunnen worden gebruikt om gegevens op te slaan, te sorteren en terug te sturen die ze nodig hebben voor hun toepassingen, zijn er enkele nuances betrokken bij het correct uitlijnen van tabellen om in de loop van de tijd het meeste uit die gegevens te halen. Daarnaast helpt een goed begrip van het relationele model u te begrijpen dat het opdelen van gegevens in afzonderlijke tabellen slechte prestaties veroorzaakt. Er zijn ook databasespecifieke trucs die u kunt leren als onderdeel van het rechtstreeks beheren van deze instanties. Velen weten bijvoorbeeld niet dat MySQL nu wil dat u op elke tabel primaire sleutels heeft, of dat PostgreSQL mogelijk tabellen moet opvullen als kolommen dat doen. passen niet mooi op een grens van acht bytes. 

De toekomst voor databeheer

Data worden steeds belangrijker binnen bedrijven. Het vormt de basis voor een efficiënte dienstverlening aan klanten, maar vormt ook de kern van nieuwe zakelijke diensten of diepgaande analyseprojecten die in nieuwe producten worden gebruikt. Zonder deze gegevens bestaan ​​deze producten – en de inkomsten die ze opleveren – niet of leveren ze niet de waarde waarvoor ze zijn ontworpen.

Tegelijkertijd lekken de vaardigheden op het gebied van datamanagement uit organisaties, worden ze ondergebracht in bredere rollen of worden ze overgedragen aan dienstverleners. Als alles werkt, is dit prima. Maar als er zich een probleem voordoet, heb je die diepgaande kennis nodig om het probleem op te lossen en ervoor te zorgen dat het niet meer gebeurt. Het betekent ook dat u meer kunt uitgeven dan nodig is om de gegevens die u bewaart te onderhouden en er werkzaamheden omheen uit te voeren.

Hoewel de rol van de DBA is overgenomen door nieuwere functies rond DevOps en SRE, zijn de taken die bij die rol horen nog steeds bij ons. Voor SRE- en DevOps-professionals kan het kennen van uw datatheorie het verschil betekenen tussen geld uitgeven aan infrastructuur en besparen op prestaties.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• PlatoData.Network Verticale generatieve AI. Versterk jezelf. Toegang hier.
• PlatoAiStream. Web3-intelligentie. Kennis versterkt. Toegang hier.
• PlatoESG. carbon, CleanTech, Energie, Milieu, Zonne, Afvalbeheer. Toegang hier.
• Plato Gezondheid. Intelligentie op het gebied van biotech en klinische proeven. Toegang hier.
• Bron: https://www.dataversity.net/devops-and-data-lessons-teams-can-learn-about-managing-databases/