sql >> Databasteknik >  >> NoSQL >> Redis

Är kommandot UNLINK alltid bättre än DEL-kommandot?

Innan vi diskuterar vilken som är bättre, låt oss ta en titt på skillnaden mellan dessa kommandon. Båda DEL och UNLINK frigör nyckeldelen i blockeringsläge. Och skillnaden är hur de frigör värdedelen.

DEL frigör alltid värdedelen i blockeringsläge. Men om värdet är för stort, t.ex. för många tilldelningar för en stor LIST eller HASH , det blockerar Redis under lång tid. För att lösa problemet implementerar Redis UNLINK kommando, det vill säga en "icke-blockerande" radering.

Faktum är att UNLINK är INTE alltid icke-blockerande/asynkroniserad . Om värdet är litet, t.ex. storleken på LIST eller HASH är mindre än 64 , kommer värdet att frigöras omedelbart. På detta sätt UNLINK är nästan samma som DEL , förutom att det kostar några fler funktionsanrop än DEL . Men om värdet är stort, lägger Redis värdet i en lista, och värdet kommer att frigöras av en annan tråd, dvs den icke-blockerande fria. På så sätt måste huvudtråden göra en viss synkronisering med bakgrundstråden, och det är också en kostnad.

Sammanfattningsvis, om värdet är litet, DEL är minst lika bra som UNLINK . Om värdet är mycket stort, t.ex. LIST med tusentals eller miljontals artiklar, UNLINK är mycket bättre än DEL . Du kan alltid säkert ersätta DEL med UNLINK . Men om du upptäcker att trådsynkroniseringen blir ett problem (multi-threading är alltid en huvudvärk), kan du gå tillbaka till DEL .

UPPDATERING:

Sedan Redis 6.0 har det kommit en ny konfiguration:lazyfree-lazy-user-del . Du kan ställa in det till ja , och Redis kör DEL kommandot som om du kör en UNLINK kommando.



  1. Redis filtrera efter intervall, sortera och returnera 10 först

  2. Node.js &Redis; Väntar på att en loop ska sluta

  3. HDFS raderingskodning i Big Data Hadoop

  4. Hur man ställer in Yii2 med Redis-konfiguration