Database-updates worden geleverd met verbeterde functies voor prestaties, beveiliging en met nieuwe geïntegreerde functies. Het is altijd raadzaam om een nieuwe versie te testen voordat u deze in productie neemt, om er zeker van te zijn dat deze aan uw behoeften voldoet en dat er geen kans op crashes is.
Gezien veel producten, hebben de producten die voorafgaan aan de eerste kleine versies van een nieuwe hoofdversie de belangrijkste oplossingen. Ik zou bijvoorbeeld liever een paar dagen na release MongoDB versie 4.2.1 in productie hebben dan versie 4.2.0.
In deze blog gaan we bespreken wat er is opgenomen en welke verbeteringen zijn aangebracht aan MongoDB versie 4.2
Wat is er nieuw in MongoDB 4.2
- Gedistribueerde transacties
- Wildcard-indexen
- Herhaalbare lees- en schrijfbewerkingen
- Automatische versleuteling op veldniveau aan de clientzijde.
- Verbeterde zoektaal voor expressieve updates
- Gerealiseerde weergaven op aanvraag
- Moderne onderhoudswerkzaamheden
Gedistribueerde transacties
Transacties zijn belangrijke databasefuncties die zorgen voor consistentie en integriteit van gegevens, vooral die welke de ACID-procedures garanderen. MongoDB versie 4.2 ondersteunt nu transacties met meerdere documenten op replicasets en een shard-cluster via de gedistribueerde transactiebenadering. Dezelfde syntaxis voor het gebruik van transacties is gehandhaafd als de vorige 4.0-versie.
De specificaties van de clientstuurprogramma's zijn echter een beetje veranderd, dus als u transacties in MongoDB 4.2 wilt gebruiken, moet u de stuurprogramma's upgraden naar versies die compatibel zijn met 4.2-servers.
Deze versie beperkt de omvang van een transactie niet in termen van geheugengebruik, maar is alleen afhankelijk van de grootte van uw hardware en de verwerkingscapaciteit van de hardware.
Het opnieuw toewijzen van globale clusterlandinstellingen is nu mogelijk met versie 4.2. Dit wil zeggen dat voor een implementatie van sharding met een geozone, als een gebruiker die in regio A woont, naar regio B verhuist, door de waarde van hun locatieveld te wijzigen, de gegevens automatisch van regio A naar B kunnen worden verplaatst via een transactie.
Het sharding-systeem maakt het nu mogelijk om een Shard-sleutel te wijzigen in tegenstelling tot de vorige versie. Letterlijk, wanneer een Shard-sleutel wordt gewijzigd, komt dit overeen met het verplaatsen van het document naar een andere Shard. In deze versie verpakt MongoDB deze update en als het document van de ene shard naar de andere moet worden verplaatst, wordt de update op de achtergrond in een transactie uitgevoerd.
Het gebruik van transacties is niet aan te raden omdat ze de databaseprestaties verslechteren, vooral als ze meerdere keren voorkomen. Tijdens een transactieperiode is er een uitgerekt venster voor bewerkingen die conflicten kunnen veroorzaken bij het schrijven naar een document dat wordt beïnvloed. Hoezeer een transactie ook opnieuw kan worden geprobeerd, er kan een update in het document zijn gemaakt voordat deze nieuwe poging wordt gedaan, en wanneer de nieuwe poging plaatsvindt, kan deze de oude in plaats van de nieuwste documentversie behandelen. Nieuwe pogingen brengen uiteraard meer verwerkingskosten met zich mee, naast het verhogen van de downtime van de applicatie door toenemende latentie.
Een goede gewoonte rond het gebruik van transacties is:
- Vermijd het gebruik van niet-geïndexeerde zoekopdrachten binnen een transactie om ervoor te zorgen dat de Op niet traag zal zijn.
- Uw transactie moet een aantal documenten bevatten.
Met de MongoDB dynamische schema-indeling en insluitfunctie, kunt u ervoor kiezen om alle velden in dezelfde verzameling te plaatsen om te voorkomen dat transactie als eerste maatregel moet worden gebruikt.
Wildcard-indexen
Wildcard-indexen zijn geïntroduceerd in MongoDB versie 4.2 om zoekopdrachten tegen willekeurige velden of velden waarvan de namen niet vooraf bekend zijn, te verbeteren door het hele document of subdocument te indexeren. Ze zijn niet bedoeld om de op werkbelasting gebaseerde indexen te vervangen maar past bij het werken met gegevens met een polymorf patroon. Bij een polymorf patroon zijn alle documenten in een verzameling vergelijkbaar, maar hebben ze geen identieke structuur. Polymorfe gegevenspatronen kunnen worden gegenereerd op basis van toepassingen, productcatalogi of sociale gegevens. Hieronder ziet u een voorbeeld van polymorfe verzamelgegevens
{
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
}Door het hele document te indexeren met behulp van Wildcard-indexen, kunt u een zoekopdracht maken met elk willekeurig veld als index.
Een wildcard-index maken
$db.collection.createIndex({“fieldA.$**”: 1})Als het geselecteerde veld een genest document of een array is, keert de wildcard-index terug in het document en slaat de waarde op voor alle velden in het document of de array.
Herhaalbare lees- en schrijfbewerkingen
Normaal gesproken kan een database enkele frequente tijdelijke netwerkstoringen oplopen, wat ertoe kan leiden dat een query gedeeltelijk of volledig niet wordt uitgevoerd. Deze netwerkfouten zijn misschien niet zo ernstig en bieden daarom de kans om deze query's opnieuw te proberen zodra ze opnieuw zijn verbonden. Vanaf MongoDB 4.2 is de configuratie voor opnieuw proberen standaard ingeschakeld. De MongoDB-stuurprogramma's kunnen mislukte lees- en schrijfbewerkingen voor bepaalde transacties opnieuw proberen wanneer ze kleine netwerkfouten tegenkomen of liever wanneer ze geen gezonde primaire in de shard-cluster/replicaset kunnen vinden. Als u de herschrijfbare schrijfbewerkingen echter niet wilt, kunt u ze expliciet uitschakelen in uw configuraties, maar ik vind geen dwingende reden waarom u ze zou moeten uitschakelen.
Deze functie is bedoeld om ervoor te zorgen dat in elk geval de MongoDB-infrastructuurwijzigingen niet worden beïnvloed door de applicatiecode. Met betrekking tot een voorbeeld uitgelegd door Eliot Horowitz, de mede-oprichter van MongoDB, voor een webpagina die 20 verschillende databasebewerkingen uitvoert, in plaats van het hele ding opnieuw te laden of de hele webpagina in een soort lus te moeten wikkelen, de driver onder de dekens kan gewoon besluiten om de operatie opnieuw te proberen. Wanneer schrijven mislukt, wordt het automatisch opnieuw geprobeerd en heeft het een contract met de server om te garanderen dat elke schrijfactie slechts één keer plaatsvindt.
De herschrijfbare schrijfbewerkingen doen slechts één nieuwe poging, wat helpt bij het oplossen van replicaset-verkiezingen en tijdelijke netwerkfouten, maar niet voor aanhoudende netwerkfouten.
Herhaalbare schrijfacties hebben geen betrekking op instanties waarbij de failoverperiode de serverSelectionTimoutMs-waarde overschrijdt in de parameterconfiguraties.
Met deze MongoDB-versie kan men de sleutelwaarden van de document-shard bijwerken (behalve als de shardkey het onveranderlijke _id-veld is) door een enkel document findAndModify/update-bewerkingen uit te voeren, hetzij in een transactie of als een herschrijfbare schrijfactie .
MongoDB versie 4.2 kan nu een upsert-bewerking in één document opnieuw proberen (d.w.z. upsert:true en multi:false) die mogelijk is mislukt vanwege een dubbele sleutelfout als de bewerking aan deze belangrijke voorwaarden voldoet:
- Doelverzameling bevat een unieke index die de dubbele sleutelfout heeft gemaakt.
- De update-bewerking zal geen van de velden in het query-predikaat wijzigen.
- De update-overeenkomstvoorwaarde is ofwel een enkel gelijkheidspredikaat {field:“value”} of een logische AND van gelijkheidspredikaten {filed:“value”, field0:“value0”}
- Set velden in het unieke indexsleutelpatroon komt overeen met de set velden in het predikaat updatequery.
Automatische versleuteling op veldniveau aan de clientzijde
MongoDB versie 4.2 wordt geleverd met Automatic Client-Side Field Level-encryptie (CSFLE), een functie waarmee ontwikkelaars individuele velden van een document selectief kunnen versleutelen aan de clientzijde voordat het naar de server wordt verzonden. De versleutelde gegevens worden dus privé gehouden voor de providers die de database hosten en voor elke gebruiker die directe toegang tot de database heeft.
Alleen toepassingen met toegang tot de juiste coderingssleutels kunnen de beveiligde gegevens decoderen en lezen. Als de coderingssleutel wordt verwijderd, worden alle gegevens die zijn gecodeerd onleesbaar gemaakt.
Opmerking:deze functie is alleen beschikbaar bij MongoDB Enterprise.
Verbeterde zoektaal voor expressieve updates
MongoDB versie 4.2 biedt een rijkere querytaal dan zijn voorgangers. Het ondersteunt nu aggregaties en moderne use-case-operaties in de trant van geo-gebaseerde zoekopdrachten, grafieken zoeken en tekst zoeken. Het heeft een externe zoekmachine geïntegreerd die zoekopdrachten sneller maakt, aangezien de zoekmachine op een ander proces/server draait. Dit verbetert over het algemeen de prestaties van de database, in tegenstelling tot wanneer alle zoekopdrachten naar het mongod-proces zouden zijn uitgevoerd, waardoor de latentie van de databasebewerking eerder vluchtig zou zijn wanneer de zoekmachine opnieuw indexeert.
Met deze versie kun je nu rechtstreeks omgaan met arrays, sommen en andere wiskundige bewerkingen uitvoeren via een update-instructie.
Gematerialiseerde weergaven op aanvraag
Het pijplijnframework voor gegevensaggregatie in MongoDB is een geweldige functie met verschillende fasen van het transformeren van een document naar een gewenste staat. De MongoDB-versie 4.2 introduceert een nieuwe fase $merge waarvan ik zal zeggen dat het me wat tijd heeft bespaard bij het werken met de uiteindelijke uitvoer die in een verzameling moest worden opgeslagen. In eerste instantie maakt de $out-fase het mogelijk om een nieuwe verzameling te maken op basis van aggregatie en wordt de verzameling gevuld met de verkregen resultaten. Als de verzameling al bestaat, zou deze de verzameling overschrijven met de nieuwe resultaten in tegenstelling tot de $merge-fase die alleen de pijplijnresultaten in een bestaande uitvoer opneemt in plaats van de verzameling volledig te vervangen. Het elke keer opnieuw genereren van een hele verzameling met de $out-fase verbruikt veel CPU en IO, wat de prestaties van de database kan verslechteren. De outputinhoud zal daarom tijdig worden bijgewerkt, zodat gebruikers on-demand gematerialiseerde weergaven kunnen creëren
Moderne onderhoudswerkzaamheden
Ontwikkelaars kunnen nu een geweldige operationele ervaring hebben met MongoDB versie 4.2 met geïntegreerde functies die hoge beschikbaarheid, cloudbeheerde back-upstrategie verbeteren, de bewakingskracht en waarschuwingssystemen verbeteren. MongoDB Atlas en MongoDB Ops Manager zijn de platforms voor deze functies. De laatste is bestempeld als de beste voor het uitvoeren van MongoDB on-enterprise. Het is ook geïntegreerd met Kubernetes-operator voor on-premises gebruikers die overstappen op een private cloud. Deze interface maakt het mogelijk om Ops Manager direct te bedienen.
Er zijn enkele interne wijzigingen aangebracht in MongoDB versie 4.2, waaronder:
- Open cursors weergeven.
- Verwijderen van de MMAPv1-opslagengine.
- Verbetering van de reparatie van het WiredTiger-gegevensbestand.
- Diagnostische velden kunnen nu queryHash hebben
- Auto-splitsende thread voor mongos-knooppunten is verwijderd.
Conclusie
MongoDB versie 4.2 wordt geleverd met enkele verbeteringen op het gebied van beveiliging en databaseprestaties. Het bevat een automatische versleuteling op veldniveau aan de clientzijde die ervoor zorgt dat gegevens vanuit het oogpunt van de klant worden beschermd. Meer functies zoals een zoekmachine van derden en opname van de $merge-fase in het aggregatieraamwerk zorgen voor enige verbetering in de databaseprestaties. Voordat u deze versie in productie neemt, moet u ervoor zorgen dat aan al uw behoeften is voldaan.