Test z Redis

1. W czasie instalacji serwera

• a) tworzony jest domyślny użytkownik o nazwie default bez żadnych uprawnień
• b) tworzony jest domyślny użytkownik o nazwie default z pełnymi uprawnieniami
• c) nie tworzy się żaden domyślny użytkownik
• d) tworzony jest domyślny użytkownik o nazwie default i jego konto zostaje zablokowane

Wyjaśnienie: Redis zakłada użytkownika default z pełnym dostępem (wszystkie polecenia, bez hasła), dopóki nie skonfiguruje się ACL. To on obsługuje połączenia zaraz po instalacji.

2. SET a b oraz SET "a" "b". Które zdanie jest prawdziwe?

• a) oba polecenia są poprawne
• b) tylko polecenie pierwsze jest poprawne
• c) tylko polecenie drugie jest poprawne
• d) oba polecenia są niepoprawne

Wyjaśnienie: Redis akceptuje argumenty z cudzysłowami i bez nich. Oba zapisują klucz a z wartością b.

3. Wartość klucza key po: SET key a, SET key b, SET key 1, INCR key, INCR Key

• a) “a”
• b) “b”
• c) “2”
• d) “3”

Wyjaśnienie: Klucze w Redisie są wrażliwe na wielkość liter. Ostatnie SET key 1 ustawia key na 1, pierwsze INCR key daje 2. Drugie polecenie to INCR Key (wielka litera K), czyli operacja na innym, nieistniejącym kluczu Key (powstaje on i przyjmuje 1). Wartość klucza key pozostaje więc 2. Gdyby oba INCR dotyczyły key pisanego małą literą, wynik wynosiłby “3”.

4. Jaką wartość przyjmie klucz key zdefiniowany poleceniem SET key a b?

• a) “a b”
• b) “a”
• c) żadną, bo polecenie jest błędne
• d) “b”

Wyjaśnienie: Po wartości a token b jest traktowany jako opcja, a b nie jest poprawną opcją (EX, PX, NX, XX itd.), więc Redis zgłasza błąd składni i klucz nie powstaje.

5. Tworzymy klucz SET key 1. Jaki komunikat zwróci TYPE key?

• a) string
• b) number
• c) done
• d) 1

Wyjaśnienie: SET zapisuje wartości jako napisy, więc TYPE zwróci string, nawet gdy wartością są same cyfry.

6. Czy po utworzeniu klucza można zmienić jego nazwę?

• a) nie
• b) tak, ale tylko klucza typu string
• c) tak, ale tylko klucza bez ustawionego czasu życia (time out key)
• d) tak

Wyjaśnienie: Polecenie RENAME działa na kluczu dowolnego typu, niezależnie od tego, czy ma ustawiony czas życia (TTL).

7. Co spowoduje wykonanie polecenia SET key1 a key2 b?

• a) utworzone zostaną dwa klucze
• b) utworzony zostanie jeden klucz
• c) nic, polecenie jest błędne
• d) ustawione zostaną nowe wartości kluczy key1 oraz key2

Wyjaśnienie: SET ustawia tylko jeden klucz. Po wartości a token key2 zostanie potraktowany jako opcja, której Redis nie rozpoznaje, więc zgłosi błąd składni.

8. Mamy SET key1 1 oraz SET key2 2. Co spowoduje SET key3 = key1 + key2?

• a) wyświetli się komunikat nil
• b) klucz key3 przyjmie wartość 3
• c) polecenie nie wykona się, zgłoszony zostanie błąd
• d) klucz key3 przyjmie wartość nieokreśloną

Wyjaśnienie: Redis nie wykonuje działań arytmetycznych ani nie odwołuje się do wartości innych kluczy. Wartością key3 zostałby napis =, a kolejne tokeny (key1, +, key2) to nadmiarowe argumenty, przez co zgłaszany jest błąd składni.

9. Jaką wartość przyjmie klucz key po SET key 2+4?

• a) “2+4”
• b) “6”
• c) polecenie nie wykona się, zgłoszony zostanie błąd
• d) wyświetli się komunikat nil

Wyjaśnienie: Redis przechowuje wartości jako napisy i nie wykonuje obliczeń. Zapisany zostaje dosłowny tekst 2+4.

10. Co spowodują dwa polecenia: SET key 2.6 oraz INCR key?

• a) drugie polecenie nie wykona się, zgłoszony zostanie błąd
• b) drugie polecenie wykona się poprawnie, ale zgłoszone zostanie ostrzeżenie
• c) drugie polecenie wykona się bez żadnego ostrzeżenia
• d) drugie polecenie nie wykona się, ale żaden błąd nie zostanie zgłoszony

Wyjaśnienie: INCR działa tylko na wartościach będących liczbami całkowitymi. 2.6 to liczba zmiennoprzecinkowa, więc Redis zwróci błąd value is not an integer or out of range.

11. Sekwencja: SET key 1, SETNX key 2, SET key 3. Zawartość klucza key?

• a) 1
• b) 2
• c) 3
• d) nieokreślona

Wyjaśnienie: SET key 1 ustawia 1. SETNX ustawia wartość tylko, gdy klucz nie istnieje, więc tutaj nic nie robi. SET key 3 nadpisuje wartość na 3.

12. Klucz SET key abcdef. Co zwróci GETRANGE key 1 3?

• a) “abc”
• b) “ab”
• c) “bcd”
• d) “bc”

Wyjaśnienie: GETRANGE zwraca podciąg po indeksach (od zera) i włącza oba końce. Znaki o indeksach 1, 2, 3 napisu abcdef to b, c, d, czyli bcd.

13. Polecenia (klucz key wcześniej nie istniał): LPUSH key a b c, LPUSH key d, RPUSH key e. Wynik LRANGE key 0 10?

• a) “d” “c” “b” “a” “e”
• b) “a” “b” “c” “d” “e”
• c) “e” “d” “c” “b” “a”
• d) “a” “b” “c” “e” “d”

Wyjaśnienie: LPUSH key a b c wkłada elementy kolejno na początek listy: po a mamy [a], po b [b, a], po c [c, b, a]. LPUSH key d dokłada d na początek: [d, c, b, a]. RPUSH key e dokłada e na koniec: [d, c, b, a, e].

14. Te same polecenia co wyżej. Wynik LRANGE key 1 2?

• a) “a” “b”
• b) “b” “c”
• c) “c” “b”
• d) “a” “e”

Wyjaśnienie: Lista to [d, c, b, a, e]. Indeksy 1 i 2 (licząc od zera) to c i b.

15. Czy polecenie HSET key marka Seat model Leon 1.4 jest poprawne?

• a) tak
• b) nie
• c) tak, ale taka składnia nie jest zalecana
• d) tak, ale 1.4 nie zostanie zapisana jako liczba, ale jako string

Wyjaśnienie: HSET przyjmuje pary pole-wartość. Po kluczu mamy tokeny: marka Seat, model Leon oraz pojedynczy, niesparowany 1.4. Nieparzysta liczba argumentów powoduje błąd wrong number of arguments, więc polecenie jest niepoprawne.

16. Zbiory: SADD z1 elem1 elem2, SADD z2 elem2 elem3 elem4 elem4. Wynik SDIFF z1 z2?

• a) “elem1”
• b) “elem1”, “elem2”
• c) “nil”
• d) “empty set”

Wyjaśnienie: SDIFF z1 z2 zwraca elementy z z1, których nie ma w z2. z1 = {elem1, elem2}, z2 = {elem2, elem3, elem4} (powtórzony elem4 jest ignorowany). Różnica to {elem1}.

17. Te same zbiory. Wynik SDIFF z2 z1?

• a) “elem1”, “elem2”
• b) “elem1”
• c) “elem2”
• d) “elem3”, “elem4”

Wyjaśnienie: SDIFF z2 z1 to elementy z z2 nieobecne w z1, czyli {elem3, elem4}. Kolejność SDIFF ma znaczenie (to różnica, nie symetryczna).

18. Polecenie DISCARD

• a) jest funkcjonalnym odpowiednikiem znanego z relacyjnych baz danych polecenia ROLLBACK
• b) wykonuje wszystkie zapisane w kolejce polecenia i kończy działanie
• c) kasuje kolejkę transakcji i rozpoczyna nową kolejkę
• d) kasuje kolejkę transakcji i kończy działanie

Wyjaśnienie: DISCARD przerywa transakcję rozpoczętą przez MULTI: czyści kolejkę zakolejkowanych poleceń i wychodzi z trybu transakcji, więc pełni rolę odpowiednika ROLLBACK (anuluje transakcję). Uwaga: opcja d (kasuje kolejkę i kończy działanie) też trafnie opisuje mechanikę, więc jest broniona. Błędne są b (to opis EXEC) i c (DISCARD nie zakłada nowej kolejki).

19. Wykonano SADD key AA BB BB. Co wyświetli GET key?

• a) wyświetli trzy elementy zbioru, czyli AA BB BB
• b) wyświetli dwa elementy zbioru, czyli AA BB
• c) wyświetli informację, że w zbiorze są 3 elementy
• d) nic nie wyświetli (polecenie GET jest tu błędne)

Wyjaśnienie: SADD tworzy zbiór {AA, BB} (duplikat BB jest pomijany). GET działa tylko na kluczach typu string, a na zbiorze zwraca błąd WRONGTYPE, więc nie pokaże zawartości. Do odczytu zbioru służy SMEMBERS.

20. Wykonano SET key abc, a następnie LPUSH key def. Co się stanie?

• a) zostanie ustawiona nowa wartość klucza key
• b) polecenie zakończy się błędem
• c) polecenie wykona się poprawnie, ale wartość klucza nie zostanie zmieniona
• d) polecenie zwróci ostrzeżenie, ale wartość klucza zostanie zmieniona

Wyjaśnienie: key jest typu string, a LPUSH działa tylko na listach. Operacja na niewłaściwym typie zwraca błąd WRONGTYPE.

21. Czy SUNION może wyświetlić wynik dotyczący 3 różnych zbiorów?

• a) tak
• b) nie
• c) tak, ale zbiory muszą być równoliczne
• d) tak, ale zbiory muszą mieć przynajmniej jeden taki sam element

Wyjaśnienie: SUNION przyjmuje dowolną liczbę zbiorów i zwraca ich sumę (unię). Liczebność ani część wspólna nie mają znaczenia.

22. Po MULTI od razu wykonujemy EXEC. Co się stanie?

• a) polecenie wykona się poprawnie
• b) polecenie zakończy się błędem
• c) polecenie zwróci ostrzeżenie
• d) polecenie będzie czekać, aż użytkownik wpisze jakieś dane do kolejki (queue)

Wyjaśnienie: Pusta transakcja jest dozwolona. EXEC przy pustej kolejce wykona się poprawnie i zwróci pustą tablicę wyników.

23. Czy uprawnienie do tworzenia kluczy gwarantuje też prawo do skasowania klucza?

• a) tak
• b) nie
• c) tak, ale tylko w szczególnych przypadkach
• d) tak, ale tylko gdy klucz jest typu string

Wyjaśnienie: W systemie ACL Redisa uprawnienia nadaje się per polecenie. Prawo do tworzenia (np. SET) nie obejmuje automatycznie usuwania (DEL), to osobne uprawnienia.

24. Którym poleceniem wgramy kopię RDB do uruchomionej bazy?

• a) LOAD
• b) RESTORE
• c) UPLOAD
• d) nie ma takiego polecenia, Redis sam wykona to zadanie, gdy znajdzie właściwy plik na dysku

Wyjaśnienie: Kopię RDB wczytuje się, umieszczając plik dump.rdb w katalogu danych i uruchamiając Redis, który ładuje go automatycznie przy starcie. Nie ma polecenia wgrywającego cały plik RDB w trakcie pracy. RESTORE służy do odtwarzania pojedynczych kluczy z serializacji DUMP, a nie całej kopii.

25. W pierwszej sesji wykonano WATCH key oraz MULTI. Czy w drugiej sesji można zmienić ten klucz?

• a) tak
• b) nie
• c) pytanie nie ma jednoznacznej odpowiedzi
• d) tak, ale tylko wtedy, gdy w pierwszej sesji wykonano też polecenie EXEC

Wyjaśnienie: WATCH to mechanizm optymistycznej blokady, ale nie blokuje klucza. Druga sesja może go swobodnie zmienić. Skutkiem jest to, że transakcja w pierwszej sesji przy EXEC zakończy się niepowodzeniem (zwróci nil), ponieważ obserwowany klucz uległ zmianie.