Ngừng đồng bộ hóa mọi dữ liệu

Cách tiếp cận mới với sao chép ở biên

• Đồng bộ hóa dữ liệu là một bài toán khó hơn tưởng tượng. Các giải pháp hiện có thường chia thành hai hướng: đồng bộ toàn bộ tập dữ liệu xuống client, hoặc theo dõi các thay đổi logic.
• Graft được thiết kế để giải quyết những vấn đề này, là một storage engine mã nguồn mở kết hợp sao chép vật lý đơn giản với sao chép logic hiệu quả.

Đồng bộ hóa lười: đồng bộ theo tốc độ bạn muốn

• Graft cho phép client tự chọn thời điểm đồng bộ, nên rất phù hợp với các môi trường edge chỉ kết nối mạng không liên tục.
• Server cung cấp chỉ mục các page đã thay đổi kể từ snapshot gần nhất của client, và client có thể chỉ chọn lấy những dữ liệu cần thiết.

Đồng bộ hóa một phần: chỉ đồng bộ những gì cần

• Trong môi trường edge, không thể tải xuống toàn bộ tập dữ liệu, vì vậy Graft hỗ trợ đồng bộ hóa một phần bằng cách chỉ lấy có chọn lọc các page cần thiết.
• Graft có thể tận dụng các thuật toán dự đoán phổ biến và kiến thức miền để lấy trước những page cần dùng.

Edge: đồng bộ gần nơi cần thiết

• Graft cung cấp dữ liệu thông qua các edge server trên toàn thế giới, giúp duy trì độ trễ thấp và khả năng phản hồi cao dù người dùng ở đâu.
• Client được thiết kế nhẹ, nên có thể dễ dàng tích hợp vào trình duyệt, ứng dụng di động và môi trường serverless.

Tính nhất quán: đồng bộ an toàn

• Graft cung cấp mô hình nhất quán mạnh, cho phép xử lý an toàn các xung đột giữa các client.
• Thông qua mô hình snapshot isolation, client có thể có được một góc nhìn dữ liệu nhất quán, còn các thao tác ghi được tuần tự hóa nghiêm ngặt.

Có thể xây gì với Graft?

• Graft cung cấp nền tảng mạnh mẽ cho nhiều loại ứng dụng edge-native.
• Có thể xây dựng ứng dụng offline-first, dữ liệu đa nền tảng, read replica không trạng thái và sao chép dữ liệu tùy ý.

Phần mở rộng SQLite của Graft (libgraft)

• libgraft là phần mở rộng native của SQLite, cho phép client chỉ sao chép phần cơ sở dữ liệu mà chúng thực sự sử dụng, nhờ đó có thể chạy SQLite ngay cả trong môi trường tài nguyên hạn chế.
• Nó cung cấp các tính năng như sao chép bất đồng bộ, sao chép một phần theo kiểu lười, snapshot isolation và khôi phục theo thời điểm.

Cách tham gia

• Graft được phát triển trên GitHub và hoan nghênh mọi đóng góp từ cộng đồng.
• Bạn có thể tham gia Discord hoặc gửi phản hồi qua email.
• Bạn cũng có thể đăng ký vào danh sách chờ cho dịch vụ quản lý Graft.

Lộ trình

• Graft vẫn đang trong quá trình phát triển, với các kế hoạch như hỗ trợ WebAssembly, tích hợp với SQLSync và hỗ trợ nhiều thư viện client khác nhau.
• Các tính năng như giảm độ trễ ghi, garbage collection, xác thực và phân quyền, volume forking và xử lý xung đột cũng sẽ được bổ sung.

So sánh với các giải pháp sao chép SQLite khác

• Graft có những lợi thế khác biệt khi so sánh với mvSQLite, Litestream, cr-sqlite, Cloudflare Durable Objects, Cloudflare D1, Turso & libSQL, rqlite & dqlite, Verneuil và các giải pháp khác.
• Những điểm khác biệt chính gồm sao chép một phần, hỗ trợ cấu trúc dữ liệu tùy ý và khả năng sao chép hiệu quả ở edge.

[GN⁺]

Ý kiến Hacker News

• Không hiểu mô hình nhất quán

  • Client Graft commit cục bộ và thử commit lên remote theo kiểu bất đồng bộ
  • Nếu hai client cùng lúc commit dựa trên cùng một snapshot thì một bên sẽ thành công và bên còn lại sẽ thất bại
  • API chỉ cung cấp thao tác commit đơn lẻ
  • Nếu commit cục bộ thành công nhưng việc lan truyền bất đồng bộ thất bại thì sẽ phát sinh vấn đề phải rollback
  • Khái niệm "commit" đang bị trộn lẫn theo nhiều nghĩa khác nhau

• Tác giả của Graft gửi lời cảm ơn

  • Đang tham dự Antithesis BugBash ở Washington DC
  • Muốn gặp những người đang ở Washington

• Hiểu rằng mô hình nhất quán này tương tự git

  • Có thể thay đổi bản sao cục bộ và khi "push" sẽ xảy ra xung đột
  • Không có cách rõ ràng để phát hiện xung đột một cách sạch sẽ
  • Xung đột có thể phát sinh do read conflict

• Khi client pull Graft thì có thể biết chính xác nội dung nào đã thay đổi

  • So sánh với manifest của Cloud-Backed SQLite
  • Không cần tính toán ở phía server

• Không đề cập đến chi tiết triển khai

  • Cần một lớp đồng bộ để nhà phát triển ứng dụng không phải bận tâm đến việc sync
  • Có thể hỗ trợ đồng bộ cá nhân mà không cần subscription

• Cho rằng việc sử dụng VFS là một "hack" thú vị

  • Đang tự phát triển một sync engine cho IDE ưu tiên offline
  • Việc giải quyết xung đột bằng cấu trúc cây là một thách thức

• Dự án sử dụng thuật toán Leap rất thú vị

  • Dù rất dễ tập trung vào tích hợp SQLite, nhưng cách tiếp cận này giải quyết một bài toán lưu trữ phân tán tổng quát hơn và ở mức thấp hơn
  • Một giải pháp quá chung chung mà không có trải nghiệm cụ thể có thể mang lại rủi ro

• Có thể phát sinh vấn đề khi client di động ở trên kết nối chậm

  • Đề xuất cách tiếp cận lai: phát hiện sync chậm và gửi truy vấn trực tiếp lên server

• Cách tiếp cận dùng page làm đơn vị đồng bộ cơ bản khá thú vị

  • Có thể phát sinh xung đột với nhiều người dùng đồng thời
  • OT hoặc CRDT có thể phù hợp hơn

• Đây là một bài toán rất thách thức

  • Muốn thử áp dụng trong ứng dụng React Native