Lưu trữ SQLite độ trễ bằng 0 trong mọi Durable Object

 (simonwillison.net)
2 điểm bởi GN⁺ 2024-10-15 | 1 bình luận | Chia sẻ qua WhatsApp

  • Lưu trữ SQLite độ trễ bằng 0 trong mọi Durable Object

    • Kenton Varda giới thiệu phiên bản tiếp theo của nền tảng Durable Object của Cloudflare. Nền tảng này gần đây đã được nâng cấp từ kho key/value lên một hệ thống quan hệ hoàn chỉnh dựa trên SQLite
    • Có thể tham khảo bài viết Cloudflare's durable multiplayer moat của Paul Butler để biết thêm bối cảnh hữu ích về phiên bản đầu tiên của Durable Objects. Đây là nền tảng phổ biến để xây dựng các ứng dụng cộng tác thời gian thực dựa trên WebSocket
    • Durable Objects dựa trên SQLite mới mang đến một khía cạnh hấp dẫn trong thiết kế hệ thống phân tán, đồng thời gợi mở những cách thú vị để thiết kế các ứng dụng quy mô lớn

  • Ý tưởng cốt lõi của Durable Objects

    • Durable Object đặt logic ứng dụng cùng với dữ liệu trên cùng một máy chủ vật lý, nhờ đó cung cấp hiệu năng đọc và ghi rất nhanh
    • Một đối tượng đơn lẻ chạy trên một luồng duy nhất của một máy, nên thông lượng bị giới hạn. Để xử lý thêm lưu lượng, cần tạo thêm nhiều đối tượng hơn. Cách này dễ áp dụng nhất khi mỗi đơn vị trạng thái có lưu lượng đủ thấp để một đối tượng đơn lẻ có thể xử lý

  • Ví dụ về hệ thống đặt vé máy bay

    • Mỗi chuyến bay có thể được ánh xạ tới một Durable Object chuyên biệt với cơ sở dữ liệu SQLite riêng. Mỗi ngày sẽ có hàng nghìn cơ sở dữ liệu mới được tạo ra cho mỗi hãng hàng không
    • Mỗi DO có một tên duy nhất, và mạng của Cloudflare sẽ định tuyến yêu cầu đến đối tượng đó dù nó đang ở bất kỳ đâu trên thế giới

  • Chi tiết kỹ thuật

    • Lấy cảm hứng từ Litestream, mỗi DO liên tục stream chuỗi mục WAL sang object storage. Việc này được gom lô sau mỗi 16MB hoặc mỗi 10 giây
    • Để đảm bảo độ bền dữ liệu trong cửa sổ 10 giây, các thao tác ghi được chuyển tới năm bản sao ở các trung tâm dữ liệu lân cận ngay khi commit, và thao tác ghi sẽ được xác nhận khi có ba bản sao phản hồi

  • Thiết kế JavaScript API

    • API được thiết kế theo kiểu blocking thay vì bất đồng bộ, nhằm cung cấp các thao tác lưu trữ đơn luồng cực nhanh
    • Có kèm ví dụ cố ý thể hiện mẫu truy vấn N+1 mà SQLite có thể xử lý tốt

  • Storage Relay Service

    • Đây là hệ thống nền tảng của Durable Objects, và đã hỗ trợ hệ thống SQLite D1 hiện có của Cloudflare trong hơn một năm

  • Durable Objects được tạo ở đâu

    • Durable Objects không thay đổi vị trí sau khi được tạo. Theo mặc định, chúng được khởi tạo tại trung tâm dữ liệu nơi diễn ra yêu cầu get() đầu tiên
    • Để tạo Durable Objects thủ công ở vị trí khác, có thể truyền tham số tùy chọn locationHint vào get()

  • Trang web where.durableobjects.live

    • Đây là trang theo dõi vị trí DO được tạo ra trong mạng Cloudflare

Tổng hợp của GN⁺

  • Durable Objects của Cloudflare dựa trên SQLite, mở ra những khả năng mới cho việc thiết kế ứng dụng quy mô lớn. Hệ thống này mang lại hiệu năng nhanh bằng cách đặt dữ liệu và logic ứng dụng trên cùng một máy chủ vật lý
  • Hệ thống này đặc biệt hữu ích cho các ứng dụng cộng tác thời gian thực, đồng thời cung cấp sự linh hoạt để xử lý nhiều đơn vị trạng thái khác nhau
  • Durable Objects tạo các bản sao ở nhiều trung tâm dữ liệu để đảm bảo độ bền dữ liệu, qua đó tăng tính ổn định và độ tin cậy
  • Công nghệ này có thể hấp dẫn với các nhà phát triển quan tâm đến thiết kế hệ thống phân tán quy mô lớn. Những hệ thống cung cấp chức năng tương tự gồm có Amazon DynamoDB và Google Firestore

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-10-15
Ý kiến Hacker News

  • API ghi là đồng bộ nhưng có cơ chế chờ bất đồng bộ ẩn. Nếu ghi thất bại, runtime sẽ thay thế phản hồi bằng lỗi HTTP để có thể tự động gom lô các lượt ghi và giả định là thành công

    • Không có transaction đọc nên khó lấy snapshot tại một thời điểm cụ thể
    • Mỗi instance runtime bị giới hạn 128MB RAM
    • WebSocket có thể chuyển sang chế độ ngủ đông, và khi đó không phát sinh chi phí. Điều này cho phép client vẫn giữ kết nối ngay cả khi DO đang ngủ
    • Có tính năng RPC tự động nên có thể giao tiếp với DO khác hoặc worker như một lời gọi JS thông thường. Runtime xử lý việc tuần tự hóa và phân tích cú pháp

  • Mỗi DO stream chuỗi mục WAL vào object storage, và dữ liệu này được gom lô mỗi 16MB hoặc mỗi 10 giây

    • Có thể mất 10 giây để ghi được phản ánh vào đọc trên phạm vi toàn cầu
    • Khó thay thế các cụm cơ sở dữ liệu được triển khai theo khu vực

  • Thích thiết kế Durable Object. Dễ hiểu cách nó hoạt động bên trong

    • DO phù hợp để xây dựng trải nghiệm thời gian thực nhanh và chi phí thấp, nhưng khó làm phân tích và tổng hợp tổng quan
    • Khi đưa dữ liệu vào SQLite, bạn phải truy vấn nhiều instance SQLite nhỏ rồi hợp nhất kết quả

  • Khó hiểu vị trí vật lý của Durable Objects nằm ở đâu

    • Thắc mắc liệu nó có nằm ở khu vực nơi phát sinh lời gọi API hay không
    • Thắc mắc liệu DO có thể tự động di chuyển sang vị trí khác hay không

  • Khó hiểu các công nghệ đám mây mới

    • Dù có hơn 15 năm kinh nghiệm phát triển web, vẫn cảm thấy những công nghệ này không phù hợp với mình

  • Thắc mắc cách xử lý schema migration

    • Nếu cơ sở dữ liệu tồn tại theo từng tenant, việc áp dụng thay đổi schema cho từng DO sẽ rất khó

  • Thiết kế DO thú vị, nhưng có vẻ chỉ phù hợp với hệ thống tải rất cao hoặc các dự án đồ chơi

    • Trong thực tế cần các hệ thống đã được kiểm chứng, còn DO thì vẫn chưa đủ trưởng thành

  • Ấn tượng với thiết kế DO. Cách nó xử lý công việc phức tạp ở quy mô nhỏ khá giống với cấu trúc sản phẩm thực tế

  • Chú ý việc CF khuyến khích các nhà phát triển dùng DO

    • Kết nối WebSocket của worker sẽ timeout sau 30 giây, nên DO được khuyến nghị sử dụng

  • Thắc mắc liệu DO có tương ứng với "model" trong kiến trúc MVC hay không

    • Muốn biết cách dùng DO theo từng tenant, và cách truy vấn hoặc join tất cả các DO