Met de MMAPv1-opslagengine worden in-place updates vaak gemarkeerd als een optimalisatiestrategie, omdat indexen voor een document rechtstreeks verwijzen naar bestandslocaties en offsets. Het verplaatsen van een document naar een nieuwe opslaglocatie (vooral als er veel indexitems zijn om bij te werken) heeft meer overhead voor MMAPv1 dan een interne update die alleen de gewijzigde velden hoeft bij te werken. Zie:Record-opslagkenmerken in MMAPv1.
WiredTiger ondersteunt geen interne updates omdat het intern MVCC (Multiversion concurrency control) gebruikt, dat vaak wordt gebruikt door databasebeheersystemen. Dit is een aanzienlijke technische verbetering ten opzichte van de simplistische weergave in MMAP en maakt het mogelijk om meer geavanceerde functies te bouwen, zoals isolatieniveaus en transacties. De indexen van WiredTiger hebben een indirectieniveau (verwijzend naar een interne RecordID in plaats van de bestandslocatie en offset), dus documentverplaatsingen op opslagniveau vormen geen significant pijnpunt.
Dit artikel zegt echter ook dat "Hoewel [WiredTiger] geen interne updates toestaat, het voor veel workloads nog steeds beter kan presteren dan MMAP".
Het betekent dat hoewel MMAPv1 een efficiënter pad heeft voor interne updates, WiredTiger andere voordelen heeft, zoals compressie en verbeterde gelijktijdigheidscontrole. Je zou misschien een workload kunnen maken die alleen bestaat uit interne updates voor een paar documenten die misschien beter presteren in MMAPv1, maar de daadwerkelijke workloads zijn doorgaans gevarieerder. De enige manier om de impact voor een bepaalde werklast te bevestigen, is door te testen in een representatieve omgeving.
De algemene keuze van MMAPv1 versus WiredTiger is echter onbespreekbaar als je plannen wilt maken voor de toekomst:WiredTiger is de standaard opslagengine sinds MongoDB 3.2 en sommige nieuwere productfuncties worden niet ondersteund door MMAPv1. MMAPv1 ondersteunt bijvoorbeeld Majority Read Concern niet, wat op zijn beurt betekent dat het niet kan worden gebruikt voor Replica Set Config Servers (vereist voor sharding in MongoDB 3.4+) of Change Streams (MongoDB 3.6+). MMAPv1 zal worden beëindigd in de volgende grote release van MongoDB (4.0) en zal momenteel worden verwijderd in MongoDB 4.2.
Wat zijn de exacte implicaties waar ik op moet letten als ik WiredTiger gebruik? Zonder interne updates zal de databasegrootte bijvoorbeeld snel groeien?
De resultaten van de opslag zijn afhankelijk van verschillende factoren, waaronder uw schemaontwerp, werkbelasting, configuratie en versie van de MongoDB-server. MMAPv1 en WiredTiger gebruiken verschillende strategieën voor recordtoewijzing, maar beide zullen proberen vooraf toegewezen ruimte te gebruiken die is gemarkeerd als vrij/herbruikbaar. Over het algemeen is WiredTiger efficiënter in het gebruik van opslagruimte en heeft het ook het voordeel van compressie voor gegevens en indexen. MMAPv1 wijst extra opslagruimte toe om te proberen te optimaliseren voor interne updates en om documentverplaatsingen te voorkomen, hoewel u een "geen opvulling"-strategie kunt kiezen voor collecties waarbij de werkbelasting de documentgrootte in de loop van de tijd niet verandert.
Er is aanzienlijk geïnvesteerd in het verbeteren en afstemmen van WiredTiger voor verschillende workloads sinds het voor het eerst werd geïntroduceerd in MongoDB 3.0, dus ik zou het testen met de nieuwste serie productie-releases ten zeerste aanmoedigen voor het beste resultaat. Als je een specifieke vraag hebt over schema-ontwerp en opslaggroei, raad ik aan om details op DBA StackExchange te plaatsen voor discussie.
Ik heb ook geleerd dat WiredTiger in MongoDB 3.6 de mogelijkheid heeft toegevoegd om delta's op te slaan in plaats van het hele document te herschrijven (https://jira.mongodb.org/browse/DOCS-11416). Wat betekent dit precies?
Dit is een implementatiedetail dat de interne gegevensstructuren van WiredTiger voor sommige gebruikssituaties verbetert. Met name WiredTiger in MongoDB 3.6+ kan efficiënter zijn in het werken met kleine wijzigingen in grote documenten (in vergelijking met eerdere releases). De WiredTiger-cache moet meerdere versies van documenten kunnen retourneren, zolang ze worden gebruikt door open interne sessies (MVCC, zoals eerder vermeld), dus voor grote documenten met kleine updates kan het efficiënter zijn om een lijst met delta's op te slaan. Als er echter te veel delta's ophopen (of als de delta's de meeste velden in een document veranderen), kan deze aanpak minder effectief zijn dan het onderhouden van meerdere exemplaren van het volledige document.
Wanneer gegevens via een controlepunt op schijf worden vastgelegd, moet er nog steeds een volledige versie van het document worden geschreven. Als je meer wilt weten over enkele van de interne onderdelen, is er een MongoDB Path To Transactions-reeks video's die de ontwikkeling van functies volgen om transacties met meerdere documenten in MongoDB 4.0 te ondersteunen.
Wat ik ook niet begrijp, is dat tegenwoordig de meeste (zo niet alle) harde schijven een sectorgrootte van 4096 bytes hebben, dus je kunt niet slechts 4 bytes naar de harde schijf schrijven (bijvoorbeeld) maar in plaats daarvan het volledige blok van 4096 moet schrijven bytes (lees het dus eerst, update de 4 bytes erin en schrijf het dan). Aangezien de meeste documenten vaak <4096 bytes zijn, betekent dit dat het hele document in ieder geval opnieuw moet worden geschreven (zelfs met MMAP). Wat heb ik gemist?
Zonder al te ver in te gaan op implementatiedetails en te proberen alle bewegende delen die erbij betrokken zijn uit te leggen, overweeg hoe de verschillende benaderingen van toepassing zijn op workloads waarbij veel documenten worden bijgewerkt (in plaats van op het niveau van één document) en wat de impact is op het geheugengebruik (vóór documenten worden naar schijf geschreven). Afhankelijk van factoren zoals documentgrootte en compressie, kan een enkel I/O-blok overal vertegenwoordigen, van een fractie van een document (max. grootte 16 MB) tot meerdere documenten.
In MongoDB is de algemene gang van zaken dat documenten worden bijgewerkt in een weergave in het geheugen (bijvoorbeeld de WiredTiger-cache) met wijzigingen die op schijf worden bewaard in een snel toe te voegen journaalformaat voordat ze periodiek naar de gegevensbestanden worden gewist. Als de besturingssysteem alleen gegevensblokken hoeft te schrijven die zijn gewijzigd, vereist het aanraken van minder gegevensblokken minder algemene I/O.