Cạm bẫy JOIN trong Firestore
Bạn đang đối mặt với một vấn đề phổ biến trong Firestore. Hàm Firebase của bạn báo lỗi kích thước batch tối đa (maximum batch size error). Bạn cần thực hiện phép JOIN giữa các collection orders và customers để hiển thị trên dashboard. Thông thường, bạn sẽ nhân bản dữ liệu để khắc phục điều này. Nhưng giờ đây, dữ liệu của bạn lại bị cũ và không nhất quán.
Google đã công bố Pipelines API để giải quyết vấn đề này. Nó cho phép thực hiện các thao tác JOIN giữa các collection mà không cần nhân bản dữ liệu. Một số nhà phát triển báo cáo thời gian truy vấn nhanh trong các bài kiểm tra quy mô nhỏ.
Tôi đã dành một tuần để kiểm tra API này dưới tải trọng lớn. Đây là những điều mà tài liệu không nói với bạn.
Chi phí cao Mỗi lần thực thi pipeline sẽ đọc từ tất cả các collection liên quan. Một phép JOIN giữa hai collection sẽ tính phí lượt đọc (reads) cho cả hai. Nếu bạn JOIN hai collection có 50.000 tài liệu, chi phí của bạn sẽ tăng vọt một cách không kiểm soát. Nó không phải là một mức chi phí tuyến tính đơn giản.
Giới hạn hiệu năng Trong các bài kiểm tra của tôi, một pipeline với 10.000 tài liệu mất 380ms. Khi tôi kiểm tra với 100.000 tài liệu, truy vấn đã bị quá thời gian (timeout) ở mức 30 giây. Bạn không hề giải quyết được vấn đề. Bạn chỉ đang biến lỗi batch thành lỗi timeout mà thôi.
Vấn đề Cold Start Pipelines tạo ra một ngữ cảnh thực thi (execution context) riêng biệt. Trong các môi trường serverless như Cloud Functions, điều này làm tăng thêm từ 2 đến 4 giây trễ. Người dùng sẽ nghĩ rằng ứng dụng của bạn bị chậm.
Pipelines API là một công cụ để tạo mẫu (prototyping) hoặc dành cho các collection nhỏ dưới 5.000 tài liệu. Nó không phải là sự thay thế cho một cơ sở dữ liệu quan hệ. Google cung cấp công cụ này để giúp bạn ở lại trong hệ sinh thái Firebase thay vì chuyển sang PostgreSQL hoặc Spanner.
Nếu bạn sử dụng Pipelines, hãy tuân thủ các quy tắc sau:
• Kiểm tra kích thước collection của bạn. Nếu một collection vượt quá 20.000 tài liệu, hãy tính toán chi phí JOIN trước. • Giới hạn độ phức tạp. Một phép JOIN qua ba collection trở lên là một dấu hiệu không tốt. • Theo dõi chi phí đọc hàng tuần. Các lượt đọc từ Pipeline sẽ hiển thị khác trên hóa đơn của bạn. • Giữ nguyên dữ liệu phi chuẩn hóa (denormalized data) của bạn. Hãy sử dụng Pipelines như một công cụ bổ trợ, không phải là sự thay thế hoàn toàn. • Kiểm tra với lưu lượng truy cập thực tế. Các kết quả benchmark trên các collection ít dữ liệu không phản ánh đúng thực tế môi trường production.
Đừng dùng một "miếng băng cá nhân" để né tránh một quyết định kiến trúc thực sự.
Bạn xử lý các mối quan hệ trong Firestore như thế nào? Bạn sử dụng phi chuẩn hóa hay client-side joins? Hãy cho tôi biết trong phần bình luận.