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

Leistungsvergleich der Verwendung von Redis-Hashes mit vielen Schlüsseln

Wählen Sie hash über string hat je nach Anwendungsfall viele Vorteile und einige Nachteile. Wenn Sie sich für Hash entscheiden, ist es besser, Ihr JSON-Objekt als Hash-Felder und -Werte wie;

zu entwerfen 
127.0.0.1:6379> hset user:1 ssn 10101010101 name john surname wick date 2020-02-02 location continental
(integer) 5
127.0.0.1:6379> hgetall user:1
 1) "ssn"
 2) "10101010101"
 3) "name"
 4) "john"
 5) "surname"
 6) "wick"
 7) "date"
 8) "2020-02-02"
 9) "location"
10) "continental"

Hier sind die Vorteile von hash über Zeichenfolgen, wenn Sie eine ordnungsgemäße Datenmodellierung durchführen.

  • Auf der Leistungsseite haben die meisten Befehle für Strings und Hash die gleiche Komplexität.
  • Zugriff/Aktualisierung/Löschung einzelner JSON-Felder auf Hashes einfacher, wenn sie mit den Strings verglichen werden. Sie müssen nicht die gesamte Zeichenfolge abrufen, decodieren, Änderungen vornehmen und erneut festlegen. Sie können HDEL, HSET oder HGET für diese Operationen verwenden, ohne das gesamte Objekt zu erhalten.
  • Wenn die Größe Ihres String-Objekts zunimmt, werden Sie beim Übertragen (Abrufen/Setzen) des gesamten Objekts unter Netzwerk und Bandbreite leiden. Wie es in der Dokumentation angegeben ist

Die Geschwindigkeit des Arbeitsspeichers und die Speicherbandbreite scheinen weniger kritisch für die Gesamtleistung zu sein, insbesondere für kleine Objekte. Bei großen Objekten (>10 KB) kann es aber auffallen.

  • Hashes sind speicherfreundlicher als Strings, wenn Sie einen guten Benchmark zur Gestaltung Ihrer Datengröße erstellen. Wie in der Dokumentation und einem Beispielanwendungsfall von Instagram Engineering angegeben, können Sie mit der speziellen Codierung einen großen Vorteil erzielen.

Hashes, Listen, Mengen, die nur aus ganzen Zahlen bestehen, und sortierte Mengen werden, wenn sie kleiner als eine bestimmte Anzahl von Elementen und bis zu einer maximalen Elementgröße sind, auf eine sehr speichereffiziente Weise codiert, die bis zu 10-mal weniger Speicher benötigt (mit 5 Zeit weniger verbrauchter Speicher ist die durchschnittliche Einsparung).

Auf der anderen Seite, abhängig von Ihren Anwendungsfällen;

  • ziplist ist nicht umsonst, es ist ein Kompromiss zwischen Arbeitsspeicher und CPU.
  • Sie können Hash-Felder nicht teilweise verfallen lassen. Wenn Sie in mehrere Zeichenfolgen aufteilen, können Sie EXPIRE sie, aber in Hashes kann nur der Schlüssel der obersten Ebene mit allen Werten abgelaufen sein.