Databaseopdateringer kommer med forbedrede funktioner til ydeevne, sikkerhed og med nye integrerede funktioner. Det er altid tilrådeligt at teste en ny version, før den implementeres i produktion, blot for at sikre, at den passer til dine behov, og der ikke er mulighed for nedbrud.
I betragtning af mange produkter har de, der går forud for de første mindre versioner af en ny større version, de vigtigste rettelser. For eksempel ville jeg foretrække at have MongoDB version 4.2.1 i produktion et par dage efter udgivelsen, end jeg ville have til version 4.2.0.
I denne blog skal vi diskutere, hvad der er inkluderet, og hvilke forbedringer der er foretaget til MongoDB version 4.2
Hvad er nyt i MongoDB 4.2
- Distribuerede transaktioner
- Jokertegnindekser
- Gentagelig læsning og skrivning
- Automatisk kryptering på feltniveau på klientsiden.
- Forbedret forespørgselssprog til udtryksfulde opdateringer
- On-demand materialiserede visninger
- Moderne vedligeholdelsesoperationer
Distribuerede transaktioner
Transaktioner er vigtige databasefunktioner, der sikrer datakonsistens og integritet, især dem, der garanterer ACID-procedurerne. MongoDB version 4.2 understøtter nu multidokumenttransaktioner på replikasæt og en splittet klynge gennem den distribuerede transaktionstilgang. Den samme syntaks for brug af transaktioner er blevet bibeholdt som den tidligere version 4.0.
Men klientdriverspecifikationerne har ændret sig en smule. Hvis man har til hensigt at bruge transaktioner i MongoDB 4.2, skal du opgradere driverne til versioner, der er kompatible med 4.2-servere.
Denne version begrænser ikke størrelsen af en transaktion med hensyn til hukommelsesforbrug, men afhænger kun af størrelsen på din hardware og hardwarehåndteringskapaciteten.
Omfordeling af global klynge-lokalitet er nu mulig med version 4.2. Det vil sige, for en implementering af geozone-sharding, hvis en bruger, der bor i region A, flytter til region B, ved at ændre værdien af deres placeringsfelt, kan dataene automatisk flyttes fra region A til B gennem en transaktion.
Sharding-systemet tillader nu at ændre en shard-nøgle i modsætning til den tidligere version. Bogstaveligt talt, når en shard-nøgle ændres, svarer det til at flytte dokumentet til et andet shard. I denne version ombryder MongoDB denne opdatering, og hvis dokumentet skal flyttes fra et shard til et andet, vil opdateringen blive udført i en transaktion i baggrunden.
At bruge transaktioner er ikke en tilrådelig tilgang, da de forringer databasens ydeevne, især hvis de forekommer flere gange. I en transaktionsperiode er der et udvidet vindue for handlinger, der kan forårsage konflikter, når der skrives til et dokument, der er påvirket. Så meget som en transaktion kan prøves igen, kan der være foretaget en opdatering af dokumentet før dette genforsøg, og når som helst genforsøget sker, kan det handle om den gamle snarere end den seneste dokumentversion. Genforsøg medfører naturligvis flere behandlingsomkostninger udover at øge applikationens nedetid gennem voksende latens.
En god praksis omkring brug af transaktioner omfatter:
- Undgå at bruge uindekserede forespørgsler inde i en transaktion for at sikre, at operationen ikke er langsom.
- Din transaktion skal omfatte nogle få dokumenter.
Med MongoDB dynamiske skemaformat og indlejringsfunktion kan du vælge at lægge alle felter i samme samling for at undgå behovet for at bruge transaktion som en første foranstaltning.
Jokertegnindekser
Jokertegnindekser blev introduceret i MongoDB version 4.2 for at forbedre forespørgsler mod vilkårlige felter eller felter, hvis navne ikke kendes på forhånd, ved at indeksere hele dokumentet eller underdokumentet. De er ikke beregnet til at erstatte de arbejdsbelastningsbaserede indekser men passer til at arbejde med data, der involverer polymorfe mønstre. Et polymorfisk mønster er, hvor alle dokumenter i en samling ligner hinanden, men ikke har en identisk struktur. Polymorfe datamønstre kan genereres fra applikationer, produktkataloger eller sociale data. Nedenfor er et eksempel på polymorfe indsamlingsdata
{
Sport: ‘Chess’,
playerName: ‘John Mah’,
Career_earning: {amount: NumberDecimal(“3000”), currency: “EUR”},
gamesPlayed:25,
career_titles:10
},
{
Sport: Tennis,
playerName: ‘Semenya Jones,
Career_earning: {amount: NumberDecimal(“34545”), currency: “USD”},
Event: {
name:”Olympics”,
career_titles:10,
career_tournaments:14
}Ved at indeksere hele dokumentet ved hjælp af jokertegnsindekser kan du lave en forespørgsel ved at bruge et hvilket som helst vilkårligt felt som indeks.
For at oprette et jokertegn
$db.collection.createIndex({“fieldA.$**”: 1})Hvis det valgte felt er et indlejret dokument eller en matrix, gentages jokertegnindekset i dokumentet og gemmer værdien for alle felterne i dokumentet eller matrixen.
Læser og skrives igen
Normalt kan en database pådrage sig nogle hyppige midlertidige netværksafbrydelser, der kan resultere i, at en forespørgsel helt eller delvist ikke udføres. Disse netværksfejl er muligvis ikke så alvorlige og giver derfor en chance for at prøve disse forespørgsler igen, når de er tilsluttet igen. Fra og med MongoDB 4.2 er genforsøgskonfigurationen aktiveret som standard. MongoDB-driverne kan igen prøve mislykkede læsninger og skrivninger for visse transaktioner, når de støder på mindre netværksfejl, eller rettere, når de ikke er i stand til at finde nogle sunde primære i det shardede klynge/replikasæt. Men hvis du ikke ønsker at skrive igen, kan du udtrykkeligt deaktivere dem i dine konfigurationer, men jeg finder ikke en overbevisende grund til, hvorfor man bør deaktivere dem.
Denne funktion er for at sikre, at applikationskoden under alle omstændigheder ikke bliver påvirket af MongoDB-infrastrukturen. Med hensyn til et eksempel forklaret af Eliot Horowitz, medstifter af MongoDB, for en webside, der udfører 20 forskellige databaseoperationer, i stedet for at genindlæse det hele eller at skulle pakke hele websiden ind i en slags loop, driveren under dynen kan bare beslutte at prøve operationen igen. Når en skrivning mislykkes, vil den automatisk prøve igen og vil have en kontrakt med serveren for at garantere, at hver skrivning kun sker én gang.
Den genprøvelige skrivning gør kun et enkelt genforsøg, hvilket hjælper med at løse replikasætvalg og forbigående netværksfejl, men ikke for vedvarende netværksfejl.
Gentagelig skrivning adresserer ikke tilfælde, hvor failover-perioden overstiger serverSelectionTimoutMs værdi i parameterkonfigurationerne.
Med denne MongoDB-version kan man opdatere dokumentshard-nøgleværdier (undtagen hvis shardkey er det uforanderlige _id-felt) ved at udstede et enkelt dokument findAndModify/update-operationer enten i en transaktion eller som en genforsøgsskrivning .
MongoDB version 4.2 kan nu prøve en enkelt dokument-upsert-operation (dvs. upsert:true og multi:false), som kan have mislykkedes på grund af duplikatnøglefejl, hvis operationen opfylder disse nøglebetingelser:
- Målsamling indeholder et unikt indeks, der lavede en dubletnøglefejl.
- Opdateringsoperationen vil ikke ændre nogen af felterne i forespørgselsprædikatet.
- Opdateringsmatchbetingelsen er enten et enkelt lighedsprædikat {field:"value"} eller et logisk AND af lighedsprædikater {filed:"value", field0:"value0"}
- Sættet af felter i det unikke indeksnøglemønster matcher sættet af felter i opdateringsforespørgselsprædikatet.
Automatisk kryptering på feltniveau på klientsiden
MongoDB version 4.2 kommer med Automatic Client-Side Field Level-kryptering (CSFLE), en funktion, der gør det muligt for udviklere selektivt at kryptere individuelle felter i et dokument på klientsiden, før det sendes til serveren. De krypterede data holdes således private fra udbyderne, der hoster databasen, og enhver bruger, der måtte have direkte adgang til databasen.
Kun applikationer med adgang til de korrekte krypteringsnøgler kan dekryptere og læse de beskyttede data. I tilfælde af at krypteringsnøglen slettes, vil alle data, der blev krypteret, blive gjort ulæselige.
Bemærk:denne funktion er kun tilgængelig med MongoDB enterprise.
Forbedret forespørgselssprog til udtryksfulde opdateringer
MongoDB version 4.2 giver et rigere forespørgselssprog end sine forgængere. Det understøtter nu aggregeringer og moderne use-case operationer på linje med geo-baserede søgninger, grafsøgning og tekstsøgning. Den har integreret en tredjeparts søgemaskine, som gør søgninger hurtigere i betragtning af, at søgemaskinen kører på en anden proces/server. Dette forbedrer generelt databasens ydeevne i modsætning til, hvis alle søgninger blev foretaget til mongod-processen, som hellere ville gøre databaseoperationens latenstid flygtig, når søgemaskinen genindekserer.
Med denne version kan du nu håndtere arrays, lave summer og andre matematiske operationer direkte gennem en opdateringssætning.
On-Demand Materialized Views
Rammeværket for dataaggregering i MongoDB er en fantastisk funktion med forskellige stadier af transformation af et dokument til en ønsket tilstand. MongoDB version 4.2 introducerer en ny fase $merge, som for mig vil jeg sige, at det sparede mig noget tid på at arbejde med det endelige output, der skulle gemmes i en samling. I starten tillader $out-stadiet oprettelse af en ny samling baseret på aggregering og udfylder samlingen med de opnåede resultater. Hvis samlingen allerede eksisterer, vil den overskrive samlingen med de nye resultater i modsætning til $merge-stadiet, som kun inkorporerer pipeline-resultaterne i et eksisterende output i stedet for fuldt ud at erstatte samlingen. At regenerere en hel samling hver gang med $out-stadiet bruger en masse CPU og IO, hvilket kan forringe databasens ydeevne. Outputindholdet vil derfor blive opdateret rettidigt, hvilket gør det muligt for brugere at oprette materialiserede visninger efter behov
Moderne vedligeholdelsesoperationer
Udviklere kan nu få en fantastisk operationel oplevelse med MongoDB version 4.2 med integrerede funktioner, der forbedrer høj tilgængelighed, cloud-administreret backupstrategi, forbedrer overvågningskraften og alarmsystemer. MongoDB Atlas og MongoDB Ops Manager er de leverede platforme til disse funktioner. Sidstnævnte er blevet betegnet som den bedste til at køre MongoDB på virksomheden. Det er også blevet integreret med Kubernetes-operatøren for on-premise-brugere, der flytter til privat sky. Denne grænseflade gør det muligt for en direkte at styre Ops Manager.
Der er nogle interne ændringer foretaget i MongoDB version 4.2, som omfatter:
- Visning af åbne markører.
- Fjernelse af MMAPv1-lagermotoren.
- Forbedring af WiredTiger-datafilreparationen.
- Diagnostiske felter kan nu have queryHash
- Auto-opdelingstråd for mongos-noder er blevet fjernet.
Konklusion
MongoDB version 4.2 kommer med nogle forbedringer i retning af sikkerhed og databaseydeevne. Den har inkluderet en automatisk klient-side feltniveaukryptering, der sikrer, at data er beskyttet fra klientvinklen. Flere funktioner som en tredjepartssøgemaskine og inklusion af $merge-stadiet i aggregeringsrammen giver en vis forbedring af databasens ydeevne. Før du sætter denne version i produktion, skal du sikre dig, at alle dine behov er fuldt ud imødekommet.