Es hängt alles davon ab, wie Sie es verwenden werden. Wenn jedes Byte zählt, beispielsweise wenn Sie für jedes an einen Cloud-Dienst übertragene kB bezahlen müssen, können Sie die Kosten berechnen. Die Mathematik ist einfach; Ein Byte ist ein Byte 'auf dem Draht'. Innerhalb von Redis ist es für größere Werte genauso einfach. Bei kleineren Werten führt Redis eine Speicheroptimierung durch.
In Ihrem HSET Beispielsweise teilen Sie die Mitglieder auf, was nur sinnvoll ist, wenn Sie sie die meiste Zeit voneinander getrennt benötigen. Ein besserer Ansatz -vielleicht- sein:HSET user:data 987654321 '{"loc": "123456", "time": "2014-01-01T13:00:00"}' . Getrennte Tasten/Mitglieder "kosten" leistungsmäßig viel mehr als längere Zeichenfolgen. Sie können sogar eine ganze Tabelle oder einen Datensatz in ein Element einfügen, wenn es nur als eine vollständige halbstatische Entität verwendet werden soll.
Geschwindigkeit und Größe:Es gibt einen bemerkenswerten Unterschied zwischen Schlüsseln und Werte .
Schlüssel: Kürzer ist im Allgemeinen sowohl speichereffizienter als auch geschwindigkeitseffizienter. Wenn Sie ein redis Sorted Set verwenden, können Sie sogar „Zahlen“ als Schlüssel verwenden (Sorted Set „Mitglieder“ plus „Ergebnisse“). Ich sage "Zahlen", weil eine Punktzahl technisch gesehen ein Float64 ist, aber um als ID verwendet zu werden, muss sie zwischen -999999999999999 und 99999999999999 liegen, einschließlich (das sind 15 Ziffern), ohne Nachkommastellen. Dies kann sehr hilfreich sein, da Redis eine schnelle und skalierbare O(log(n))-on-the-fly-Sortierung von sortierten Sätzen durchführt (unter Verwendung von Skiplisten, vereinfacht).
Werte: Das MsgPack-Format (unkomprimiert) nimmt am wenigsten Speicherplatz ein, insbesondere wenn Sie die Definitionen einmal und die Werte viele speichern. JSON ist etwas weniger speichereffizient, aber natürlich ein so verbreitetes IPC-Format, dass es nicht ausgelassen werden sollte. Rohe Zeichenfolgen, zeichengetrennt, feste Länge (ugh), was auch immer Sie wünschen, es ist möglich, es zu verwenden. Sie können Ihre Daten jederzeit komprimieren, bevor Sie sie in Redis speichern. Bisher Speichereffizienz . Wenn es um Geschwindigkeit geht , es ist weniger einfach. Wenn Sie serverseitiges Lua-Skripting verwenden möchten (was Sie tun sollten), können Sie mit komprimierten Daten nichts anfangen. JSON und MsgPack können deserialisiert werden, aber nur „als Ganzes“. Was in den meisten Szenarien in Ordnung ist. Am flexibelsten ist das Speichern separater Werte (z. B. als Mitglieder eines HSET), aber auch dies hat seinen Preis (meistens:einen zu hohen Preis). All dies können Sie auch kombinieren. Was wir am häufigsten verwenden:ein Präfix aus zwei oder drei durch Trennzeichen getrennten Werten, gefolgt von einer MsgPack-Nutzlast.
Mein allgemeiner Rat ist:Beginnen Sie damit, nur HSETs und ZSETs zu verwenden, teilen Sie keine Daten auf, die zusammengehören, verwenden Sie aussagekräftige PascalCased-Namen für Ihre Schlüssel zwischen 10 und 25 Zeichen, verwenden Sie ':', wenn Sie Trennzeichen in Ihren Schlüsseln (Namespaces) benötigen. , als JSON serialisieren (der Einfachheit halber, aber Code für den einfachen Wechsel zu MsgPack), Lua-Skripting verwenden (auch wenn Sie Lua nicht kennen, die Teilmenge, die Sie in Redis verwenden, ist winzig).
Ich würde mir in der Startphase Ihres Projekts keine allzu großen Gedanken darüber machen, Sie können es später jederzeit ändern und einige A/B-Vergleiche durchführen, sobald Sie einige interpolierbare Daten haben.
Hoffe das hilft, TW
