Aggregation pipeline — conveyor belt của MongoDB

Trước khi nói về $group, mình cần chắc rằng bạn hình dung được aggregation pipeline hoạt động thế nào.

Hãy tưởng tượng một dây chuyền sản xuất trong nhà máy. Nguyên liệu thô (documents trong collection) đi vào đầu dây chuyền, đi qua từng trạm xử lý (stage), và ra thành phẩm ở cuối.

Mỗi stage nhận output của stage trước, xử lý, rồi đẩy kết quả sang stage tiếp theo.

Collection
    │

$sort — sắp xếp documents

$sort là stage đơn giản nhất. Nó nhận tất cả documents từ stage trước, sắp xếp theo field bạn chỉ định, rồi đẩy ra theo thứ tự mới.

Python

# Sort theo created_at giảm dần (mới nhất lên đầu)
{"$sort": {"created_at": -1}}

Nếu bạn chỉ dùng $match → → , thứ tự output luôn đúng. Không có gì bất ngờ ở đây.

$group — kẻ phá hoại thứ tự

$group gom documents lại theo một field (gọi là _id của group). Ví dụ: gom tất cả orders theo customer_id, rồi lấy order mới nhất của mỗi customer bằng $first.

Python

{
    "$group": {
        "_id":

Tại sao $group không giữ thứ tự output?

Phần này hơi tricky, nhưng hiểu được nó sẽ giúp bạn tránh cả một lớp bugs tương tự.

Hãy nghĩ về cách $group xử lý bên trong. Khi MongoDB nhận được 1000 documents cần group theo customer_id, nó cần:

1. Đọc từng document
2. Xem customer_id là gì
3. Tìm xem nhóm cho customer_id đó đã tồn tại chưa
4. Nếu chưa → tạo nhóm mới. Nếu rồi → merge vào nhóm có sẵn

Bước 3 — “tìm xem nhóm đã tồn tại chưa” — đòi hỏi một hash table (hay tương tự). MongoDB dùng hash table nội bộ để tra cứu nhanh group nào đã có.

Và đây là vấn đề: hash table không có khái niệm thứ tự. Nó được thiết kế để tra cứu nhanh O(1), không phải để giữ thứ tự chèn vào.

Khi $group hoàn thành và cần đẩy kết quả sang stage tiếp theo, nó iterate qua hash table. Thứ tự iterate phụ thuộc vào implementation nội bộ của hash — nó có thể thay đổi giữa các lần chạy, giữa các phiên bản MongoDB, thậm chí giữa các lần restart server.

⚠️ Đây là lý do kết quả “ngẫu nhiên” mỗi lần refresh. Không phải MongoDB random — mà là thứ tự hash table không deterministic từ góc nhìn của bạn.

Quay lại ẩn dụ nhà máy: giống như trạm . Sản phẩm đi vào theo thứ tự, được phân loại vào từng thùng (mỗi thùng = 1 customer). Bên trong mỗi thùng, sản phẩm vẫn xếp đúng thứ tự. Nhưng khi các thùng được đẩy ra khỏi trạm? Thùng nào ra trước phụ thuộc vào vị trí nó nằm trong kho — không ai sắp xếp thứ tự các thùng cả.

Pipeline bị lỗi — phân tích từng bước

Hãy xem pipeline gốc và trace xem data đi qua từng stage thế nào.

Python

pipeline = [
    {"$match": {"user_id": user_id}},
    {"$sort": {"created_at": -1}},       # Stage 2

Giải pháp: sort 2 lần — mỗi lần một mục đích

Fix thực ra rất đơn giản khi đã hiểu nguyên nhân: thêm $sort thứ hai SAU $group.

Python

pipeline = [
    {"$match": {"user_id": user_id}},

Edge case mà bạn sẽ gặp: timestamp trùng lặp

Bạn đã fix xong, test pass, deploy lên staging. Mọi thứ ngon. Rồi trên production, thứ tự lại “lung tung” ở một vài records.

Nguyên nhân: nhiều orders có cùng created_at. Điều này xảy ra thường xuyên hơn bạn nghĩ — bulk import, race conditions khi nhiều request đến cùng lúc, hoặc đơn giản là timestamp chỉ chính xác đến giây.

Khi hai documents có cùng created_at, MongoDB không biết cái nào “đứng trước”. Mỗi lần chạy, nó có thể chọn thứ tự khác.

Fix: thêm _id làm tiebreaker. _id (ObjectId) luôn unique nên đảm bảo thứ tự xác định ngay cả khi created_at trùng.

Python

Code hoàn chỉnh

Đây là phiên bản production-ready, xử lý cả trường hợp user truyền sort params động:

Python

def get_orders_with_deduplication(

Ngoài $group — những stage khác có phá thứ tự không?

Câu hỏi hay mà mình từng tự hỏi sau khi fix bug này.

Không phải mỗi $group. Trong aggregation pipeline, có một nhóm stages mà MongoDB gọi là blocking stages — chúng cần đọc TẤT CẢ documents đầu vào trước khi bắt đầu output. Và thứ tự output phụ thuộc vào implementation nội bộ, không phải thứ tự input.

Các blocking stages cần cẩn thận:

• $group — như mình vừa phân tích, output order không xác định
• $bucket / $bucketAuto — tương tự $group, gom vào buckets, thứ tự output phụ thuộc bucket boundaries
• $sortByCount — gom + sort theo count, nhưng documents cùng count thì thứ tự không xác định
• — mỗi facet chạy pipeline riêng, thứ tự trong mỗi facet phụ thuộc pipeline đó

Cái giá của sort 2 lần

Bạn có thể thắc mắc: sort 2 lần có chậm không?

Câu trả lời ngắn: có tốn thêm, nhưng thường không đáng lo.

Sort #1 chạy trên dataset đầy đủ (trước $group). Sort #2 chạy trên dataset đã deduplicate (sau $group) — nhỏ hơn nhiều. Nếu bạn có 10,000 orders từ 500 customers, sort #1 sort 10,000 documents nhưng sort #2 chỉ sort 500.

Nếu thật sự cần optimize, đảm bảo field sort có index:

Python

# Compound index cho sort + group
Order.collection.create_index([
    ("user_id", 1),

Thứ tự kiểm tra khi debug sort issues

Nếu bạn gặp kết quả sort “lung tung” trong aggregation pipeline, check theo thứ tự:

1. Có $group (hoặc blocking stage khác) sau $sort không? → Thêm sort thứ 2
2. Sort field có giá trị trùng lặp không? → Thêm _id tiebreaker
3. Sort field có index không? → Nếu dataset lớn, cần compound index
4. $skip + $limit có nằm SAU sort cuối cùng không? → Nếu không, pagination sẽ sai

Bốn câu hỏi này cover phần lớn sort bugs mình từng gặp với MongoDB aggregation.

Suy nghĩ cuối

Bug này dạy mình một bài học rộng hơn MongoDB: đừng giả định về thứ tự trừ khi bạn tường minh yêu cầu nó.

Hash tables không giữ thứ tự. Goroutines không chạy theo thứ tự bạn spawn. Network packets không đến theo thứ tự gửi. Kafka partitions không đảm bảo thứ tự across partitions.

Mỗi khi bạn cần thứ tự, hãy nói rõ — bằng $sort, bằng sequence number, bằng timestamp + tiebreaker. Hệ thống không đoán ý bạn.

Và nếu bạn đang dùng $group trong MongoDB aggregation pipeline ngay lúc này — mở code lên kiểm tra xem có sort thứ 2 sau nó chưa. Có thể bạn đang ship một bug mà chưa ai phát hiện.