Chạy toàn bộ cơ sở dữ liệu DuckDB trực tiếp trên S3 mà không cần dịch vụ bổ sung

Các kỹ sư đã phát triển một phương pháp để chạy hoàn chỉnh cơ sở dữ liệu DuckDB trực tiếp trên kho lưu trữ đối tượng như Amazon S3, loại bỏ nhu cầu về máy chủ cơ sở dữ liệu riêng biệt hoặc danh mục hồ chứa dữ liệu (data lake) phức tạp. Được công bố vào tháng 10 năm 2026, phương pháp này sử dụng một tiện ích mở rộng tùy chỉnh có tên là duckdb_objfs để ánh xạ động cơ lưu trữ nội bộ của DuckDB sang SlateDB, một kho lưu trữ khóa-giá trị nhúng được thiết kế cho các đối tượng đám mây.

Chuyện gì đã xảy ra

Đổi mới cốt lõi là một tiện ích mở rộng của DuckDB cho phép cơ sở dữ liệu coi một bucket S3 như ổ đĩa chính của nó. Khác với các giải pháp hiện có như Iceberg hoặc DuckLake, vốn tập trung vào việc chia sẻ các bảng Parquet giữa các động cơ khác nhau, phương pháp này bảo toàn toàn bộ bộ tính năng của DuckDB. Điều này bao gồm các chỉ mục nâng cao, ràng buộc, view, macro và các kiểu dữ liệu cụ thể thường bị mất hoặc ánh xạ kém khi chuyển đổi sang các định dạng bảng mở.

Hệ thống cho phép một quy trình ghi duy nhất cập nhật cơ sở dữ liệu trong khi nhiều quy trình khác gắn kết với cùng dữ liệu đó ở chế độ chỉ đọc. Những người đọc này có thể thực thi các truy vấn SQL phức tạp, bao gồm liên kết (join) và tổng hợp (aggregation), trực tiếp trên dữ liệu trong bucket. Kiến trúc đảm bảo rằng những người đọc luôn thấy trạng thái nhất quán của cơ sở dữ liệu, ngay cả khi họ hơi chậm hơn so với lần ghi mới nhất, ngăn chặn các thao tác đọc một phần hoặc bị hỏng trong quá trình cập nhật.

Cách thức hoạt động

Tiện ích mở rộng hoạt động bằng cách thay thế lớp ổ đĩa cơ bản thay vì sửa đổi chính động cơ lưu trữ của DuckDB. Nó đăng ký một trình xử lý hệ thống tệp tùy chỉnh cho scheme duckdb_objfs://. Khi DuckDB cố gắng đọc hoặc ghi các tệp, yêu cầu được chuyển tiếp thông qua một giao diện C đến lõi Rust quản lý SlateDB. SlateDB đóng vai trò là một bộ chuyển đổi, dịch các thao tác tệp thành các lệnh gọi kho lưu trữ đối tượng bằng cách sử dụng Apache OpenDAL, hỗ trợ nhiều backend như S3, MinIO và thư mục cục bộ.

Để xử lý sự không khớp giữa các cập nhật tệp tại chỗ của DuckDB và bản chất bất biến của kho lưu trữ đối tượng, hệ thống căn chỉnh chính xác các khối dữ liệu. Mỗi khối 256 KiB của DuckDB được ánh xạ tới một chunk 256 KiB duy nhất trong SlateDB, bắt đầu sau một tiêu đề 12 KiB. Hình học này đảm bảo rằng việc ghi một khối chỉ yêu cầu một thao tác put, và việc đọc nó chỉ yêu cầu một thao tác get, tránh các chu kỳ đọc-sửa-ghi tốn kém. Độ bền được duy trì bằng cách gộp các chunk bẩn và metadata vào một batch ghi duy nhất được flush xuống bucket trước khi lệnh đồng bộ hóa tệp trả về.

Chi tiết chính

• Hỗ trợ SQL đầy đủ: Giải pháp giữ lại tất cả các tính năng của DuckDB, bao gồm chỉ mục ART, R-tree không gian và chỉ mục vector HNSW thử nghiệm, những thứ không được hỗ trợ trong các định dạng bảng dựa trên Parquet tiêu chuẩn.
• Mô hình một người ghi: Chỉ một quy trình có thể ghi vào cơ sở dữ liệu tại một thời điểm. Việc hàng rào hóa người ghi (writer fencing) ngăn ngừa xung đột bằng cách đảm bảo các người ghi cũ nhận được lỗi I/O nếu một người ghi mới tiếp quản.
• Đọc nhất quán: Các attachment chỉ đọc sử dụng những người đọc không bị hàng rào hóa, cập nhật quan điểm của họ về manifest mỗi mười giây, đảm bảo tính nhất quán mà không chặn người ghi.
• Số liệu hiệu suất: Trên Apple M4, các thao tác đọc lạnh từ S3 chậm hơn khoảng 1,2 lần so với HTTPFS gốc, trong khi các thao tác ghi cục bộ nhanh gấp khoảng 0,19 lần tốc độ ghi trên ổ đĩa cục bộ gốc do độ trễ mạng.
• Không cần dịch vụ bổ sung: Việc triển khai chỉ yêu cầu một bucket S3. SlateDB xử lý phối hợp, nén (compaction) và thu gom rác (garbage collection) bên trong quy trình ghi, loại bỏ nhu cầu về các dịch vụ catalog bên ngoài.
• Tích hợp với Duckherder: Lớp lưu trữ này đóng vai trò là nền tảng cho Duckherder, một động cơ thực thi phân tán cho phép nhiều worker đọc dữ liệu được phân vùng từ cùng một bucket để xử lý truy vấn song song.

Tại sao điều này quan trọng

Đối với các kỹ sư phần mềm và nhóm dữ liệu, phương pháp này đơn giản hóa hạ tầng bằng cách loại bỏ gánh nặng vận hành trong việc quản lý máy chủ cơ sở dữ liệu, sao lưu và cụm sẵn sàng cao (high-availability). Bucket trở thành nguồn sự thật duy nhất, giảm số lượng thành phần cần cung cấp, bảo mật và giám sát. Điều này đặc biệt có giá trị đối với các ứng dụng tự host hoặc các nhóm nhỏ muốn sức mạnh của một cơ sở dữ liệu quan hệ mà không phải chịu sự phức tạp của quản trị cơ sở dữ liệu truyền thống.

Tuy nhiên, các đánh đổi liên quan đến độ trễ và thông lượng ghi. Bởi vì mỗi commit yêu cầu một vòng lặp đến kho lưu trữ đối tượng, các tải làm việc ghi nặng sẽ chậm hơn đáng kể so với các thao tác trên ổ đĩa cục bộ. Các kỹ sư phải thiết kế ứng dụng của mình để gộp các bản ghi nhỏ và chấp nhận rằng các replica chỉ đọc có thể chậm hơn tối đa mười giây. Mô hình này lý tưởng cho các tải làm việc phân tích nơi dữ liệu được thêm mới hoặc cập nhật không thường xuyên nhưng được truy vấn thường xuyên bởi nhiều người dùng hoặc dịch vụ.

Bạn có thể làm gì

• Đánh giá mức độ phù hợp của tải làm việc: Xác định xem ứng dụng của bạn có thể chịu đựng được độ trễ của các thao tác ghi S3 và độ trễ đọc mười giây hay không. Mô hình này phù hợp hơn với các dashboard phân tích so với các hệ thống giao dịch tần suất cao.
• Gộp các thao tác ghi: Nhóm các bản cập nhật nhỏ vào các transaction lớn hơn để giảm thiểu số lượng vòng lặp đến bucket lưu trữ đối tượng, cải thiện thông lượng ghi tổng thể.
• Sử dụng attachment chỉ đọc: Mở rộng khả năng truy vấn bằng cách gắn kết nhiều quy trình chỉ đọc vào cùng một cơ sở dữ liệu, cho phép phân tích đồng thời mà không ảnh hưởng đến người ghi.
• Giám sát thống kê IO: Sử dụng các hàm duckdb_objfs_io_stats() và duckdb_objfs_cache_stats() được cung cấp để theo dõi số lượng yêu cầu, độ trễ và hiệu suất cache nhằm mục đích gỡ lỗi và tối ưu hóa.
• Lập kế hoạch di cư: Vì bucket chứa các đối tượng SlateDB chứ không phải một tệp .duckdb tiêu chuẩn, hãy lập kế hoạch cẩn thận cho quá trình di chuyển dữ liệu.