Ciągi znaków Redis a skróty Redis reprezentujące JSON:wydajność?

Ten artykuł może dostarczyć wielu informacji tutaj:http://redis.io/topics/memory-optimization

Istnieje wiele sposobów przechowywania tablicy obiektów w Redis (spoiler :Lubię opcję 1 w większości przypadków użycia):

1. Przechowuj cały obiekt jako ciąg zakodowany w formacie JSON w jednym kluczu i śledź wszystkie obiekty za pomocą zestawu (lub listy, jeśli jest to bardziej odpowiednie). Na przykład:

   INCR id:users
   SET user:{id} '{"name":"Fred","age":25}'
   SADD users {id}
   

   Ogólnie rzecz biorąc, jest to prawdopodobnie najlepsza metoda w większości przypadków. Jeśli w obiekcie jest dużo pól, twoje obiekty nie są zagnieżdżone z innymi obiektami i masz tendencję do uzyskiwania dostępu tylko do małego podzbioru pól na raz, lepiej wybrać opcję 2.

   Zalety :uważany za „dobrą praktykę”. Każdy obiekt jest pełnoprawnym kluczem Redis. Analiza JSON jest szybka, zwłaszcza gdy potrzebujesz jednocześnie uzyskać dostęp do wielu pól dla tego obiektu. Wady :wolniej, gdy potrzebujesz dostępu tylko do jednego pola.

2. Przechowuj właściwości każdego obiektu w hashu Redis.

   INCR id:users
   HMSET user:{id} name "Fred" age 25
   SADD users {id}
   

   Zalety :uważany za „dobrą praktykę”. Każdy obiekt jest pełnoprawnym kluczem Redis. Nie ma potrzeby analizowania ciągów JSON. Wady :prawdopodobnie wolniej, gdy musisz uzyskać dostęp do wszystkich/większości pól w obiekcie. Ponadto zagnieżdżone obiekty (obiekty w obiektach) nie mogą być łatwo przechowywane.

3. Przechowuj każdy obiekt jako ciąg JSON w hashu Redis.

   INCR id:users
   HMSET users {id} '{"name":"Fred","age":25}'
   

   Pozwala to na pewną konsolidację i używanie tylko dwóch kluczy zamiast wielu kluczy. Oczywistą wadą jest to, że nie można ustawić TTL (i innych rzeczy) dla każdego obiektu użytkownika, ponieważ jest to tylko pole w skrótu Redis, a nie pełny klucz Redis.

   Zalety :Parsowanie JSON jest szybkie, zwłaszcza gdy potrzebujesz jednocześnie uzyskać dostęp do wielu pól dla tego obiektu. Mniej „zanieczyszczania” przestrzeni nazw klucza głównego. Wady :O tym samym zużyciu pamięci, co #1, gdy masz dużo obiektów. Wolniej niż #2, gdy potrzebujesz dostępu tylko do jednego pola. Prawdopodobnie nie jest uważany za „dobrą praktykę”.

4. Przechowuj każdą właściwość każdego obiektu w dedykowanym kluczu.

   INCR id:users
   SET user:{id}:name "Fred"
   SET user:{id}:age 25
   SADD users {id}
   

   Zgodnie z powyższym artykułem ta opcja jest prawie nigdy preferowane (chyba że właściwość obiektu musi mieć określony czas TTL lub coś takiego).

   Zalety :właściwości obiektu to w pełni rozwinięte klucze Redis, które mogą nie być przesadą dla Twojej aplikacji. Wady :powolny, zużywa więcej pamięci i nie jest uważany za „najlepszą praktykę”. Dużo zanieczyszczeń w głównej przestrzeni nazw kluczy.

Ogólne podsumowanie

Opcja 4 na ogół nie jest preferowana. Opcje 1 i 2 są bardzo podobne i obie są dość powszechne. Preferuję opcję 1 (ogólnie rzecz biorąc), ponieważ pozwala ona przechowywać bardziej skomplikowane obiekty (z wieloma warstwami zagnieżdżenia itp.). Opcja 3 jest używana, gdy naprawdę Ci zależy o nie zanieczyszczaniu głównej przestrzeni nazw klucza (tzn. nie chcesz, aby w Twojej bazie danych było wiele kluczy i nie przejmujesz się takimi rzeczami jak TTL, dzielenie klucza lub cokolwiek).

Jeśli coś mi się nie udało, rozważ pozostawienie komentarza i umożliwienie mi poprawienia odpowiedzi przed odrzuceniem. Dzięki! :)