SQLite là tất cả những gì bạn cần cho các quy trình bền vững

SQLite là tất cả những gì bạn cần cho các quy trình bền vững

Gần đây, DBOS đã lập luận rằng Postgres là tất cả những gì bạn cần cho việc thực thi bền vững (durable execution): nếu bạn đã tin tưởng vào cơ sở dữ liệu của mình, bạn sẽ không cần một tầng điều phối (orchestration tier) riêng biệt. Tôi đồng ý với hướng đi này và tin rằng ý tưởng này có thể được đẩy xa hơn nữa. Đối với một lớp lớn các hệ thống bền vững, SQLite là tất cả những gì bạn cần.

Phần cốt lõi của tính bền vững

Thực thi bền vững thường được thảo luận như thể nó yêu cầu một hạ tầng cơ sở bền vững. Trong nhiều trường hợp, điều này là không cần thiết. Phần cần phải bền vững thực sự là trạng thái của quy trình làm việc (workflow state). Phần tính toán (compute) có thể giữ giá rẻ và có thể loại bỏ (disposable).

Đây là sự phù hợp tự nhiên cho Obelisk: tiến trình của quy trình sống trong một nhật ký thực thi (execution log), các quy trình phát lại lại từ lịch sử đã lưu trữ, và các hoạt động có thể được thử lại lại. Điều quan trọng nhất là giữ trạng thái của quy trình xung quanh và dễ dàng kiểm tra.

Tại sao SQLite lại phù hợp

SQLite hấp dẫn vì nó cung cấp trạng thái bền vững theo giao dịch mà không cần giới thiệu một dịch vụ cơ sở dữ liệu riêng biệt. Không có sự nhảy qua mạng (network hop), không có mặt phẳng điều khiển (control plane) bổ sung, và không có diện tích vận hành mới chỉ để giữ tiến trình quy trình an toàn. Đối với nhiều hệ thống, một tệp cơ sở dữ liệu cục bộ chính xác là mức độ máy móc phù hợp.

Kiến trúc hệ thống sử dụng SQLite

Litestream giúp tăng tính di động

Mối lo ngại rõ ràng là phải làm gì với những tệp SQLite đó khi các thí nghiệm bắt đầu tích tụ. Đó là nơi Litestream giúp đỡ. Nó có thể truyền các thay đổi của SQLite một cách không đồng bộ đến bộ nhớ đối tượng (object storage) tương thích S3. Điều này mang lại cho bạn một cách đơn giản để giữ trạng thái làm việc gần với thời gian chạy trong khi vẫn sao chép cơ sở dữ liệu ra ngoài để sao lưu, di chuyển và kiểm tra.

Điểm cần lưu ý là sao chép của Litestream là không đồng bộ. Một quá trình khôi phục có thể bỏ lỡ các ghi cục bộ mới nhất nếu khối lượng SQLite biến mất trước khi chúng được sao chép. Điều đó ổn cho nhiều quy trình AI và thử nghiệm, nhưng nó không giống như một cơ sở dữ liệu chia sẻ có tính sẵn sàng cao.

Vẫn dẫn đến một mô hình vận hành hữu ích: chạy một máy chủ Obelisk với cơ sở dữ liệu SQLite, sao lưu nó bằng Litestream, và để một quan sát viên kéo các cơ sở dữ liệu thú vị khi cần. Cùng một tệp đó có thể được sử dụng để phát lại cục bộ, gỡ lỗi và hiểu tác nhân thực sự đã làm gì.

Tại sao mô hình này hoạt động tốt cho các tác nhân AI

Điều này đặc biệt hấp dẫn cho các tác nhân AI và quy trình được tạo bởi AI. Những hệ thống này thường hoạt động theo đợt (bursty), mang tính thử nghiệm, và dễ dàng lý luận hơn khi mỗi tác nhân hoặc người thuê có một đơn vị trạng thái nhỏ tự chứa. Một đội máy gồm các máy chủ nhỏ trong micro VMs hoặc container, mỗi cái có cơ sở dữ liệu SQLite và sao lưu bộ nhớ đối tượng riêng, thường phù hợp hơn một hệ thống chia sẻ lớn luôn hoạt động. Nó đơn giản hơn, rẻ hơn và mang lại sự cô lập lỗi tốt hơn.

Khi nào nên sử dụng Postgres thay thế

SQLite không phải là câu trả lời cho mọi hình thức triển khai. Obelisk cũng hỗ trợ Postgres, và đó là lựa chọn đúng đắn khi bạn cần tính sẵn sàng cao hơn, khả năng mở rộng chia sẻ rộng rãi hơn, hoặc các thuộc tính triển khai khác được phục vụ tốt hơn bởi một cơ sở dữ liệu mạng. Nó cũng phù hợp hơn khi sao chép không đồng bộ đến bộ nhớ đối tượng không phải là mô hình bền vững bạn muốn.

Nhiều hệ thống quy trình không cần điều đó vào ngày đầu tiên và không nên bắt đầu với nhiều hạ tầng hơn mức trạng thái của họ thực sự yêu cầu.

Trong một tập hợp lớn các trường hợp, một cơ sở dữ liệu SQLite cục bộ cộng với sao lưu Litestream đến S3 là đủ. Thêm các worker giá rẻ xung quanh và bạn có một hệ thống bền vững với rất ít hạ tầng. Đối với thế giới của các tác nhân AI, đó có thể là mặc định hợp lý nhất.