რატომ იღებს ყოველი Mythex აპი საკუთარ მონაცემთა ბაზას

როცა თქვენ მიერ Mythex-ზე აგებულ აპს მონაცემების შენახვა სჭირდება — რეგისტრაციები, ჯავშნები, შეკვეთები — Mythex ამ პროექტს საკუთარ Postgres ბაზას აძლევს. არა ცხრილს საერთო ბაზაში და არა სქემას სხვისი გვერდით: ცალკე ბაზას, რომელიც საჭიროებისამებრ იქმნება და როცა არავინ იყენებს, იძინებს. აი, რატომ ავაგეთ ასე და რა ღირს ეს.

რას იღებთ

როცა მონაცემებს ითხოვთ („შეინახე ლოდინის სიის ელფოსტები“, „შეინახე ჯავშნები“), ან იყენებთ ბრძანებას /database, Mythex:

• ქმნის პროექტისთვის გამოყოფილ Postgres ბაზას (ამჟამად Postgres 17),
• აკავშირებს ბაზის მონაცემებს თქვენს სამუშაო სივრცესა და გამოქვეყნებულ აპში გარემოს ცვლადების სახით, ასე რომ ისინი კოდში არასდროს ჩნდება, და
• აძლევს აგენტს საშუალებას, შექმნას ცხრილები და წაიკითხოს და ჩაწეროს მონაცემები თქვენთვის.

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

რატომ არა ერთი დიდი საერთო ბაზა?

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

1. იზოლაცია, რომელსაც არ უნდა ენდოთ

AI-ით დაწერილი კოდი შეცდომებს უშვებს. საერთო ბაზაში ერთ აპის ერთ მოთხოვნაში დაკარგული WHERE app_id = … მეორე მომხმარებლის მონაცემებს წაიკითხავდა ან გადაწერდა. აპზე ერთი ბაზით არცერთი სხვა მომხმარებლის მონაცემი არ არის ხელმისაწვდომი — ბაგი თავის აპში რჩება.

2. ეს რეალური Postgres-ია, არა საკუთრებითი ფენა

თქვენი აპი სტანდარტულ Postgres-ს უკავშირდება ჩვეულებრივი კავშირის სტრიქონით. ნებისმიერი ბიბლიოთეკა, ORM ან ინსტრუმენტი, რომელიც Postgres-თან მუშაობს, აქაც მუშაობს. თუ პროექტს ექსპორტირებთ სხვაგან გასაშვებად, ის Postgres ბაზას ელის — რასაც ყველა ჰოსტინგ პროვაიდერი სთავაზობს — და არა Mythex-ისთვის სპეციფიკურ API-ს.

3. თითოეული აპი ისეთი იქნება, როგორიც მას სჭირდება

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

4. ფასი მოჰყვება გამოყენებას

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

კომპრომისები

ეს დიზაინი უფასო არ არის:

• ცივი დაწყება. მძინარე ბაზას ჭირდება წუთი, რომ გაიღვიძოს პირველ მოთხოვნაზე სიჩუმის შემდეგ. ბევრი აპისთვის ეს თითქმის შეუმჩნეველია; აპისთვის, რომელმაც ყოველთვის, ნებისმიერ საათზე, მაშინვე უნდა უპასუხოს, ეს გასათვალისწინებელია.
• ღვიძილში ხარჯი. ბაზა ღვიძავს, სანამ რაიმე მას უკავშირდება. აპი, რომელიც ბაზას ყოველ რამდენიმე წამში აკითხავს, მას მთელი დღე ღვიძილში ინახავს და უფრო მეტი ღირს, ვიდრე აპი, რომელიც მოთხოვნით კითხულობს. თუ თქვენი გამოყენება უფრო მაღალია, ვიდრე მოელოდით, ხშირად ეს არის მიზეზი — სთხოვეთ AI-ს, შეწყვიტოს გამოკითხვა და მონაცემები მაშინ ჩატვირთოს, როცა საჭიროა.
• მეტი მოძრავი ნაწილი ჩვენთვის. ათასობით ბაზის შექმნა, თვალყურის დევნება და გასუფთავება ერთზე მეტი სამუშაოა. ეს ჩვენი პრობლემაა, არა თქვენი.

თუ მონაცემთა ბაზებში ახალი ხართ

ბაზა არის ადგილი, სადაც აპი ინახავს იმას, რაც უნდა დაიმახსოვროს. თუ იდეა ახალია, დაიწყეთ რა არის მონაცემთა ბაზა და რა არის Postgres. როცა მზად იქნებით იმის ასაგებად, რაც მონაცემს ინახავს, როგორ ავაგოთ აპი AI-ით ნაბიჯ-ნაბიჯ გიხსნით, როგორ დაამატოთ ბაზა.