როგორ მასშტაბირდება Cloudflare-ის D1 მილიონობით მონაცემთა ბაზამდე

ზრდა AI-ის დახმარებით შექმნილი აპების ხარჯზე

Cloudflare-ის D1, SQLite-ზე აგებული მართვადი სერვერლეს მონაცემთა ბაზა, 5,5 მილიონ მონაცემთა ბაზას გადააჭარბა: 2026 წლის 8 ოქტომბრის მდგომარეობით, ცოცხალი, წაუშლელი ბაზების რაოდენობა ერთი წლის განმავლობაში 15-ჯერ, ორ წელიწადში კი 65-ჯერ გაიზარდა. ყოველდღიურად აქტიური ბაზების რაოდენობა იმავე პერიოდში 18-ჯერ მოიმატა. კომპანია ამ ნახტომს AI-ის დახმარებით დეველოპმენტსა და vibe coding-ის პლატფორმებს უკავშირებს, რომლებიც აპლიკაციებს უამრავ პატარა ბაზისკენ უბიძგებენ: თითო მომხმარებელზე, აპზე, გადახედვის გარემოზე ან ტენანტზე. OpenAI-ს ChatGPT Sites იმ პლატფორმებს შორისაა, რომლებიც D1-ზეა აგებული. ChatGPT Sites-ის ჯონ აბრამსის თქმით, D1 მომხმარებლებს „მარტივ და მასშტაბირებად გზას“ აძლევს, რომ თავიანთ დაფებს, თამაშებსა და ხელსაწყოებს ისეთი ფუნქციები დაუმატონ, როგორიცაა მორგებული მეტრიკები, ლიდერბორდები და კომენტარები.

არქიტექტურა: Durable Objects, Workers KV და Hyperdrive

ყოველი D1 ბაზა ერთი SQLite-ის Durable Object-ითაა მხარდაჭერილი, რაც მათი მილიონობით შექმნას შესაძლებელს ხდის. API-მოთხოვნები D1 Edge API Worker-ში შემოდის, Eyeball Worker კი მთელ ტრაფიკს ქვეშ მყოფ Durable Objects-ებისკენ გადაამისამართებს და დაკვირვებადობას, ავტომატურ ხელახლა ცდებსა და შეცდომების დამუშავებას უზრუნველყოფს. Workers KV წაკითხვაზე მძიმე როუტინგის მეტამონაცემებისთვის edge-ქეშირების ფენად გამოდგება, Hyperdrive კი Cloudflare-ის ძირითად მონაცემთა ცენტრებში მდებარე ცენტრალურ Postgres-კლასტერს კავშირების დაჯგუფებას, ქეშირებასა და ოპტიმიზებულ როუტინგს სთავაზობს. გუნდი ოპერაციებს სამ ნაწილად ყოფს: მონაცემთა სიბრტყე (data plane) query-ებისთვის, მართვის სიბრტყე (control plane) API-ოპერაციებისთვის და ფონური ასინქრონული სიბრტყე ანალიტიკისა და ბილინგისთვის.

სწრაფი შექმნა და თვითგამოსწორებადი heartbeat-ები

ბაზის შექმნისას მოწმდება ანგარიშის ლიმიტები, გენერირდება უნიკალური ბაზის UUID და Durable Object-ის ID, ინიციალიზდება Durable Object, მეტამონაცემები Postgres-ში ინახება და ID-ების დამაკავშირებელი ჩანაწერი Workers KV-ში იწერება. Postgres-ში ჩაწერა შექმნის საკონტროლო წერტილად მოქმედებს, KV-ის საბოლოო განახლება კი waitUntil() გამოძახებაში ხდება, რომელსაც ჩავარდნის უფლება აქვს. ყოველ 30 წამში, თითო ბაზისთვის ინდივიდუალური ჟიტერით, ყოველი Durable Object მართვის სიბრტყეს heartbeat-ს უგზავნის, რათა გაიგოს, აქტიურ მდგომარეობაშია თუ წაშლილში. ეს ობოლი Durable Objects-ებს საკუთარი თავის წაშლილად მონიშვნის საშუალებას აძლევს და იმას უზრუნველყოფს, რომ Workers KV საბოლოოდ რეალობას ასახავდეს; ამასთან, KV-ში ჩაწერების სერიალიზაციის წერტილად სწორედ Durable Object გვევლინება.

query-ების მოშორება ცენტრალური ბაზისგან

HTTP-ით გაგზავნილი query-მოთხოვნები Postgres-ს სრულად გვერდს უვლის. Edge API Worker ბაზის დამაკავშირებელ ჩანაწერს Workers KV-დან იტვირთავს და Hyperdrive-სა და Postgres-ის რეპლიკებს მხოლოდ იშვიათი ქეშ-გამოტოვების შემთხვევაში მიმართავს, შემდეგ კი query-ს Eyeball Worker-ის გავლით Durable Object-ს გადასცემს. Worker-ის binding-ები დაშიფრულ ავტორიზაციას ატარებს, ამიტომ მომხმარებლის Worker-ებიდან მომავალი მოთხოვნები დამაკავშირებელი ჩანაწერის ძებნას საერთოდ გამოტოვებს. საცავის გამოყენების განახლებები Kafka-ს მსგავსი რიგით გადის, რომ Postgres-ში ჩაწერები დაჯგუფდეს, ხოლო incremental view maintenance თითო ანგარიშის ჯამებს account_database_stats ცხრილში წინასწარ ითვლის, რათა ლიმიტების შემოწმება მუდმივ დროში მიმდინარეობდეს მილიონობით ბაზის მქონე ანგარიშებისთვისაც კი.

წყაროები: Cloudflare