Supabase թե Firebase․ իրական ժամանակը, offline-ը և հաշիվը տարբեր հաղթողներ ունեն

Կապակցված տվյալներով հավելվածի համար Supabase-ի PostgreSQL-ը հաճախ ավելի հարմար մեկնարկ է։ Եթե բջջային ծառայությունը պետք է պահպանի փոփոխությունները կապի բացակայության ժամանակ և ուղարկի դրանք վերամիանալուց հետո, Firebase-ի Cloud Firestore-ն ունի պատրաստի հնարավորություն։ Այս ընտրությունը որոշում է նաև, թե թիմը որքան համաժամեցման աշխատանք պետք է կատարի ինքնուրույն։

Իրական ժամանակի արագության և ամսական հաշվի ընդհանուր հաղթող չկա։ Հրապարակված մեկ Flutter հավելվածում նույն տարածաշրջանի թարմացումը Firestore-ով ավելի շուտ է հասել, մինչդեռ ծառայությունների գնացուցակները չափում են տարբեր բաներ՝ փաստաթղթային գործողություններ մի կողմում, նախագծի ռեսուրսներ և հաղորդագրություններ՝ մյուսում։ Նույն հավելվածի ընթերցումները, բաժանորդագրություններն ու ելքային տրաֆիկը կարող են փոխել ծախսերի հարաբերությունը։

Տվյալների մոդելը փոխում է հարցումները

Supabase-ի հիմքում PostgreSQL-ն է։ Պայմանական թիմային հավելվածում թիմերը, անդամներն ու առաջադրանքները կարելի է պահել առանձին աղյուսակներում և կապել SQL հարցմամբ։ Դա օգտակար է, երբ նույն առաջադրանքների մասին պետք են տարբեր համակցված պատկերներ՝ ըստ թիմի, պատասխանատուի կամ վերջնաժամկետի։ Փոխարենը թիմը նախագծում է սխեման, ինդեքսներն ու մուտքի կանոնները։

Cloud Firestore-ի Standard տարբերակը տվյալները կազմակերպում է հավաքածուների ու փաստաթղթերի մեջ։ Առաջադրանքի էջի համար ամբողջական փաստաթուղթ կարդալը կարող է պարզ լինել, բայց տարբեր դաշտերով զտումն ու տեսակավորումը պահանջում են համապատասխան ինդեքսներ։ Այդ պատճառով ընտրությունը վերաբերում է նաև տվյալների դասավորությանը. PostgreSQL-ում կապակցված գրառումները կարելի է հարցնել միասին, իսկ Firestore-ում պետք է նախապես մտածել, թե որ փաստաթղթերն է կարդալու յուրաքանչյուր էկրան։

Իրական ժամանակի ուշացումը ամբողջ պատկերը չէ

Նույն Flutter հավելվածի հրապարակված համեմատության մեջ թարմացման տարածումը նույն տարածաշրջանում կազմել է մոտ 60 մվ Firebase-ի և մոտ 80 մվ Supabase-ի դեպքում։ Սա այդ հավելվածի արդյունքն է. հրապարակումը չի տալիս հիմք նույն տարբերությունը խոստանալու Հայաստանից միացող բոլոր օգտատերերին։ Օգտատիրոջ ցանցը, բազայի տարածաշրջանը, լսիչների կազմը և ծանրաբեռնվածությունը ազդում են նրա տեսած ուշացման վրա։

Թիմային հավելվածում կարևոր է նաև, թե ինչ է կատարվում կապի ընդհատումից հետո։ Firestore-ի լսիչը աշխատում է տեղային պահոցի հետ, իսկ Supabase Realtime-ի վերամիացումը հավելվածի համար բաց թողնված փոփոխությունների ամբողջական հերթ չի կազմում։ Supabase օգտագործող հաճախորդը պետք է նորից ստանա ընթացիկ վիճակը, որպեսզի չշարունակի աշխատել հնացած առաջադրանքների ցուցակով։ Եթե սարքում կան չուղարկված փոփոխություններ, անհրաժեշտ է նաև դրանք համադրել սերվերի վիճակի հետ։

Offline աշխատանքը պատրաստի հնարավորություն է միայն մի կողմում

Firestore-ի offline աշխատանքի ուղեցույցը նկարագրում է տեղային պահոցը, կապի բացակայության ժամանակ գրառումները և վերադարձած կապով դրանց համաժամեցումը։ Android և Apple հավելվածներում պահպանումը միացված է լռելյայն, իսկ վեբում այն պետք է միացնել։ Սարքում հասանելի են նախկինում ստացված տվյալները, ոչ ամբողջ հեռավոր բազան. չպահված փաստաթուղթը offline հարցմամբ չի հայտնվի։

Նույն փաստաթղթի մրցակցող փոփոխությունների դեպքում Firestore-ը կիրառում է վերջին գրառման կանոնը։ Դա կարևոր է, օրինակ, երբ երկու աշխատակից կապից դուրս փոխում են մեկ առաջադրանքի կարգավիճակը. սերվերի հետ համաժամեցումից հետո հավելվածի ցուցադրած վերջնական վիճակը կարող է չպահպանել երկուսի մտադրությունն էլ։ Supabase-ով offline ծառայություն կառուցելիս տեղային պահոցը, չուղարկված գործողությունների հերթը և նման հակասությունների մշակումը պետք է նախագծել հավելվածի կազմում։ Այդ աշխատանքի արժեքը ամպային ամսական վճարում չի երևում։

Ինչի համար է գանձվում վճարը

Supabase-ի գնացուցակում Pro պլանը սկսվում է ամսական $25-ից. ներառված $10 հաշվարկային վարկը ծածկում է մեկ Micro նախագծի հաշվարկային հզորությունը։ Պլանում ներառված են 100 000 ամսական ակտիվ օգտատեր՝ նույնականացման ծառայության համար, 250 ԳԲ սովորական ելքային տրաֆիկ և ամսական 5 միլիոն Realtime հաղորդագրություն։ Այդ շեմերից հետո սովորական ելքի սակագինը $0.09 է մեկ ԳԲ-ի, իսկ հաղորդագրություններինը՝ $2.50 մեկ միլիոնի համար։ Ավելի մեծ հաշվարկային հզորությունն ու լրացուցիչ նախագծերը կարող են ավելացնել վճարը։

Firestore Standard-ի սակագնային նկարագրության us-central1 օրինակում մեկ միլիոն փաստաթղթային ընթերցումն արժե $0.30, մեկ միլիոն գրառումը՝ $0.90։ Լսիչի արդյունքներում հայտնված կամ թարմացված փաստաթուղթը նույնպես ընթերցում է հաշվվում։ Բարդ հարցումը կարող է առաջացնել ինդեքսի ընթերցումներ, իսկ փաստաթղթերի պահեստավորումն ու ցանցային ելքը վճարի առանձին մասեր են։

Firebase-ի գնացուցակով Firestore Standard-ի անվճար բաժինը օրական 50 000 ընթերցում և 20 000 գրառում է, իսկ ելքի համար՝ ամսական 10 GiB։ Օրական սահմանը չի կարելի նույնացնել Supabase-ի ամսական շեմերի հետ։ Ստորև Firestore-ի դոլարային թվերը հաշվարկում են միայն փաստաթղթային ընթերցումներն ու գրառումները us-central1-ի նշված սակագներով. ելքի, պահեստավորման և այլ ծառայությունների արժեքը դրանց վրա պետք է ավելացնել առանձին։

Երեք պայմանական հավելվածի հաշիվը

Հաշվարկների ամիսը պայմանական 30 օր է։ Ամեն սցենարում օրական ակտիվ մարդկանց կազմը նույնն է ամբողջ ամսվա ընթացքում, գործողությունները հավասարաչափ են բաշխված, իսկ Supabase-ի մեկ Micro նախագիծը բավարար է։ Այս ենթադրությունները թույլ են տալիս կիրառել օրական անվճար բաժինը և ամսական ակտիվ օգտատերերի շեմը՝ առանց դրանց միջև կեղծ հավասարություն դնելու։ Իրական հավելվածում նոր օգտատերերի հոսքը կամ ծանրաբեռնվածության պիկերը կարող են փոխել արդյունքը։

• Պարզ MVP. Պայմանական 1 000 օրական ակտիվ օգտատերից յուրաքանչյուրը կատարում է օրական 10 ընթերցում և 2 գրառում, իսկ ամսական ելքը 3 ԳԲ է։ Սա կազմում է ամսական 300 000 ընթերցում և 60 000 գրառում. Firestore-ի գործողությունները տեղավորվում են օրական անվճար բաժնում։ Supabase Free-ը նույնպես կարող է տեղավորել այս բեռը, եթե բազան և մյուս ռեսուրսները մնում են դրա սահմաններում։ Անընդհատ գործող Pro նախագծի ելակետը $25 է։
• Իրական ժամանակի թիմային հավելված. Պայմանական 10 000 օրական ակտիվ օգտատերից յուրաքանչյուրը կատարում է 100 ընթերցում և 10 գրառում, իսկ ամսական ելքը 100 ԳԲ է։ Ամսական 30 միլիոն ընթերցման և 3 միլիոն գրառման Firestore վճարովի մասը, օրական անվճար բաժինը հանելուց հետո, $10.71 է՝ առանց ելքի։ Եթե նույն հավելվածը Supabase-ում առաջացնում է 30 միլիոն հաշվարկվող Realtime հաղորդագրություն, դրանց հավելավճարը $62.50 է, և Pro-ի ու Micro-ի պայմանական հաշիվը դառնում է $87.50։ Ընթերցումների ու հաղորդագրությունների հավասար քանակն այստեղ հաշվարկային ենթադրություն է. իրական բաժանորդագրությունը կարող է մեկ փոփոխությունը հասցնել բազմաթիվ հաճախորդների։
• Offline-first բջջային ծառայություն. Պայմանական 50 000 կայուն օրական ակտիվ օգտատերերից յուրաքանչյուրը կատարում է 5 ընթերցում և 2 գրառում, ամսական ելքը 20 ԳԲ է։ Firestore-ի 7.5 միլիոն ընթերցման և 3 միլիոն գրառման վճարովի մասը $3.96 է՝ առանց ելքի։ Supabase Pro-ի Micro ելակետը $25 է, եթե լրացուցիչ Realtime վճար չի առաջանում։ Սակայն այս համեմատության մեջ Supabase-ի տեղային հերթի ու համաժամեցման մշակման աշխատանքը դրամային թիվ չունի։

Որ փոփոխությունն է շրջում ծախսերի հարաբերությունը

Թիմային պայմանական սցենարի հիմքը 10 000 կայուն օրական ակտիվ օգտատեր, 30 միլիոն ամսական ընթերցում, նույնքան ենթադրված Realtime հաղորդագրություն և 100 ԳԲ ելք է։ Հետևյալ զգայունության տողերում փոխվում է մեկ պայման, իսկ Firestore-ի դրամային թվերը շարունակում են բացառել ելքը։

• Ընթերցումները կրկնապատկվում են. Firestore-ի միայն ընթերցումների վճարը $8.55-ից հասնում է $17.55-ի։ Եթե Supabase-ի հաղորդագրություններն էլ աճում են մինչև 60 միլիոն, դրանց հավելավճարը $62.50-ից դառնում է $137.50։ Առանց բաժանորդագրության լրացուցիչ SQL հարցումը ինքնին Realtime հաղորդագրություն չէ։
• Ելքը հասնում է 300 ԳԲ-ի. Supabase Pro-ի սովորական ելքի ներառված բաժնից 50 ԳԲ ավելը տալիս է $4.50 հավելավճար։ Firestore-ում ևս անցնում է անվճար ելքի սահմանը, բայց դրա վճարը կախված է ընտրված տարածաշրջանից և փոխանցման ուղղությունից. այն այստեղ նույն դոլարային սակագնով հաշվելը սխալ համեմատություն կլիներ։
• Օրական ակտիվ օգտատերերը կրկնապատկվում են. Եթե մեկ մարդու գործողությունների թիվը նույնն է, Firestore-ի ընթերցումների ու գրառումների միասնական վճարը $10.71-ից դառնում է $22.41՝ առանց ելքի։ Հաղորդագրությունների համաչափ աճի դեպքում Supabase-ի պայմանական հաշիվը $87.50-ից հասնում է $162.50-ի, եթե Micro-ի հզորությունն ու միաժամանակյա կապերի սահմանը շարունակում են բավարարել հավելվածին։

Տեղափոխվելիս որ աշխատանքն է մնում

Supabase-ից հեռանալիս PostgreSQL աղյուսակներն ու SQL հարցումները տեղափոխելի հիմք են, սակայն նույնականացումը, մուտքի կանոնները և իրական ժամանակի հաղորդագրությունները նույնպես պետք է փոխարինել։ Firestore-ից հարաբերական բազա անցնելիս փաստաթղթերում ներդրված տվյալները պետք է վերածել աղյուսակների ու կապերի։ Հակառակ ուղղությամբ կարող է անհրաժեշտ լինել կրկնել որոշ տվյալներ փաստաթղթերում, որպեսզի հավելվածի էկրանները ստանան իրենց անհրաժեշտ պատասխանը։

Ուստի կապակցված տվյալներով ծառայության համար Supabase-ի առավելությունը հարցումների ու հետագա տեղափոխման կառուցվածքի մեջ է, իսկ հաճախ կապը կորցնող բջջային ծառայության համար Firestore-ի առավելությունը պատրաստի տեղային աշխատանքն է։ Իրական ժամանակի թիմային հավելվածում որոշիչը լսիչների և վերամիացումների վարքն է՝ դրա հետ միասին առաջացող ընթերցումներն ու հաղորդագրությունները։ Միայն անվճար շեմը կամ մեկ հրապարակված ուշացման չափումը այդ ընտրությունը չի լուծում։

Կարդացեք նաև:

• Riverside թե Descript․ լավ ձայնագրությունն ու արագ մոնտաժը տարբեր հաղթողներ ունեն
• Meta թե Alphabet․ ԱԲ ծախսերի նույն մրցավազքը թաքցնում է տարբեր շարժիչներ
• PostgreSQL թե MySQL․ արագության հաղթողը որոշում է հենց ծանրաբեռնվածությունը