sql >> Database teknologi >  >> NoSQL >> Redis

Er UNLINK-kommandoen altid bedre end DEL-kommandoen?

Før vi diskuterer, hvilken der er bedst, lad os se på forskellen mellem disse kommandoer. Begge DEL og UNLINK frigør nøgledelen i blokeringstilstand. Og forskellen er den måde, de frigør værdidelen på.

DEL frigiver altid værdidelen i blokeringstilstand. Men hvis værdien er for stor, f.eks. for mange tildelinger til en stor LIST eller HASH , blokerer det Redis i lang tid. For at løse problemet implementerer Redis UNLINK kommando, dvs. en 'ikke-blokerende' sletning.

Faktisk UNLINK er IKKE altid ikke-blokerende/asynkroniseret . Hvis værdien er lille, f.eks. størrelsen på LIST eller HASH er mindre end 64 , vil værdien blive frigivet med det samme. På denne måde UNLINK er næsten det samme som DEL , bortset fra at det koster et par flere funktionskald end DEL . Men hvis værdien er stor, sætter Redis værdien på en liste, og værdien frigives af en anden tråd, dvs. den ikke-blokerende gratis. På denne måde skal hovedtråden lave en vis synkronisering med baggrundstråden, og det er også en omkostning.

Som konklusion, hvis værdien er lille, DEL er mindst lige så god som UNLINK . Hvis værdien er meget stor, f.eks. LIST med tusinder eller millioner af varer, UNLINK er meget bedre end DEL . Du kan altid trygt erstatte DEL med UNLINK . Men hvis du opdager, at trådsynkroniseringen bliver et problem (multi-threading er altid en hovedpine), kan du rulle tilbage til DEL .

OPDATERING:

Siden Redis 6.0 er der en ny konfiguration:lazyfree-lazy-user-del . Du kan indstille det til at være ja , og Redis vil køre DEL kommando, som om du kører en UNLINK kommando.



  1. Oprettelse af et administrationsområde på fem minutter med AdminBro, express, mongoDB, mongoose

  2. JedisPoolConfig kan ikke tildeles til GenericObjectPoolConfig

  3. Hvordan kopierer jeg en database fra en MongoDB-server til en anden?

  4. Byg en reaktiv publikation med yderligere felter i hvert dokument