Förr i tiden var proprietära databaser de enda acceptabla alternativen.
"Ingen fick någonsin sparken för att ha köpt från Oracle/Microsoft/IBM" var talesättet.
Enorma, monolitiska databaser som används för varje enskilt syfte. Betald support - det var så databaslandskapet såg ut på 90-talet och början av 00-talet. Visst, databaser med öppen källkod fanns där men de behandlades som en "leksaksdatabas", lämplig för en liten webbplats, en blogg kanske eller en mycket liten e-butik. Ingen vettig skulle använda dem till något kritiskt.
Saker och ting har förändrats över tiden och databaser med öppen källkod har mognat. Fler och fler skapas för varje år. Vi ser nu specialisering, vilket gör det möjligt för användare att välja det bästa alternativet för given arbetsbelastning - tidsserier, analytiska, kolumnbutiker, NoSQL, relationella, nyckel-värde - du kan välja vilka databaser du behöver och vanligtvis finns det många alternativ att välja mellan. Detta leder till att öppen källkod blir mer och mer populär i databasvärlden. Företag tittar nu på sina räkningar från sin egen databasleverantör och undrar om de kan minska det lite genom att använda en gratis databas med öppen källkod.
Som vanligt finns det för- och nackdelar. Vilka är saker du kanske vill överväga innan du implementerar öppen källkodsdatabas? I det här blogginlägget kommer vi att dela med dig av några tips som du kanske vill ha i åtanke när du planerar att migrera till databaser med öppen källkod.
Börja smått och expandera
Om din organisation inte använder databaser med öppen källkod har den troligen inte heller erfarenhet av att hantera dem. Även om det kan göras genom externa konsulter, är det förmodligen inte en bra idé att migrera hela din miljö till databaser med öppen källkod.
Det bättre tillvägagångssättet är istället att börja med små projekt. Kanske behöver du bygga något slags internt verktyg eller webbplats, kanske något slags övervakningsverktyg - det är ett utmärkt tillfälle att använda databaser med öppen källkod och få erfarenhet av att använda det i verkliga miljöer. Detta låter dig lära dig detaljerna i en databas - hur man diagnostiserar den, hur man spårar dess prestanda, hur man ställer in den för att förbättra dess prestanda.
Utöver det skulle du lära dig mer om alternativen för hög tillgänglighet och implementeringar. Att arbeta med det hjälper också att förstå skillnaderna mellan den egenutvecklade databasen som du använder och databaserna med öppen källkod som du implementerat för mindre projekt. Med tiden bör du se att den öppna källkoddatabasens fotavtryck i din organisation ökat avsevärt tillsammans med dina teams erfarenheter.
Vid någon tidpunkt, efter att ha samlat tillräckligt med erfarenhet för att köra databaserna med öppen källkod, kan du bestämma dig för att dra i spaken och starta ett migreringsprojekt. Ett annat, också ganska troligt alternativ, är att du gradvis skulle flytta din verksamhet till databaser med öppen källkod på projekt-för-projekt-basis. Så småningom kommer dina befintliga applikationer som använder proprietära RDBMS att fasas ut och så småningom ersättas av ny iteration av programvaran, som förlitar sig på databaser med öppen källkod.
Välj rätt databas för jobbet
Vi har redan nämnt att databaser med öppen källkod vanligtvis är ganska specialiserade. Du kan välja ett datalager som lämpar sig för olika användningsområden - tidsserier, dokumentlager, nyckel-värdelager, kolumnlager, textsökning. Detta, i kombination med det föregående tipset, låter dig välja exakt den typ av databas som ditt lilla projekt kräver. Låt oss säga att du vill bygga en övervakningsstack för din miljö.
Du kanske vill titta i tidsseriedatabaser som Prometheus eller TimeScaleDB för att driva din övervakningsapplikation. Kanske vill du implementera någon form av analytiska/big data-lösningar. Du skulle behöva designa någon form av en ETL-process för att extrahera data från din huvudsakliga RDBMS och ladda den i en öppen källkodslösning. Det finns många alternativ som kan användas som datalager. Beroende på krav och data kan du välja från en mängd olika databaser, till exempel Clickhouse, Cassandra, Hive och många fler.
Vad sägs om att flytta vissa delar av programmet från det proprietära RDBMS till en lösning med öppen källkod?
Det finns alternativ för det också. Databutiker som PostgreSQL eller MariaDB har en hel del funktioner relaterade till enkel migrering från databutiker som Oracle. De kommer med till exempel stöd för PL/SQL och andra SQL-funktioner tillgängliga för Oracle. Detta är en stor hjälp - mindre kod behöver konverteras tillsammans med migreringen från Oracle till andra databaser, det är mer troligt att dina lagrade procedurer och funktioner också kommer att fungera mestadels direkt och du behöver inte spendera en betydande tid för att skriva om, testa och felsöka kod som representerar en central logik i din applikation.
Du bör inte heller glömma de resurser du redan har i ditt team. Kanske har någon erfarenhet av mer populära databutiker med öppen källkod? Om de matchar dina krav och passar in i din miljö kanske du kan använda befintlig kunskap i ditt team och enkelt gå över till världen med öppen källkod.
Överväg att skaffa support
Att migrera till databutiker som du inte har för mycket erfarenhet av är alltid svårt. Även om du fortsätter med små steg kan du fortfarande fångas av överraskningsbeteende, oväntad situation, buggar eller till och med bara driftssituationer som du inte är bekant med.
Databaser med öppen källkod har vanligtvis ett bra communitystöd - e-postlistor, forum, Slack-kanaler. Vanligtvis, när du frågar, kommer någon att försöka hjälpa dig. Detta kanske inte räcker i vissa fall. Om så är fallet bör du leta efter en betald support. Det finns många sätt hur detta kan uppnås.
För det första görs inte alla projekt med öppen källkod lika. Större projekt, som PostgreSQL eller MySQL kan ha utvecklat ett ekosystem av konsultföretag som anställer experter som kan utföra konsulttjänster åt dig. Om ett sådant alternativ, av någon anledning, inte är tillgängligt eller genomförbart, kan du alltid kontakta projektunderhållarna.
Det är mycket vanligt att företaget, som utvecklar datalagret, gärna hjälper till för ett pris.
Oberoende konsultföretag har en betydande fördel - de är oberoende och de kommer att föreslå en lösning baserat på sin erfarenhet, inte baserat på datalagringen och verktygen de utvecklar. Försäljare, ja, de kommer vanligtvis att driva sina egna lösningar och miljö. Å andra sidan är leverantörer ganska intresserade av att öka användningen av deras datalager. Om du migrerar från en proprietär databutik kan de ha varit i den situationen flera gånger tidigare, så de borde kunna ge dig god praxis, hjälpa dig att utforma migreringsprocessen och så vidare. För ett oerfaret företag kan tillgång till experter inom migrationsområdet vara en stor tillgång.
Du kan tycka att tillgång till extern support är användbar inte bara under migreringsfasen. Att hantera en ny databutik är alltid svårt och att lära sig alla aspekter av verksamheten är tidskrävande. Även efter migreringen kan du fortfarande ha nytta av att ha någon du kan ringa, fråga och, vad som är viktigast, lära dig av. Utbildningar, fjärr-DBA, allt detta är vanliga alternativ i världen av databaser med öppen källkod, särskilt för de större, mer etablerade projekten.
Hitta ett system eller verktyg för att hjälpa
Databaser med öppen källkod kommer med en mängd olika verktyg, några mer eller mindre komplexa. Vissa lägger till funktionalitet (hög tillgänglighet, säkerhetskopiering, övervakning), vissa är designade för att göra databashanteringen enklare.
Det är viktigt att utnyttja dem (konsultkontrakt kan vara användbara här för att introducera dig till de viktigaste verktygen för den öppna källkodsdatalagringen du väljer) eftersom de avsevärt kan öka din driftshastighet och prestanda och stabiliteten för hela installationen.
Vissa verktyg är gratis, vissa kräver licens för att fungera, du bör titta in i poolen och välja det som passar dig bäst. Vi pratar här om lastbalanserare, verktyg för att hantera replikeringstopologi, virtuella IP-hanteringsverktyg, klustringslösningar, mer eller mindre dedikerade övervaknings- och observerbarhetsplattformar som kan spåra allt från typiska databasprestandamått till att ge smarta förutsägelser baserade på data till specialiserade analys av frågeprestanda.
Världen med öppen källkod är där sådana verktyg frodas - det har också för- och nackdelar. Det är lätt att hitta "A"-verktyget, det är svårt att hitta "THE"-verktyget. Du kan hitta många projekt på GitHub, alla gör nästan samma sak som andra. Vilken man ska välja är den svåra delen. Det är därför du helst skulle ha en hjälpande hand i antingen ett supportkontrakt eller så kan du också lita på hanteringsplattformar som hjälper dig att hantera flera aspekter av verksamheten på databaser med öppen källkod, inklusive att hjälpa dig att standardisera och välja rätt verktyg för det.
Det finns också plattformar som ClusterControl, som designades för att hjälpa icke-erfarna personer att till fullo förstå kraften i databaser med öppen källkod. ClusterControl stöder flera olika typer av databutiker med öppen källkod:MySQL och dess smaker, PostgreSQL, TimeScaleDB eller MongoDB. Det ger ett enhetligt användargränssnitt för åtkomst till hanteringsfunktioner för dessa databutiker, vilket gör det enkelt att distribuera och hantera dem. Istället för att spendera tid på att testa olika verktyg och lösningar kan du med ClusterControl enkelt distribuera högtillgänglig miljö, schemalägga säkerhetskopieringar och hålla reda på mätvärden i systemet.
Verktyg som ClusterControl minskar belastningen på ditt team, vilket ökar deras förmåga att förstå vad som händer i databasen de inte är så bekanta med som de skulle ha velat.
Ta på dig
Vad som är bra att tänka på är att det inte finns någon anledning att brådska. Stabiliteten i din miljö och dina användares välbefinnande är av största vikt. Ta dig tid att köra testerna, verifiera alla aspekter av din ansökan. Kontrollera att du har korrekta processer för hög tillgänglighet och katastrofåterställning på plats.
Först när du är 100 % säker på att du är bra att byta, är det dags att dra i spaken och byta till databaser med öppen källkod.