|
Tworzenie aplikacji w Redis to przyjemny proces, ale jak w przypadku każdej technologii, jest kilka rzeczy, o których trzeba pamiętać podczas projektowania aplikacji opartych na Redis. Być może znałeś już całą procedurę tworzenia relacyjnych baz danych, a tworzenie aplikacji opartych na Redisie ma wiele podobieństw, ale musisz pamiętać o dwóch rzeczach – Redis to baza danych w pamięci i jest jednowątkowa. Dlatego korzystając z Redis, należy zwrócić uwagę na następujące punkty: 1. Kontrolować wszystkie klucze przechowywane w Redis Główną funkcją bazy danych jest przechowywanie danych, ale normalne jest, że deweloperzy ignorują niektóre dane przechowywane w bazie z powodu zmian w wymaganiach aplikacji lub metodach wykorzystania danych, podobnie jest w Redis. Możesz przeoczyć niektóre klucze, które wygasają, albo zapomnieć dane, ponieważ moduł Twojej aplikacji jest przestarzały. W obu przypadkach Redis przechowuje dane, które nie są już używane, zajmując miejsce bez powodu. Słabo ustrukturyzowany wzór danych Redis utrudnia określenie, co jest przechowywane centralnie, chyba że użyjesz bardzo dojrzałej nomenklatury kluczy. Zastosowanie odpowiedniej metody nazewnictwa uprości zarządzanie bazą danych, a gdy tworzysz przestrzeń nazw dla kluczy przez aplikację lub usługę (zwykle używając dwukropków do dzielenia nazw kluczy), możesz łatwo zidentyfikować dane podczas migracji, konwersji lub usuwania. Innym częstym przypadkiem użycia Redis jest stworzenie jako drugiego magazynu danych dla gorących elementów, gdzie większość danych jest przechowywana w innych bazach danych, takich jak PostgreSQL czy MongoDB. W takich przypadkach deweloperzy często zapominają usunąć odpowiadające dane w Redis, gdy dane są usuwane z pamięci głównej. W takim przypadku zwykle wymagane jest kascadowe usuwanie, które można osiągnąć poprzez zapisanie wszystkich identyfikatorów dla konkretnego elementu danych w konfiguracji Redis, aby po usunięciu danych w bazie głównej wezwany jest sprzątacz do usunięcia wszystkich istotnych kopii i informacji. 2. Kontrolować długość wszystkich nazw kluczy Jak wspomnieliśmy wyżej, zastosowaliśmy odpowiednie konwencje nazewnictwa i dodaliśmy prefiksy, aby określić, dokąd zmierzają dane, więc wydaje się, że to idzie z tym przeciwstawnie. Nie zapominaj jednak, że Redis to baza danych w pamięci, a im krótsze, tym mniej miejsca potrzebujesz. Naturalnie, gdy w bazie danych znajduje się miliony lub miliardy kluczy, długość nazwy klucza będzie miała duży wpływ. Na przykład na 32-bitowym serwerze Redis, jeśli przechowujesz milion kluczy o długości 32 znaków, zajmie to około 96MB miejsca przy użyciu 6-znakowej nazwy klucza, natomiast jeśli używasz 12-znakowej, zużycie miejsca wzrośnie do około 111MB. Przy większej liczbie kluczy dodatkowe 15% kosztów ogólnych będzie miało znaczący wpływ. 3. Używaj odpowiedniej struktury danych Niezależnie od tego, czy chodzi o zużycie pamięci, czy wydajność, czasami struktury danych mogą mieć duży wpływ – oto kilka najlepszych praktyk, do których warto się odwołać: Zamiast przechowywać dane jako tysiące (lub miliony) osobnych ciągów tekstowych, rozważ użycie zahashowanych struktur danych do grupowania powiązanych danych. Tablice skrótów są bardzo wydajne i mogą zmniejszyć zużycie plików; Jednocześnie haszowanie jest również bardziej korzystne dla abstrakcji szczegółów i czytelności kodu. Gdy to możliwe, używaj listy zamiast ustawień. Jeśli nie musisz korzystać z funkcji set, List może zapewnić szybsze prędkości niż set, zużywając przy tym mniej pamięci. Zbiory sortowane są najdroższymi strukturami danych, zarówno pod względem zużycia pamięci, jak i złożoności podstawowych operacji. Jeśli potrzebujesz tylko sposobu na zapytania do rekordów i nie zależy ci na sortowaniu takich właściwości, zdecydowanie zaleca się używanie tablic mieszających. Często pomijaną funkcją w Redis są bitmapy lub bitsety (po wersji 2.2). Bitsety pozwalają na wykonywanie wielu operacji na poziomie bitowym na wartościach Redis, takich jak lekka analiza. 4. Nie używaj klucza podczas korzystania ze skanowania Od wersji Redis 2.8 polecenie SCAN jest już dostępne i pozwala na pobranie kluczy z przestrzeni kluczy za pomocą kursora. W porównaniu z poleceniem KEYS, chociaż SCAN nie może zwrócić wszystkich dopasowanych wyników jednocześnie, unika wysokiego ryzyka zablokowania systemu, dzięki czemu niektóre operacje mogą być wykonywane na węźle głównym. Ważne jest, aby zauważyć, że komenda SCAN jest iteratorem opartym na kursorze. Za każdym razem, gdy wywołane jest polecenie SCAN, użytkownik otrzymuje nowy kursor, a użytkownik musi użyć go jako parametru kursora polecenia SCAN w kolejnej iteracji, aby kontynuować poprzedni proces iteracji. Jednocześnie, dzięki SCAN, użytkownicy mogą także dostosowywać polecenia za pomocą opcji nagród i liczby. Polecenia związane ze SCAN obejmują także polecenia SSCAN, HSCAN oraz ZSCAN, które są używane odpowiednio do kolekcji, kluczy skrótów i kontynuacji. 5. Używanie skryptów Lua po stronie serwera W procesie korzystania z Redus wsparcie skryptów Lua niewątpliwie zapewnia deweloperom bardzo przyjazne środowisko programistyczne, co znacznie uwalnia kreatywność użytkowników. Przy prawidłowym użyciu skrypty Lua mogą przynieść znaczącą poprawę wydajności i zużycia zasobów. Zamiast przekazywać dane do CPU, skrypty pozwalają wykonywać logikę najbliższą danym, zmniejszając opóźnienia sieciowe i redundantny transfer danych. W Reduis bardzo klasycznym zastosowaniem Lua jest filtrowanie lub agregacja danych do aplikacji. Poprzez zapakowanie procesu przetwarzania do skryptu, możesz po prostu wywołać go i uzyskać mniejszą odpowiedź, używając niewielkich zasobów w krótszym czasie. Porada profesjonalna:Lua jest świetna, ale ma też pewne problemy, takie jak trudności z zgłaszaniem i radzeniem sobie z błędami. Sprytnym podejściem jest użycie funkcji Pub/Sub w Rédis i pozwolenie skryptowi przesyłać wiadomości logowe przez dedykowany kanał. Następnie stwórz proces subskrypcyjny i przetwarzaj go odpowiednio.
| 
Opublikowano 29.12.2015 12:22:28
|
|
|
