Skip to content

Odpowiedzi egzamin - NoSQL

  • a) wyświetli informację, że baza moja_baza jeszcze nie istnieje
  • b) wyświetli podstawowe informacje techniczne o bazie moja_baza
  • c) wyświetli informację, że baza moja_baza już istnieje
  • d) utworzy nową bazę moja_baza, gdy taka jeszcze nie istnieje

Wyjaśnienie: use przełącza kontekst na wskazaną bazę i przygotowuje ją do utworzenia. Fizycznie baza powstaje dopiero po zapisaniu pierwszego dokumentu, ale z punktu widzenia użytkownika to polecenie ją tworzy.

2. Które polecenie wyświetli wszystkie bazy danych?

Section titled “2. Które polecenie wyświetli wszystkie bazy danych?”
  • a) show databases
  • b) show dbs -all
  • c) show alldbs
  • d) show dbs

Wyjaśnienie: Kanoniczne polecenie to show dbs. W nowszym mongosh działa też show databases (opcja a), więc to jedyna inna poprawna składnia, ale show dbs jest odpowiedzią wzorcową.

3. Jak nazywa się pole z unikalnym kluczem?

Section titled “3. Jak nazywa się pole z unikalnym kluczem?”
  • a) _id
  • b) id
  • c) ID
  • d) Id

Wyjaśnienie: MongoDB domyślnie przechowuje unikalny identyfikator w polu _id (z podkreślnikiem).

4. Które polecenie ukryje unikalne identyfikatory dokumentów?

Section titled “4. Które polecenie ukryje unikalne identyfikatory dokumentów?”
  • a) db.abc.find({},{“_id”:-1})
  • b) db.abc.find({“_id”:0})
  • c) db.abc.find({},{“_id”:0})
  • d) db.abc.find({}{“_id”:0})

Wyjaśnienie: Drugi argument find to projekcja. {"_id":0} wyłącza pole _id z wyniku. Opcja b ma to w filtrze (a nie projekcji), opcja d ma błąd składni (brak przecinka).

5. Czy można ustawić własną wartość _id przy tworzeniu dokumentu?

Section titled “5. Czy można ustawić własną wartość _id przy tworzeniu dokumentu?”
  • a) zależy od ustawień serwera
  • b) nie
  • c) tak
  • d) zależy od rodzaju kolekcji

Wyjaśnienie: Można podać własne _id. Jeśli się go nie poda, system generuje ObjectId automatycznie. Wartość musi być unikalna w kolekcji.

6. Rejestr klientów i zamówień (relacja 1:N) w DWÓCH plikach JSON

Section titled “6. Rejestr klientów i zamówień (relacja 1:N) w DWÓCH plikach JSON”
  • a) JSON z zagnieżdżoną tablicą (array)
  • b) drugi plik z referencją do pierwszego, podstawowego pliku
  • c) JSON zagnieżdżony w innym pliku JSON
  • d) takiej struktury nie zamodelujemy

Wyjaśnienie: Skoro mają być DWA pliki, modelujemy to przez referencję (zamówienie przechowuje klient_id wskazujący na klienta). Zagnieżdżanie (a, c) dałoby jeden plik.

7. Ile dokumentów zwróci db.zam.find({cena:{$ne:20}}) dla cen 10, 20, 20, 40, 50?

Section titled “7. Ile dokumentów zwróci db.zam.find({cena:{$ne:20}}) dla cen 10, 20, 20, 40, 50?”
  • a) dokładnie 1
  • (pozostałe opcje nieczytelne)

Poprawna odpowiedź: 3 dokumenty (10, 40, 50).

Wyjaśnienie: $ne:20 zwraca dokumenty, których cena jest różna od 20. Spośród pięciu pasują trzy. Zaznaczona opcja a (dokładnie 1) jest błędna.

  • a) wiersza w relacyjnej bazie danych
  • b) kolumny
  • c) widoku (view)
  • d) tabeli

Wyjaśnienie: Dokument odpowiada rekordowi (wierszowi). Kolekcja odpowiada tabeli.

9. Które polecenie wyświetli wszystkie kolekcje?

Section titled “9. Które polecenie wyświetli wszystkie kolekcje?”
  • a) show collection
  • b) show db.collections
  • c) show all collections
  • d) show collections

Wyjaśnienie: Poprawna składnia to show collections (liczba mnoga, bez dodatków).

10. db.posts.find({ likes:{$gte:200}, likes:{$lt:400} })

Section titled “10. db.posts.find({ likes:{$gte:200}, likes:{$lt:400} })”
  • a) polecenie jest błędne
  • b) lajki <= 400 i jednocześnie >= 200
  • c) lajki <= 200 i jednocześnie > 400
  • d) lajki < 400 i jednocześnie >= 200

Wyjaśnienie: Intencją jest przedział 200 <= likes < 400, czyli odpowiedź d. Uwaga techniczna: obiekt ma dwa razy klucz likes, więc w praktyce drugi nadpisuje pierwszy i realnie działa tylko $lt:400. Poprawnie należałoby napisać {likes:{$gte:200,$lt:400}}. Na egzaminie oczekiwana jest odpowiedź d.

11. Po którym poleceniu w wyniku pojawią się systemowe identyfikatory dokumentów?

Section titled “11. Po którym poleceniu w wyniku pojawią się systemowe identyfikatory dokumentów?”
  • a) db.emp.find({})
  • b) db.emp.find({“_id”:0})
  • c) db.emp.find({},{“_id”:0})
  • d) db.dept.find({},{“dname”:1,“_id”:0})

Wyjaśnienie: Domyślnie find zwraca _id. Opcje c i d jawnie je ukrywają (_id:0).

12. Po utracie serwera PRIMARY dalsze działanie

Section titled “12. Po utracie serwera PRIMARY dalsze działanie”
  • a) jest niemożliwe
  • b) jest możliwe
  • c) możliwe, ale tylko po ręcznej promocji przez administratora
  • d) wymaga restartu całego środowiska

Wyjaśnienie: Replica set automatycznie przeprowadza wybory (election) i promuje jeden z węzłów SECONDARY na PRIMARY. Nie wymaga to ręcznej interwencji ani restartu.

  • a) db.zamowienia.createIndex({klient:1})
  • b) db.zamowienia.createIndex({klient:-1})
  • c) db.zamowienia.createIndex({klient:1}, {unique: true})
  • d) db.zamowienia.createIndex({klient:1, unique: true})

Wyjaśnienie: unique to opcja indeksu, musi być w drugim argumencie (osobnym obiekcie), tak jak w c. W d wmieszano ją do definicji klucza, co jest błędne.


  • a) muszą mieć zdefiniowane właściwości
  • b) mogą mieć zdefiniowane właściwości
  • c) nie mogą mieć właściwości
  • d) nie mogą mieć etykiet

Wyjaśnienie: Właściwości są opcjonalne. Węzeł może istnieć bez nich.

  • a) nawiasami klamrowymi
  • b) nawiasami kwadratowymi
  • c) nawiasami trójkątnymi
  • d) nawiasami okrągłymi

Wyjaśnienie: Węzły zapisuje się w nawiasach okrągłych, np. (p:Person).

16. Właściwości (properties) ujmowane są

Section titled “16. Właściwości (properties) ujmowane są”
  • a) w nawiasy klamrowe
  • b) w nawiasy kwadratowe
  • c) w nawiasy trójkątne
  • d) w nawiasy okrągłe

Wyjaśnienie: Właściwości podaje się w nawiasach klamrowych, np. {name:'Smith'}.

17. Które oznaczenie węzła jest poprawne?

Section titled “17. Które oznaczenie węzła jest poprawne?”
  • a) (p:Person (name:‘Smith’))
  • b) (p:Person {name:Smith})
  • c) (p:Person {name Smith})
  • d) (p:Person {name:‘Smith’})

Wyjaśnienie: Właściwości w klamrach, para klucz dwukropek wartość, wartość tekstowa w apostrofach. Opcja b nie ma cudzysłowów wokół tekstu, c nie ma dwukropka.

18. Które polecenie usunie wszystkie węzły i relacje?

Section titled “18. Które polecenie usunie wszystkie węzły i relacje?”
  • a) MATCH (n) DETACH DELETE n
  • b) MATCH (n) DELATE n
  • c) MATCH (n) DETACH n
  • d) MATCH (n) DETACH n

Wyjaśnienie: DETACH DELETE usuwa węzeł razem z jego relacjami. Samo DELETE na węźle z relacjami zgłosiłoby błąd.

  • a) MATCH (m:Movie) RETURN m
  • b) MATCH (m:Movie) RETURN
  • c) MATCH (m:Movie) RETURN n
  • d) MATCH (m Movie) RETURN m

Wyjaśnienie: Zwracamy zmienną zdefiniowaną w MATCH (m). W c zwracane jest niezdefiniowane n, w b brakuje argumentu, w d brak dwukropka przy etykiecie.

20. Które oznaczenie relacji NIE jest poprawne?

Section titled “20. Które oznaczenie relacji NIE jest poprawne?”
  • a) <-[h:HIRED]->
  • b) -[h:HIRED]-
  • c) -[h:HIRED]->
  • d) <-[h:HIRED]<-

Wyjaśnienie: Poprawne kierunki to -[r]->, <-[r]- oraz -[r]- (bez kierunku). Opcja d ma strzałki po obu stronach skierowane w tę samą stronę, co jest niepoprawne. Uwaga: opcja a (<-[r]->, strzałki na obu końcach) też nie jest poprawnym Cypherem, więc to pytanie ma dwie błędne składnie. Odpowiedzią wzorcową jest d.

21. Które polecenie wyświetli wszystkie dane?

Section titled “21. Które polecenie wyświetli wszystkie dane?”
  • a) MATCH n RETURN n
  • b) NATCH (n) RETURN
  • c) MATCH (n) RETURN n
  • d) MATCH (n) RETURN ()

Wyjaśnienie: MATCH (n) RETURN n dopasowuje wszystkie węzły i je zwraca. W a brak nawiasów wokół n, b ma literówkę NATCH.

  • a) MATCH (m:Movie) RETURN m.title
  • b) MATCH (m:Movie) RETURN “*”
  • c) MATCH (m:Movie) RETURN m
  • d) MATCH (m:Movie) RETURN m:Movie

Wyjaśnienie: Zwrócenie całej zmiennej m odpowiada pobraniu wszystkich kolumn (*). Opcja a zwraca tylko jedno pole.

  • a) tylko dane węzłów
  • b) tylko relacje
  • c) dane węzłów oraz relacji między nimi
  • d) tylko etykiety węzłów

Wyjaśnienie: LOAD CSV pozwala tworzyć zarówno węzły, jak i relacje między nimi.

24. Usunięcie daty urodzenia z węzła (p:person {name:'Piotr', data_ur:'01-09-22'})

Section titled “24. Usunięcie daty urodzenia z węzła (p:person {name:'Piotr', data_ur:'01-09-22'})”
  • a) MATCH ({name:‘Piotr’}) SET n.data_ur = null
  • b) MATCH (n{name:‘Piotr’}) SET data_ur = null
  • c) MATCH (n{name:‘Piotr’}) DELETE data_ur
  • d) MATCH (n{name:‘Piotr’}) SET n.data_ur = null

Wyjaśnienie: Właściwość usuwa się przypisując jej null (lub przez REMOVE). Tylko d ma poprawnie powiązaną zmienną n i pełną składnię SET n.data_ur. W treści testu w opcji d widnieje nullx, co jest najprawdopodobniej literówką i powinno być null. W a zmienna n nie jest powiązana w MATCH, w b brak prefiksu n., w c DELETE nie usuwa właściwości.

  • a) MATCH (n {name:‘B’})-[r:XYZ]- DELETE r
  • b) MATCH (n {name:‘A’})-[r:XYZ]->() DELETE r
  • c) MATCH (n {name:‘B’})-[r:XYZ]->() DELETE r
  • d) MATCH (n {name:‘B’})-[r:XYZ]->() DROP r

Wyjaśnienie: Relacja wychodzi z B w stronę A, więc dopasowujemy ją od B (->) i usuwamy przez DELETE. W b kierunek wychodzi z A (źle), w d DROP nie jest poleceniem usuwania relacji.

26. Migracja 4 tabel (10, 20, 30, 40 rekordów) do Neo4j

Section titled “26. Migracja 4 tabel (10, 20, 30, 40 rekordów) do Neo4j”
  • a) 4 węzły i 100 etykiet
  • b) 100 węzłów i 100 etykiet
  • c) 100 węzłów i 4 etykiety
  • d) 100 węzłów i 40 etykiet

Wyjaśnienie: Każdy rekord to węzeł (10+20+30+40 = 100), a każda tabela to jedna etykieta (4 tabele = 4 etykiety).


  • a) po 30 minutach usunięcie klucza
  • b) klucz po 30 s staje się nieaktywny, ale nie zostaje skasowany
  • c) po 30 sekundach klucz zostanie usunięty
  • d) po 30 milisekundach klucz zostanie usunięty

Wyjaśnienie: EXPIRE ustawia czas życia w sekundach. Po upływie tego czasu klucz jest usuwany.

  • a) SET zm wart ex 10sec
  • b) SET zm 10sec
  • c) SET zm wart ex 10
  • d) SET zm 10 ex

Wyjaśnienie: Składnia to SET klucz wartość EX sekundy. EX przyjmuje liczbę sekund (10), nie 10sec.

  • a) SET mykey
  • b) SET my key
  • c) GET my
  • d) SETNX my key

Wyjaśnienie: SET wymaga klucza i wartości. SET mykey nie ma wartości. W b i d wartością staje się key.

30. GET dla nieistniejącego klucza zwróci

Section titled “30. GET dla nieistniejącego klucza zwróci”
  • a) null
  • b) (integer) 0
  • c) NA
  • d) (nil)

Wyjaśnienie: Redis dla brakującego klucza zwraca (nil).

31. HyperLogLog z 20000 unikalnych danych, PFCOUNT na pewno NIE zwróci

Section titled “31. HyperLogLog z 20000 unikalnych danych, PFCOUNT na pewno NIE zwróci”
  • a) 20150
  • b) 19990
  • c) 20200
  • d) 20001

Wyjaśnienie: Standardowy błąd HyperLogLog to ok. 0,81 procenta, czyli dla 20000 około plus minus 162. Wartości a, b, d mieszczą się w tym przedziale, a 20200 (odchylenie 200) wykracza poza margines, więc na pewno nie zostanie zwrócona.

  • a) QUEUED
  • b) EXEC
  • c) DISCARD
  • d) MULTI

Wyjaśnienie: MULTI otwiera blok transakcji, do którego kolejkowane są polecenia.

33. Polecenie wykonujące zarejestrowaną transakcję

Section titled “33. Polecenie wykonujące zarejestrowaną transakcję”
  • a) QUEUED
  • b) DISCARD
  • c) MULTI
  • d) EXEC

Wyjaśnienie: EXEC wykonuje wszystkie polecenia zakolejkowane po MULTI. DISCARD anulowałby transakcję.

  • a) Redis może zrzucać dane na dysk twardy
  • b) Redis zawsze co jakiś czas zrzuca dane na dysk twardy
  • c) Redis może tworzyć kopie na dysku za pomocą AOF
  • d) Redis może tworzyć kopie na dysku za pomocą RDB

Wyjaśnienie: Persystencja jest opcjonalna i konfigurowalna. Redis nie zapisuje na dysk “zawsze”, można ją całkowicie wyłączyć, więc b jest nieprawdą.

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

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

  • a) “a b”
  • b) “a”
  • c) żadna, 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.

  • a) “2+4”
  • b) “6”
  • c) błąd
  • d) nil

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

  • a) może być wartością numeryczną
  • b) musi być wartością numeryczną
  • c) jest generowany automatycznie
  • d) musi być liczbą całkowitą

Wyjaśnienie: Klucz to napis (binary safe string). Może składać się z cyfr, ale nie musi być liczbą i nie jest generowany automatycznie.

  • a) Redis przechowuje dane w pamięci operacyjnej lub na dysku, zależnie od konfiguracji w redis.conf
  • b) Redis przechowuje dane w plikach dyskowych
  • c) Redis czasami przechowuje dane w dokładnie jednym pliku
  • d) Redis przechowuje dane w pamięci operacyjnej

Wyjaśnienie: Redis działa w pamięci RAM, a opcjonalną persystencję (RDB lub AOF) konfiguruje się w redis.conf. Odpowiedź a najpełniej to opisuje. Odpowiedź d jest prawdziwa, ale pomija konfigurowalny zapis na dysk.

40. SET mykey "Hello", potem SET mykey "Witaj"

Section titled “40. SET mykey "Hello", potem SET mykey "Witaj"”
  • a) klucz zostanie nadpisany nową wartością
  • b) klucz nie zostanie nadpisany
  • c) błąd
  • d) powstanie nowy klucz, stary bez zmian

Wyjaśnienie: Domyślnie SET nadpisuje istniejącą wartość. Aby zapisać tylko gdy klucza nie ma, użyto by SETNX.

  • a) SET mykey
  • b) SET my key
  • c) GET my
  • d) SETNX my key

Wyjaśnienie: Tak jak w pytaniu 29, SET mykey nie ma wartości i jest niepoprawne.

  • a) SET klucz moje_dane
  • b) SET klucz “moje dane”
  • c) SET klucz =“moje dane”
  • d) SET klucz moje dane

Wyjaśnienie: Wartość ze spacją trzeba ująć w cudzysłów (jak w b). SET klucz moje dane rozbije się na zbyt wiele argumentów i zgłosi błąd. Uwaga: opcja c (zbędny znak =) również jest niepoprawna, więc to pytanie ma dwie błędne składnie. Odpowiedzią wzorcową, kontrastującą z poprawnym b, jest d.

43. Sekwencja: SET key a, SET key b, SET key 1, INCR key, INCR key

Section titled “43. Sekwencja: SET key a, SET key b, SET key 1, INCR key, INCR key”
  • a) “a”
  • b) “b”
  • c) “3”
  • d) “2”

Wyjaśnienie: Ostatnie SET ustawia wartość 1. Pierwsze INCR daje 2, drugie 3. Wynik to “3”.


  • a) 6
  • b) 7
  • c) 8
  • d) 9

Wyjaśnienie: Quorum liczy się jako floor(RF/2) + 1, czyli floor(15/2) + 1 = 7 + 1 = 8.

45. Klucz złożony Primary key (category, points), kolumna points to

Section titled “45. Klucz złożony Primary key (category, points), kolumna points to”
  • a) clustering key
  • b) Node key
  • c) Primary column
  • d) partition key

Wyjaśnienie: Pierwsza kolumna klucza złożonego to klucz partycjonujący (category), a kolejne to klucze klastrujące (points).

46. Tabela tab z primary key (imie). Które zapytanie nie wykona się poprawnie?

Section titled “46. Tabela tab z primary key (imie). Które zapytanie nie wykona się poprawnie?”
  • a) select * from tab where nazwisko like ‘Gramacki’ AND imie=‘Artur’ ALLOW FILTERING
  • b) SELECT imie from tab
  • c) SELECT * FROM tab WHERE nazwisko = ‘Gramacki’
  • d) select nazwisko from tab

Wyjaśnienie: Filtrowanie po kolumnie spoza klucza (nazwisko) bez ALLOW FILTERING zgłasza błąd, więc c się nie wykona. Uwaga: opcja a też jest problematyczna, bo LIKE wymaga specjalnego indeksu (SASI) nawet z ALLOW FILTERING. Odpowiedzią wzorcową jest c.

47. Tabela z primary key (imie, nazwisko). Które zapytanie się nie wykona?

Section titled “47. Tabela z primary key (imie, nazwisko). Które zapytanie się nie wykona?”
  • a) select* from tab where imie=‘X’ and nazwisko=‘Y’
  • b) select from tab where imie=‘X’ or nazwisko=‘Y’*
  • c) select* from tab where nazwisko=‘Y’ ALLOW FILTERING
  • d) select* from tab where imie=‘X’

Wyjaśnienie: CQL nie obsługuje operatora OR w klauzuli WHERE, więc b się nie wykona.

48. Dlaczego czasem wymagane jest ALLOW FILTERING?

Section titled “48. Dlaczego czasem wymagane jest ALLOW FILTERING?”
  • a) bo trzeba wyłączyć mechanizm filtrowania
  • b) bo w tabeli jest dużo danych
  • c) bo trzeba przejrzeć dane w praktycznie wszystkich węzłach, co bywa czasochłonne
  • d) bo chcemy filtrować dane jak w WHERE

Wyjaśnienie: Zapytanie nieoparte na kluczu partycjonującym wymaga przeszukania całego klastra, dlatego Cassandra wymusza świadome użycie ALLOW FILTERING.

  • a) każdy węzeł jest równouprawniony
  • b) niektóre węzły są bardziej uprawnione
  • c) można nadać węzłom szczególne uprawnienia
  • d) można ustawić węzły w trybie read-only

Wyjaśnienie: Cassandra ma architekturę bezmistrzową (peer to peer), wszystkie węzły są równorzędne.

50. Tabela tab z primary key (kraj, miasto). Które zapytanie wymaga ALLOW FILTERING?

Section titled “50. Tabela tab z primary key (kraj, miasto). Które zapytanie wymaga ALLOW FILTERING?”
  • a) select * from tab
  • b) select * from tab where kraj=‘PL’
  • c) select kraj from tab
  • d) select * from tab where miasto = ‘ZG’

Wyjaśnienie: miasto to klucz klastrujący. Zapytanie o niego bez podania klucza partycjonującego (kraj) wymaga ALLOW FILTERING. Zapytanie po kraj (b) takiej klauzuli nie potrzebuje.

  • a) może należeć do jakiejś przestrzeni kluczy
  • b) nie może należeć do jednej przestrzeni kluczy
  • c) musi mieć zdefiniowany klucz główny
  • d) może mieć zdefiniowany klucz główny

Wyjaśnienie: Klucz główny jest obowiązkowy dla każdej tabeli w Cassandrze.


52. W modelu relacyjnym zakłada się, że

Section titled “52. W modelu relacyjnym zakłada się, że”
  • a) każda kolumna zawiera dane tego samego typu
  • b) każda kolumna może zawierać dane tego samego typu
  • c) zwykle każda kolumna zawiera dane tego samego typu
  • d) większość kolumn zawiera dane tego samego typu

Wyjaśnienie: W modelu relacyjnym każda kolumna ma ściśle określony typ, więc wszystkie jej wartości są tego samego typu.

53. Najlepsza struktura do modelu relacji 1:N w jednym pliku JSON

Section titled “53. Najlepsza struktura do modelu relacji 1:N w jednym pliku JSON”
  • a) drugi plik z referencją
  • b) plik JSON z zagnieżdżoną tablicą (array)
  • c) plik JSON z zagnieżdżonym zbiorem (set)
  • d) plik JSON z zagnieżdżoną listą (list)

Wyjaśnienie: W jednym pliku stronę N osadzamy jako tablicę (array) wewnątrz dokumentu nadrzędnego. Referencja (a) wymagałaby dwóch plików.

  • a) poprawa szybkości dostępu do danych
  • b) poprawa szybkości odczytu
  • c) poprawa niezawodności przechowywania danych
  • d) poprawa szybkości zapisu

Wyjaśnienie: Replikacja przede wszystkim zwiększa niezawodność i dostępność (dane przetrwają awarię węzła). Szybszy odczyt to efekt uboczny.

55. Które zdanie najlepiej oddaje istotę baz NoSQL?

Section titled “55. Które zdanie najlepiej oddaje istotę baz NoSQL?”
  • a) spójność danych jest mniej istotna niż szybkość działania
  • b) szybkość nie jest osiągana kosztem spójności
  • c) spójność i szybkość mają podobny priorytet
  • d) priorytetem jest spójność danych

Wyjaśnienie: Bazy NoSQL często stosują model BASE i poświęcają część spójności na rzecz wydajności i dostępności.

  • a) sposób kompresji danych
  • b) metodologia przetwarzania dużych zbiorów danych w środowisku rozproszonym
  • c) metodologia mapowania i jednoczesnego redukowania danych
  • d) sposób rozproszonego przechowywania danych

Wyjaśnienie: Map reduce to model przetwarzania równoległego dużych zbiorów danych w klastrze (faza map i faza reduce).

  • a) zdecydowanie poprawia niezawodność i bezpieczeństwo wszystkich danych
  • b) zdecydowanie zmniejsza szybkość dostępu
  • c) odpowiednio skonfigurowany zdecydowanie poprawia niezawodność i bezpieczeństwo
  • d) nie poprawia niezawodności i bezpieczeństwa przechowywania wszystkich danych

Wyjaśnienie: Sharding (podział danych na fragmenty między węzłami) służy skalowalności i wydajności, a nie niezawodności. Za niezawodność odpowiada replikacja. Sam sharding może wręcz zwiększać ryzyko (awaria węzła to utrata jego fragmentu).

58. Z którą bazą kojarzymy skróty RDB i AOF?

Section titled “58. Z którą bazą kojarzymy skróty RDB i AOF?”
  • a) redis
  • b) mongodb
  • c) cassandra
  • d) neo4j

Wyjaśnienie: RDB (snapshoty) i AOF (append only file) to dwa mechanizmy persystencji w Redisie.