Яагаад Mythex апп бүр өөрийн өгөгдлийн сантай байдаг вэ
Таны Mythex дээр бүтээсэн апп өгөгдөл хадгалах хэрэгтэй үед — бүртгэл, захиалга, захиалга — тэр төсөлд өөрийн Postgres өгөгдлийн сан өгдөг. Нийтлэг өгөгдлийн сан дээрх хүснэгт биш, өөр хэн нэгний хажууд схем биш: тусдаа өгөгдлийн сан, хэрэгцээтэй үед үүсгэж, хэн ч ашиглахгүй үед унтдаг. Бид яагаад ингэж бүтээснийг, мөн үүний зардлыг энд тайлбарлая.
Танд юу өгөгддөг вэ
Та өгөгдөл хүсвэл («waitlist имэйлүүдийг хадгал», «захиалгуудыг хадгал») эсвэл /database команд ашиглавал Mythex:
- төсөлд зориулсан тусгай Postgres өгөгдлийн сан үүсгэнэ (одоогоор Postgres 17),
- холболтын мэдээллийг таны ажлын талбар болон нийтлэгдсэн апп руу орчны хувьсагчаар оруулна, ингэснээр тэдгээр таны кодонд огт гарахгүй, мөн
- агент таны оронд хүснэгт үүсгэж, өгөгдлийг уншиж, бичиж чадна.
Live preview болон нийтлэгдсэн апп ижил өгөгдлийн санг ашигладаг. Тэр 5 минутын идэвхгүй байсны дараа унтдаг, дараагийн query-д сэрдэг. Шинэ өгөгдлийн сан жижиг эхэлж, ачаалал ихтэй үед томрох боломжтой, мөн хязгаартай тул хэт их query-ийн үед хэмжээ хязгааргүй өсөхгүй. Дэлгэрэнгүйг өгөгдлийн сангийн баримт-аас үзнэ үү.
Яагаад нэг том нийтлэг өгөгдлийн сан биш вэ?
Аппын id-г заасан баганатай нэг нийтлэг өгөгдлийн сан нь ажиллуулахад хямд, удирдахад хялбар. Бид дөрвөн шалтгаанаар үүнийг сонгоогүй.
1. Итгэх шаардлагагүй тусгаарлалт
AI-ийн бичсэн код алдаа гаргадаг. Нийтлэг өгөгдлийн санд нэг аппын query-д WHERE app_id = … дутуу байвал өөр харилцагчийн өгөгдлийг уншиж эсвэл дарж бичих байсан. Аппын бүр өөрийн өгөгдлийн сантай бол өөр харилцагчийн өгөгдөл огт хүрэх боломжгүй — алдаа өөрийн аппд л үлдэнэ.
2. Энэ бол жинхэнэ Postgres, өмчийн давхарга биш
Таны апп стандарт Postgres-тэй энгийн холболтын мөрөөр харилцдаг. Postgres-тэй ажилладаг аливаа library, ORM, хэрэгсэл энд ажилладаг. Хэрэв та төслөө экспортлож өөр газар ажиллуулбал, тэр Postgres өгөгдлийн сан хүлээдэг — хостинг бүр санал болгодог зүйл — Mythex-д онцгой API биш.
3. Апп бүрийг хэрэгтэйгээр нь хэлбэржүүлж болно
Нэг апп bookings хүснэгтэд цагийн завсарт давтагдахгүй unique constraint хүсдэг; өөр нэг нь бүтээгдэхүүний дээр бүтэн текстийн хайлт хүсдэг. Өөрийн өгөгдлийн сантай бол апп бүрийн схем, миграци өөрийнх нь асуудал. Юу ч хамгийн доод нийтлэг хуваарьтай таарах шаардлагагүй.
4. Зардал хэрэглээг дагадаг
Өгөгдлийн сан бүр өөрөө унтдаг тул ашиглагдаагүй апп бараг зардалгүй, мөн завгүй аппын зардал өөрийн мөрөөр харагддаг. Нийтлэгдсэн өгөгдлийн санг жинхэнэ хэмжсэн зүйлээр нь төлбөр тооцдог — энэ биллинг хэрхэн ажилладаг вэ.
Хосолсон зардал
Энэ загвар үнэгүй биш:
- Хүйтэн эхлэл. Унтсан өгөгдлийн сан чимээгүй хугацааны дараах эхний query дээр сэрэхэд хэсэг хугацаа шаардана. Ихэнх аппд энэ бараг мэдэгдэхгүй; цаг үеэс үл хамааран тэр даруй хариулах ёстой аппд авч үзэх зүйл.
- Сэрүүн байхад зардал. Өгөгдлийн сан ямар нэг зүйл query хийж байх үед сэрүүн байдаг. Хэдэн секунд тутам өгөгдлийн саныг шалгадаг апп нь өдөржингөө сэрүүн байж, эрэлт хүссэн үедээ query хийдэг аппаас илүү зардал гаргадаг. Хэрэглээ чинь хүлээснээс өндөр харагдвал ихэвчлэн энэ шалтгаан — AI-аас шалгахаа зогсоож, хэрэгтэй үед өгөгдөл ачаалахыг хүс.
- Бидний талын илүү хөдөлгүүр. Олон мянган өгөгдлийн санг үүсгэх, мөрдөх, цэвэрлэх нь нэгээс илүү хэцүү. Энэ бол бидний үүрэх ажил, таных биш.
Өгөгдлийн санд шинэ бол
Өгөгдлийн сан бол аппын санах ёстой зүйлсээ хадгалдаг газар. Хэрэв санаа шинэ бол өгөгдлийн сан гэж юу вэ болон Postgres гэж юу вэ-ээс эхэл. Өгөгдөл хадгалдаг зүйл бүтээхэд бэлэн болмогц AI-ээр апп хэрхэн бүтээх вэ нь нэмэх алхамуудыг дамжуулдаг.