Պատահական I/O-ի իրական արժեքը

Ձեր բիզնեսի ծրագրակազմն ավելի դանդաղ է, քան պետք է լինի, և պատահական մուտքը/ելքը անտեսանելի մեղավորն է

Ամեն անգամ, երբ հաճախորդը դժգոհում է դանդաղ վահանակից, ամեն անգամ, երբ ձեր թիմը լրացուցիչ երեք վայրկյան է սպասում հաշվետվության բեռնմանը, և ամեն անգամ, երբ ձեր վճարման էջը կորցնում է գնորդին անհամբերության պատճառով, մեծ հավանականություն կա, որ պատահական I/O հանգիստ սպառում է ձեր եկամուտը: Դա տվյալների բազայի ինժեներների համար վերապահված բառ չէ: Դա չափելի, ծախսատար խոչընդոտ է, որը թաքնվում է գրեթե յուրաքանչյուր բիզնես հավելվածի ներսում՝ սկսած CRM որոնումներից մինչև հաշիվ-ապրանքագրերի ստեղծում: Դրա իրական արժեքը հասկանալը ոչ միայն տեխնիկական վարժություն է, այլ նաև ֆինանսական: Ընկերությունները, որոնք անտեսում են այն, վճարում են փքված ամպային հաշիվները, կորցրած հաճախորդներին և թիմերին, որոնք սպասում են էկրաններին, որոնք պետք է անմիջապես բեռնվեն:

Ի՞նչ է իրականում նշանակում պատահական I/O (և ինչու է այն թանկ)

Իր հիմքում I/O — մուտք/ելք — տվյալների պահպանման և ընթերցման և գրելու գործընթացն է: Երբ ձեր հավելվածը գրառումներ է վերցնում տվյալների բազայից, ֆայլեր բեռնում սկավառակից կամ գրում է գործարքների տեղեկամատյանները, այն կատարում է I/O գործողություններ: Այս գործողությունները լինում են երկու տեսակի՝ հաջորդականև պատահական: Հերթական I/O-ն կարդում կամ գրում է տվյալներ հարակից բլոկներով, օրինակ՝ գիրք կարդալն սկզբից մինչև վերջ: Պատահական I/O-ն անկանխատեսելիորեն ցատկում է, օրինակ՝ թերթելով էջ 47, ապա էջ 3, ապա էջ 812:

Այս երկու օրինաչափությունների միջև կատարողականի տարբերությունը ապշեցուցիչ է: Ավանդական կոշտ սկավառակի վրա հաջորդական ընթերցումները կարող են հասնել 150-200 ՄԲ/վ թողունակության, մինչդեռ պատահական ընթերցումները հաճախ սողում են 0,5-1,5 ՄԲ/վ արագությամբ՝ 100x կամ ավելի տարբերություն: Նույնիսկ ժամանակակից NVMe SSD-ների վրա, որոնք կտրուկ բարելավում են պատահական I/O կատարումը, այդ բացը դեռ տատանվում է 5x-ից մինչև 20x՝ կախված ծանրաբեռնվածությունից: Երբ ձեր բիզնես հավելվածը վայրկյանում թողարկում է հազարավոր փոքր, ցրված ընթերցման հարցումներ՝ հաճախորդի անունը քաշելով այստեղ, հաշիվ-ապրանքագրի գծի ապրանքը այնտեղ, թույլտվության ստուգում մեկ այլ վայրում, յուրաքանչյուր հոպ ներմուծում է ուշացում, որը չափվում է միկրովայրկյաններով, որը վերածվում է իրական օգտագործողի սպասման վայրկյանների:

Տասնամյակների ընթացքում ֆիզիկան չի փոխվել. պահեստում ցրված տվյալների հասանելիությունը սկզբունքորեն ավելի դանդաղ է, քան դրանց հերթականությամբ հեռարձակումը: Փոխվել է այն մասշտաբները, որոնցով ժամանակակից հավելվածները պատահական մուտքեր/ելք են ստեղծում, ինչը անհնար է դարձնում անտեսել դրա արժեքը:

Թաքնված հարկը յուրաքանչյուր բիզնեսի վրա

Մտածեք, թե ինչ է տեղի ունենում, երբ մեկ օգտվող բացում է CRM վահանակը: Հավելվածը հարցումներ է կատարում հաճախորդների աղյուսակում, միանում է վերջին գործունեության գրանցամատյաններին, վերցնում է առնչվող գործարքների արժեքները, ստուգում է օգտատերերի թույլտվությունները, բեռնում է ծանուցումների քանակը և առբերում ցուցադրման նախապատվությունները: Այս հարցումներից յուրաքանչյուրը կարող է շոշափել սկավառակի տարբեր վայրերում պահվող տարբեր աղյուսակներ: Վահանակի վահանակը, որը ցուցադրում է հաճախորդների 50 գրառումները, կարող է առաջացնել 300-ից 500 պատահական I/O գործողություններ գլխարկի տակ: Բազմապատկեք դա 200 միաժամանակ օգտագործողով աշխատանքային պիկ ժամերին, և ձեր տվյալների բազայի սերվերը մշակում է ավելի քան 100,000 պատահական ընթերցումներ վայրկյանում:

Սա հիպոթետիկ չէ: Percona-ի 2024 թվականի ուսումնասիրությունը ցույց է տվել, որ տվյալների բազայի վատ օպտիմիզացված աշխատանքային բեռները ծախսում են իրենց կատարման ընդհանուր ժամանակի մինչև 68%-ը սպասելով I/O գործողություններին, ընդ որում պատահական մուտքի օրինաչափությունները հանդիսանում են հիմնական հանցագործը: SaaS ընկերության համար, որը սպասարկում է հազարավոր բիզնեսներ, դա ուղղակիորեն նշանակում է ենթակառուցվածքի ավելի բարձր ծախսեր: Ամպային մատակարարները գանձում են IOPS-ով (I/O գործառնություններ վայրկյանում), և պատահական I/O-ծանր ծանրաբեռնվածությունը կարող է ամսական պահեստային հաշիվները հարյուրավորից հասցնել տասնյակ հազարավոր դոլարների՝ ոչ թե տվյալների ծավալի, այլ մուտքի օրինաչափությունների պատճառով:

Արժեքը գերազանցում է ենթակառուցվածքը: Ամեն 100 միլիվայրկյան էջի բեռնման լրացուցիչ ժամանակը նվազեցնում է փոխակերպման տոկոսադրույքը մոտավորապես 7%-ով, ըստ Akamai-ի հետազոտության: Երբ պատահական I/O-ն ամբողջ վայրկյան է ավելացնում ձեր հաշիվ-ապրանքագրի ստեղծմանը կամ հաշվետվության բեռնմանը, դուք ոչ միայն հաշվում եք, այլև եկամուտ եք ծախսում:

Այնտեղ, որտեղ բիզնես հավելվածները նվազեցնում են արդյունավետությունը

Ոչ բոլոր հատկանիշներն են ստեղծվում հավասար, երբ խոսքը գնում է I/O նախշերի մասին: Ամենատարածված բիզնես գործառնություններից մի քանիսը նաև պատահական մուտքի ամենավատ խախտումներն են.

• Որոնում և զտում. Հարցումը մի քանի դաշտերում (անուն, ամսաթիվ, կարգավիճակ, պիտակներ) ստիպում է տվյալների բազան սկանավորել պահեստում ցրված ինդեքսները՝ առաջացնելով ծանր պատահական ընթերցումներ
• Վահանակի ագրեգացիաներ. Եկամուտների ամփոփումը, ակտիվ օգտատերերի հաշվումը կամ ժամկետանց հաշիվ-ապրանքագրերի հաշվարկը պահանջում է դիպչել հազարավոր տողերի՝ տարածված տվյալների տարբեր էջերում
• Թույլտվությունների ստուգում. Բազմ վարձակալների հարթակներում դերի վրա հիմնված մուտքի վերահսկումը հաճախ պահանջում է բազմակի որոնումներ յուրաքանչյուր հարցման համար՝ օգտատեր → դեր → թույլտվություններ → ռեսուրս՝ յուրաքանչյուրը տարբեր աղյուսակներ է դիպչում
• Հաշվետվությունների ստեղծում. Ամսական աշխատավարձի հաշվետվությունները, նավատորմի պահպանման ամփոփագրերը կամ մարդկային ռեսուրսների վերլուծությունը հավաքում են տվյալներ միաժամանակ տասնյակ աղյուսակներից
• Իրական ժամանակում ծանուցումներ. մոդուլների մեջ նոր հաղորդագրությունների, առաջադրանքների թարմացումների և համակարգի ծանուցումների ստուգումը ստեղծում է փոքր, պատահական հարցումների մշտական հոսք

Նախշը պարզ է. որքան շատ մոդուլներ և հնարավորություններ է առաջարկում պլատֆորմը, այնքան շատանում են I/O ուղիները: Պարզ հղում-in-bio գործիքը կարող է առաջացնել 10 հարցում յուրաքանչյուր էջի բեռնման համար: Ամբողջական բիզնես օպերացիոն համակարգը CRM, հաշիվ-ապրանքագրերի, HR, աշխատավարձի, ամրագրման և վերլուծական մոդուլներով, ինչպես այն, ինչ Mewayz-ն է տրամադրում իր 207 մոդուլներով, տեսականորեն կարող է ստեղծել հարյուրավոր: Ակնթարթային և դանդաղ զգացող հարթակի միջև տարբերությունը հաճախ բացատրվում է նրանով, թե որքան խելացի կերպով են կառավարվում այդ I/O նախշերը կուլիսներում:

Ինչու խնդրին ապարատը նետելը չի աշխատում

Հավելվածների դանդաղեցման բնազդը արդիականացումն է: Ավելի մեծ սերվերներ, ավելի արագ SSD, ավելի շատ RAM: Եվ չնայած ապարատային բարելավումները օգնում են, դրանք հետևում են նվազող եկամտաբերության կորին, որը ֆինանսական տնօրեններին անհարմար է դարձնում: Ձեր տվյալների բազայի սերվերի RAM-ի կրկնապատկումը՝ 64 ԳԲ-ից մինչև 128 ԳԲ, կարող է բարելավել քեշի հարվածների արագությունը 92%-ից մինչև 96%, ինչը նշանակալի շահույթ է, բայց քեշի բաց թողնված մնացած 4%-ը դեռևս հարվածում է պահեստավորմանը պատահական I/O-ով: AWS-ի վրա ձեր IOPS հատկացումը 3000-ից 10000-ի եռապատկելը ամսական մոտավորապես $450 ավելի է արժենում, սակայն կարող է միայն 30%-ով բարելավել p99 արձագանքման ժամանակը:

Իրական խնդիրը ճարտարապետական է: Պատահական I/O-ն հաճախ ավելի խորը խնդիրների ախտանիշ է. բացակայող կամ վատ նախագծված ինդեքսներ, N+1 հարցումների օրինաչափություններ, որտեղ հավելվածը կատարում է տվյալների բազայի մեկ զանգ յուրաքանչյուր կետի փոխարեն, չափից ավելի նորմալացված սխեմաներ, որոնք պահանջում են հինգ աղյուսակի միացում մեկ ցուցադրման տողի համար, և կարդալու կրկնօրինակների կամ քեշավորման շերտերի բացակայություն: Սարքավորումների արդիականացումը բուժում է ախտանիշը: Ճարտարապետական օպտիմալացումը բուժում է պատճառը:

Ամենաթանկ I/O օպերացիան այն է, որն ի սկզբանե չպետք է գոյություն ունենա: Ավելի արագ պահեստավորման վրա ծախսված յուրաքանչյուր դոլարի դիմաց հարցումների օպտիմալացման վրա ծախսված տասը ցենտն ավելի լավ արդյունքներ է տալիս: Այն ընկերությունները, որոնք հաղթում են արդյունավետության վրա, չեն գերազանցում իրենց մրցակիցները. նրանք ավելի շատ են մտածում տվյալների հասանելիության իրենց օրինաչափությունների մասին:

💡 DID YOU KNOW?

Mewayz replaces 8+ business tools in one platform

CRM · Invoicing · HR · Projects · Booking · eCommerce · POS · Analytics. Free forever plan available.

Start Free →

Գործնական ռազմավարություններ, որոնք իրականում նվազեցնում են պատահական մուտքերը/ելքը

Պատահական I/O-ի կրճատումը չի պահանջում ձեր դիմումի ամբողջական վերաշարադրում: Այն պահանջում է նպատակային, չափելի փոփոխություններ այն մասին, թե ինչպես են տվյալները պահվում, մուտք գործվում և պահվում: Ահա ամենաբարձր ազդեցությունն ապահովող ռազմավարությունները.

1. Իրականացրեք հարցումների ագրեսիվ փաթեթավորում: Փոխարինեք N+1 հարցումների ձևանմուշները անհամբեր բեռնումով: Եթե ​​ձեր վահանակը բեռնում է 50 հաճախորդ և նրանց վերջին գործունեությունը, բեռնեք բոլոր 50 գործողությունների հավաքածուները մեկ հարցման մեջ՝ օգտագործելով WHERE customer_id IN (...), այլ ոչ թե 50 անհատական ​​որոնումներ: Միայն սա կարող է նվազեցնել պատահական մուտքերը/ելքը 80%-ով ցանկի դիտումների դեպքում:
2. Օգտագործեք կոմպոզիտային ինդեքսները ռազմավարական առումով: Համակցված ինդեքսը -ում (tenant_id, status, created_at)-ում թույլ է տալիս տվյալների բազան բավարարել ընդհանուր ֆիլտրացված հարցումները մեկ հաջորդական ինդեքսների սկանավորման փոխարեն` առանձին ինդեքսներում բազմաթիվ պատահական որոնումների փոխարեն:
3. Ներկայացրեք խելացի անվավերությամբ քեշավորման շերտ: Հիշողության մեջ հաճախ հասանելի, բայց հազվադեպ փոփոխվող տվյալների՝ օգտատիրոջ թույլտվությունները, կազմակերպության կարգավորումները, մոդուլի կազմաձևերը, քեշը: Redis-ը կամ Memcached-ը կարող են դրանք մատուցել միկրովայրկյանում՝ վերացնելով րոպեում հազարավոր պատահական ընթերցումներ:
4. Նախապես հաշվարկեք ագրեգացիաները: Վահանակի յուրաքանչյուր բեռնվածության վրա ամսական եկամուտը կամ աշխատատեղերի քանակը հաշվարկելու փոխարեն, գործարկեք ագրեգացիոն աշխատանքները ժամանակացույցով և պահեք արդյունքները: Փոխանակեք փոքր քանակությամբ տվյալների թարմություն իրական ժամանակում պատահական I/O-ի զանգվածային կրճատման համար:
5. Մեծ աղյուսակները բաժանեք ըստ մուտքի օրինաչափության: Եթե հարցումների 90%-ը վերաբերում է վերջին 30 օրվա տվյալներին, բաժանեք ձեր աղյուսակներն ըստ ամսաթվերի միջակայքի, որպեսզի ակտիվ բաժանումը մնա տաք պահոցում, մինչդեռ պատմական տվյալները սառչում են ավելի էժան պահեստավորման դեպքում:

Սրանք էկզոտիկ տեխնիկա չեն: Դրանք նույն օրինաչափություններն են, որոնք թույլ են տալիս հարյուր հազարավոր օգտատերերի սպասարկող հարթակներին պահպանել պատասխանի երկրորդական ժամանակները բարդ, բազմամոդուլային ինտերֆեյսներում: Երբ Mewayz-ը վերակառուցեց իր ճարտարապետությունը V2-ի համար՝ մասշտաբը մեկ կապի մեջ բիո գործիքից մինչև 207 մոդուլանոց բիզնես ՕՀ, որը սպասարկում է ավելի քան 138,000 օգտատերերի, I/O մուտքի օրինաչափությունների օպտիմալացումը հիմնարար նշանակություն ունեցավ այդ ընդլայնումը կենսունակ դարձնելու համար՝ առանց ենթակառուցվածքի ծախսերը համամասնորեն բազմապատկելու:

Բարդող ազդեցություն օգտատերերի փորձի և պահպանման վրա

Կատարումը պարզապես հետին պլանի խնդիր չէ, այլ արտադրանքի առանձնահատկություն է: Google-ի հետազոտությունը հետևողականորեն ցույց է տվել, որ բջջային օգտատերերի 53%-ը լքում է էջը, որի բեռնումը տևում է ավելի քան 3 վայրկյան: Բիզնես հավելվածների համար, որտեղ օգտատերերը շփվում են օրական տասնյակ անգամներ, հանդուրժողականությունը նույնիսկ ավելի ցածր է: Աշխատավարձի մենեջեր, որը վարում է շաբաթական հաշվետվություններ, HR առաջատարը, որը վերանայում է դիմորդներին կամ վաճառքի ներկայացուցիչը ստուգում է խողովակաշարի կարգավիճակը. այս օգտվողները զարգացնում են արագության ինտուիտիվ զգացողություն: Նրանք չեն կարող արտահայտել «պատահական I/O հետաձգումը հաշիվ-ապրանքագրերի ագրեգացման հարցումում չափազանց բարձր է», բայց նրանք կասեն «այս ծրագրաշարը դանդաղ է թվում» և կսկսեն գնահատել այլընտրանքները:

Միացվող ազդեցությունը չափելի է: Պլատֆորմը, որը 2,4 վայրկյանի փոխարեն բեռնում է վահանակները 800 մվ-ում, ոչ միայն 3 անգամ ավելի արագ է զգում, այլ փոխում է օգտագործման վարքագիծը: Օգտատերերն ավելի հաճախ են ստուգում տվյալները, ուսումնասիրում են ավելի շատ մոդուլներ և ավելի խորը ինտեգրում գործիքն իրենց աշխատանքային հոսքերի մեջ: Ավելի բարձր ներգրավվածությունը հանգեցնում է ավելի մեծ պահպանման, ինչը հանգեցնում է կյանքի ավելի մեծ արժեքի: Slack-ը հայտնի է, որ իր վաղ աճի զգալի մասը վերագրում էր աշխատանքի մոլուցքային օպտիմիզացմանը՝ գիտակցելով, որ արագությունն ինքնին մրցակցային խրամատ է:

Բոլորը մեկում բիզնես հարթակների համար այս էֆեկտը բազմապատկվում է յուրաքանչյուր մոդուլի վրա: Եթե ​​CRM-ն արագ է, բայց հաշիվ-ապրանքագրերը դանդաղ են, ամբողջ հարթակի ընկալումը տուժում է: Գործառույթների հետևողականությունը՝ սկսած ամրագրումների կառավարումից մինչև նավատորմի հետագծում մինչև վերլուծություն, պահանջում է հետևողականորեն օպտիմիզացված I/O նախշեր ամենուր, ոչ միայն ամենատեսանելի մոդուլներում:

Կարևորների չափում. Պատահական I/O տեսանելի դարձնելը

Դուք չեք կարող ուղղել այն, ինչ չեք կարող տեսնել: Պատահական I/O ծախսերը լուծելու առաջին քայլը դրանք տեսանելի դարձնելն է ձեր ինժեներական և գործառնական թիմերի համար: Դիտորդության ժամանակակից գործիքները, ինչպիսիք են Datadog-ը, New Relic-ը կամ նույնիսկ բաց կոդով լուծումները, ինչպիսիք են Prometheus-ը Grafana-ով, կարող են հետևել IOPS-ի օրինաչափություններին, հարցումների հետաձգման բաշխմանը և քեշի հարվածների արագությանը իրական ժամանակում: Առավել կարևոր ցուցանիշներն են՝

• p95 և p99 հարցումների ուշացում. Միջին ուշացումը թաքցնում է ցավը: 95-րդ և 99-րդ տոկոսը ցույց է տալիս, թե իրականում ինչ են զգում ձեր ամենադանդաղ և հիասթափված օգտվողները
• IOPS-ի բաշխումն ըստ կարդալու և գրելու, հաջորդական ընդդեմ պատահականության. Սա ցույց է տալիս, թե արդյոք ձեր ծանրաբեռնվածությունը I/O-ի հետ կապված է, և I/O-ի որ տեսակն է գերակշռում
• Քեշի հարվածների հարաբերակցությունը. 95%-ից ցածր հարաբերակցությունը լավ կարգավորված համակարգում հուշում է տվյալների հասանելիության օրինաչափություններ, որոնք չեն սպասարկվում հիշողությունից
• Հարցումների քանակը մեկ էջի բեռնման համար. Եթե մեկ օգտատիրոջ գործողությունը առաջացնում է տվյալների բազայի 20-30-ից ավելի հարցումներ, ապա գրեթե անկասկած կա օպտիմալացման հնարավորություն

Զինված այս տվյալներով՝ թիմերը կարող են առաջնահերթություն տալ ամենաբարձր ազդեցություն ունեցող օպտիմալացումներին, քան գուշակություններին: Այն ձեռնարկությունները, որոնք վերաբերվում են I/O-ի կատարողականին որպես առաջին կարգի չափման՝ գործարկման ժամանակի, սխալների տեմպերի և օգտատերերի բավարարվածության հետ մեկտեղ, հետևողականորեն մատուցում են ավելի արագ արտադրանք՝ ավելի ցածր գնով: Մի շուկայում, որտեղ օգտատերերն ակնկալում են, որ բիզնես գործիքները նույնքան արձագանքող կլինեն, որքան սպառողական հավելվածները, այդ կարգապահությունը կամընտիր չէ: Դա տարբերվում է հարթակի միջև, որը նրբագեղորեն հասնում է 138,000 օգտատերերի, և այն հարթակի միջև, որն իր բարդության տակ է: