Odpowiedzi egzamin - NoSQL
MongoDB
Section titled “MongoDB”1. W MongoDB polecenie use moja_baza
Section titled “1. W MongoDB polecenie use moja_baza”- a) wyświetli informację, że baza
moja_bazajeszcze nie istnieje - b) wyświetli podstawowe informacje techniczne o bazie
moja_baza - c) wyświetli informację, że baza
moja_bazajuż 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.
8. Dokument w MongoDB jest odpowiednikiem
Section titled “8. Dokument w MongoDB jest odpowiednikiem”- 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.
13. Które polecenie jest błędne?
Section titled “13. Które polecenie jest błędne?”- 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.
14. Węzły w Neo4j
Section titled “14. Węzły w Neo4j”- 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.
15. Węzły (nodes) oznaczane są
Section titled “15. Węzły (nodes) oznaczane są”- 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.
19. Które polecenie jest poprawne?
Section titled “19. Które polecenie jest poprawne?”- 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.
22. Odpowiednik SELECT * FROM Movie
Section titled “22. Odpowiednik SELECT * FROM Movie”- 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.
23. Import danych z CSV w Neo4j
Section titled “23. Import danych z CSV w Neo4j”- 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.
25. Usunięcie relacji (b)-[:XYZ]->(a)
Section titled “25. Usunięcie relacji (b)-[:XYZ]->(a)”- 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).
27. EXPIRE zmienna 30
Section titled “27. EXPIRE zmienna 30”- 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.
28. Klucz usuwany automatycznie po 10 s
Section titled “28. Klucz usuwany automatycznie po 10 s”- 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.
29. Które polecenie jest błędne?
Section titled “29. Które polecenie jest błędne?”- 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.
32. Polecenie rozpoczynające transakcję
Section titled “32. Polecenie rozpoczynające transakcję”- 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ę.
34. Które zdanie NIE jest prawdziwe?
Section titled “34. Które zdanie NIE jest prawdziwe?”- 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ą.
35. SET a b oraz SET "a" "b"
Section titled “35. SET a b oraz SET "a" "b"”- 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.
36. SET key a b
Section titled “36. SET key a 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.
37. SET key 2+4
Section titled “37. SET key 2+4”- 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.
38. Unikalny klucz w Redis
Section titled “38. Unikalny klucz w Redis”- 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.
39. Które zdanie jest prawdziwe?
Section titled “39. Które zdanie jest prawdziwe?”- 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.
41. Które polecenie jest błędne?
Section titled “41. Które polecenie jest błędne?”- 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.
42. Które polecenie jest błędne?
Section titled “42. Które polecenie jest błędne?”- 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”.
Cassandra
Section titled “Cassandra”44. RF = 15, ile wynosi CL (quorum)?
Section titled “44. RF = 15, ile wynosi CL (quorum)?”- 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.
49. W bazie Cassandra
Section titled “49. W bazie Cassandra”- 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.
51. W Cassandrze każda tabela
Section titled “51. W Cassandrze każda tabela”- 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.
Model relacyjny i NoSQL ogólnie
Section titled “Model relacyjny i NoSQL ogólnie”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.
54. Podstawowym celem replikacji jest
Section titled “54. Podstawowym celem replikacji jest”- 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.
56. Map reduce to
Section titled “56. Map reduce to”- 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).
57. Sharding
Section titled “57. Sharding”- 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.