คุณขยายขนาด Django ในระดับฐานข้อมูลอย่างไร?

Question

Accepted Answer

เมื่อแอปพลิเคชัน Django เติบโต **ฐานข้อมูล** มักเป็นคอขวดแรกและสำคัญที่สุด การขยายมันเกี่ยวข้องกับการ optimize query, การทำ index, การจัดการ connection, read replica, การ cache และในที่สุดคือการเปลี่ยนแปลงเชิงสถาปัตยกรรม — การจัดการฐานข้อมูลเป็นงานขยายขนาดที่ให้ผลตอบแทนสูงสุดสำหรับแอป Django ส่วนใหญ่

## 1. Optimize query ก่อน (ผลลัพธ์ใหญ่ที่สุดและถูกที่สุด)

```python
# ✅ eliminate N+1 queries (the #1 issue) with select_related/prefetch_related
Book.objects.select_related("author").prefetch_related("tags")

# ✅ fetch only needed columns
Article.objects.only("title", "created_at")        # SELECT just these
Article.objects.values("title")                     # dicts, even lighter

# ✅ use database aggregation instead of Python loops
from django.db.models import Count, Sum
Author.objects.annotate(book_count=Count("books"))  # let the DB do the work
```

การ optimize query (การแก้ปัญหา N+1, การ select เฉพาะข้อมูลที่ต้องการ, การผลักการ aggregation ไปยังฐานข้อมูล) มักให้ผลด้านประสิทธิภาพสูงสุดด้วยความพยายามน้อยที่สุด — ทำสิ่งนี้ก่อนเพิ่มโครงสร้างพื้นฐาน

## 2. เพิ่ม index

```python
class Article(models.Model):
    slug = models.SlugField(db_index=True)              # index a frequently-queried field
    class Meta:
        indexes = [
            models.Index(fields=["author", "-created_at"]),  # composite index for common queries
        ]
```

index เร่งความเร็ว query ที่ filter/order ตามคอลัมน์เหล่านั้นอย่างมาก — จำเป็นสำหรับฟิลด์ใด ๆ ที่คุณ query บ่อย (index ที่ขาดหายเป็นสาเหตุที่พบบ่อยของ query ที่ช้า)

## 3. Connection pooling

```text
Reuse database connections instead of opening one per request (expensive at scale).
Use a pooler (PgBouncer for PostgreSQL) or Django's CONN_MAX_AGE for persistent connections.
```

## 4. Read replica (database routing)

```python
# route READ queries to replicas, WRITES to the primary
class PrimaryReplicaRouter:
    def db_for_read(self, model, **hints): return "replica"   # reads → replica
    def db_for_write(self, model, **hints): return "primary"  # writes → primary
# DATABASES = { "primary": {...}, "replica": {...} }
```

read replica กระจายภาระการอ่านไปยังสำเนาฐานข้อมูลหลายชุด (แอปส่วนใหญ่ read-heavy) โดยการ write ไปยัง primary — database router ของ Django ส่ง query ไปอย่างเหมาะสม

## 5. การ cache เพื่อลดภาระฐานข้อมูล

```python
# cache expensive query results (Redis) so they don't hit the DB every time
result = cache.get_or_set("expensive", lambda: expensive_query(), 3600)
```

## 6. การขยายเพิ่มเติม (เมื่อข้างต้นไม่เพียงพอ)

```text
✓ Caching layers (Redis) — biggest load reduction for read-heavy workloads
✓ Database tuning (query plans, vacuuming, configuration)
✓ Denormalization / materialized views for expensive aggregations
✓ Partitioning large tables; archiving old data
✓ Sharding (splitting data across databases) — last resort, complex
✓ Move heavy/async work to background tasks (Celery) off the request path
```

## วัดผลก่อน

```text
Use Django Debug Toolbar, django-silk, slow-query logs, and EXPLAIN to find the
ACTUAL bottleneck. Optimize what's slow, not what you guess is slow.
```

## ทำไมจึงสำคัญ

การขยายขนาด Django ในระดับฐานข้อมูลเป็นความรู้ระดับ senior ที่สำคัญยิ่ง เพราะฐานข้อมูลแทบจะเป็นคอขวดหลักเสมอเมื่อแอปพลิเคชันเติบโต — การเข้าใจวิธีจัดการมันคือสิ่งที่ทำให้แอปพลิเคชัน Django รองรับภาระและปริมาณข้อมูลที่เพิ่มขึ้นได้

ข้อมูลเชิงลึกสำคัญคือการขยายฐานข้อมูลดำเนินตามลำดับความสำคัญที่ชัดเจน โดยมีการแทรกแซงที่ให้ผลตอบแทนสูงสุดและถูกที่สุดมาก่อน: **การ optimize query** (โดยเฉพาะการแก้ปัญหา N+1 ด้วย `select_related`/`prefetch_related`, การ fetch เฉพาะคอลัมน์ที่ต้องการ และการผลักการ aggregation ไปยังฐานข้อมูล) มักให้ผลสูงสุดด้วยความพยายามน้อยที่สุดและควรมาก่อนการเพิ่มโครงสร้างพื้นฐานเสมอ และ **การทำ index ที่เหมาะสม** เป็นสิ่งจำเป็นเนื่องจาก index ที่ขาดหายเป็นสาเหตุที่พบบ่อยของ query ที่ช้า

นอกเหนือจากพื้นฐานเหล่านี้ การเข้าใจลำดับขั้นของเทคนิคการขยายขนาด — **connection pooling** (การใช้ connection ฐานข้อมูลที่มีต้นทุนสูงซ้ำในระดับใหญ่), **read replica พร้อม database routing** (การกระจายภาระการอ่านไปยังสำเนาฐานข้อมูล มีค่าเพราะแอปส่วนใหญ่ read-heavy), **การ cache** (Redis เพื่อลดการเข้าถึงฐานข้อมูลทั้งหมดสำหรับข้อมูลที่ read-heavy) และในที่สุดคือมาตรการที่ซับซ้อนกว่า (denormalization, partitioning, sharding เป็นทางเลือกสุดท้าย) — ให้ชุดเครื่องมือเพื่อจัดการประสิทธิภาพในแต่ละขั้นของการเติบโต

สิ่งที่สำคัญพอ ๆ กันคือวินัยของการ **วัดผลก่อน** (ใช้ Django Debug Toolbar, slow-query log และ EXPLAIN เพื่อหาคอขวดที่แท้จริงแทนที่จะเดา) เนื่องจากการ optimize สิ่งที่ผิดทำให้เสียความพยายาม

การรู้ลำดับขั้นของการขยายฐานข้อมูลนี้ — การ optimize query และ index ก่อน จากนั้น pooling/replica/caching จากนั้นการเปลี่ยนแปลงเชิงสถาปัตยกรรม ทั้งหมดขับเคลื่อนด้วยการวัดผล — คือสิ่งที่แยกแยะนักพัฒนาที่สามารถรักษาแอปพลิเคชัน Django ให้เร็วและขยายตัวได้เมื่อมันเติบโต ออกจากผู้ที่แอปเสื่อมประสิทธิภาพภายใต้ภาระจริง

เนื่องจากฐานข้อมูลเป็นข้อจำกัดในการขยายขนาดที่พบบ่อยที่สุด และเทคนิคต่าง ๆ มีตั้งแต่การแก้ query ง่าย ๆ ไปจนถึงโครงสร้างพื้นฐานที่ซับซ้อน การเข้าใจวิธีขยายขนาด Django ในระดับฐานข้อมูลอย่างเป็นระบบเป็นความรู้ที่สำคัญและมีค่าสูงสำหรับการสร้างและดำเนินการแอปพลิเคชัน production ที่ต้องรองรับการเติบโต ทำให้มันเป็นหัวข้อที่เกี่ยวข้องบ่อยสำหรับวิศวกรระดับ senior ที่รับผิดชอบประสิทธิภาพและการขยายขนาดของแอปพลิเคชัน