Wszystko zależy od tego, jak zamierzasz z niego korzystać. Jeśli liczy się każdy bajt, np. kiedy musisz zapłacić za każdy przeniesiony kB do usługi w chmurze, możesz obliczyć koszty. Matematyka jest prosta; bajt to bajt „na przewodzie”. Wewnątrz redis, dla większych wartości jest to równie proste. W przypadku mniejszych wartości Redis wykonuje pewną optymalizację pamięci.
W swoim HSET na przykład rozdzielasz członków, co ma sens tylko wtedy, gdy potrzebujesz ich odseparowanych od siebie przez większość czasu. Lepsze podejście -móg- be:HSET user:data 987654321 '{"loc": "123456", "time": "2014-01-01T13:00:00"}' . Oddzielne klucze/elementy składowe „kosztują” znacznie więcej niż dłuższe ciągi, jeśli chodzi o wydajność. Możesz nawet umieścić całą tabelę lub zestaw danych w jednym elemencie, jeśli ma być używany tylko jako jedna kompletna jednostka półstatyczna.
Szybkość i rozmiar:istnieje znacząca różnica między klawiszami i wartości .
Klawisze: Krótszy jest ogólnie bardziej wydajny pod względem pamięci, a także wydajny. Jeśli używasz redis posortowanego zestawu, możesz nawet użyć 'liczb' jako kluczy (posortowany zestaw 'członkowie' plus 'punkty'). Mówię „liczby”, ponieważ wynik jest technicznie float64, ale aby mógł być użyty jako identyfikator, musi mieścić się w zakresie od -999999999999999 do 999999999999999 włącznie (to 15 cyfr), bez części ułamkowej. Może to być naprawdę pomocne, ponieważ Redis wykonuje szybkie i skalowalne sortowanie posortowanych zestawów w locie O(log(n)) (przy użyciu list pomijania, uproszczone).
Wartości: Format MsgPack (nieskompresowany) zajmuje najmniej miejsca, zwłaszcza jeśli przechowujesz definicje raz, a wartości wiele. JSON jest nieco mniej wydajny pod względem pamięci, ale jest oczywiście tak powszechnym formatem IPC, że nie należy go pomijać. Surowe ciągi znaków, oddzielone znakami, stała długość (ugh), cokolwiek chcesz, możesz użyć. Zawsze możesz skompresować swoje dane przed zapisaniem ich w Redis. Jak dotąd wydajność pamięci . Jeśli chodzi o szybkość , to mniej proste. Jeśli chcesz używać skryptów po stronie serwera Lua (co powinieneś), nie możesz nic zrobić ze skompresowanymi danymi. JSON i MsgPack można zdeserializować, ale tylko „jako całość”. Co jest w porządku w większości scenariuszy. Najbardziej elastyczne jest przechowywanie oddzielnych wartości (na przykład jako członków HSET), ale ma to również swoją cenę (w większości przypadków:zbyt wysoka cena). Możesz również połączyć to wszystko. Czego używamy najczęściej:prefiks składający się z dwóch lub trzech wartości oddzielonych ogranicznikami, po których następuje ładunek MsgPack.
Moja ogólna rada to:zacznij od używania tylko HSET i ZSET, nie rozdzielaj danych, które należą do siebie, używaj opisowych nazw PascalCased dla swoich kluczy o długości od 10 do 25 znaków, użyj ':', jeśli potrzebujesz ograniczników w swoich kluczach (przestrzeniach nazw) , serializuj jako JSON (dla uproszczenia, ale kod ułatwiający przejście do MsgPack), użyj skryptów Lua (nawet jeśli nie znasz Lua, podzbiór, którego używasz w Redis, jest mały).
Nie martwiłbym się tym zbytnio w fazie początkowej twojego projektu, zawsze możesz to zmienić później i zrobić kilka porównań A/B, gdy tylko będziesz miał jakieś dane, które można interpolować.
Mam nadzieję, że to pomoże, TW
