„SQLite საკმარისია გამძლე workflow-ებისთვის“ — არგუმენტი Obelisk-ის ბლოგიდან

Obelisk-ის ბლოგზე გამოქვეყნებული პოსტი ამტკიცებს, რომ გამძლე სისტემების დიდი ნაწილისთვის SQLite საკმარისია — ეს უფრო შორს მიმავალი არგუმენტია, ვიდრე DBOS-ის ცოტა ხნის წინ გამოთქმული თეზისი, რომ durable execution-ისთვის Postgres საკმარისია. ავტორი ამ მიმართულებას ეთანხმება: თუ საკუთარ ბაზას უკვე ენდობი, ცალკე ორკესტრაციის ფენა საჭირო არ არის. პოსტი 2026 წლის 29 მაისს გამოქვეყნდა.

გამძლე ნაწილი მდგომარეობაა, ინფრასტრუქტურა — არა

durable execution-ზე ხშირად ისე საუბრობენ, თითქოს ის გამძლე ინფრასტრუქტურას მოითხოვდეს. ხშირ შემთხვევაში ეს ასე არ არის: შესანარჩუნებელია workflow-ის მდგომარეობა, ხოლო გამოთვლითი რესურსი შეიძლება იაფი და ერთჯერადი დარჩეს. ეს Obelisk-ის მოდელს შეესაბამება: პროგრესი ინახება execution log-ში, workflow-ები შენახული ისტორიიდან ხელახლა მუშავდება, აქტივობები კი ხელახლა სრულდება. მთავარია, მდგომარეობა ხელმისაწვდომი და ადვილად შესამოწმებელი იყოს.

არც ქსელური ჰოპი, არც დამატებითი კონტროლის ფენა

SQLite მიმზიდველია ზუსტად იმიტომ, რომ ტრანზაქციულ გამძლე მდგომარეობას გაძლევს ცალკე ბაზის სერვისის გარეშე. არ არის ქსელური ჰოპი, არ არის დამატებითი კონტროლის სიბრტყე და არ ჩნდება ახალი ოპერაციული ზედაპირი მხოლოდ იმისთვის, რომ პროგრესი უსაფრთხოდ იყოს. ბევრი სისტემისთვის ლოკალური ბაზის ფაილი ზუსტად ის დონეა, რაც საჭიროა.

Litestream ფაილს გადატანადს ხდის

მთავარი კითხვა ისაა, რა ვუყოთ ფაილებს, როცა ექსპერიმენტები გროვდება. სწორედ აქ ეხმარება Litestream: ის SQLite-ის ცვლილებებს ასინქრონულად გადასცემს S3-თან თავსებად ობიექტურ საცავს. ასე სამუშაო მდგომარეობა გარემოსთან ახლოს რჩება, ბაზები კი სარეზერვო ასლისთვის, მიგრაციისა და დათვალიერებისთვის გადაჰქვია. შეზღუდვა ისაა, რომ რეპლიკაცია ასინქრონულია: აღდგენისას უახლესი ლოკალური ჩანაწერები შეიძლება დაიკარგოს, თუ მოცულობა მათი გადატანამდე გაქრა. AI-ისა და ექსპერიმენტული workflow-ებისთვის ეს მისაღებია, მაგრამ მაღალი ხელმისაწვდომობის საერთო ბაზას არ უტოლდება.

კარგი ნაგულისხმევი აგენტებისთვის

არგუმენტი AI-აგენტებსა და მათ მიერ გენერირებულ workflow-ებზეა გათვლილი: ისინი არათანაბარი და ექსპერიმენტულია, და მათი გააზრება უფრო ადვილია, როცა თითოეულ აგენტს ან მომხმარებელს მცირე, დამოუკიდებელი მდგომარეობა აქვს. პატარა სერვერების ფლოტი micro VM-ებში ან კონტეინერებში, თითოეულს საკუთარი SQLite ბაზითა და ობიექტურ საცავში სარეზერვო ასლით, ხშირად უფრო მარტივი, იაფი და იზოლირებულია, ვიდრე ერთი დიდი მუდმივად ჩართული სისტემა. Obelisk მხარს უჭერს Postgres-საც — ავტორის თქმით, ის სწორი არჩევანია, როცა საჭიროა მაღალი ხელმისაწვდომობა, ფართო საერთო მასშტაბირება ან სხვა სახის გამძლეობის მოდელი. ბევრ სისტემას ეს პირველ დღეს არ სჭირდება, ასკვნის პოსტი, და არ უნდა დაიწყოს იმაზე მეტი ინფრასტრუქტურით, ვიდრე მისი მდგომარეობა რეალურად მოითხოვს.