Bạn scale Django ở cấp database như thế nào?

Question

Accepted Answer

Khi một ứng dụng Django lớn lên, **database** thường là nút thắt cổ chai đầu tiên và đáng kể nhất. Scale nó bao gồm tối ưu truy vấn, đánh index, quản lý kết nối, read replica, caching, và cuối cùng là các thay đổi kiến trúc — giải quyết database là công việc scale có đòn bẩy cao nhất cho hầu hết các app Django.

## 1. Tối ưu truy vấn trước (thắng lợi lớn nhất, rẻ nhất)

```python
# ✅ loại bỏ truy vấn N+1 (vấn đề số 1) với select_related/prefetch_related
Book.objects.select_related("author").prefetch_related("tags")

# ✅ chỉ lấy các cột cần thiết
Article.objects.only("title", "created_at")        # SELECT chỉ những cái này
Article.objects.values("title")                     # dict, còn nhẹ hơn

# ✅ dùng tổng hợp database thay vì vòng lặp Python
from django.db.models import Count, Sum
Author.objects.annotate(book_count=Count("books"))  # để DB làm việc
```

Tối ưu truy vấn (sửa vấn đề N+1, chỉ chọn dữ liệu cần thiết, đẩy tổng hợp xuống database) thường mang lại lợi ích hiệu năng lớn nhất với ít nỗ lực nhất — làm điều này trước khi thêm hạ tầng.

## 2. Thêm index

```python
class Article(models.Model):
    slug = models.SlugField(db_index=True)              # đánh index một field hay truy vấn
    class Meta:
        indexes = [
            models.Index(fields=["author", "-created_at"]),  # composite index cho truy vấn phổ biến
        ]
```

Index tăng tốc đáng kể các truy vấn filter/order theo các cột đó — thiết yếu cho bất kỳ field nào bạn truy vấn thường xuyên (một index thiếu là nguyên nhân phổ biến của truy vấn chậm).

## 3. Connection pooling

```text
Tái sử dụng kết nối database thay vì mở một kết nối mỗi request (tốn kém ở quy mô lớn).
Dùng một pooler (PgBouncer cho PostgreSQL) hoặc CONN_MAX_AGE của Django cho kết nối bền vững.
```

## 4. Read replica (database routing)

```python
# định tuyến truy vấn ĐỌC tới replica, GHI tới primary
class PrimaryReplicaRouter:
    def db_for_read(self, model, **hints): return "replica"   # đọc → replica
    def db_for_write(self, model, **hints): return "primary"  # ghi → primary
# DATABASES = { "primary": {...}, "replica": {...} }
```

Read replica phân phối tải đọc xuyên nhiều bản sao database (hầu hết app nặng về đọc), với ghi đi tới primary — database router của Django định hướng truy vấn phù hợp.

## 5. Caching để giảm tải database

```python
# cache kết quả truy vấn tốn kém (Redis) để chúng không chạm DB mỗi lần
result = cache.get_or_set("expensive", lambda: expensive_query(), 3600)
```

## 6. Scale thêm (khi những cái trên chưa đủ)

```text
✓ Lớp caching (Redis) — giảm tải lớn nhất cho workload nặng về đọc
✓ Tuning database (query plan, vacuuming, cấu hình)
✓ Denormalization / materialized view cho các tổng hợp tốn kém
✓ Phân vùng (partition) bảng lớn; lưu trữ (archive) dữ liệu cũ
✓ Sharding (chia dữ liệu xuyên các database) — phương án cuối, phức tạp
✓ Chuyển công việc nặng/async sang background task (Celery) ra khỏi đường request
```

## Đo lường trước

```text
Dùng Django Debug Toolbar, django-silk, slow-query log, và EXPLAIN để tìm nút thắt
THỰC SỰ. Tối ưu cái gì chậm, không phải cái bạn đoán là chậm.
```

## Tại sao điều này quan trọng

Scale Django ở cấp database là kiến thức cấp senior then chốt vì database gần như luôn là nút thắt cổ chai chính khi ứng dụng lớn lên — hiểu cách giải quyết nó là cái cho phép các ứng dụng Django xử lý tải và khối lượng dữ liệu tăng.

Hiểu biết then chốt là scale database tuân theo một thứ tự ưu tiên rõ ràng, với các can thiệp có đòn bẩy cao nhất, rẻ nhất trước: **tối ưu truy vấn** (đặc biệt loại bỏ vấn đề N+1 với `select_related`/`prefetch_related`, chỉ lấy các cột cần thiết, và đẩy tổng hợp xuống database) thường mang lại lợi ích lớn nhất với ít nỗ lực nhất và luôn nên đến trước việc thêm hạ tầng, và **đánh index đúng cách** là thiết yếu vì index thiếu là nguyên nhân thường gặp của truy vấn chậm.

Ngoài các nền tảng này, hiểu sự tiến triển của các kỹ thuật scale — **connection pooling** (tái sử dụng các kết nối database tốn kém ở quy mô lớn), **read replica với database routing** (phân phối tải đọc xuyên các bản sao database, có giá trị vì hầu hết ứng dụng nặng về đọc), **caching** (Redis để giảm hoàn toàn việc chạm database cho dữ liệu nặng về đọc), và cuối cùng các biện pháp phức tạp hơn (denormalization, partition, sharding như phương án cuối) — cho bạn một bộ công cụ để giải quyết hiệu năng ở mỗi giai đoạn tăng trưởng.

Quan trọng không kém là kỷ luật **đo lường trước** (dùng Django Debug Toolbar, slow-query log, và EXPLAIN để tìm nút thắt thực sự thay vì đoán), vì tối ưu sai chỗ lãng phí nỗ lực.

Biết sự tiến triển scale database này — tối ưu truy vấn và đánh index trước, rồi pooling/replica/caching, rồi thay đổi kiến trúc, tất cả được dẫn dắt bởi đo lường — là cái phân biệt các lập trình viên có thể giữ các ứng dụng Django nhanh và mở rộng được khi chúng lớn lên với những người mà app suy thoái dưới tải thực.

Vì database là ràng buộc scale phổ biến nhất và các kỹ thuật trải từ sửa truy vấn đơn giản tới hạ tầng phức tạp, hiểu cách scale Django một cách hệ thống ở cấp database là kiến thức quan trọng, giá trị cao để xây dựng và vận hành các ứng dụng production phải xử lý tăng trưởng, khiến nó trở thành một chủ đề thường liên quan cho các kỹ sư senior chịu trách nhiệm về hiệu năng và khả năng mở rộng của ứng dụng.