Blog

Pagbi-bill ng Database Ayon sa Aktuwal na Gamit

Bawat Mythex app na kailangang mag-imbak ng data ay may sariling Postgres database, at ang gamit ng database ng na-publish na app ay kinakaltas sa parehong credit balance ng pagbuo. Hanggang huling bahagi ng Setyembre, tinatantya namin ang gamit na iyon mula sa tagal ng pagtakbo ng server ng app. Mali ang tantiya sa paraang may malaking epekto, kaya pinalitan namin ito: ngayon, sinisingil ang bawat database batay sa compute na aktuwal na sinukat ng provider, isang tapos na oras sa isang pagkakataon, at maaari lang singilin ang bawat oras nang isang beses.

Paano gumagana ang mga database

Tumatakbo ang bawat database sa serverless Postgres na nagso-scale to zero: pagkatapos ng ilang minutong idle, natutulog ito, at gumigising sa susunod na query. Habang gising, kaya nitong dagdagan o bawasan ang compute nito ayon sa load. Ito ang nagpapaabot ng "isang database bawat app": karamihan ng app ay tahimik karamihan ng oras, at halos walang gastos ang natutulog na database.

Ibig sabihin din nito na ang gastos ng database ay nakadepende sa dalawang bagay na hindi namin nakikita mula sa labas: gaano katagal ito gising at gaano kalaki habang gising.

Ang mali sa tantiya

Ang orihinal naming meter ay may ipinapalagay: para sa bawat oras na tumatakbo ang server ng na-publish na app, maniningil ito ng database sa pinakamaliit na laki ng compute.

Mali iyon sa tatlong paraan:

  1. Mali ang laki. Sa katotohanan, mas malaki ang default na laki ng pagtakbo ng mga database kaysa sa ipinapalagay ng tantiya.
  2. Nag-a-autoscale ang mga database. Sa ilalim ng load, lumalaki ang mga ito, at hindi ito nakita ng tantiya.
  3. Hindi sumusunod ang database sa server ng app. Nananatiling gising ang database kapag may anumang nagq-query dito, ang app, isang scheduled job, o script na nagpo-poll dito, kahit tumatakbo o hindi ang server ng app.

Ang netong epekto: sinisingil ng tantiya ang mga user ng halos kalahati lang ng aktuwal na gastos ng mga database. Hindi ito napapanatili para sa amin, at ibig sabihin din nito na ang mga numero ng usage sa app ay hindi nangangahulugan ng inaakala ng mga tao.

Pagsukat sa halip na paghula

Iniuulat ng database provider namin ang compute-unit-seconds kada oras ng bawat proyekto, kung gaano karaming compute ang aktuwal na nagamit, kasama ang laki. Kaya ganito na gumagana ang meter:

  1. Para sa bawat na-publish na app na may database, kunin ang sinukat na gamit para sa bawat tapos na oras mula nang ma-live ang app.
  2. I-convert ang gamit na iyon sa gastos ayon sa presyo ng provider, ilapat ang rate ng plan, at singilin sa credits ng may-ari ng app.
  3. Tumingin pabalik nang hanggang isang araw sa bawat pagtakbo, para ang mga oras na nalaktawan habang nagre-restart ang API namin ay masisingil pa rin sa susunod.

Hiwalay na sinisingil ang storage ayon sa laki, dahil hindi ito nakadepende sa aktibidad.

Hindi kailanman magsisingil ng dalawang beses sa isang oras

Ang billing meter na tumatakbo sa higit sa isang server, at maaaring mag-crash at mag-retry, ay kailangang mag-ingat na huwag mag-double-charge. Bawat oras ng bawat database ay kinu-claim sa sarili nitong database row bago ito singilin, na may uniqueness constraint sa pares na (database, oras). Kung dalawang server, o isang retry, ang sumubok magbill ng parehong oras, isa lang ang claim na magtatagumpay.

Gumawa rin kami ng sinadyang pasya para sa bihirang kaso ng pagkabigo: kung mag-crash ang process sa pagitan ng pag-claim ng oras at ng pagsingil dito, mananatiling naka-claim at hindi nasisingil ang oras na iyon. Mas mabuting mawalan ng kaunting kita sa bihirang crash kaysa magsingil nang dalawang beses sa isang tao.

At nang i-on ang sinukat na billing, nagsimula ito sa susunod na buong oras. Ang mga oras bago iyon ay nasingil na ng lumang tantiya, at ang pagsingil ulit sa mga iyon mula sa sinukat na data ay magsisingil ng dalawang beses sa bahaging iyon.

Ano ang ibig sabihin nito kung nagbu-build ka sa Mythex

  • Ang bill ng database mo ngayon ay sumasalamin sa aktuwal na ginawa ng database mo. Ang app na bihirang gamitin ay halos walang gastos; ang app na patuloy na nagq-query sa database ay papanatilihing gising ito at mas magastos.
  • Ang pinakamalaking lever ay kung paano ginagamit ng app mo ang database. Ang pag-poll sa database kada ilang segundo ay papanatilihin itong gising buong araw. Ang pagpapahiling sa AI na kumuha ng data kapag kailangan, o pag-cache nito, ay nagpapahintulot sa database na matulog. Sakop ng aming gabay tungkol sa ano ang database ang mga pangunahing kaalaman.
  • Nagbabayad ang Pro plans ng kalahati ng Free na rate para sa hosting, database at storage. Nasa credits docs ang mga detalye.

Ang natutunan namin

  • Nagkakamali ang tantiya ng mga gastos na nakabatay sa gamit. Kapag masasabi sa iyo ng upstream provider kung ano ang nagamit, sa batay doon ka magbill.
  • Gawing idempotent ang billing sa pinakamaliit na yunit na sinisingil mo. Para sa amin, isang oras ng database.
  • Kapag kailangan mong pumalpak, pumalpak ka pabor sa customer.

Mythex · Pricing · Gumawa ng kahit ano gamit ang AI · Mga template ng website at app · Paghahambing ng Mythex · Glosaryo ng paggawa ng app gamit ang AI · Mga libreng tool sa paggawa ng app gamit ang AI · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Dansk Deutsch Ελληνικά Español Español (España) Eesti فارسی Suomi Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം Монгол मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)