MongoDB Academy · 강의

Skip과 Limit: 오프셋 페이지 매김

학습자는 skip()과 limit()으로 전통적인 페이지 번호 방식의 페이지 매김을 구현하고, 대규모 컬렉션에서 발생하는 성능 비용을 측정합니다.

Skip과 Limit: 오프셋 페이지 매김은(는) CoddyKit의 무료 MongoDB Academy 강의입니다. 이것은 4개 중 2번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 MongoDB Academy 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. MongoDB Academy 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

What Is Offset Pagination?

Offset pagination—also called page-number pagination—divides results into fixed-size pages and uses a page number to determine how far into the result set to start. Page 1 shows items 1-20, page 2 shows items 21-40, and so on. In MongoDB this is implemented with skip() to jump over earlier results and limit() to restrict how many documents are returned per page.

Using skip() and limit()

limit(N) tells the cursor to return at most N documents. skip(N) tells MongoDB to skip the first N documents before returning any results. Together they implement page-number pagination: to get page P with size S items per page, use skip((P-1)*S) and limit(S).

const PAGE = 3;
const PAGE_SIZE = 20;

// Page 3 of 20 results per page
const products = await db.collection('products')
  .find({ isActive: true })
  .sort({ createdAt: -1 })
  .skip((PAGE - 1) * PAGE_SIZE)  // skip 40 docs (pages 1 and 2)
  .limit(PAGE_SIZE)               // return next 20
  .toArray();

console.log('Page 3 results:', products.length);

Counting Total Pages

Offset pagination usually requires a total document count to display page numbers in the UI. Use countDocuments(filter) to count matching documents before applying pagination. Run the count and the paged query in parallel to avoid adding latency. The total count divided by the page size (rounded up) gives the total number of pages.

const filter = { isActive: true };

const [total, results] = await Promise.all([
  db.collection('products').countDocuments(filter),
  db.collection('products')
    .find(filter)
    .sort({ createdAt: -1 })
    .skip((PAGE - 1) * PAGE_SIZE)
    .limit(PAGE_SIZE)
    .toArray()
]);

const totalPages = Math.ceil(total / PAGE_SIZE);
console.log('Total:', total, 'Pages:', totalPages);

The Hidden Cost of skip()

MongoDB implements skip() by scanning and discarding the first N documents. Even with an index, MongoDB must walk through and count N index entries before returning results. On page 1, skip is 0—fast. On page 500 with 20 items per page, skip is 9980—MongoDB must traverse nearly 10,000 entries just to find where page 500 starts. This is the core performance problem with offset pagination.

O(skip + limit) Query Complexity

The time to execute a skip/limit query grows linearly with the skip amount. The query cost is O(skip + limit)—the server must examine skip documents before returning limit documents. For page 1 this is O(20); for page 1000 with 20 items per page it is O(20020). As users navigate to higher page numbers, queries get progressively slower, often going from milliseconds to seconds on large collections.

When Offset Pagination Is Acceptable

Despite its performance limitations, offset pagination is acceptable in these scenarios: (1) the collection has fewer than a few thousand documents; (2) users rarely navigate beyond the first few pages; (3) the feature requires jumping directly to a page number (e.g., 'go to page 47'). Many admin dashboards and search results with low page depth fit this profile. Use keyset pagination for infinite scroll or large data sets.

Implementing an API Endpoint With Offset Pagination

A typical REST list endpoint accepts page and limit query parameters, validates them, and applies skip/limit accordingly. Always cap the maximum limit to prevent clients from requesting thousands of documents in a single call, which would exhaust server memory.

// Express route: GET /api/products?page=2&limit=20
async function listProducts(req, res) {
  const page  = Math.max(1, parseInt(req.query.page)  || 1);
  const limit = Math.min(100, parseInt(req.query.limit) || 20); // cap at 100
  const skip  = (page - 1) * limit;

  const [total, items] = await Promise.all([
    Product.countDocuments({ isActive: true }),
    Product.find({ isActive: true }).sort('-createdAt').skip(skip).limit(limit).lean()
  ]);

  res.json({ page, limit, total, totalPages: Math.ceil(total / limit), items });
}

Data Consistency Issues With Offset Pagination

Offset pagination has a subtle correctness problem: if documents are inserted or deleted between page requests, items can shift positions in the sorted result set. A document inserted between page 1 and page 2 pushes every subsequent document forward, causing one item to appear on both pages (duplicate) or be skipped entirely. This is called the page drift problem and is inherent to offset pagination.

Estimating vs Exact Count

For very large collections, countDocuments(filter) can be slow because it scans the index. An alternative is estimatedDocumentCount(), which is O(1) but counts all documents in the collection without applying a filter. For simple cases where you want the total without filtering, the estimated count is much faster. For filtered counts on large collections, consider caching the count or using Atlas's faceted search.

// O(1) but no filter support
const approxTotal = await db.collection('products').estimatedDocumentCount();

// Exact count with filter (slower on large collections)
const exactTotal = await db.collection('products').countDocuments({ isActive: true });

Combining skip/limit With Projections

Always combine pagination with a tight projection for list endpoints. Fetching all fields while paginating defeats the purpose: you're still paying to transfer full document payloads for every page. A projection that returns only summary fields (name, price, thumbnail) reduces bandwidth by 80-95% compared to fetching full documents, making pagination viable at larger page offsets.

const SUMMARY = { _id: 1, name: 1, price: 1, thumbnailUrl: 1, rating: 1 };

const items = await db.collection('products')
  .find({ isActive: true })
  .projection(SUMMARY)
  .sort({ rating: -1 })
  .skip((PAGE - 1) * PAGE_SIZE)
  .limit(PAGE_SIZE)
  .toArray();

When to Switch to Keyset Pagination

Switch from offset to keyset (cursor) pagination when: users scroll infinitely through results (no page numbers needed), the collection has more than 100,000 documents, page load times increase noticeably for higher page numbers, or data changes frequently between page requests. Keyset pagination is always O(log n) regardless of position in the result set, because it uses a range query on an indexed field instead of skip.

Quick Check

Test your understanding of MongoDB & NoSQL Databases concepts from this lesson.

Lesson Recap

In this lesson you learned: offset pagination uses skip((page-1)*size) and limit(size) to fetch a page, skip() scans and discards documents so deep pages become progressively slower, and offset pagination is acceptable for small collections or shallow page depths but keyset pagination is better at scale. Next up we implement keyset pagination with range queries for consistent O(log n) performance.

자주 묻는 질문

“Skip과 Limit: 오프셋 페이지 매김” 강의는 무료인가요?

네 — “Skip과 Limit: 오프셋 페이지 매김” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 MongoDB Academy 강의 전체를 잠금 해제할 수 있습니다. MongoDB Academy 강의에는 총 4개의 강의가 포함되어 있습니다.

“Skip과 Limit: 오프셋 페이지 매김”에서 뭘 배우나요?

학습자는 skip()과 limit()으로 전통적인 페이지 번호 방식의 페이지 매김을 구현하고, 대규모 컬렉션에서 발생하는 성능 비용을 측정합니다. 브라우저에서 직접 실행하는 실습 코드로 MongoDB Academy을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

MongoDB Academy을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 MongoDB Academy은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 2번째 강의입니다.

“Skip과 Limit: 오프셋 페이지 매김” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 MongoDB Academy 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 MongoDB Academy 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← MongoDB Academy(으)로 돌아가기