Skip to content

Ước tính dung lượng Database

Các con số dưới đây neo vào hệ thống chạy thật, không phải kích thước dòng lý thuyết, và là all-in - dữ liệu, index, MVCC bloat, các bảng audit / event / CDC-outbox, WAL slack, đúng như dung lượng chiếm thật trên đĩa.

Đây là mô hình TRẦN (ceiling)

Tỷ lệ đo được lấy từ các merchant đang hoạt động thật sự. Áp cho N merchant nghĩa là giả định cả N đều hoạt động mạnh như nhau - đây là trường hợp xấu nhất về dung lượng. Triển khai thật là hỗn hợp: phần lớn merchant ít hoạt động hơn nhiều, nên dung lượng thực thấp hơn bảng trần. Dùng bảng trần cho giới hạn trên; dùng phần fleet hỗn hợp cho con số thực tế.

Số đo nền (production)

Chỉ sốGiá trị
Số merchant (đều active)10
Khoảng thời gian1.368 ngày (~3,75 năm)
Tổng dung lượng DB24 GB

Tỷ lệ trần mỗi merchant:

24 GB ÷ 10 merchant ÷ 1.368 ngày = 1,75 MB / merchant active / ngày
                                 ≈ 0,64 GB / merchant active / năm

Đã gồm chi phí thực tế của hệ thống, nên cao gấp ~5-6 lần ước tính "chỉ tính dòng giao dịch lõi". Đây là trần mỗi merchant active.

Merchant không hoạt động đồng đều

Một fleet thật trải rộng nhiều mức hoạt động. Chỉ merchant active mới tạo dung lượng đáng kể; merchant ngủ chỉ chiếm phần tĩnh một lần (tài khoản + catalog ≈ 0,4 MB) và gần như không tăng theo ngày.

NhómĐặc điểmDữ liệu/ngày (× trần)
NặngCửa hàng đông / chuỗitới ~1× (mô hình trần đã bao gồm ở mức fleet)
ActiveHộ kinh doanh vận hành điển hình - chính là số đo nền1× = 1,75 MB/ngày
Nhẹ / mùa vụLượng thấp hoặc gián đoạn~0,2-0,4×
Ngủ / dùng thửĐã đăng ký, chưa bán~0 (chỉ tĩnh 0,4 MB một lần)

Hệ quả quan trọng: tổng dung lượng ≈ (số merchant active-tương-đương) × tỷ lệ trần. Số merchant đã đăng ký gần như không ảnh hưởng tới dung lượng - mỗi merchant ngủ chỉ thêm ~0,4 MB. Tính theo merchant active, không phải tổng tài khoản.

Ước tính TRẦN - mọi merchant đều active (giới hạn trên)

Cột merchant ở đây = merchant active. "Giữ toàn bộ" = giữ hết trong DB chính. "DB nóng" = dữ liệu giao dịch cũ hơn 180 ngày được archive sang cold storage, DB chính đứng yên.

Merchant activeTăng / ngàyDB / năm (giữ toàn bộ)DB nóng, ổn định (archive 180 ngày)
10 (đo thật)17,5 MB6,4 GB3,2 GB
100175 MB64 GB32 GB
1.0001,75 GB0,64 TB0,32 TB
10.00017,5 GB6,4 TB3,2 TB
50.00088 GB32 TB16 TB
100.000175 GB64 TB32 TB

100.000 merchant active theo thời gian

MốcTổng DB (giữ toàn bộ)
Mỗi ngày~175 GB
1 tháng~5,3 TB
6 tháng~32 TB
1 năm~64 TB
3 năm~192 TB

Ước tính THỰC TẾ - fleet hỗn hợp 100.000 merchant đăng ký

Phần lớn merchant đăng ký không hoạt động hết công suất. Vì merchant ngủ thêm ~0/ngày, tổng ≈ tỷ lệ active × trần. Chọn tỷ lệ active khớp với thực tế triển khai.

Tỷ lệ activeMerchant activeDB / năm (giữ toàn bộ)DB nóng (180 ngày)
100% (trần)100.000~64 TB~32 TB
50%50.000~32 TB~16 TB
30%30.000~19 TB~9,6 TB
20%20.000~13 TB~6,4 TB
10%10.000~6,4 TB~3,2 TB

(Cộng ~40 GB tĩnh cho 100.000 tài khoản + catalog - không đáng kể ở quy mô này.)

Ước tính tải - giao dịch, khách hàng, connection

Fleet tham chiếu: 1.000 merchant active. Giao dịch và khách hàng scale tuyến tính; connection thì không (bám theo topology service, không theo số merchant).

Giao dịch & khách hàng

Suy từ mốc 1,75 MB / merchant / ngày (~10 KB all-in mỗi đơn):

Chỉ sốMỗi merchant active× 1.000 merchant
Giao dịch (đơn/bill)~175 / ngày~175.000 / ngày
Lệnh ghi DB (~20 mỗi đơn)~3.500 / ngày~3,5 triệu / ngày (peak ~300-600 /s)
Khách mới¹~10-50 / ngày~10-50 K / ngày
Khách tích lũy (~3 năm)~5-15 K dòng~5-15 triệu dòng

¹ Số mềm nhất - phần lớn giao dịch POS là khách vãng lai; chỉ loyalty signup mới tạo dòng.

Connection

Có hai con số rất khác nhau. Số đang thật sự bận tại một thời điểm thì nhỏ - PgCat transaction-pool gom ~360 client app (18 process × pool 10 × ~2 instance HA) xuống vài connection server đang làm việc. Nhưng max_connections không cấp theo số bận đó; nó phải chừa chỗ cho mọi thứ có thể giữ connection cùng lúc, cộng dư cho vận hành và sự cố. Cấp theo góc nhìn vận hành:

Hộ tiêu thụ trên masterConnection
App qua PgCat write pool (pool_size, nâng từ 25 để dư cho transaction chạy lâu)~50
Debezium CDC - connector + snapshot song song~15
Streaming replication walsender (mỗi replica, cộng lúc rebuild)~5
Migration lúc deploy (nhiều service cùng lúc)~15
Backup - pg_dump -j song song / pg_basebackup dựng lại replica~10
Monitoring & APM exporter~5
Phiên DBA / ops + bảo trì (VACUUM, REINDEX, ad-hoc)~15
superuser_reserved_connections5
Tổng vận hành~120
× ~2 dư (dồn connection lúc query chậm, spike, thêm service)~240
NodeCấp max_connections
Master300
Mỗi replica (read pool + replication receiver + exporter + backup + ops)200

Chi phí nhỏ: mỗi connection ~5-10 MB RAM, nên 300 ≈ 2-3 GB so với 32-64 GB. Đòn bẩy throughput vẫn là pool_size của PgCat - nâng nó (và max_connections theo cùng) nếu client app bắt đầu xếp hàng lúc report back-office chạy chậm hay chờ lock, chứ không phải bơm pool của từng service.

Kiến trúc cho quy mô lớn

  • Partition SaleOrder / SaleOrderItem / FinanceTransaction theo tháng (range partitioning) - giữ index active trong RAM, detach partition cũ rẻ.
  • Read replica cho báo cáo/dashboard back-office; checkout POS chỉ ghi vào DB chính.
  • Archive dữ liệu giao dịch cũ hơn 180 ngày sang cold storage (ClickHouse / S3) - giữ DB chính ở cột DB nóng thay vì cột giữ toàn bộ.

Phương pháp & biến số

  • Cơ sở: một hệ production thật (10 merchant active, 1.368 ngày, 24 GB). Số thật, all-in. Coi là trần mỗi merchant active.
  • Hai biến: (1) số merchant active-tương-đương, (2) tỷ lệ mỗi merchant (1,75 MB/ngày) - chỉnh nếu mức hoạt động trung bình khác hệ đo.
  • Công thức:
    • tổng giữ-toàn-bộ ≈ merchant_active × ngày × 1,75 MB
    • DB nóng ≈ merchant_active × 180 × 1,75 MB
    • tĩnh ≈ merchant_đăng_ký × 0,4 MB
    • giao dịch/ngày ≈ merchant_active × 175 đơn (≈ × 20 lệnh ghi DB)
    • max_connections (master) ≈ (pgcat_pool_size + CDC + replication + migration + backup + monitoring + ops + reserved) × ~2 dư → ~300
  • Giới hạn: bảng trần là giới hạn trên; con số thực tế nằm ở hàng tỷ-lệ-active khớp với triển khai.

Proprietary and Confidential. Unauthorized copying, distribution, or use of this software is strictly prohibited.