Det nya sättet att hantera databaser med öppen källkod

För inte så länge sedan bestod databasbranschen av en handfull leverantörer. Databaser var huvudsakligen relationella och kördes på enstaka maskiner. Hög tillgänglighet implementerades via aktiva standby-kluster. Med en vertikal "uppskalningsmodell" handlade det mest om delad lagring (SAN eller DRBD) eller asynkron replikering av loggar för att synkronisera tillstånd till en standbynod. 2001, när jag började arbeta med NDB Cluster (det som senare skulle bli MySQL Cluster), var konceptet att hålla en hel databas i huvudminnet konstigt - "tänk om du stänger av servern?". Att distribuera en databas över flera servrar var oroande - "du har bitar av data här och där". Och hela idén med en öppen källkodsdatabas för verksamhetskritiska arbetsbelastningar var skrattretande.

Snabbspola framåt 15 år och vi har nu dussintals databasleverantörer på marknaden - mestadels öppen källkod, olika modeller (nyckelvärde, dokument, graf, ...) och distribuerade som standard. Minnesresidenta data är i stort sett normen för att uppnå hög prestanda och låg latens. Tre av de 5 mest populära databaserna (enligt db-motorernas rankning) är öppen källkod (MySQL, PostgreSQL och MongoDB). Nuförtiden är det mer sannolikt att du hanterar en flotta av databasservrar fördelade över olika datacenter. Du kanske till och med har några av dina databaser som hanteras av en tredje parts molnleverantör.

Så, hur är det att hantera databaser under 2018?

AUTOMATION

Med så många uppgifter att hantera och bara så många timmar på en dag, skulle man vara galen om man gör saker manuellt.

Automatisering är ett bra sätt att få saker gjorda. När vi hade få databaser att hantera, skulle driften av databasen vara väldigt praktisk, med vissa uppgifter skriptade i något som bash eller perl - t.ex. ett skript för att säkerhetskopiera databasen, ett annat för att flytta säkerhetskopior till någon plats. Failover skulle vara manuellt, och vi skulle till och med diskutera om det skulle vara automatiserat eller inte.

Nuförtiden är automatisering en no-brainer. Det finns ett antal IT-automatiserings- eller konfigurationshanteringssystem som kan utnyttjas - Puppet, Chef, Ansible och Salt erbjuder alla ramverk för allmänna ändamål som kan användas för att bygga automatisering för olika databastopologier. Programvara för klusterhantering som är skriven speciellt för att hantera databasinställningar inkluderar MongoDB Ops Manager och ClusterControl. De gör det möjligt för operationsteamen att hantera sina kluster med något som är lättillgängligt från hyllan. Att bygga ett klusterhanteringssystem från grunden med ett konfigurationshanteringssystem är ingen liten bedrift. Det kräver betydande expertis inom automationsverktyget samt förståelse för hanteringsoperationer som schemaläggning och verifiering av säkerhetskopiering, automatisk failover med efterföljande omkonfigurering av system, utrullning av konfigurationsändringar, patchning, versionsuppgradering eller nedgradering, etc.

Och naturligtvis finns det uppkomsten av DBaaS-tjänstplattformar, där driftsättning, hälsa, failover, säkerhetskopior, etc., allt styrs av programvara. Molnleverantörer är verkligen mycket bra på automatisering. Amazon RDS är ett utmärkt exempel på databasautomatisering i stor skala - den automatiserar distribution, patchuppgraderingar, säkerhetskopieringar, punktåterställning, skalning av repliker och hög tillgänglighet/failover.

Husdjur kontra Nötkreatur

På 90-talet och fram till dotcom-boomen och busten gjorde Sun Microsystems och Oracle en förmögenhet på att sälja uppskalningsdatabaser på stor SMTP-hårdvara. Kasta in lite SAN-lagring och Veritas failover-mjukvara och du skulle ha fått ett toppmodernt failover-kluster med aktivt standby-läge för hög tillgänglighet. Databasservrarna var relativt få till antalet, men kraftfulla eftersom de skulle växa vertikalt. De fick namn (precis som du namnger dina husdjur!) och togs om hand av DBA:er.

Numera är databaser billiga och fungerar bra på råvaruhårdvara. Det finns många av dem, och vi ger dem siffror - precis som boskap. Om en går sönder kan vi bara skaffa en ny.

Det är också en ny nötkreatursras - nötkreatur med öppen källkod! Tre av de fem bästa databaserna, enligt db-motorer, är alla öppen källkod - de äter sakta men säkert in på marknadsandelen för de två egenutvecklade leverantörerna. Öppen källkod är den nya datacenterstandarden, inte bara för operativsystem utan även för databaser.

Så vad betyder detta för dig? Tja, i framtiden är det mer sannolikt att du kommer att hantera en databas med öppen källkod - eller till och med flera sådana för applikationer som använder heterogena datainsamlingar. I en värld av polyglot-beständighet och mikrotjänster, dikteras nu den underliggande datalagringen av datas natur. Ur en arkitektonisk synvinkel ger enstaka instansdatabaser med diskbaserad HA plats för kluster som potentiellt är distribuerade över flera datacenter.

Behöver vi en DBA?

DBA-rollen är specialiserad - det krävs flera års erfarenhet för att bli det. Tidigare, när det bara fanns ett par egenutvecklade databasleverantörer att välja mellan, skulle du ha specialiserade DBA:er med en specifik uppsättning kunskaper och erfarenheter. Det krävdes också - databaser som Oracle eller SQL Server har enorma funktionsuppsättningar, byggda under decennier. De är inte lätta att hantera. De distribuerades vanligtvis som den enda databasen för en applikation och behövde övervakas, säkerhetskopieras data och alla problem som uppstod måste hanteras. Dessa uppgifter var precis vad DBA:erna var här för att fokusera på.

Under det senaste decenniet har dock en helt ny databasindustri uppstått - med dussintals och dussintals databaser med öppen källkod, såväl som molndatabastjänster. Som vi såg tidigare är det inte ovanligt att en applikation använder ett par olika databutiker. Men företag har sällan en DBA för dessa databutiker de använder. Var hittar du en MongoDB eller Cassandra eller DBA med 5+ års produktionserfarenhet? Man kan hävda att den nya generationen av NoSQL-databaser är mycket enklare än sina föregångare med stängd källkod och därför inte skulle ha samma inlärningskurva.

Att hantera dem skulle bara vara ytterligare en uppgift som läggs till i att göra-listan för SysAdmin- eller DevOps- eller Site Reliability Engineering (SRE)-teamet. Och vi ser idag att många företag inte har heltids-DBA. Ansvaret fördelas istället över teamen, där automatiseringsverktyg i allt högre grad används för att ta hand om de dagliga rutinerna. För databaser som har flyttat till molnet, outsourcas de operativa aspekterna av hur data lagras helt till molnleverantören. Så istället för att arbeta med hur man lagrar data kan operationsteamet nu fokusera på användningen av data.

Databaslivscykel

Den genomsnittliga livscykeln för en databas brukade vara mycket längre än vad de är idag. När du väl valde en databasplattform var det det. Beslutet skulle fattas mellan två eller tre relationsdatabaser, vanligtvis av DBA eller någon högre upp i organisationen. Företaget skulle hitta pengar för att köpa eviga licenser. När beslutet väl togs fick du nu leva med det i över 10 år. Databaser var monolitiska och applikationer skulle vanligtvis använda en enda delad databas.

Idag, i en värld av containrar, moln, mikrotjänster och CI/CD-pipelines, är det inte ovanligt att utvecklare gör de tekniska valen - speciellt om det är en databas med öppen källkod som enkelt kan laddas ner eller erbjudas som en tjänst, utan att behöva prata med en säljare, eller att behöva söka budget från ledningen. Organisationer utmanas att skapa värde snabbare, så förändringstakten för infrastrukturen/applikationerna har ökat dramatiskt. Monolitiska databaser är nu uppdelade i flera små databaser, där varje databas hanterar domändata för en individuell mikrotjänst. Med den mängd olika databasprodukter som finns tillgängliga idag i ekosystemet med öppen källkod, har teamen valet och friheten att flytta till en bättre databutik. När tjänsterna tas i drift och avvecklas följer också databaser med - även om själva data kan arkiveras eller flyttas till en datasjö. I ett infrastrukturlandskap som är mycket mer dynamiskt idag, finner vi att våra databaser lever kortare liv.

DBA-ROLL

DBA, traditionellt både väktare och portvakt för databasen, skulle betjäna databasbehoven hos olika applikations-/infrastrukturteam i organisationen. Alla ändringar som krävde åtkomst eller ändringar i databasen skulle kräva DBA:s tjänster. Men motstridiga prioriteringar och brist på DBA-tillgänglighet kan innebära att projektet skulle blockeras/försenas, och oundviklig friktion skulle följa.

Höga kostnader för samarbete och snabb innovation/kort tid till marknad går inte bra ihop. Som vi såg tidigare är mikrotjänster ett exempel på hur infrastruktur och applikationstjänster nu är uppbyggda för att frikoppla så mycket som möjligt. Databaser automatiseras alltmer och kontrollen över databasen övergår till utvecklare eller projektteam. Även saker som schemaändringar är inte så tunga som de brukade vara. De var mycket svårare i samband med en central databas för en monolitisk applikation. Med data som delas mellan olika komponenter skulle schemaändringar behöva samordnas och noggrant planeras - vanligtvis månader i förväg. DBA:er hade en nyckelroll i att förstå och genomföra förändringar. Dynamiken är annorlunda idag, där förändringstakten är mycket snabbare. Det är inte ovanligt att utvecklingsteam driver kodändringar i produktionen varje vecka eller dagligen - eller till och med flera gånger om dagen! Databaser behöver ständiga uppdateringar för att hålla jämna steg med applikationsändringar, och dessa utförs av utvecklare. Några av de nyare databaserna som MongoDB gör det till och med väldigt enkelt genom att ha en schemalös modell. Vad det i praktiken betyder är att databasschemat flyttar in i applikationskoden.

Så om alla vanliga kärnuppgifter automatiseras bort, vad kommer att hända med DBA-rollen i framtiden? Istället för att fokusera på administrativa uppgifter kommer DBA att fungera mer som en mentor för andra team i organisationen. Organisationer måste förstå vilken data de har och hur den kan användas. När allt kommer omkring är data mest värdefull när den delas och kombineras med andra resurser, inte bara lagras. Schemaless låter bra, men vi behöver fortfarande hålla reda på vår data – antingen i databasen eller i koden. Säkerhet är en utmaning, och dataintrång blir bara värre. Så om vi ska göra data bra igen, måste DBA övergå till en horisontell rådgivare/enabler-roll som sträcker sig över team. Ur ett kompetensperspektiv behöver den moderna DBA förstå hur man designar distribuerade högtillgänglighetssystem och sätter på plats effektiva automationssystem för att ta hand om de vardagliga uppgifterna. När företag distribuerar infrastruktur i moln- eller till och med containermiljöer, kommer förståelse för hur man bygger högt tillgängliga och skalbara databaser på dessa plattformar att säkerställa DBA:s överlevnad.

Sammanfattning

Vi sitter vid en fascinerande knutpunkt i databasindustrins historia, som har genomgått en massiv omvandling under de senaste två decennierna. Tabellen nedan försöker sammanfatta det.

Jag skulle vara intresserad av att höra dina tankar om databashantering med öppen källkod och om du har sett samma trender? Hur har dina kamper eller framgångar sett ut med OSDB under de senaste åren? Och vad förväntar du dig att hända nästa år?

Vi på Severalnines kommer naturligtvis att fortsätta att kämpa på för att hjälpa till att underlätta hanteringen och automatiseringen av dina databaser med öppen källkod under nästa år och framåt. Så håll utkik efter uppdateringar om det från och med nästa januari.

Men under tiden, låt mig veta dina tankar, så ses vi 2019!

Foton av SoRad (Shutterstock) &The Simpsons; andra foton är av deras respektive ägare.