ბაზის სქემის შეცვლა სიურპრიზების გარეშე: Supabase-ის ბრენჩები, pg-delta და მილიონობით SQLite

ერთ კვირაში ოთხი ჩანაწერი გამოვიდა მონაცემთა ბაზების სტრუქტურაზე. Supabase-მა აჩვენა, როგორ იქმნება პროექტის ასლი-ბრენჩი და როგორ იწყობა ახლა მიგრაციები pg-delta-ზე. Cloudflare-მა მოყვა, როგორ ემსახურება D1 მილიონობით SQLite ბაზას. PlanetScale-მა ახსნა, რატომ არ შეიძლება შარდირებულ Postgres-ში sequence შარდს მიანდო. PostgreSQL-ის სიახლეებში კი pgrecon გამოაცხადეს, Oracle-დან გადასვლის შეფასების ინსტრუმენტი. საერთო თემა ერთია: მონაცემების სტრუქტურის ცვლილება პროგნოზირებადი უნდა იყოს. ბიზნესისთვის ეს ასე ჟღერს: შეკვეთას ახალი ველი დაამატეს, და არც ერთი ანგარიში, არც ერთი ინტეგრაცია არ გატყდა.

რა გამოვიდა

Supabase-მა 15 ოქტომბერს განიხილა, როგორ იღებს ახალი ბრენჩი კონფიგურაციას, მიგრაციებსა და ფუნქციებს. ბრენჩი ცალკე პროექტია, და შექმნისას სამი ნაწილი პარალელურად მიდის: მთავარი პროექტიდან პარამეტრების კოპირება, მიგრაციები და Edge Functions-ის დეპლოი; მზადყოფნის მედიანური დრო დაახლოებით 20 წამია. მიგრაციის ყოველი ფაილი ერთ ტრანზაქციად სრულდება. ყოველ ნაბიჯს თავისი მდგომარეობა აქვს: RUNNING, EXITED, PAUSED ან DEAD, ასე რომ ჩავარდნისას ჩანს, რამ მოასწრო შესრულება.

13 ოქტომბერს Supabase-მა აღწერა Declarative Schemas 2.0 pg-delta-ზე, რომლებიც 2 ოქტომბერს Supabase Select-ზე აჩვენეს. სქემა SQL-ფაილებში ინახება, მიგრაციას კი CLI თავად წერს. pg-delta ორ დროებით ბაზას უშვებს: ერთში სქემის ფაილებს ტვირთავს, მეორეში მიგრაციების ისტორიას ათამაშებს, მათ სისტემური კატალოგით ადარებს და შედეგს დამოკიდებულებების გრაფის მიხედვით ალაგებს. დიფში ახლა შედის RLS-პოლიტიკები, გრანტები, დომენები, პარტიციები და გაფართოებების ობიექტები, ხოლო დამანგრეველ გამოძახებებს CLI ცალკე ნიშნავს.

PlanetScale-მა 14 ოქტომბერს გამოაქვეყნა ჩანაწერი sequence-ზე და სხვა volatile-გამოსახულებებზე Neki-ში, მათ შარდირებულ Postgres-ში. არსებობს router-only გამოსახულებების კლასი: now() სხვადასხვა შარდზე საათების დრეიფის გამო სხვადასხვა დროს მოგცემს, ამიტომ მას მარშრუტიზატორზე ითვლიან, ერთხელ ყოველ მოთხოვნაზე. Sequence-ს იმავე მიზეზით ცენტრი სჭირდება: გარანტიას, რომ ნომერი არ განმეორდება, შარდებს შორის ვერ გაყოფ.

Cloudflare-მა 13 ოქტომბერს მოყვა, როგორ მასშტაბირდება D1 მილიონობით ბაზამდე. D1 მათი serverless ბაზაა SQLite-ზე. მათი ციფრებით, 2026 წლის 8 ოქტომბრისთვის ცოცხალი ბაზების რაოდენობა წელიწადში 15-ჯერ გაიზარდა და ორ წელიწადში 65-ჯერ, ხოლო დღეში აქტიური ბაზების რაოდენობა წელიწადში 18-ჯერ. პრინციპები, რომლებსაც ასახელებენ: ყოველი პროცესი ისე დააპროექტე, რომ ჩავარდნა და გვერდითი ეფექტის გარეშე ხელახალი გაშვება გაითვალისწინოს, მოთხოვნის გზაზე ცენტრალიზებული კომპონენტები არ დადგა და სისტემა რეალურთან ახლო დატვირთვით შეამოწმე.

22 ოქტომბერს PostgreSQL-ის სიახლეებში გამოჩნდა pgrecon 0.7.3, Oracle-დან PostgreSQL-ზე გადასვლის შეფასების ინსტრუმენტი Apache-2.0 ლიცენზიით. ოფლაინ მუშაობს: მხოლოდ წაკითხვის სკრიპტი დამპს აკეთებს, ინსტრუმენტი მის მიხედვით ინვენტარს აგებს, 80 წესს ატარებს და ადამიან-დღეების დიაპაზონს გასცემს. ყველაფერი, რისი გადატანაც შეუძლებელია, ცალკე ანგარიშში ხვდება.

მაგალითი: გაქირავება ბავშვის სავარძელს ამატებს

მანქანების გაქირავების კომპანია ჯავშნებს Google Sheets-ის ცხრილში აწარმოებს და ამატებს სვეტს „ბავშვის სავარძლის საფასური“. CRM-თან ინტეგრაცია სვეტების ძველ ნაკრებს ელოდება, მენეჯერების აპლიკაციამ ახალი ველის შესახებ არ იცის, შემოსავლის ანგარიში კი სხვა რამეს აჯამებს. ეს სქემის მიგრაციაა ინსტრუმენტების გარეშე და ბრენჩის გარეშე, სადაც მისი შემოწმება შეიძლებოდა. სამხრეთ აფრიკაში ამით დავიწყე: პირველი ამოცანა იყო AmoCRM-ის Google Sheets-ის ცხრილთან დაკავშირება, რომ მასში მომსახურების ღირებულება, გარბენი და ბავშვის სავარძლის საფასური განახლებულიყო, შემდეგ კი FlutterFlow-ზე აწყობილი აპლიკაციის ველების AmoCRM-თან შესაბამისობაში მოყვანა და არჩეული ველების სინქრონიზაციის მოწყობა. სქემა სისტემებს შორის შეთანხმებაა, და ის ისე უნდა შეიცვალოს, რომ ყველა მხარემ ამის შესახებ წინასწარ გაიგოს.

როგორ არის ეს ჩემთან მოწყობილი

შიდა სერვისი „ყავა ერთად“ React-სა და TypeScript-ზეა დაწერილი და Cloudflare Workers-ის runtime-ში მუშაობს, D1 API-ით ლოკალური SQLite ბაზის თავზე Docker volume-ში, საერთო სერვერზე 2 GB მეხსიერებით. საიტი kononov.dev-იც SQLite-ზეა.

Cloudflare-ის პრინციპებიდან პირველი, ხელახალი გაშვება გვერდითი ეფექტის გარეშე, ჩემთან „ყავა ერთად“-ში მუშაობს: ძველი Google Sheets-ის ცხრილიდან იმპორტის ჟურნალი შეკვეთას საწყისი სტრიქონის ნომერთან აკავშირებს, ამიტომ განმეორებითი ჩატვირთვა დუბლიკატებს არ ქმნის, შეცვლილი სტრიქონი კი კონფლიქტად ჩანს. გვერდით არის წესი, რომელსაც თავად ვიცავ: წარუმატებელი ნაბიჯი სამუშაო მონაცემებს არ აფუჭებს. კატალოგი Tasty Coffee-ს საბითუმო API-სთან განრიგით სინქრონიზდება, და წარუმატებელი მცდელობა გამოქვეყნებულ კატალოგს არ შლის.

აშშ-ის PDR-კომპანიაში 2023 წელს შევთავაზე Google Sheets-იდან SQL-ბაზაზე გადასვლა სიჩქარისა და მონაცემების ერთიანი ფორმატისთვის. იდეას მხარი დაუჭირეს, და MariaDB-ზე გადასვლის შემდეგ ახალ სერვისებს ერთმანეთის მიყოლებით ვაერთებდით. ნებისმიერი მიგრაცია ჯობია ჯერ ბაზის ასლზე გაატარო და მხოლოდ შემდეგ გამოუშვა. Supabase-ის ბრენჩები, pg-delta და pgrecon ჩემთან არ გამიშვია და აღწერებით ვმსჯელობ.

რას გავაკეთებდი

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

ყოველი მიგრაცია სამუშაო ბაზის გუშინდელ ასლზე გაატარეთ, აპლიკაციასა და ანგარიშებთან ერთად.

ველები ორ ნაბიჯად შეცვალეთ: ჯერ ახალი დაამატეთ და ყველა სისტემა მასზე გადაიყვანეთ, ძველი კი ცალკე რელიზით წაშალეთ, როცა მას აღარავინ იყენებს.

დიფი, რომელიც ინსტრუმენტმა დაწერა, თვალით წაიკითხეთ, განსაკუთრებით ყველაფერი, რაც დამანგრევლად არის მონიშნული.

თუ გადასვლა სხვადასხვა DBMS-ს შორისაა, დაიწყეთ ინვენტარით და იმის სიით, რისი გადატანაც შეუძლებელია, pgrecon-ის მსგავსად.

იმაზე, რატომ უნდა ცხოვრობდეს სისტემის მდგომარეობა ერთ ადგილას, არის სტატია სერვერზე, როგორც სისტემის ბირთვზე. ამ მიმოხილვის სერვისი: „ყავა ერთად“. ბაზაში სამი გადაწყვეტილება, რომლებზეც მერე ნანობენ, მიმოხილვაშია კასკადურ წაშლაზე, შარდებსა და რეპლიკებზე, პლატფორმები საკუთარი სერვერის წინააღმდეგ მიმოხილვაში ბექენდებზე Vercel-ზე, Fly-სა და Supabase-ში, განახლებების დაზიანების რადიუსი მიმოხილვაში Netflix-ის ინსტრუმენტსა და TypeScript 7.1-ზე. შუამავლებს ბაზის განახლებამდე ადრეც ვამოწმებდი. მიმართულებები: ინფრასტრუქტურა და DevOps და შიდა სისტემები. თუ სამუშაო სისტემაში მონაცემების სტრუქტურის შეცვლა გელით, მომიყევით, რა იცვლება და ვინ სარგებლობს ამ მონაცემებით. ამოცანის განხილვა.