Redis
 sql >> Datenbank >  >> NoSQL >> Redis

Ist der UNLINK-Befehl immer besser als der DEL-Befehl?

Bevor wir diskutieren, welches besser ist, werfen wir einen Blick auf den Unterschied zwischen diesen Befehlen. Beide DEL und UNLINK Geben Sie den Schlüsselteil im Blockiermodus frei. Und der Unterschied ist die Art und Weise, wie sie den Wertteil freigeben.

DEL gibt den Wertteil im Blockiermodus immer frei. Wenn der Wert jedoch zu groß ist, z. zu viele Zuordnungen für eine große LIST oder HASH , es blockiert Redis für eine lange Zeit. Um das Problem zu lösen, implementiert Redis den UNLINK Befehl, d.h. ein 'nicht blockierendes' Löschen.

Genau genommen UNLINK ist NICHT immer nicht blockierend/asynchron . Wenn der Wert klein ist, z. die Größe von LIST oder HASH ist kleiner als 64 , wird der Wert sofort freigegeben. Auf diese Weise UNLINK ist fast dasselbe wie DEL , außer dass es ein paar Funktionsaufrufe mehr kostet als DEL . Wenn der Wert jedoch groß ist, fügt Redis den Wert in eine Liste ein, und der Wert wird von einem anderen Thread freigegeben, d. h. dem nicht blockierenden freien. Auf diese Weise muss der Haupt-Thread etwas mit dem Hintergrund-Thread synchronisieren, und das ist auch mit Kosten verbunden.

Zum Schluss, wenn der Wert klein ist, DEL ist mindestens so gut wie UNLINK . Wenn der Wert sehr groß ist, z. LIST mit Tausenden oder Millionen von Artikeln, UNLINK ist viel besser als DEL . Sie können DEL jederzeit sicher ersetzen mit UNLINK . Wenn Sie jedoch feststellen, dass die Thread-Synchronisierung zu einem Problem wird (Multi-Threading bereitet immer Kopfschmerzen), können Sie auf DEL zurücksetzen .

AKTUALISIERUNG:

Seit Redis 6.0 gibt es eine neue Konfiguration:lazyfree-lazy-user-del . Sie können es auf Ja setzen , und Redis führt den DEL aus Befehl, als würde ein UNLINK ausgeführt Befehl.