Heroku Postgres Advanced-ը բաժանում է հաշվարկն ու պահեստը՝ առանց restart-ի

2026 թվականի հոկտեմբերի 6-ին Heroku-ն հայտարարեց Advanced-ի ընդհանուր հասանելիության մասին․ նոր շերտը բաժանում է հաշվարկն ու պահեստը, ընկերությունը խոստանում է ավելի քան 200 ՏԲ պահեստ, իսկ համադրելի Classic կազմաձևերի նկատմամբ 3–4 անգամ մեծ թողունակությունը վերագրում է իր ներքին չափումներին և փորձնական կիրառմանը։ Ծանրաբեռնված հավելվածի համար ճարտարապետական փոփոխությունն այն է, որ տվյալների ծավալի աճն այլևս պարտադիր չի պահանջում համարժեք հաշվարկային հզորություն գնել։

Postgres Weekly-ի թողարկումը նույնպես Advanced-ը ներկայացնում է որպես ընդհանուր հասանելի նոր շերտ։ Արդեն հավելվածին կցված հաշվարկային pool-ը կարելի է մեծացնել առանց հավելվածը վերագործարկելու, սակայն այդ պայմանը չի տարածվում նոր կապակցում ավելացնելու կամ Classic-ից տեղափոխվելու ամբողջ ընթացքի վրա։ Հետևաբար անցման օգուտը կախված է ոչ միայն բազայի չափից, այլև նրանից, թե որ ծանրաբեռնվածությունն է այսօր սահմանափակում հավելվածը։

Պահեստի աճն այլևս չի թելադրում հաշվարկի չափը

Advanced-ի կլաստերում պահեստը ընդհանուր է, իսկ հաշվարկային ռեսուրսները կազմակերպված են առանձին instance pool-երով։ Եթե տվյալները շատանում են, բայց հարցումների մշակման պահանջը գրեթե նույնն է մնում, կարելի է ավելացնել պահեստը՝ առանց հաշվարկի նույնպիսի աճի։ Հակառակ իրավիճակում հաշվարկային հզորությունը կարելի է փոխել՝ տվյալների պահման կարիքը չդարձնելով ավելի մեծ պլան ընտրելու պատճառ։ Սա հատկապես շոշափելի տարբերություն է այն հավելվածների համար, որոնց պահեստի օգտագործումն ու պրոցեսորի ծանրաբեռնվածությունը աճում են տարբեր տեմպերով։

Առավելագույն ծավալի հարցում, սակայն, Heroku-ի հրապարակված տվյալները չեն համընկնում։ Instance pool-երի տեխնիկական փաստաթուղթը նշում է կլաստերի համար ներառված 100 ԳԲ պահեստ և մինչև 100 ՏԲ օգտագործման հնարավորություն, մինչդեռ մեկնարկային հայտարարությունը խոսում է ավելի քան 200 ՏԲ-ի մասին։ Երկուսն էլ վերաբերում են նույն նոր շերտի պահեստին, ուստի մեծ բազայի նախագծման համար փաստաթղթում նշված հասանելի սահմանը չի կարելի ինքնաբերաբար փոխարինել հայտարարության բարձր արժեքով։

Առանձին մասշտաբումը չի նշանակում, որ յուրաքանչյուր կլաստեր ավելի էժան կլինի Classic-ից։ Վճարման մեջ նշանակություն ունեն պահեստի փաստացի օգտագործումը, leader-ի ընտրված հզորությունը և ավելացված follower-ների կազմաձևը։ Պահեստով ծանր, բայց հաշվարկով թեթև հավելվածի համար այդ բաժանումը կարող է վերացնել ավելորդ հաշվարկ գնելու անհրաժեշտությունը։ Եթե հավելվածին միաժամանակ պետք են ավելի հզոր leader և լրացուցիչ follower-ներ, համեմատելի է արդեն ամբողջ կլաստերի, այլ ոչ միայն պահեստի արժեքը։

Follower pool-երը փոխում են ընթերցումների բաշխումը

Advanced-ի leader-ը կատարում է գրառումները և կարող է սպասարկել նաև ընթերցումներ, իսկ follower pool-երը նախատեսված են ընթերցման հարցումների համար։ Հավելվածը կարող է հիմնական գործողություններից առանձնացնել, օրինակ, հաշվետվության կամ վերլուծության հարցումները և դրանք ուղղել follower-ին։ Այդ դեպքում երկարատև ընթերցումները նույն հաշվարկային ռեսուրսի համար ավելի քիչ են մրցում գրառումները մշակող leader-ի հետ։ Ընթերցման պահանջի աճին հնարավոր է արձագանքել follower-ի հզորությամբ՝ չփոխելով leader-ի չափը։

Այս բաժանումը պահանջում է, որ հավելվածը տարբերակի կապերը։ Նոր pool ունենալը ինքնուրույն չի տեղափոխում առկա հարցումները․ ընթերցումները պետք է օգտագործեն follower-ի միացման հասցեն, իսկ տվյալ փոխող գործողությունները՝ leader-ինը։ Եթե հիմնական խցանումը գրառումներն են, follower-ների ավելացումը ուղղակիորեն չի մեծացնի գրելու հզորությունը։ Իսկ երբ ծանր հաշվետվությունները մրցում են օգտատերերի սովորական հարցումների հետ, առանձին pool-ը դրանց համար հստակ հաշվարկային սահման է ստեղծում։

Classic-ում նույնպես կան ընթերցման follower-ներ, հետևաբար ընտրությունը միայն դրանց առկայության հարցը չէ։ Advanced-ի տարբերությունը նույն կլաստերի ներսում առանձին հաշվարկային pool-երի կառավարումն է՝ ընդհանուր պահեստի վրա։ Այդ կառուցվածքը կարող է օգտակար լինել, երբ ընթերցման տարբեր աշխատանքներ տարբեր հզորություն են պահանջում։ Պարզ ծանրաբեռնվածությամբ հավելվածի համար լրացուցիչ pool-երի կառավարումը կարող է ավելի մեծ բարդություն բերել, քան չափելի օգուտ։

Առանց restart-ի մասշտաբումն ունի հստակ սահման

Արդեն հավելվածին կցված pool-ի հզորությունը կարելի է փոխել՝ պահպանելով նրա առկա կապակցումը և հավելվածի կարգավորման փոփոխականը։ Այդ պայմաններում հաշվարկային ռեսուրսի մասշտաբումը հավելվածի restart չի պահանջում։ Նոր attachment ավելացնելը այլ գործողություն է․ այն ստեղծում է միացման նոր կարգավորում, որի պատճառով հավելվածը վերագործարկվում է։ Այս տարբերությունը կարևոր է հատկապես այն ծառայության համար, որն իր երթևեկության պիկերի ժամանակ հաշվարկի արագ փոփոխության կարիք ունի։

Classic-ից Advanced տեղափոխվելը նույնպես առանձին փոփոխություն է։ Նոր բազան պետք է ստանա տվյալները, հավելվածը՝ նոր միացման կարգավորումը, իսկ գրառումների շարունակականությունը պետք է պահպանվի անցման ընտրված եղանակով։ Գործող Advanced pool-ի հետագա մասշտաբման հատկությունից չի հետևում, որ սկզբնական տեղափոխությունը կանցնի առանց դադարի։ Թույլատրելի ընդհատման տևողությունը որոշվում է տվյալների ծավալով, փոփոխությունների հոսքով և հավելվածի միացումը փոխելու ընթացքով։

Այդ պատճառով «առանց restart-ի» խոստումը առավել օգտակար է կրկնվող գործառնական փոփոխությունների համար։ Եթե հավելվածը պարբերաբար բախվում է հաշվարկային ծանրաբեռնվածության աճին, արդեն կցված pool-ի մեծացումը կարող է կատարվել առանց հավելվածի նոր գործարկման։ Եթե նպատակը միայն մեկանգամյա տեղափոխությունն է, այս հատկությունը ինքնին չի լուծում անցման կազմակերպման խնդիրը։

Որ ծանրաբեռնվածության դեպքում է անցումն արդարացված

Classic-ից անցնելու որոշումը կարելի է կառուցել փոխկապակցված պայմանների շուրջ։ Առավել ուժեղ դեպքն այն է, երբ գործող բազայի սահմանափակումն արդեն տեսանելի է և Advanced-ի կոնկրետ հնարավորությունը համապատասխանում է հենց այդ սահմանափակմանը։ Ընտրությունը կախված է պահեստի աճից, ընթերցումների բաժանման կարիքից, թույլատրելի դադարից և համադրելի կազմաձևերի սեփական չափումներից։

• Պահեստ. Երբ տվյալների ծավալն աճում է հաշվարկային ծանրաբեռնվածությունից արագ, ընդհանուր պահեստի առանձին մեծացումն ունի հստակ արժեք։ Շատ մեծ ծավալի դեպքում հրապարակված սահմանների անհամապատասխանությունը պետք է հաշվի առնել մինչև կլաստերի չափը որոշելը։
• Ընթերցումներ. Երբ հաշվետվությունները կամ վերլուծական հարցումները ծանրաբեռնում են հիմնական բազան, follower pool-ը դրանց համար առանձին հզորություն է տալիս։ Եթե խցանումը գրառումներն են, այս բաժանումը չի հասցեագրում հիմնական խնդիրը։
• Pool-երի կարիք. Երբ ընթերցման աշխատանքներն ունեն տարբեր պահանջներ, դրանց առանձնացումը կարող է արդարացնել նոր կառուցվածքի կառավարումը։ Միատեսակ և կայուն ծանրաբեռնվածության դեպքում Classic-ի պարզ կազմաձևը կարող է բավարար մնալ։
• Դադար. Գործող pool-ի հետագա մասշտաբման և սկզբնական տեղափոխության ազդեցությունները տարբեր են։ Ծառայությունը, որի համար տեղափոխության ընդհատումը կարևոր է, պետք է գնահատի հենց անցման ընթացքը։
• Սեփական չափում. Արտադրողի ներքին թողունակության արդյունքը չի նկարագրում յուրաքանչյուր հավելվածի հարցումները։ Համադրելի Classic և Advanced կազմաձևերով անհրաժեշտ են նույն իրական ծանրաբեռնվածության ուշացման, թողունակության, կապերի օգտագործման և ամբողջական ծախսի տվյալները։

Եթե Classic-ի պահեստն ու հաշվարկը դեռ բավարար են, իսկ ընթերցումները չեն խցանում հիմնական բազան, նոր շերտի ճկունությունը կարող է մնալ չօգտագործված։ Այն հավելվածների համար, որոնց սահմանափակումը արդեն չափված է, որոշիչը կլինի՝ արդյոք առանձին պահեստը կամ follower pool-երը բարելավում են հենց այդ ծանրաբեռնվածության արդյունքը՝ հաշվի առնելով տեղափոխության ազդեցությունն ու ամբողջ կլաստերի արժեքը։

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

• App Store-ի նոր վիզուալը կարելի է փոխել՝ առանց հավելվածի նոր տարբերակի
• Kit թե Mailchimp․ անվճար 10 հազար բաժանորդը գալիս է առանց ավտոմատացումների
• PostgreSQL թե MySQL․ արագության հաղթողը որոշում է հենց ծանրաբեռնվածությունը