Dịch vụ cơ sở dữ liệu D1 của Cloudflare đang phải đối mặt với nhiều chỉ trích từ các nhà phát triển đã triển khai nó trong môi trường sản xuất, với nhiều báo cáo về hiệu suất kém ổn định mặc dù đã có nhiều nỗ lực tối ưu hóa. Trong khi một bài viết gần đây đã mô tả nhiều kỹ thuật để tối ưu hóa các truy vấn cơ sở dữ liệu D1, phản hồi từ cộng đồng cho thấy những tối ưu hóa này có thể không đủ để khắc phục những hạn chế kiến trúc cơ bản.
Vấn đề hiệu suất toàn cầu
Các nhà phát triển trên nhiều khu vực báo cáo thời gian phản hồi chậm một cách nhất quán với Cloudflare D1, với các truy vấn đơn giản thường mất 200-400ms hoặc hơn để hoàn thành. Vấn đề hiệu suất này dường như đặc biệt rõ rệt bên ngoài châu Âu, với một số người dùng báo cáo thời gian phản hồi tăng vọt lên 500ms hoặc cao hơn ở Bắc Mỹ. Mạng lưới phân phối toàn cầu của Cloudflare, thường là điểm mạnh cho các sản phẩm khác của họ, dường như không thể vượt qua những hạn chế kiến trúc của D1, nơi cơ sở dữ liệu được lưu trữ trong một khu vực chính duy nhất, đòi hỏi giao tiếp giữa các trung tâm dữ liệu cho nhiều hoạt động.
Tôi đã đánh giá D1 cho một dự án cách đây vài tháng và thấy rằng hiệu suất toàn cầu khá tệ. Tôi không biết chính xác vấn đề với kiến trúc của họ là gì, nhưng nếu bạn nhìn vào các con số thời gian đến byte đầu tiên, bạn có thể thấy rằng ngay cả với cơ sở dữ liệu demo D1, các con số bên ngoài châu Âu là tệ hại, và ngay cả trong châu Âu, có TTFB > 200ms cũng không tốt.
Vấn đề về hiệu suất D1 được báo cáo bởi các nhà phát triển:
- Các truy vấn đơn giản thường xuyên mất 200-400ms+ để hoàn thành
- Thời gian phản hồi tăng vọt lên 500ms hoặc cao hơn ở Bắc Mỹ
- Thời gian phản hồi truy vấn dao động từ 300-3000ms với CF Workers + D1
- So với khoảng 50-100ms khi sử dụng CF Workers + PostgreSQL được lưu trữ
Những hạn chế về kiến trúc đã được xác định:
- Cơ sở dữ liệu được lưu trữ trong một khu vực chính duy nhất cho tất cả các thao tác ghi
- Khởi động lạnh yêu cầu thiết lập kết nối
- Cache miss yêu cầu tìm nạp từ khu vực chính
- Được xây dựng trên SQLite với khả năng ghi đồng thời hạn chế
- Thiếu khả năng lưu trữ cache kết quả chủ động từ khu vực chính đến edge
Hạn chế kiến trúc
Một số nhà phát triển đã xác định các đặc điểm kiến trúc cụ thể có thể góp phần gây ra vấn đề hiệu suất của D1. Những điều này bao gồm cơ sở dữ liệu được lưu trữ trong một khu vực chính duy nhất nơi tất cả các thao tác ghi phải được xử lý, khởi động lạnh liên quan đến chi phí thiết lập kết nối, và trường hợp cache miss trong các bản sao cục bộ yêu cầu tìm nạp dữ liệu từ khu vực chính. Ngoài ra, D1 được xây dựng trên SQLite, vốn có những hạn chế đã biết về khả năng ghi đồng thời trong môi trường phân tán. Việc thiếu cache kết quả chủ động từ khu vực chính đến các vị trí edge càng làm trầm trọng thêm những vấn đề này.
Kỹ thuật tối ưu hóa so với vấn đề cơ bản
Bài viết ban đầu mô tả một số kỹ thuật tối ưu hóa bao gồm sử dụng các yêu cầu hàng loạt, loại trừ ID khỏi các thao tác cập nhật, tránh quét toàn bộ bảng, tách các phép join nhiều bảng và tối ưu hóa các thao tác chèn nhiều bản ghi. Mặc dù những kỹ thuật này có thể giúp giảm số lượng đọc hàng và cải thiện hiệu quả truy vấn, phản hồi từ cộng đồng cho thấy chúng không giải quyết được các vấn đề độ trễ cốt lõi. Nhiều nhà phát triển báo cáo rằng ngay cả sau khi thực hiện các tối ưu hóa tương tự, thời gian phản hồi vẫn cao không thể chấp nhận được cho các ứng dụng sản xuất.
Kỹ thuật tối ưu hóa D1 được khuyến nghị:
- Sử dụng các thao tác hàng loạt cho nhiều hoạt động cơ sở dữ liệu
- Loại trừ các trường ID khỏi các thao tác cập nhật
- Tránh quét toàn bộ bảng cho các truy vấn đếm
- Tách các phép nối nhiều bảng thành các truy vấn riêng biệt
- Sử dụng phương pháp chèn nhiều bản ghi theo từng phần cho các thao tác hàng loạt
- Kích hoạt Smart Placement để cải thiện hiệu suất nhẹ
Các trường hợp sử dụng phù hợp cho D1:
- Dự án nhỏ với <5 bảng và phép JOIN tối thiểu
- Đếm số lượng khách truy cập trang
- Danh sách gửi thư
- Theo dõi lượt xem trang web
- Kịch bản đọc nhiều, ghi ít với bộ nhớ đệm tích cực
Trường hợp sử dụng hạn chế
Với những hạn chế về hiệu suất, các nhà phát triển nhận thấy ứng dụng thực tế của D1 hạn chế hơn so với hy vọng ban đầu. Một số người gợi ý rằng nó có thể chỉ phù hợp cho các kịch bản cụ thể như các ứng dụng đọc nhiều, ghi ít với bộ nhớ đệm tích cực, hoặc các dự án rất nhỏ với độ phức tạp quan hệ hạn chế. Một số người dùng lưu ý rằng D1 hoạt động tốt nhất cho các trường hợp sử dụng đơn giản như đếm số lượt truy cập trang, danh sách gửi thư, hoặc theo dõi lượt xem trang web, nơi không yêu cầu các phép join phức tạp và kích thước bảng vẫn khiêm tốn.
Các giải pháp thay thế và so sánh
Nhiều nhà phát triển đã đánh giá D1 cuối cùng chọn các giải pháp thay thế. Một số người bình luận đề cập đến việc đạt được hiệu suất tốt hơn đáng kể khi sử dụng Cloudflare Workers với các cơ sở dữ liệu PostgreSQL truyền thống được lưu trữ, báo cáo thời gian phản hồi truy vấn trong khoảng 50-100ms so với 300-3000ms của D1. Những người khác gợi ý rằng đối với các ứng dụng yêu cầu chức năng cơ sở dữ liệu thực sự, chi phí ban đầu cao hơn của giải pháp cơ sở dữ liệu truyền thống có thể được bù đắp bằng thời gian kỹ thuật giảm, thay vì phải xử lý các vấn đề của serverless và hóa đơn có thể không dự đoán được.
Smart Placement và cải tiến trong tương lai
Một số người dùng báo cáo hiệu suất được cải thiện nhẹ sau khi bật tính năng Smart Placement của Cloudflare, tính năng này cố gắng tối ưu hóa vị trí thực thi worker. Tuy nhiên, ngay cả khi bật tính năng này, nhiều người vẫn thấy hiệu suất không đủ cho các ứng dụng sản xuất. Một số nhà phát triển bày tỏ hy vọng rằng các vấn đề hiệu suất của D1 có thể được giải quyết trong các bản cập nhật tương lai, cho rằng triển khai hiện tại có thể ưu tiên thời gian ra thị trường hơn là tối ưu hóa hiệu suất.
Tóm lại, mặc dù Cloudflare D1 cung cấp một tùy chọn cơ sở dữ liệu serverless hấp dẫn được tích hợp với nền tảng Workers của họ, những hạn chế hiệu suất hiện tại dường như đủ đáng kể khiến nhiều nhà phát triển tìm kiếm nơi khác cho các ứng dụng sản xuất. Các kỹ thuật tối ưu hóa được mô tả trong các bài viết có thể giúp cải thiện hiệu quả nhưng dường như không giải quyết được các hạn chế kiến trúc cơ bản gây ra vấn đề độ trễ. Hiện tại, D1 dường như phù hợp nhất cho các trường hợp sử dụng cụ thể, nơi yêu cầu hiệu suất khiêm tốn và độ phức tạp của cơ sở dữ liệu hạn chế.
Tham khảo: Journey to Optimize Cloudflare D1 Database Queries