Twoja wymarzona praca? Lets Git IT. Interaktywna platforma przygotowująca do rozmów technicznych dla nowoczesnych programistów.
© 2026 LetsGit.IT. Wszelkie prawa zastrzeżone.
Replica set vs sharding w MongoDB? | LetsGit.IT
LetsGit.IT / Kategorie / MongoDB Odpowiedź Replica set zapewnia wysoką dostępność: jedna instancja primary replikuje dane do secondary z automatycznym failoverem. Sharding daje skalowanie horyzontalne: dane są dzielone na shard’y według klucza shardowania i routowane przez mongos. Często stosuje się oba naraz.
Odpowiedź zaawansowana Głębiej Rozwinięcie krótkiej odpowiedzi — co zwykle ma znaczenie w praktyce:
Kontekst (tagi): replication , sharding , scalability, mongodb Model danych i dostęp: jakie zapytania dominują (read/write ratio, sortowanie, paginacja). Indeksy: kiedy pomagają, a kiedy szkodzą (write amplification, pamięć). Spójność i transakcje: co jest gwarantowane i gdzie trzeba uważać. Wytłumacz "dlaczego", nie tylko "co" (intuicja + konsekwencje). Trade-offy: co zyskujesz i co tracisz (czas, pamięć, złożoność, ryzyko). Edge-case’y: puste dane, duże dane, błędne dane, współbieżność. Przykłady Krótki przykład (query + projection):
// Example: query + projection
const user = await db.collection('users').findOne(
{ email: '[email protected] ' },
{ projection: { _id: 0, email: 1, name: 1 } },
)Typowe pułapki Zbyt ogólna odpowiedź (brak konkretów, brak przykładów). Brak rozróżnienia między "średnio" a "najgorzej" (np. złożoność). Pomijanie ograniczeń: pamięć, współbieżność, koszty sieci/dysku. Pytania uzupełniające na rozmowie Kiedy zastosował(a)byś alternatywę i dlaczego?
Jakie są typowe problemy w produkcji i jak je diagnozować?
Jak byś przetestował(a) edge-case’y? #mongodb