Dengang var proprietære databaser de eneste acceptable muligheder.
"Ingen er nogensinde blevet fyret for at købe fra Oracle/Microsoft/IBM" var ordsproget.
Kæmpe, monolitiske databaser, der bruges til hvert enkelt formål. Betalt support - sådan så databaselandskabet ud i 90'erne og begyndelsen af 00'erne. Selvfølgelig var der open source-databaser, men de blev behandlet som en "legetøjsdatabase", der var egnet til en lille hjemmeside, en blog måske eller en meget lille e-butik. Ingen fornuftige ville bruge dem til noget kritisk.
Tingene har ændret sig over tid, og open source-databaser er modnet. Der skabes flere og flere hvert år. Vi ser nu specialisering, der giver brugerne mulighed for at vælge den bedste mulighed for en given arbejdsbyrde - tidsserier, analytiske, columnstore, NoSQL, relationelle, nøgleværdi - du kan vælge de databaser, du har brug for, og som regel er der adskillige muligheder at vælge imellem. Dette fører til, at open source bliver mere og mere populær i databaseverdenen. Virksomheder ser nu på deres regninger fra deres proprietære databaseleverandør og spekulerer på, om de kan reducere det en smule ved at indføre gratis open source-database.
Som sædvanligt er der fordele og ulemper. Hvad er ting, du måske vil overveje, før du implementerer open source-database? I dette blogindlæg vil vi dele nogle tips, du måske vil huske på, når du planlægger at migrere til open source-databaser.
Start lille og udvid
Hvis din organisation ikke bruger open source-databaser, har den højst sandsynligt heller ikke erfaring med at administrere dem. Selvom det kan lade sig gøre gennem eksterne konsulenter, er det sandsynligvis ikke en god idé at migrere hele dit miljø til open source-databaser.
Den bedre tilgang ville i stedet være at starte med små projekter. Måske skal du bygge en slags internt værktøj eller websted, måske en slags overvågningsværktøj - det er en fantastisk mulighed for at bruge open source-databaser og få oplevelsen af at bruge det i virkelige miljøer. Dette giver dig mulighed for at lære ins og outs af en database - hvordan man diagnosticerer den, hvordan man sporer dens ydeevne, hvordan man tuner den for at forbedre dens ydeevne.
Oven i det ville du lære mere om mulighederne for høj tilgængelighed og implementeringer. At arbejde med det hjælper også med at forstå forskellene mellem den proprietære database, du bruger, og de open source-databaser, som du implementerede til mindre projekter. Med tiden skulle du se, at open source-databasefodaftrykket i din organisation er steget markant sammen med dine teams erfaringer.
På et tidspunkt, efter at have indsamlet nok erfaring til at køre open source-databaserne, kan du beslutte at trække i håndtaget og starte et migreringsprojekt. En anden, også ret sandsynlig mulighed, er, at du gradvist vil flytte dine operationer til open source-databaser på projekt-for-projekt-basis. Til sidst vil dine eksisterende applikationer, der bruger proprietære RDBMS, blive forældet og i sidste ende erstattet af ny iteration af softwaren, som er afhængig af open source-databaser.
Vælg den rigtige database til jobbet
Vi har allerede nævnt, at open source-databaser typisk er ret specialiserede. Du kan vælge et datalager, der er egnet til forskellige anvendelser - tidsserier, dokumentlager, nøgleværdilager, kolonnelager, tekstsøgning. Dette, kombineret med det forrige tip, lader dig vælge præcis den type database, som dit lille projekt kræver. Lad os sige, at du vil bygge en overvågningsstak til dit miljø.
Du vil måske kigge ind i tidsseriedatabaser som Prometheus eller TimeScaleDB for at drive din overvågningsapplikation. Måske vil du implementere en form for analytiske/big data-løsninger. Du bliver nødt til at designe en slags ETL-proces for at udtrække dataene fra dit primære RDBMS og indlæse det i en open source-løsning. Der er mange muligheder, der skal bruges som datalager. Afhængigt af kravene og data kan du vælge mellem en bred vifte af databaser, for eksempel Clickhouse, Cassandra, Hive og mange flere.
Hvad med at flytte nogle dele af applikationen fra det proprietære RDBMS til en open source-løsning?
Der er også muligheder for det. Datastores som PostgreSQL eller MariaDB har en masse funktioner relateret til nem migrering fra datastores som Oracle. De kommer med for eksempel understøttelse af PL/SQL og andre SQL-funktioner, der er tilgængelige for Oracle. Dette er en stor hjælp - mindre kode skal konverteres sammen med migreringen fra Oracle til andre databaser, det er mere sandsynligt, at dine lagrede procedurer og funktioner også vil fungere for det meste ud af boksen, og du behøver ikke at bruge en betydelig tid til at omskrive, teste og fejlfinde kode, der repræsenterer en kernelogik i din applikation.
Du bør heller ikke glemme de ressourcer, du allerede har i dit team. Måske nogen har erfaring med mere populære open source datastores? Hvis disse matcher dine krav og passer ind i dit miljø, kan du muligvis bruge eksisterende viden i dit team og let overgang til open source-verdenen.
Overvej at få support
Det er altid vanskeligt at migrere til databutikker, som du ikke har for meget erfaring med. Selvom du fortsætter med små skridt, kan du stadig blive fanget af overraskelsesadfærd, uventede situationer, fejl eller endda bare operationelle situationer, som du ikke er bekendt med.
Open source-databaser har typisk en fantastisk fællesskabsstøtte - e-mail-lister, fora, Slack-kanaler. Normalt, når du spørger, vil nogen forsøge at hjælpe dig. Dette er muligvis ikke nok i nogle tilfælde. Hvis det er tilfældet, bør du kigge efter en betalt support. Der er mange måder, hvorpå dette kan opnås.
For det første er det ikke alle open source-projekter, der er ens. Større projekter som PostgreSQL eller MySQL kan have udviklet et økosystem af konsulentvirksomheder, der hyrer eksperter, der kan udføre rådgivning for dig. Hvis en sådan mulighed, uanset årsagen, ikke er tilgængelig eller gennemførlig, kan du altid kontakte projektvedligeholderne.
Det er meget almindeligt, at virksomheden, der udvikler datalageret, gerne hjælper til en pris.
Uafhængige konsulentvirksomheder har en betydelig fordel - de er uafhængige, og de vil foreslå en løsning baseret på deres erfaring, ikke baseret på det datalager og de værktøjer, de udvikler. Sælgere, ja, de vil normalt presse deres egne løsninger og miljø. På den anden side er leverandører ret interesserede i at øge adoptionen af deres datalager. Hvis du migrerer fra et proprietært datalager, kan de have været i den situation flere gange før, så de burde være i stand til at give dig god praksis, hjælpe dig med at designe migreringsprocessen og så videre. For en uerfaren virksomhed kan adgang til eksperterne inden for migration være et stort aktiv.
Du kan finde adgang til ekstern support nyttig, ikke kun i migreringsfasen. Det er altid vanskeligt at håndtere nye datalager, og det er tidskrævende at lære alle aspekter af operationerne. Selv efter migrering kan du stadig have gavn af at have nogen, du kan ringe til, spørge og, hvad der er vigtigst, lære af. Uddannelser, ekstern DBA, alle disse er almindelige muligheder i verden af open source-databaser, især for de større, mere etablerede projekter.
Find et system eller værktøj til at hjælpe
Open source-databaser leveres med en række forskellige værktøjer, nogle mere eller mindre komplekse. Nogle tilføjer funktionalitet (høj tilgængelighed, sikkerhedskopier, overvågning), nogle er designet til at gøre databasestyringen nemmere.
Det er vigtigt at udnytte dem (rådgivningskontrakter kan være nyttige her for at introducere dig til det vigtigste værktøj til dit valgfrie open source-datalager), da de betydeligt kan øge din driftshastighed og ydeevne og stabilitet af hele opsætningen.
Nogle værktøjer er gratis, nogle kræver en licens for at fungere, du bør kigge ind i poolen og vælge det, der passer dig bedst. Vi taler her om belastningsbalancere, værktøjer til at styre replikeringstopologi, virtuelle IP-administrationsværktøjer, klyngeløsninger, mere eller mindre dedikerede overvågnings- og observerbarhedsplatforme, der kan spore alt fra typiske databasepræstationsmålinger til at give smarte forudsigelser baseret på dataene til specialiserede analyse af forespørgselsydelsen.
Open source-verdenen er, hvor sådanne værktøjer trives - det har også fordele og ulemper. Det er nemt at finde "A"-værktøjet, det er svært at finde "THE"-værktøjet. Du kan finde adskillige projekter på GitHub, alle gør næsten det samme som andre. Hvilken man skal vælge er den svære del. Derfor ville du ideelt set have en hjælpende hånd i enten en supportkontrakt, eller du kan også stole på administrationsplatforme, der hjælper dig med at administrere flere aspekter af operationerne på open source-databaser, herunder hjælpe dig med at standardisere og vælge de korrekte værktøjer til det.
Der er også platforme som ClusterControl, som blev designet til at hjælpe ikke-erfarne mennesker til fuldt ud at forstå kraften i open source-databaser. ClusterControl understøtter flere forskellige typer open source-datalagre:MySQL og dets varianter, PostgreSQL, TimeScaleDB eller MongoDB. Det giver en ensartet brugergrænseflade for at få adgang til administrationsfunktioner for disse datalagre, hvilket gør det nemt at implementere og administrere dem. I stedet for at bruge tid på at teste forskellige værktøjer og løsninger kan du ved hjælp af ClusterControl nemt implementere højt tilgængeligt miljø, planlægge sikkerhedskopier og holde styr på metrics i systemet.
Værktøjer som ClusterControl reducerer belastningen på dit team og øger deres evne til at forstå, hvad der sker i databasen, de ikke er så fortrolige med, som de ville have ønsket.
Tag dig god tid
Det, der er godt at huske på, er, at det ikke er nødvendigt at skynde sig. Stabiliteten af dit miljø og dine brugeres velbefindende er altafgørende. Tag dig tid til at køre testene, bekræft alle aspekter af din ansøgning. Bekræft, at du har korrekte processer med høj tilgængelighed og katastrofegendannelse på plads.
Kun når du er 100 % sikker på, at du er god til at skifte, ville det være tid til at trække i håndtaget og skifte til open source-databaser.