MongoDB Schema Planeringstips

En av de mest annonserade funktionerna i MongoDB är dess förmåga att vara "schemalös". Detta innebär att MongoDB inte lägger något schema på några dokument som lagras i en samling. Normalt lagrar MongoDB dokument i ett JSON-format så att varje dokument kan lagra olika typer av schema/struktur. Detta är fördelaktigt för de inledande stadierna av utvecklingen, men i de senare stadierna kanske du vill framtvinga viss schemavalidering samtidigt som du infogar nya dokument för bättre prestanda och skalbarhet. Kort sagt, "Schemaless" betyder inte att du inte behöver designa ditt schema. I den här artikeln kommer jag att diskutera några allmänna tips för att planera ditt MongoDB-schema.

Att ta reda på den bästa schemadesignen som passar din applikation kan ibland bli tråkigt. Här är några punkter som du kan tänka på när du utformar ditt schema.

Undvik växande dokument

Om ditt schema tillåter att skapa dokument som växer i storlek kontinuerligt bör du vidta åtgärder för att undvika detta eftersom det kan leda till försämring av DB- och disk-IO-prestanda. Som standard tillåter MongoDB 16 MB storlek per dokument. Om din dokumentstorlek ökar med mer än 16 MB under en tidsperiod är det ett tecken på dålig schemadesign. Det kan ibland leda till misslyckade frågor. Du kan använda dokumentsegment eller tekniker för dokumentfördelning för att undvika denna situation. Om din applikation behöver lagra dokument som är större än 16 MB kan du överväga att använda MongoDB GridFS API.

Undvik att uppdatera hela dokument

Om du försöker uppdatera hela dokumentet kommer MongoDB att skriva om hela dokumentet någon annanstans i minnet. Detta kan drastiskt försämra skrivprestandan för din databas. Istället för att uppdatera hela dokumentet kan du använda fältmodifierare för att endast uppdatera specifika fält i dokumenten. Detta kommer att utlösa en uppdatering på plats i minnet, och därmed förbättrad prestanda.

Försök att undvika anslutningar på applikationsnivå

Som vi alla vet stöder MongoDB inte servernivåanslutningar. Därför måste vi hämta all data från DB och sedan utföra join på applikationsnivå. Om du hämtar data från flera samlingar och sammanfogar en stor mängd data, måste du ringa DB flera gånger för att få all nödvändig data. Detta kommer naturligtvis att kräva mer tid eftersom det involverar nätverket. Som en lösning för det här scenariot, om din applikation är starkt beroende av joins, är avnormalisering av schemat mer meningsfullt. Du kan använda inbäddade dokument för att få all nödvändig data i ett enda frågesamtal.

Använd korrekt indexering

När man gör sökningar eller sammanställningar sorterar man ofta data. Även om du ansöker om att sortera i det sista steget av en pipeline, behöver du fortfarande ett index för att täcka sorteringen. Om index på sorteringsfält inte är tillgängligt, tvingas MongoDB att sortera utan index. Det finns en minnesgräns på 32 MB av den totala storleken på alla dokument som ingår i sorteringsoperationen. Om MongoDB når den gränsen kan det antingen skapa ett fel eller returnera en tom uppsättning.

Efter att ha diskuterat att lägga till index är det också viktigt att inte lägga till onödiga index. Varje index du lägger till i databasen måste du uppdatera alla dessa index samtidigt som du uppdaterar dokument i samlingen. Detta kan försämra databasens prestanda. Varje index kommer också att uppta lite utrymme och minne, så antalet index kan leda till lagringsrelaterade problem.

Ett annat sätt att optimera användningen av ett index är att åsidosätta standardfältet _id. Det enda syftet med detta fält är att behålla ett unikt fält per dokument. Om din data innehåller en tidsstämpel eller något id-fält kan du åsidosätta _id-fältet och spara ett extra index.

Läs v/s skrivförhållande

Att utforma ett schema för alla program beror mycket på om ett program är lästungt eller skrivtungt. Om du till exempel bygger en instrumentpanel för att visa tidsseriedata bör du designa ditt schema på ett sådant sätt att det maximerar skrivgenomströmningen. Om din applikation är e-handelsbaserad kommer de flesta av operationerna att vara läsoperationer eftersom de flesta användare kommer att gå igenom alla produkter och bläddra i olika kataloger. I sådana fall bör du använda avnormaliserat schema för att minska antalet anrop till DB för att få relevant data.

BSON-datatyper

Se till att du definierar BSON-datatyper för alla fält korrekt när du utformar schemat. För när du ändrar datatypen för något fält kommer MongoDB att skriva om hela dokumentet i ett nytt minnesutrymme. Om du till exempel försöker lagra (int)0 i stället för (float)0.0-fältet, skriver MongoDB om hela dokumentet till en ny adress på grund av förändring i BSON-datatyp.

Slutsats

I ett nötskal är det klokt att utforma ett schema för din Mongo-databas eftersom det bara kommer att förbättra prestandan för din applikation. Från och med version 3.2 började MongoDB stödja dokumentvalidering där du kan definiera vilka fält som krävs för att infoga ett nytt dokument. Från version 3.6 introducerade MongoDB ett mer elegant sätt att genomdriva schemavalidering med JSON Schema Validation. Med den här valideringsmetoden kan du genomdriva datatypkontroll tillsammans med obligatorisk fältkontroll. Du kan använda ovanstående metoder för att kontrollera om alla dokument använder samma typ av schema eller inte.