Databasuppdateringar kommer med förbättrade funktioner för prestanda, säkerhet och med nya integrerade funktioner. Det är alltid tillrådligt att testa en ny version innan den sätts i produktion, bara för att säkerställa att den passar dina behov och att det inte finns någon risk för krascher.
Med tanke på många produkter har de som föregår de första mindre versionerna av en ny större version de viktigaste korrigeringarna. Till exempel skulle jag föredra att ha MongoDB version 4.2.1 i produktion några dagar efter release än vad jag skulle göra för version 4.2.0.
I den här bloggen kommer vi att diskutera vad som har inkluderats och vilka förbättringar som har gjorts av MongoDB version 4.2
Vad är nytt i MongoDB 4.2
- Distribuerade transaktioner
- Jokerteckenindex
- Läs och skriv igen
- Automatisk kryptering på klientsidan på fältnivå.
- Förbättrat frågespråk för uttrycksfulla uppdateringar
- On-demand materialiserade vyer
- Modern underhållsverksamhet
Distribuerade transaktioner
Transaktioner är viktiga databasfunktioner som säkerställer datakonsistens och integritet, särskilt de som garanterar ACID-procedurerna. MongoDB version 4.2 stöder nu transaktioner med flera dokument på replikuppsättningar och ett delat kluster genom den distribuerade transaktionsmetoden. Samma syntax för att använda transaktioner har bibehållits som den tidigare versionen 4.0.
Men klientens drivrutinsspecifikationer har ändrats lite. Om man tänker använda transaktioner i MongoDB 4.2 måste du uppgradera drivrutinerna till versioner som är kompatibla med 4.2-servrar.
Denna version begränsar inte storleken på en transaktion när det gäller minnesanvändning utan beror bara på storleken på din hårdvara och maskinvaruhanteringskapaciteten.
Omtilldelning av globalt klusterspråk är nu möjligt med version 4.2. Det vill säga, för en implementering av geografisk zondelning, om en användare som bor i region A flyttar till region B, genom att ändra värdet på sitt platsfält, kan data automatiskt flyttas från region A till B genom en transaktion.
Sharding-systemet tillåter nu att man ändrar en shard-nyckel i motsats till den tidigare versionen. Bokstavligen, när en shard-nyckel ändras, motsvarar det att flytta dokumentet till en annan shard. I den här versionen omsluter MongoDB denna uppdatering och om dokumentet behöver flyttas från en skärva till en annan kommer uppdateringen att utföras i en transaktion på ett bakgrundssätt.
Att använda transaktioner är inte ett tillrådligt tillvägagångssätt eftersom de försämrar databasprestanda, särskilt om de inträffar flera gånger. Under en transaktionsperiod finns det ett utdraget fönster för operationer som kan orsaka konflikter när du skriver till ett dokument som påverkas. Så mycket som en transaktion kan prövas på nytt, kan det göras en uppdatering av dokumentet innan det här försöket igen, och närhelst ett nytt försök sker, kan det hantera den gamla snarare än den senaste dokumentversionen. Omförsök utövar uppenbarligen högre bearbetningskostnader förutom att öka applikationens stilleståndstid genom växande latens.
En bra praxis för att använda transaktioner inkluderar:
- Undvik att använda oindexerade frågor i en transaktion för att säkerställa att opet inte blir långsamt.
- Din transaktion bör omfatta några dokument.
Med MongoDB dynamiska schemaformat och inbäddningsfunktion kan du välja att lägga alla fält i samma samling för att undvika behovet av att använda transaktionen som en första åtgärd.
Jokerteckenindex
Jokerteckenindex introducerades i MongoDB version 4.2 för att förbättra frågor mot godtyckliga fält eller fält vars namn inte är kända i förväg, genom att indexera hela dokumentet eller underdokumentet. De är inte avsedda att ersätta de arbetsbelastningsbaserade indexen men passar att arbeta med data som involverar polymorfa mönster. Ett polymorft mönster är när alla dokument i en samling är lika men inte har en identisk struktur. Polymorfa datamönster kan genereras från tillämpningar, produktkataloger eller sociala data. Nedan är ett exempel på polymorfa insamlingsdata
{
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
}Genom att indexera hela dokumentet med jokerteckenindex kan du göra en fråga med vilket godtyckligt fält som helst som index.
För att skapa ett jokerteckenindex
$db.collection.createIndex({“fieldA.$**”: 1})Om det valda fältet är ett kapslat dokument eller en matris återkommer jokerteckenindexet i dokumentet och lagrar värdet för alla fält i dokumentet eller matrisen.
Läs och skriv igen
Normalt kan en databas drabbas av några frekventa övergående nätverksavbrott som kan leda till att en fråga helt eller delvis inte körs. Dessa nätverksfel kanske inte är så allvarliga och erbjuder därför en chans att göra ett nytt försök med dessa frågor när de är återanslutna. Från och med MongoDB 4.2 är konfigurationen för försök igen aktiverad som standard. MongoDB-drivrutinerna kan försöka igen misslyckade läsningar och skrivningar för vissa transaktioner när de stöter på mindre nätverksfel eller snarare när de inte kan hitta någon frisk primär i den sönderdelade klustret/replikuppsättningen. Men om du inte vill att skrivningar som går att göra om kan du uttryckligen inaktivera dem i dina konfigurationer, men jag hittar ingen övertygande anledning till att man ska inaktivera dem.
Denna funktion är till för att säkerställa att applikationskoden i alla fall inte påverkas av MongoDB-infrastrukturen. Angående ett exempel förklarat av Eliot Horowitz, medgrundare av MongoDB, för en webbsida som gör 20 olika databasoperationer, istället för att ladda om hela grejen eller behöva slå in hela webbsidan i någon form av loop, drivrutinen under täcket kan bara bestämma sig för att försöka igen. Närhelst en skrivning misslyckas kommer den att försöka igen automatiskt och kommer att ha ett kontrakt med servern för att garantera att varje skrivning bara sker en gång.
Den omförsökbara skrivningen gör bara ett enda försök igen, vilket hjälper till att åtgärda replikuppsättningar och övergående nätverksfel, men inte för ihållande nätverksfel.
Återförsökbara skrivningar adresserar inte tillfällen där failover-perioden överskrider serverSelectionTimoutMs värde i parameterkonfigurationerna.
Med denna MongoDB-version kan man uppdatera dokumentshardnyckelvärden (förutom om shardkey är det oföränderliga _id-fältet) genom att utfärda ett enda dokument findAndModify/update-operationer antingen i en transaktion eller som en skrivning som går att försöka igen .
MongoDB version 4.2 kan nu försöka igen en uppskärningsoperation för ett dokument (dvs. upsert:true och multi:false) som kan ha misslyckats på grund av dubblettnyckelfel om operationen uppfyller dessa nyckelvillkor:
- Målsamlingen innehåller ett unikt index som orsakade dubblettnyckelfelet.
- Uppdateringsoperationen kommer inte att ändra något av fälten i frågepredikatet.
- Uppdateringsmatchningsvillkoret är antingen ett enda likhetspredikat {field:“value”} eller ett logiskt AND av likhetspredikat {filed:“value”, field0:“value0”}
- Set med fält i det unika indexnyckelmönstret matchar uppsättningen av fält i uppdateringsfrågepredikatet.
Automatisk kryptering på klientsidan på fältnivå
MongoDB version 4.2 kommer med Automatic Client-Side Field Level-kryptering (CSFLE), en funktion som gör det möjligt för utvecklare att selektivt kryptera enskilda fält i ett dokument på klientsidan innan det skickas till servern. Den krypterade informationen hålls således privat från leverantörerna som är värd för databasen och alla användare som kan ha direktåtkomst till databasen.
Endast applikationer med åtkomst till rätt krypteringsnycklar kan dekryptera och läsa den skyddade informationen. Om krypteringsnyckeln raderas kommer all data som krypterades att göras oläslig.
Obs! Den här funktionen är endast tillgänglig med MongoDB Enterprise.
Förbättrat frågespråk för uttrycksfulla uppdateringar
MongoDB version 4.2 ger ett rikare frågespråk än sina föregångare. Det stöder nu aggregering och moderna användningsfallsoperationer i linje med geobaserade sökningar, grafsökning och textsökning. Den har integrerat en sökmotor från tredje part som gör sökningar snabbare med tanke på att sökmotorn körs på en annan process/server. Detta förbättrar generellt databasens prestanda i motsats till om alla sökningar gjordes till mongod-processen som hellre skulle göra databasoperationens latens flyktig närhelst sökmotorn indexerar om.
Med den här versionen kan du nu hantera arrayer, göra summor och andra matematiska operationer direkt genom en uppdateringssats.
On-Demand materialiserade vyer
Dataaggregationspipeline-ramverket i MongoDB är en fantastisk funktion med olika stadier av omvandling av ett dokument till ett önskat tillstånd. MongoDB version 4.2 introducerar ett nytt steg $merge som för mig skulle jag säga att det sparade lite tid på att arbeta med den slutliga utdata som behövde lagras i en samling. Inledningsvis tillåter $out-stadiet att skapa en ny samling baserad på aggregering och fyller samlingen med de erhållna resultaten. Om samlingen redan finns, skulle den skriva över samlingen med de nya resultaten i motsats till $merge-steget som bara införlivar pipeline-resultaten i en befintlig utdata istället för att helt ersätta samlingen. Att regenerera en hel samling varje gång med $out-steget förbrukar mycket CPU och IO vilket kan försämra databasens prestanda. Utdatainnehållet kommer därför att uppdateras i tid så att användare kan skapa materialiserade vyer på begäran
Modern underhållsverksamhet
Utvecklare kan nu få en fantastisk driftsupplevelse med MongoDB version 4.2 med integrerade funktioner som förbättrar hög tillgänglighet, molnhanterad säkerhetskopieringsstrategi, förbättrar övervakningskraften och varningssystem. MongoDB Atlas och MongoDB Ops Manager är de tillhandahållande plattformarna för dessa funktioner. Den senare har märkts som den bästa för att köra MongoDB på företag. Den har också integrerats med Kubernetes-operatören för lokala användare som flyttar till privat moln. Detta gränssnitt gör det möjligt för en att direkt styra Ops Manager.
Det har gjorts några interna ändringar i MongoDB version 4.2 som inkluderar:
- Lista öppna markörer.
- Borttagning av MMAPv1-lagringsmotorn.
- Förbättring av WiredTiger-datafilreparationen.
- Diagnosfält kan nu ha queryHash
- Automatisk uppdelning av tråd för mongos noder har tagits bort.
Slutsats
MongoDB version 4.2 kommer med några förbättringar i linje med säkerhet och databasprestanda. Den har inkluderat en automatisk fältnivåkryptering på klientsidan som säkerställer att data skyddas från klientens vinkel. Fler funktioner som en sökmotor från tredje part och inkludering av $merge-steget i aggregeringsramverket ger en viss förbättring av databasens prestanda. Innan du sätter den här versionen i produktion, se till att alla dina behov tillgodoses till fullo.