MongoDB-låsning är annorlunda
Att låsa in MongoDB fungerar inte som att låsa in ett RDBMS, så lite förklaring är på sin plats. I tidigare versioner av MongoDB fanns det en enda global läsare/skrivarspärr. Från och med MongoDB 2.2 finns det en läsare/skrivare för varje databas.
Läsare-skrivarspärren
Spärren är flerläsare, enkelskrivare och är skribentgirig. Det betyder att:
- Det kan finnas ett obegränsat antal samtidiga läsare i en databas
- Det kan bara finnas en författare åt gången på en samling i en databas (mer om detta om ett tag)
- Skribenter blockerar läsare
- Med "skribent-girig" menar jag att när en skrivförfrågan väl kommer in blockeras alla läsare tills skrivningen är klar (mer om detta senare)
Observera att jag kallar detta en "spärr" snarare än ett "lås". Detta beror på att det är lätt, och i ett korrekt utformat schema hålls skrivlåset i storleksordningen ett dussin mikrosekunder. Se här för mer om läsare-skrivarlåsning.
I MongoDB kan du köra så många samtidiga frågor som du vill:så länge som relevant data finns i RAM kommer de alla att vara nöjda utan låsningskonflikter.
Atomic Document Updates
Kom ihåg att i MongoDB är transaktionsnivån ett enda dokument. Alla uppdateringar av ett enda dokument är Atomic. MongoDB uppnår detta genom att hålla skrivspärren bara så länge som det tar att uppdatera ett enda dokument i RAM. Om det finns en långsam operation (särskilt om ett dokument eller en indexpost måste sökas in från disken), kommer den operationen att ge skrivspärren. När operationen ger spärren, kan nästa köade operation fortsätta.
Detta innebär att skrivningarna till alla dokument i en enda databas serialiseras. Detta kan vara ett problem om du har en dålig schemadesign, och dina skrivningar tar lång tid, men i ett korrekt utformat schema är låsning inget problem.
Girig författare
Några fler ord om att vara författargirig:
Endast en författare kan hålla i spärren åt gången; flera läsare kan hålla spärren åt gången. I en naiv implementering kunde författare svälta i det oändliga om det fanns en enda läsare i drift. För att undvika detta, i MongoDB-implementeringen, när en enskild tråd gör en skrivbegäran för en viss spärr
- Alla efterföljande läsare som behöver den spärren kommer att blockera
- Den skribent kommer att vänta tills alla nuvarande läsare är klara
- Skribenten skaffar skrivspärren, gör sitt arbete och släpper sedan skrivspärren
- Alla köade läsare fortsätter nu
Det faktiska beteendet är komplext, eftersom detta skribentgiriga beteende interagerar med eftergivande på sätt som kan vara icke-uppenbara. Kom ihåg att det, från och med version 2.2, finns en separat latch för varje databas, så skrivning till vilken samling som helst i databasen 'A' kommer att få en separat latch än skrivning till någon samling i databasen 'B'.
Särskilda frågor
Angående de specifika frågorna:
- Lås (faktiskt spärrar) hålls av MongoDB-kärnan så länge som det tar att uppdatera ett enda dokument
- Om du har flera anslutningar som kommer in till MongoDB, och var och en av dem utför en serie skrivningar, kommer spärren att hållas per databas så länge som det tar för skrivningen att slutföras li>
- Flera anslutningar som kommer när de skriver (uppdatera/infoga/ta bort) kommer alla att interfolieras
Även om detta låter som att det skulle vara ett stort prestationsproblem, saktar det inte ner i praktiken. Med ett korrekt utformat schema och en typisk arbetsbelastning kommer MongoDB att mätta diskens I/O-kapacitet -- även för en SSD -- innan låsprocenten på någon databas går över 50 %.
MongoDB-klustret med högsta kapacitet som jag känner till utför för närvarande 2 miljoner skrivningar per sekund.