სიახლეები და ანალიზი
ON DELETE CASCADE, შარდები და რეპლიკები: სამი გადაწყვეტილება ბაზაში, რომელსაც მერე ნანობენ
PlanetScale-მა ერთ კვირაში კასკადურ წაშლაზე, shard group-ებსა და Neki-ს რეპლიკებზე დაწერა. რა ეხება აქედან ერთ სერვერზე მდგომ ბაზას და როგორ ვაპროექტებ თავად.
PlanetScale-მა ერთ კვირაში Postgres-ზე სამი ტექსტი გამოუშვა: რატომ არ უნდა ენდო ON DELETE CASCADE-ს, როგორ დააპროექტო შარდები და რა არის ახალი მათ შარდირებულ Neki-ში. ოცდაათკაციან კომპანიას შარდები ჯერ დიდხანს არ დასჭირდება. კასკადური წაშლა და კითხვა „რა ჩაითვალოს წაშლილად“ კი ნებისმიერ ბაზას ეხება, იმასაც, რომელიც ერთ ვირტუალურ მანქანაზე დგას და განაცხადებს, ხარჯთაღრიცხვებსა და კლიენტებს ინახავს.
რა გამოვიდა
PlanetScale-მა 21 ოქტომბერს ახსნა, რატომ არ ენდობა ON DELETE CASCADE-ს. ცდუნება გასაგებია: აღწერე გარე გასაღებები, და Postgres შვილობილ სტრიქონებს თავად შლის. პრობლემები მერე მოდის. დიდი კასკადური წაშლა ყველა შეხებულ ცხრილზე ბლოკირებას იჭერს, ხოლო ჩვეულებრივი მიგრაცია, როგორიც სვეტის დამატებაა, მის უკან რიგში დგება და ყველა ახალ მოთხოვნას თან მიათრევს: მათთან ეს production-ში ჩაწერის გაჩერებით დასრულდა. ერთი ასეთი DELETE დიდ გარემოებში ტრანზაქციაზე ასობით გიგაბაიტ WAL-ს წერდა. გარე გასაღები ინდექსის გარეშე ერთი სტრიქონის წაშლას ცხრილის სრულ გავლად აქცევს. ლოგიკური რეპლიკაციისას კი გამომწერი კასკადებს არ ასრულებს, და თუ მას საკუთარი შვილობილი ცხრილი აქვს, მასში ობლები რჩება ერთი შეცდომის გარეშე. მათი პასუხი: რბილი წაშლა. ერთი სტრიქონი deleted_at-ს იღებს, ნამდვილი DELETE-ები კი მერე მიდის, პაკეტებად, წყნარ საათებში, მაგალითად 30 დღის შემდეგ.
23 ოქტომბერს იმავე გუნდმა Neki-ში შარდების პროექტირება გაარჩია. პროექტირების ერთეული იქ shard group-ია: ცხრილები, რომლებიც გასაღებს ერთნაირად ჰეშავენ, ერთი customer_id-ის მქონე სტრიქონებს ერთ შარდზე დებენ, და კლიენტის შეკვეთები, პოზიციები და მისამართები ყოველთვის გვერდიგვერდაა. ცნობარები, როგორიც ქვეყნები და ვალუტებია, reference tables-ად ცხადდება და ყველა შარდზე კოპირდება. კატალოგის შარდირება lower(sku)-თი შეიძლება, რომ AB-1042 და ab-1042 ერთ ადგილას მოხვდეს. და ერთი დათქმა: ტრანზაქცია ერთი შარდის შიგნით Postgres-ის სემანტიკას ინარჩუნებს, ტრანზაქციას ორ შარდზე ატომური commit არ აქვს.
20 ოქტომბერს Neki-ს განახლებების მიმოხილვაში დაწერეს, რომ preview-ს ერთ თვეში შარდებისთვის read-only რეპლიკები დაამატეს, Metal კვანძები $50-დან თვეში 1/8 vCPU-მდე, 1 GB მეხსიერებითა და 10 GB NVMe-ით, გაშვება Azure-ში, მატერიალიზებული წარმოდგენების, LISTEN/NOTIFY-ისა და კურსორების მხარდაჭერა, ხოლო COPY TO STDOUT ახლა შარდირებულ ცხრილებზე მუშაობს, ასე რომ pg_dump მონაცემებს კითხულობს. განაწილებული INSERT ... SELECT, მათი თქმით, preview-ს დაწყებასთან შედარებით დაახლოებით 76-ჯერ უფრო სწრაფი გახდა.
რატომ სჭირდება ეს ბიზნესს
ავიღოთ ავტომობილების გაქირავება. მენეჯერი კლიენტს შლის, რადგან მან სთხოვა, ან შეცდომით. თუ ბაზაში კასკადი ჩართულია, კლიენტთან ერთად მისი ჯავშნები, გაცემის აქტები, ხელმოწერები და დათვალიერების ფოტოებიც მიდის. ერთ თვეში დაზიანებაზე დავა მოდის, და დასამტკიცებელი არაფერია. თუ კასკადი არ არის და „წაშლილია“ ნიშანია, კლიენტი სიებში არ ჩანს, მაგრამ ისტორია მთელია, და 30 დღის განმავლობაში გადაწყვეტილების გაუქმება შეიძლება.
დასკვნა: ბიზნეს-სისტემაში წაშლა სტატუსი უნდა იყოს, რომლის გაუქმებაც შეიძლება. შარდები და რეპლიკები კი მაშინ არის საჭირო, როცა ერთი მანქანა ვეღარ უმკლავდება, და ამ მომენტამდე კომპანიების უმეტესობას შორს აქვს. ინდექსის გარეშე გარე გასაღებიან ბაზებს უფრო ხშირად ვხვდები, ვიდრე ბაზებს, რომლებსაც ერთ სერვერზე ადგილი არ ჰყოფნით.
როგორ მაქვს ეს მოწყობილი
MariaDB თითქმის ყველა ჩემს პროექტში დგას, და კასკადურ წაშლას არ ვრთავ ხოლმე: კავშირები აღწერილია, ხოლო რა ჩაითვალოს წაშლილად, სერვერზე ლოგიკა წყვეტს.
საწარმოო კომპანიასთან ნომენკლატურაში ათიათასობით პოზიციაა, და დეტალებისა და მასალების გაანგარიშების პროგრამა მათ 1C-სთან ადარებს. თუ პოზიცია ნომენკლატურაში არ არის, სპეციფიკაცია ან დოკუმენტაციის ფაილი აკლია, პროგრამა ამას ჩუმად არ უშვებს: ნიშანი შედეგში ჩანს. ეს იგივე ისტორიაა ობლებზე PlanetScale-ის ტექსტიდან, წესების დონეზე გადაწყვეტილი. ერთ შეკვეთას პროგრამა საშუალოდ 65 წამში ამუშავებს, ადრე ამას 4-5 საათი სჭირდებოდა, და შარდები ამისთვის არ დასჭირვებია.
აშშ-ში PDR-კომპანიაში 2023 წელს Google Sheets-იდან SQL-ბაზაზე გადასვლა შევთავაზე სიჩქარისა და მონაცემების ერთიანი ფორმატისთვის. იდეას მხარი დაუჭირეს, და MariaDB-ზე გადასვლის შემდეგ სერვისებს ერთიმეორის მიყოლებით ვაერთებდით: დოკუმენტების პარსერებს, ტელეფონიას, leaderboard-ს. იქ ყოველი ზარი იწერება, ყოველი ნამდვილი ლიდი ძაბრს ბოლომდე გადის, და კონვერსია 30%-ით გაიზარდა. ასეთს კასკადურ წაშლაზე არ ავაგებდი: ლიდი ზარის ჩანაწერითა და დოკუმენტებით მერე ანგარიშებისთვის არის საჭირო, გარიგება დახურულიც რომ იყოს ან კლიენტი წასულიყოს.
Neki და მისი shard group-ები ჩემთან არ შემიმოწმებია: არცერთი ჩემი დამკვეთის მონაცემები იმ დონემდე არ გაზრდილა, სადაც ერთი ბაზა Debian-ზე Google Cloud-ში ვეღარ უმკლავდება.
რას გავაკეთებდი
ნახეთ, არის თუ არა ბაზაში ON DELETE CASCADE. თუ არის, ამოწერეთ ცხრილების ჯაჭვი, რომელიც ერთი სტრიქონის მიყოლებით წაიშლება, და აჩვენეთ ბიზნესის მფლობელს. ჩვეულებრივ ამაზე კასკადს თიშავენ.
შემოიღეთ რბილი წაშლა კლიენტებისთვის, შეკვეთებისა და დოკუმენტებისთვის: ველი deleted_at და ფილტრი მოთხოვნებში. ფიზიკური წმენდა ცალკე დავალებით გაუშვით, პაკეტებად, არასამუშაო საათებში.
შეამოწმეთ ინდექსები გარე გასაღებებზე. ეს ერთი ბრძანებაა და ხშირად ნელი ბაზის ყველაზე იაფი შეკეთება.
შარდებზე არ იფიქროთ, სანამ ერთი მანქანა უმკლავდება. თუ ვეღარ უმკლავდება, ჯერ წაკითხვის რეპლიკა ანგარიშებისთვის, და მხოლოდ მერე საუბარი shard group-ებზე.
როგორ იჭერს სერვერი სისტემის წესებსა და მდგომარეობას, სტატიაში სერვერი: მონაცემები, წვდომა და პროცესის შესრულება დავწერე. მიმართულებები: შიდა სისტემები და მონაცემების დამუშავება Python-ზე. ქეისები: შეკვეთის გაანგარიშება წარმოებისთვის და PDR-კომპანიის ტექნიკური პარტნიორი. იმავე თემაზე: სქემის მიგრაციები შიშის გარეშე და ბექაპი, რომელიც არავის აღუდგენია. ადრე ვწერდი მძიმე მოთხოვნებსა და ბაზაში დიდ მნიშვნელობებზე. თუ თქვენს ბაზაში რაღაც კასკადურად იშლება და დარწმუნებული არ ხართ, ზუსტად რა, მოყევით, როგორ არის მოწყობილი: ამოცანის განხილვა.