From 3TB to 100GB: A Cost-Saving Journey in Database Maintenance

Allegro · 2023 · 4. Điều chỉnh · Độ khó: Dễ — bài gốc

Bối cảnh

Một database Azure SQL (mô hình vCore) chứa nhiều dữ liệu lịch sử, phục vụ audit. Ở 4 vCore, dung lượng tối đa là 1 TB; dữ liệu tăng lên 3 TB, buộc phải lên 12 vCore vì Azure gắn dung lượng với CPU/RAM. Chi phí khoảng vài nghìn euro mỗi tháng.
So sánh: 3 TB trên Azure SQL 12 vCore khoảng $2.876/tháng, trên Storage Account tầng archive khoảng $31/tháng.
Họ đã có giải pháp đẩy dữ liệu mới sang warehouse bất đồng bộ; phần dữ liệu cũ từ trước đó vẫn nằm trong DB.

Export bằng SqlPackage ra file bacpac (công cụ export của portal chỉ cho DB tới 200 GB). Chạy từ một VM tạm có accelerated networking trong mạng nội bộ. Nén Fast nhanh hơn Maximum khoảng 2 giờ, file lớn hơn chưa tới 10%. 3 TB thành khoảng 100 GB, mất vài giờ, chạy ban đêm.
Thử import lại từ file trước (SSMS lỗi, SqlPackage thì được) để chắc dữ liệu dùng lại được khi cần audit.
AzCopy lên container tầng archive: vài phút.
Xoá dữ liệu cũ rồi SHRINK (WAIT_AT_LOW_PRIORITY), mất vài giờ.
Bất ngờ: sau shrink, endpoint chậm hẳn. Nguyên nhân là index fragmentation lên trên 90% cho gần như mọi index (Microsoft có ghi trong tài liệu). Rebuild index với ONLINE = ON để không khoá bảng; fragmentation về gần 0%.

Từ 12 vCore + 3 TB xuống Standard 100 DTU + 150 GB: chi phí từ gần €3.000 còn khoảng €125/tháng, giảm gần 30 lần.

Dữ liệu lịch sử ít đọc không nên ở trong DB OLTP đắt; trên cloud, dung lượng thường kéo theo CPU (Chi phí hạ tầng và build vs buy).
Trước khi xoá, chứng minh khôi phục được từ bản lưu trữ.
Thao tác bảo trì lớn (shrink) có tác dụng phụ về hiệu năng; theo dõi sau khi làm, không chỉ trong lúc làm.
Tạm thời tốn thêm (VM) để làm một lần cho đúng vẫn rẻ hơn trả tiền hằng tháng.