Jak zoptymalizować wydajność MongoDB?

Question

Accepted Answer

Optymalizacja wydajności MongoDB skupia się na **indeksowaniu** (największy zysk), **projektowaniu schematu** pod kątem wzorców dostępu, wydajnych **zapytaniach** oraz użyciu narzędzi takich jak **`explain()`** do znalezienia wąskich gardeł. Jak zawsze: najpierw zmierz, potem napraw rzeczywisty problem — zwykle brakujące indeksy lub słabe projektowanie schematu.

## Indeksowanie jest największym zyskiem

```js
// use explain() to check if a query uses an index
db.users.find({ email: "ann@x.com" }).explain("executionStats");
// → look for: COLLSCAN (collection scan = BAD, no index) vs IXSCAN (index = GOOD)

db.users.createIndex({ email: 1 });   // add the missing index → fast
```

```text
✓ Index fields used in queries, sorts, and filters (the #1 optimization)
✓ Compound indexes for multi-field queries (mind the field order)
✓ explain() to verify queries use indexes (COLLSCAN = problem)
✓ Don't over-index (slows writes); index what's actually queried
```

## Projektowanie schematu pod kątem wzorców dostępu

```text
✓ EMBED data accessed together → single-query reads (no joins)
✓ Reference large/unbounded/shared data appropriately
✓ Design around your QUERIES (the access-pattern principle) → most reads = one document
→ Poor schema design (e.g. needing many $lookups, huge documents) hurts performance
  more than almost anything else in MongoDB.
```

## Optymalizacja zapytań

```text
✓ Use PROJECTION — return only needed fields (less data transferred)
✓ Filter early; use covered queries (all fields from the index → no document fetch)
✓ In aggregation pipelines, put $match (and $limit) EARLY to reduce data through the pipeline
✓ Avoid querying without the shard key on sharded collections (scatter-gather)
✓ Use limit/pagination; prefer range-based over deep skip()
```

## Inne techniki

```text
✓ Working set in RAM — frequently-accessed data + indexes should fit in memory
  (MongoDB caches in RAM; disk access is much slower)
✓ Connection pooling (drivers pool by default)
✓ Monitor: explain(), MongoDB profiler, Atlas Performance Advisor (suggests indexes)
✓ Avoid large/unbounded arrays; consider the bucket pattern for time-series
```

## Dlaczego to ważne

Optymalizacja wydajności MongoDB to cenną wiedzę na poziomie senior, niezbędną do utrzymania szybkości aplikacji MongoDB. Zrozumienie właściwego podejścia — sterowanego pomiarem, z indeksowaniem i projektowaniem schematu jako głównymi dźwigniami — jest ważne dla efektywnej optymalizacji.

**Największym pojedynczym zyskiem jest indeksowanie** (tak samo jak w bazach danych relacyjnych): brakujące indeksy powodują **przeskanowania kolekcji** (COLLSCAN — sprawdzanie każdego dokumentu, katastrofalne tempo wzrostu wraz z danymi), a dodanie odpowiednich indeksów na polach pytanych/sortowanych/filtrowanych zamienia je w szybkie przeskanowania indeksów — użycie **`explain()`** do weryfikacji, że zapytania korzystają z indeksów (wykrywanie problemów COLLSCAN), jest kluczową umiejętnością diagnostyczną. **Projektowanie schematu pod kątem wzorców dostępu** jest argumentacyjnie jeszcze bardziej wpływowe w MongoDB niż w SQL: projektowanie wokół zapytań (osadzanie razem dostępowanych danych dla pojedynczych odczytów, odpowiednie referencjonowanie), aby większość odczytów trafiała do jednego dokumentu, podczas gdy słabe projektowanie (wymagające wielu `$lookup`ów, ogromne dokumenty) znacznie wpływa na wydajność — czyniąc projektowanie schematu główną dźwignią optymalizacji, unikalną dla elastyczności MongoDB. **Optymalizacja zapytań** (projekcja zwracająca tylko potrzebne pola, zapytania obejmowane, umieszczanie `$match`/`$limit` na początku potoki agregacji w celu zmniejszenia przepływu danych, unikanie scatter-gather w kolekcjach shardowanych, efektywna paginacja) i zapewnienie, że **zestaw roboczy mieści się w RAM** (często dostępowane dane i indeksy buforowane w pamięci, ponieważ dysk jest znacznie wolniejszy) uzupełniają zestaw narzędzi.

**Dyscyplina sterowana pomiarem** (przy użyciu explain(), profilera i Atlas Performance Advisor do znalezienia i naprawy rzeczywistych wąskich gardeł — zwykle brakujące indeksy lub słabe projektowanie schematu) jest niezbędna.

Ponieważ wydajność MongoDB ma kluczowe znaczenie dla aplikacji, a właściwa optymalizacja (indeksowanie, projektowanie schematu, wydajność zapytań, zestaw roboczy w RAM) utrzymuje ją szybko w skali, zrozumienie optymalizacji wydajności MongoDB — szczególnie indeksowania (weryfikowanego za pomocą explain()) i projektowania schematu opartego na wzorcach dostępu jako głównych dźwigni — to cenną wiedzę na poziomie senior dla obsługi wydajnych aplikacji MongoDB, częsty problem i temat demonstrujący umiejętność systematycznej optymalizacji MongoDB.