Երեք քեշի շերտ ընտրության և սկավառակի միջև

Երբ ձեր հավելվածը գործարկում է SELECT դրույթը, այդ հարցումը գրեթե երբեք չի դիպչում պտտվող սկավառակին կամ նույնիսկ չմշակված ֆլեշ պահեստին. այն անցնում է երեք հստակ քեշի շերտերով, որոնք անձայն որոշում են՝ արդյոք ձեր պատասխանը հասնում է միկրովայրկյանների կամ միլիվայրկյանների ընթացքում: Այս շերտերի ըմբռնումը տարբերվում է բիզնես հարթակի միջև, որը մեծանում է առանց ջանքերի և այն հարթակի միջև, որը ճկվում է իրական ծանրաբեռնվածության տակ:

Ի՞նչ է տեղի ունենում այն պահին, երբ SELECT հարցումը թողնում է ձեր հավելվածը:

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

Այստեղ կարևոր պատկերացումն այն է, որ հարցումների քեշը խիստ զգայուն է տվյալների մուտացիաների նկատմամբ: Ցանկացած INSERT, UPDATE կամ DELETE հիմքում ընկած աղյուսակում անվավեր է դարձնում համապատասխան քեշավորված արդյունքները: Սա է պատճառը, որ գրելու ծանրաբեռնված գործարքային համակարգերը հաճախ անջատում են հարցումների քեշը և փոխարենը ապավինում են ավելի խորը շերտերին:

Ի՞նչ է բուֆերային լողավազանը և ինչո՞ւ է այն ավելի կարևոր, քան կարծում եք:

Երկրորդ քեշի շերտը, և, հավանաբար, ամենակարևորը արտադրական համակարգերում, բուֆերային լողավազանն է (կոչվում է ընդհանուր բուֆեր PostgreSQL-ում, InnoDB բուֆերային լողավազան MySQL-ում): Սա RAM-ի տարածք է, որը տվյալների բազայի շարժիչն օգտագործում է վերջերս մուտք գործած տվյալների էջերը պահելու համար: Երբ հարցումը չի կարող մատուցվել արդյունքների քեշից, շարժիչը ստուգում է, թե արդյոք պահանջվող տվյալների էջերն արդեն իսկ գտնվում են բուֆերային ֆոնդում, նախքան սկավառակի ընթերցումը թողարկելը:

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

Հիմնական պատկերացում. OLTP աշխատանքային բեռների մեծ մասում լավ չափի բուֆերային լողավազան նշանակում է, որ տվյալների բոլոր ընթերցումների 95–99%-ը սպասարկվում է RAM-ից: Աշխատանքային հավաքածուն՝ ձեր տվյալների ենթաբազմությունը, որին իրականում հարցումները հաճախ են շոշափում, հաճախ շատ ավելի փոքր է, քան տվյալների բազայի ընդհանուր չափը: Ձեր բուֆերային լողավազանի չափը այնպես, որ համապատասխանի ձեր աշխատանքային հավաքածուին, այլ ոչ թե ձեր ամբողջ տվյալների հավաքածուն, ամենաբարձր եկամտաբեր կարգավորիչ գործողությունն է, որը դուք կարող եք կատարել:

Ինչպե՞ս է օպերացիոն համակարգի քեշը լրացնում RAM-ի և սկավառակի միջև եղած բացը:

Նույնիսկ երբ տվյալների բազայի սեփական բուֆերային ֆոնդը բացակայում է, հարցումը դեռ նախատեսված չէ իրական սկավառակի ընթերցման համար: Օպերացիոն համակարգը պահպանում է էջի քեշը (նաև կոչվում է ֆայլային համակարգի քեշ), միջուկի միջոցով կառավարվող RAM-ի մի տարածք, որը բուֆերացնում է ընթերցումները և գրումը՝ սարքերը արգելափակելու համար: Երբ տվյալների բազայի շարժիչը պահանջում է էջ, որը բացակայում է իր բուֆերային լողավազանից, OS միջուկը ստուգում է իր էջի քեշը նախքան պահեստավորման կարգավորիչին ֆիզիկական I/O հրաման տալը:

Այս երրորդ շերտը հիմնականում անտեսանելի է հավելվածների մշակողների համար, բայց խորապես կարևոր է այն համակարգերում, որտեղ տվյալների բազայի բուֆերային լողավազանն անբավարար է ապահովված: ՕՀ էջի քեշը համօգտագործվում է բոլոր գործընթացներում, ուստի այն մրցակցում է ձեր հավելվածի սերվերի, վեբ սերվերի և նույն հոսթի վրա աշխատող ցանկացած այլ ծրագրաշարի հետ: Տվյալների բազայի հատուկ սերվերների վրա այս մրցակցությունը նվազագույն է, և ՕՀ-ի քեշն ապահովում է երկրորդ հնարավորության բովանդակալից բուֆեր: Հիշողության խիստ սահմանափակումներով համօգտագործվող սերվերներում կամ բեռնարկղերում ՕՀ-ի քեշը հաճախ շատ փոքր է, որպեսզի կարողանա օգնել:

Քեշի ո՞ր շերտն է պատասխանատու գործնականում առավել արդյունավետության համար:

Իրական արտադրության համակարգերում բուֆերային ֆոնդը գերիշխում է կատարողականի արդյունքների վրա մեծ տարբերությամբ: Ահա թե ինչու յուրաքանչյուր շերտը տարբեր կերպ է նպաստում օգտագործման դեպքերին.

• Հարցման արդյունքների քեշ. Ամենաբարձր օգուտը կարդալու համար ծանրաբեռնված, հիմնականում ստատիկ տվյալների հավաքածուներից՝ հաշվետվությունների հարցումներ, քեշավորված վահանակներ, հանրային բովանդակության վերջնակետեր: Անիմաստ է գրավոր ծանր աղյուսակների վրա:
• Տվյալների բազայի բուֆերային լողավազան. Համընդհանուր աշխատանքային ձի: Արտադրության տվյալների բազայի յուրաքանչյուր սերվեր նախ պետք է կարգավորվի այստեղ: Արդյունավետորեն մշակում է ինչպես պատահական, այնպես էլ հաջորդական մուտքի օրինաչափությունները:
• OS էջի քեշ. Ապահովում է անվտանգության ցանց, երբ բուֆերային լողավազանն ավելի փոքր է: Նաև զգալիորեն օգնում է մեծ աղյուսակների հաջորդական սկանավորման ժամանակ, որոնք հակառակ դեպքում կհեռացնեն տաք էջերը բուֆերային լողավազանից:
• Պահպանման կարգավորիչի քեշը (ապարատային շերտ). Չորրորդ, հաճախ անտեսված շերտ. Սա պաշտպանում է երկարակեցությունը՝ առանց գրելու թողունակությունը զոհաբերելու fsync-ի հետաձգման հաշվին:
• Հավելվածի շերտի քեշը (Redis, Memcached). Ամբողջովին տեղադրվում է տվյալների բազայի վերևում՝ քեշելով սերիականացված հարցումների արդյունքները կամ հաշվարկված օբյեկտները՝ տվյալների բազան ընդհանրապես հարվածելուց խուսափելու համար. իդեալական է բազմաբնակարան վարձակալող SaaS հարթակների համար, որոնք սպասարկում են հազարավոր միաժամանակյա օգտատերերի:

Ինչպե՞ս կարող են ժամանակակից բիզնես հարթակներն օգտագործել քեշի ճարտարապետությունը մասշտաբով հուսալիության համար:

Բազմաթիվ ֆունկցիոնալ մոդուլներում գործող բիզնեսների համար՝ CRM, նախագծերի կառավարում, էլեկտրոնային առևտուր, վերլուծություն, քեշի ճարտարապետությունը ուղղակիորեն որոշում է հարթակի արձագանքման մակարդակը թիմերի աճի հետ մեկտեղ: Լավ շերտավորված քեշի ռազմավարության վրա կառուցված հարթակները կարող են սպասարկել տասնյակ հազարավոր միաժամանակ օգտագործողների՝ առանց ենթակառուցվածքի համամասնական ծախսերի: Հիմնական բանը տվյալների մուտքի օրինաչափությունների նախագծումն է, որոնք հարգում են քեշի սահմանները. տաք տվյալները փոքր պահելը և մուտքի օրինաչափությունները կանխատեսելի, կարդալու կրկնօրինակների օգտագործումը բուֆերային լողավազանի բեռը բաշխելու համար և կիրառական շերտի քեշի տեղադրումը, ինչպիսին է Redis-ը, տվյալների բազայի առջև վերջնակետերի համար, որոնք միաժամանակ նույնական տվյալներ են մատուցում մի քանի օգտատերերի:

Mewayz-ը կառուցված է հենց այս փիլիսոփայությամբ: 207 ինտեգրված բիզնես մոդուլներով, որոնք ապահովում են ավելի քան 138,000 օգտատերերի, պլատֆորմի տվյալների շերտը նախագծված է այնպես, որ ընթերցումների ճնշող մեծամասնությունը սպասարկվում է քեշից՝ արագ արձագանքելու ժամանակը և ենթակառուցվածքի ծախսերը կանխատեսելի՝ անկախ նրանից՝ աշխատում եք $19/ամսական մեկնարկային պլանով, թե $49/ամսական պրոֆեսիոնալ մակարդակով:

Հաճախակի տրվող հարցեր

Հարցումների քեշի անջատումը միշտ բարելավո՞ւմ է տվյալների բազայի աշխատանքը:

Ոչ միշտ, բայց գրելու ծանրաբեռնվածության դեպքում դա սովորաբար արվում է: Հարցման քեշը պահանջում է գլոբալ մուտեքս՝ հետևողականությունը պահպանելու համար, որը դառնում է խցան՝ բարձր միաժամանակության դեպքում: MySQL 8.0-ն ամբողջությամբ հեռացրեց հարցումների քեշը այս պատճառով: PostgreSQL-ը երբեք չի իրականացրել ներկառուցված հարցումների քեշ՝ փոխարենը հենվելով բուֆերային լողավազանի և հավելվածի շերտի քեշավորման վրա: Եթե ձեր կարդալ-գրելու հարաբերակցությունը բարձր է, և ձեր հարցումները շատ կրկնվող են, հարցումների քեշը կարող է իրական օգուտներ բերել, հակառակ դեպքում՝ ներդնեք այդ կարգավորիչ ջանքերը բուֆերային լողավազանում:

Ինչպե՞ս կարող եմ իմանալ, արդյոք իմ բուֆերային լողավազանը ճիշտ է չափված:

Դիտեք ձեր բուֆերային լողավազանի հարվածների հարաբերակցությունը. էջի հարցումների տոկոսը, որոնք մատուցվում են լողավազանից, ընդդեմ նրանց, որոնք պահանջում են սկավառակի ընթերցում: OLTP աշխատանքային ծանրաբեռնվածության վրա 95%-ից ցածր հարվածի հարաբերակցությունը լողավազանի չափը մեծացնելու ազդանշան է: MySQL-ում հարցում կատարեք ՑՈՒՑԵՔ ENGINE INNODB STATUS-ը և դիտեք բուֆերային լողավազանի հարվածների արագությունը: PostgreSQL-ում pg_statio_user_tables տեսքը բացահայտում է սկավառակից կարդացվող կույտային բլոկները բուֆերային լողավազանից սպասարկվողի փոխարեն: Նպատակ դրեք ձեր ամբողջ աշխատանքային հավաքածուն, ոչ թե ամբողջական տվյալների բազան, պահել RAM-ում:

Ի՞նչ կապ կա քեշի շերտերի և բազմաբնակարանային SaaS հուսալիության միջև:

Բազմաբնակարանային SaaS-ում քեշի շերտերը կանխում են «աղմկոտ հարևանների» խնդիրները, երբ մեկ վարձակալի հարցումների ծանր բեռը վատացնում է մյուս բոլոր վարձակալների աշխատանքը: Վարձակալների մասին տեղեկացված հավելվածների քեշավորումը TTL-ի վրա հիմնված անվավերության միջոցով պահում է յուրաքանչյուր վարձակալի տաք տվյալները Redis-ում՝ կտրուկ նվազեցնելով բուֆերային լողավազանի ճնշումը խոշոր հաշիվներից: Տվյալների բազայի մակարդակի կապի միավորումը տաք բուֆերային լողավազանի հետ միասին երաշխավորում է, որ որևէ մեկ հաշվի ներխուժման ակտիվությունը չի մաքրում ընդհանուր էջերը քեշից և չի առաջացնում հետաձգման աճեր հարթակում:

Քեշի շերտերը տվյալների բազայի մանրուքներ չեն, դրանք ճարտարապետական հիմքն են, որը բաժանում է մասշտաբով արագ պահպանվող հարթակները նրանցից, որոնք պահանջում են մշտական ենթակառուցվածքային հրդեհաշիջում: Եթե դուք կառուցում կամ ղեկավարում եք բիզնես, որն արդեն օպտիմիզացված հարթակի կարիք ունի այս իրողությունների համար, ուսումնասիրեք Mewayz-ը app.mewayz.com կայքում — 207 մոդուլ, մեկ համահունչ հարթակ, որը կառուցված է հուսալիորեն աշխատելու ձեր առաջին օգտագործողից մինչև հարյուր հազարերորդը: