Drizzle ORM: nhẹ, gần SQL, hợp dự án nào

Trả lời nhanh: Drizzle ORM đi theo triết lý ngược với các lớp truy cập nặng: cú pháp bám sát SQL nên ai biết SQL là đọc hiểu ngay, và gói chạy rất nhẹ nên hợp với môi trường giới hạn tài nguyên hoặc cần khởi động nhanh. Đổi lại bạn tự làm nhiều hơn: ít công cụ đi kèm, và bạn phải hiểu SQL chứ không có lớp che bớt. Hợp nhất với đội đã quen SQL và muốn kiểm soát chính xác truy vấn chạy xuống database.

Sau vài năm dùng các lớp truy cập nhiều phép màu, không ít đội quay lại với thứ gần SQL hơn, vì họ nhận ra mình vẫn phải đọc SQL để gỡ lỗi. Drizzle nằm ở nhóm đó. Bài này nói rõ nó đánh đổi cái gì để lấy sự nhẹ nhàng đó.

Cú pháp gần SQL nghĩa là gì

Khai báo bảng bằng chính TypeScript, không cần ngôn ngữ lược đồ riêng:

export const sanPham = pgTable('san_pham', {  id: serial('id').primaryKey(),  ten: varchar('ten', { length: 255 }).notNull(),  gia: numeric('gia', { precision: 12, scale: 2 }),  danhMucId: integer('danh_muc_id').references(() => danhMuc.id),})

Truy vấn viết theo hình dạng của câu SQL:

const ketQua = await db  .select({ ten: sanPham.ten, gia: sanPham.gia, danhMuc: danhMuc.ten })  .from(sanPham)  .leftJoin(danhMuc, eq(sanPham.danhMucId, danhMuc.id))  .where(gt(sanPham.gia, 100000))  .limit(50)

Lợi ích lớn nhất không phải cú pháp đẹp mà là bạn đoán được truy vấn nào sẽ chạy xuống database chỉ bằng cách đọc code. Với các lớp trừu tượng cao, bạn phải bật nhật ký lên xem mới biết, và đó là nơi những bất ngờ về hiệu năng sinh ra.

Nhẹ tới mức nào và điều đó có ý nghĩa gì

Gói chạy nhỏ hơn nhiều so với các lựa chọn nặng, và không cần bước sinh mã kèm phần lõi biên dịch sẵn. Ba nơi khác biệt này có giá trị thật:

• Môi trường tính theo tài nguyên, nơi kích thước gói và thời gian khởi động ảnh hưởng trực tiếp tới chi phí và độ trễ.
• Máy chủ nhỏ. Với VPS 1GB chạy vài dịch vụ, vài chục MB bộ nhớ tiết kiệm được cũng đáng.
• Ảnh Docker. Ảnh nhỏ hơn nghĩa là triển khai nhanh hơn và ít bề mặt cần vá hơn.

Ngược lại, nếu bạn chạy trên một máy chủ thường với vài GB RAM, khác biệt này gần như không cảm nhận được. Đừng chọn chỉ vì con số nhẹ hơn, hãy chọn vì cách viết hợp với đội bạn.

Bạn phải tự làm gì nhiều hơn

Nói thẳng để tránh kỳ vọng sai:

Công cụ đi kèm ít hơn. Hệ sinh thái quanh các lựa chọn phổ biến hơn có nhiều tiện ích sẵn, còn ở đây bạn thường phải tự ghép.

Phải hiểu SQL. Đây vừa là điểm mạnh vừa là rào cản. Người mới chưa vững SQL sẽ thấy khó hơn, vì không có lớp che bớt phần nối bảng và gom nhóm.

Migration đơn giản hơn nhưng thô hơn. Có công cụ sinh file SQL từ thay đổi lược đồ, nhưng bạn cần đọc kỹ file sinh ra trước khi chạy trên máy chủ thật, nhất là với bảng lớn.

Tài liệu và ví dụ ít hơn. Khi gặp tình huống lạ, bạn sẽ tìm thấy ít bài viết hơn so với các lựa chọn phổ biến.

Điểm cuối cũng ảnh hưởng tới việc dùng agent: mô hình biết ít ví dụ hơn nên hay bịa cú pháp nghe hợp lý. Hãy kiểm chứng bằng tài liệu chính thức thay vì tin ngay, đúng nguyên tắc đã nói ở bài về hook WordPress.

So với Prisma, chọn thế nào

Chọn Drizzle khi: đội đã quen SQL và muốn kiểm soát truy vấn; chạy ở môi trường giới hạn tài nguyên; ứng dụng có nhiều truy vấn phức tạp mà lớp trừu tượng cao sẽ vướng; hoặc bạn muốn ít phép màu để dễ đoán.

Chọn Prisma khi: đội có nhiều người chưa vững SQL; bạn muốn công cụ đi kèm đầy đủ; hoặc dự án chủ yếu là các thao tác đơn giản mà việc viết nhanh quan trọng hơn kiểm soát chi tiết. Phân tích kỹ nằm ở bài về Prisma.

Một điểm chung phải nhớ dù chọn cái nào: cả hai đều dính bẫy truy vấn lồng sinh ra hàng loạt lượt hỏi database nếu bạn viết ngây thơ. Lớp truy cập không cứu bạn khỏi việc phải hiểu dữ liệu của mình.

Vài lưu ý khi chạy thật

Quản lý kết nối. Với môi trường tạo mới tiến trình liên tục, hãy dùng cơ chế gộp kết nối phù hợp, nếu không database sẽ cạn số kết nối cho phép. Đây là sự cố hay gặp khi lượng truy cập tăng đột ngột.

Đọc file migration trước khi chạy. Công cụ sinh ra SQL, và với bảng lớn thì một câu đổi kiểu cột có thể khóa bảng rất lâu. Sao lưu trước, và với bảng nhiều bản ghi thì tách thành nhiều bước.

Đo bằng kế hoạch thực thi. Vì bạn viết gần SQL nên rất dễ lấy câu truy vấn thật ra chạy thử. Cách đọc kế hoạch nằm ở bài đọc EXPLAIN, và với PostgreSQL thì các tham số đáng chỉnh nằm ở bài tối ưu PostgreSQL.

Bảng việc thư viện lo hộ và việc bạn tự làm

Điểm đánh đổi cốt lõi: thư viện nhẹ bắt bạn hiểu SQL, nhưng đổi lại bạn kiểm soát được truy vấn sinh ra. Với người đã biết SQL, đó là ưu điểm; với người chưa biết, đó là rào cản.

Tự đo dung lượng và thời gian khởi động

# Do kich thuoc thu muc thu viendu -sh node_mod*/drizzle-orm node_mod*/@prisma 2>/dev/null # Do thoi gian khoi dong ung dungtime node -e "require('./dist/index.js')" # Do so tep phai doc khi khoi dongstrace -c -f -e trace=openat node dist/index.js 2>&1 | tail -5 # Khac biet ro nhat o hai cho:# 1. Container nho: anh nhe hon, khoi dong nhanh hon# 2. Moi truong chay dang ham: thoi gian khoi dong lanh ngan hon

Với ứng dụng chạy liên tục trên máy chủ, khác biệt về thời gian khởi động gần như không quan trọng vì nó chỉ xảy ra một lần. Với ứng dụng chạy dạng hàm khởi động lại liên tục, đó là khác biệt thật.

Chọn thế nào cho dự án của bạn

• Đội đã quen SQL và muốn kiểm soát truy vấn: chọn thư viện nhẹ.
• Đội chưa quen SQL, muốn công cụ lo hộ nhiều: chọn thư viện nặng hơn.
• Chạy trong container nhỏ hoặc môi trường dạng hàm: thư viện nhẹ có lợi thế rõ.
• Đang có dự án chạy ổn định: đừng đổi. Chi phí chuyển đổi luôn lớn hơn phần lợi trên giấy.

Điểm đáng nhớ cuối: với dự án vừa và nhỏ, khác biệt do ổ đĩa và bộ nhớ của máy lớn hơn nhiều so với khác biệt giữa hai thư viện. Đo trước khi đổi. Xem VPS NVMe.