Բարեւ բոլորին! Ես Գոլով Նիկոլայ եմ։ Նախկինում ես աշխատել եմ Avito-ում և ղեկավարել եմ Data Platform-ը վեց տարի, այսինքն՝ աշխատել եմ բոլոր տվյալների բազաներում՝ վերլուծական (Vertica, ClickHouse), հոսքային և OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL): Այս ընթացքում ես առնչվել եմ մեծ թվով տվյալների բազաների հետ՝ շատ տարբեր և անսովոր, և դրանց օգտագործման ոչ ստանդարտ դեպքերի հետ:
Ես ներկայումս աշխատում եմ ManyChat-ում: Ըստ էության, սա ստարտափ է՝ նոր, հավակնոտ և արագ աճող: Եվ երբ ես առաջին անգամ միացա ընկերությանը, առաջացավ դասական հարց. «Ի՞նչ պետք է վերցնի երիտասարդ ստարտափը այժմ DBMS-ի և տվյալների բազայի շուկայից»:
Այս հոդվածում, հիմնվելով իմ զեկույցի վրա , ես կպատասխանեմ այս հարցին. Զեկույցի տեսագրությունը հասանելի է հետևյալ հասցեով .
Ընդհանուր հայտնի տվյալների բազաներ 2020 թ
2020 թվականն է, ես նայեցի շուրջս և տեսա երեք տեսակի տվյալների բազա։
Առաջին տեսակ - դասական OLTP տվյալների բազաներPostgreSQL, SQL Server, Oracle, MySQL: Դրանք գրվել են շատ վաղուց, բայց դեռևս արդիական են, քանի որ այնքան ծանոթ են մշակողների համայնքին:
Երկրորդ տեսակն է հիմքերը «զրոյից». Նրանք փորձեցին հեռանալ դասական օրինաչափություններից՝ հրաժարվելով SQL-ից, ավանդական կառուցվածքներից և ACID-ից՝ ավելացնելով ներկառուցված հղկման և այլ գրավիչ հատկություններ: Օրինակ, սա Cassandra, MongoDB, Redis կամ Tarantool է: Այս բոլոր լուծումները ցանկանում էին շուկային սկզբունքորեն նոր բան առաջարկել և զբաղեցրին իրենց տեղը, քանի որ պարզվեց, որ դրանք չափազանց հարմար են որոշակի խնդիրների համար: Ես կնշեմ այս տվյալների բազաները NOSQL տերմինով:
«Զրոներն» ավարտվեցին, մենք ընտելացանք NOSQL տվյալների բազաներին, և աշխարհը, իմ տեսանկյունից, կատարեց հաջորդ քայլը. կառավարվող տվյալների բազաներ. Այս տվյալների բազաները ունեն նույն միջուկը, ինչ դասական OLTP տվյալների բազաները կամ նոր NoSQL: Բայց նրանք DBA-ի և DevOps-ի կարիք չունեն և աշխատում են ամպերում կառավարվող ապարատով: Մշակողի համար սա «ուղղակի բազա է», որն աշխատում է ինչ-որ տեղ, բայց ոչ ոքի չի հետաքրքրում, թե ինչպես է այն տեղադրվում սերվերի վրա, ով է կարգավորել սերվերը և ով է այն թարմացնում:
Նման տվյալների բազաների օրինակներ.
- AWS RDS-ը կառավարվող փաթաթան է PostgreSQL/MySQL-ի համար:
- DynamoDB-ն փաստաթղթերի վրա հիմնված տվյալների բազայի AWS անալոգ է, որը նման է Redis-ին և MongoDB-ին:
- Amazon Redshift-ը կառավարվող վերլուծական տվյալների բազա է:
Սրանք հիմնականում հին տվյալների շտեմարաններ են, բայց ստեղծվել են կառավարվող միջավայրում, առանց սարքաշարի հետ աշխատելու անհրաժեշտության:
Նշում. Օրինակները վերցված են AWS միջավայրի համար, սակայն դրանց անալոգները կան նաև Microsoft Azure-ում, Google Cloud-ում կամ Yandex.Cloud-ում:
Ի՞նչ նորություն կա այս մասին: 2020 թվականին՝ սրանից ոչ մեկը։
Առանց սերվերի հայեցակարգ
2020 թվականին շուկայում իսկապես նոր բան կա առանց սերվերի կամ առանց սերվերի լուծումների:
Ես կփորձեմ բացատրել, թե դա ինչ է նշանակում՝ օգտագործելով սովորական ծառայության կամ հետին պլանի հավելվածի օրինակը:
Սովորական backend հավելվածը տեղակայելու համար մենք գնում կամ վարձակալում ենք սերվեր, պատճենում ենք կոդը դրա վրա, հրապարակում վերջնակետը դրսում և պարբերաբար վճարում վարձակալության, էլեկտրաէներգիայի և տվյալների կենտրոնի ծառայությունների համար: Սա ստանդարտ սխեման է:
Այլ ճանապարհ կա՞։ Առանց սերվերի ծառայություններով դուք կարող եք.
Ո՞րն է այս մոտեցման կենտրոնացումը. սերվեր չկա, նույնիսկ ամպի մեջ վիրտուալ օրինակ վարձել չկա: Ծառայությունը տեղակայելու համար պատճենեք կոդը (գործառույթները) պահոցում և հրապարակեք այն վերջնական կետում: Այնուհետև մենք պարզապես վճարում ենք այս ֆունկցիայի յուրաքանչյուր զանգի համար՝ ամբողջովին անտեսելով այն սարքաշարը, որտեղ այն իրականացվում է:
Այս մոտեցումը կփորձեմ պատկերացնել նկարներով։
Դասական տեղակայում. Մենք որոշակի ծանրաբեռնվածությամբ ծառայություն ունենք։ Մենք բարձրացնում ենք երկու օրինակ՝ ֆիզիկական սերվերներ կամ օրինակներ AWS-ում: Արտաքին հարցումներն ուղարկվում են այդ ատյաններ և այնտեղ ընթացք ստանում։
Ինչպես տեսնում եք նկարում, սերվերները հավասարապես չեն հեռացվում: Մեկը 100%-ով օգտագործված է, կա երկու հարցում, իսկ մեկը միայն 50%-ով` մասամբ պարապուրդի: Եթե ոչ թե երեք խնդրանք գա, այլ 30, ապա ամբողջ համակարգը չի կարողանա հաղթահարել բեռը և կսկսի դանդաղեցնել:
Առանց սերվերի տեղակայում. Առանց սերվերի միջավայրում նման ծառայությունը չունի օրինակներ կամ սերվերներ: Կա ջեռուցվող ռեսուրսների որոշակի լողավազան՝ փոքր պատրաստված Docker կոնտեյներներ՝ տեղակայված գործառույթի կոդով: Համակարգը ստանում է արտաքին հարցումներ և դրանցից յուրաքանչյուրի համար առանց սերվերի շրջանակը բարձրացնում է կոդով փոքր կոնտեյներ. այն մշակում է այս կոնկրետ հարցումը և սպանում կոնտեյները:
Մեկ խնդրանք՝ բարձրացված մեկ կոնտեյներ, 1000 հարցում՝ 1000 կոնտեյներ։ Իսկ ապարատային սերվերների վրա տեղակայումն արդեն ամպային մատակարարի աշխատանքն է: Այն ամբողջովին թաքնված է առանց սերվերի շրջանակի կողմից: Այս հայեցակարգում մենք վճարում ենք յուրաքանչյուր զանգի համար: Օրինակ՝ օրը մեկ զանգ էր գալիս՝ մեկ զանգի համար վճարում էինք, րոպեում միլիոնը գալիս էր՝ միլիոնի համար վճարում։ Կամ մեկ վայրկյանում սա էլ է լինում։
Առանց սերվերի գործառույթի հրապարակման հայեցակարգը հարմար է քաղաքացիություն չունեցող ծառայության համար: Եվ եթե Ձեզ անհրաժեշտ է (պետական) պետական ծառայություն, ապա մենք ծառայությանը ավելացնում ենք տվյալների բազա: Այս դեպքում, երբ խոսքը վերաբերում է state-ի հետ աշխատելուն, յուրաքանչյուր statefull ֆունկցիա պարզապես գրում և կարդում է տվյալների բազայից: Ավելին, հոդվածի սկզբում նկարագրված երեք տեսակներից որևէ մեկի տվյալների բազայից։
Ո՞րն է այս բոլոր տվյալների բազաների ընդհանուր սահմանափակումը: Սրանք անընդհատ օգտագործվող ամպային կամ ապարատային սերվերի (կամ մի քանի սերվերի) ծախսերն են: Կարևոր չէ՝ մենք օգտագործում ենք դասական, թե կառավարվող տվյալների բազա, ունենք Devops և ադմինիստրատոր, թե ոչ, մենք դեռ վճարում ենք սարքաշարի, էլեկտրաէներգիայի և տվյալների կենտրոնի վարձակալության համար 24/7: Եթե մենք ունենք դասական բազա, մենք վճարում ենք տիրոջ և ստրուկի համար։ Եթե դա շատ բեռնված բեկորային տվյալների բազա է, մենք վճարում ենք 10, 20 կամ 30 սերվերի համար և անընդհատ վճարում ենք։
Մշտապես պահպանված սերվերների առկայությունը ծախսերի կառուցվածքում նախկինում ընկալվում էր որպես անհրաժեշտ չարիք։ Պայմանական տվյալների բազաները ունեն նաև այլ դժվարություններ, ինչպիսիք են կապերի քանակի սահմանափակումները, մասշտաբային սահմանափակումները, աշխարհաբաշխված կոնսենսուսը. դրանք կարող են ինչ-որ կերպ լուծվել որոշակի տվյալների բազաներում, բայց ոչ միանգամից և ոչ իդեալական:
Առանց սերվերի տվյալների բազա՝ տեսություն
2020 թվականի հարց. հնարավո՞ր է տվյալների բազան նույնպես առանց սերվերի դարձնել: Բոլորը լսել են առանց սերվերի հետին պլանի մասին... եկեք փորձենք տվյալների բազան դարձնել առանց սերվերի:
Սա տարօրինակ է հնչում, քանի որ տվյալների բազան պետական ծառայություն է, որը շատ հարմար չէ առանց սերվերի ենթակառուցվածքի համար: Միևնույն ժամանակ տվյալների շտեմարանի վիճակը շատ մեծ է՝ գիգաբայթ, տերաբայթ, իսկ վերլուծական տվյալների բազաներում՝ նույնիսկ պետաբայթ։ Դա այնքան էլ հեշտ չէ բարձրացնել այն թեթև Docker տարաներում:
Մյուս կողմից, գրեթե բոլոր ժամանակակից տվյալների բազաները պարունակում են հսկայական քանակությամբ տրամաբանություն և բաղադրիչներ՝ գործարքներ, ամբողջականության համակարգում, ընթացակարգեր, հարաբերական կախվածություններ և շատ տրամաբանություն: Բավականին շատ տվյալների բազայի տրամաբանության համար բավական է փոքր վիճակը: Գիգաբայթերը և տերաբայթները ուղղակիորեն օգտագործվում են տվյալների բազայի տրամաբանության միայն մի փոքր մասի կողմից, որը ներգրավված է ուղղակիորեն հարցումների կատարման մեջ:
Համապատասխանաբար, գաղափարը հետևյալն է. եթե տրամաբանության մի մասը թույլ է տալիս քաղաքացիություն չունեցող մահապատիժը, ինչու չբաժանել բազան պետական և քաղաքացիություն չունեցող մասերի:
OLAP լուծումների համար առանց սերվերի
Տեսնենք, թե ինչ տեսք կարող է ունենալ տվյալների բազան Պետական և Քաղաքացիություն չունեցող մասերի՝ օգտագործելով գործնական օրինակներ:
Օրինակ՝ մենք ունենք վերլուծական տվյալների բազաԱրտաքին տվյալներ (ձախ կողմում գտնվող կարմիր գլան), ETL գործընթաց, որը բեռնում է տվյալները տվյալների բազա, և վերլուծաբան, որը SQL հարցումներ է ուղարկում տվյալների բազա: Սա տվյալների պահեստի շահագործման դասական սխեմա է:
Այս սխեմայում ETL-ը պայմանականորեն կատարվում է մեկ անգամ: Այնուհետև պետք է անընդհատ վճարել այն սերվերների համար, որոնց վրա աշխատում է տվյալների բազան ETL-ով լցված տվյալներով, որպեսզի հարցումներ ուղարկելու բան լինի։
Դիտարկենք այլընտրանքային մոտեցում, որն իրականացվել է AWS Athena Serverless-ում: Չկա մշտական հատուկ սարքաշար, որի վրա պահվում են ներբեռնված տվյալները: Սրա փոխարեն.
- Օգտագործողը SQL հարցում է ներկայացնում Athena-ին: Athena օպտիմիզատորը վերլուծում է SQL հարցումը և որոնում է մետատվյալների պահեստում (Մետտվյալներ)՝ հարցումը կատարելու համար անհրաժեշտ կոնկրետ տվյալների համար:
- Օպտիմիզատորը, հավաքված տվյալների հիման վրա, արտաքին աղբյուրներից անհրաժեշտ տվյալները ներբեռնում է ժամանակավոր պահեստ (ժամանակավոր տվյալների բազա):
- Օգտագործողի կողմից SQL հարցումը կատարվում է ժամանակավոր պահեստում և արդյունքը վերադարձվում է օգտագործողին:
- Ժամանակավոր պահեստը մաքրվում է, և ռեսուրսները ազատվում են:
Այս ճարտարապետության մեջ մենք վճարում ենք միայն հարցումը կատարելու գործընթացի համար: Ոչ մի հարցում - առանց ծախսերի:
Սա աշխատանքային մոտեցում է և իրականացվում է ոչ միայն Athena Serverless-ում, այլ նաև Redshift Spectrum-ում (AWS):
Athena-ի օրինակը ցույց է տալիս, որ «Serverless» տվյալների բազան աշխատում է իրական հարցումների վրա՝ տասնյակ և հարյուրավոր տերաբայթ տվյալների վրա: Հարյուրավոր տերաբայթների համար կպահանջվեն հարյուրավոր սերվերներ, բայց մենք չպետք է վճարենք դրանց համար, մենք վճարում ենք հարցումների համար: Յուրաքանչյուր հարցման արագությունը (շատ) ցածր է՝ համեմատած Vertica-ի նման մասնագիտացված վերլուծական տվյալների բազաների հետ, սակայն մենք չենք վճարում պարապուրդի ժամանակաշրջանների համար:
Նման տվյալների բազան կիրառելի է հազվադեպ վերլուծական ժամանակավոր հարցումների համար: Օրինակ, երբ մենք ինքնաբերաբար որոշում ենք ստուգել վարկածը որոշակի հսկայական քանակությամբ տվյալների վրա: Athena-ն կատարյալ է այս դեպքերի համար: Կանոնավոր հարցումների դեպքում նման համակարգը թանկ է: Այս դեպքում քեշավորեք տվյալները ինչ-որ մասնագիտացված լուծման մեջ:
OLTP լուծումների համար առանց սերվերի
Նախորդ օրինակը դիտարկել է OLAP (վերլուծական) առաջադրանքները: Հիմա եկեք նայենք OLTP առաջադրանքներին:
Եկեք պատկերացնենք մասշտաբային PostgreSQL կամ MySQL: Եկեք բարձրացնենք սովորական կառավարվող օրինակ՝ PostgreSQL կամ MySQL՝ նվազագույն ռեսուրսներով: Երբ օրինակն ավելի շատ բեռնվածություն ստանա, մենք կկապենք լրացուցիչ կրկնօրինակներ, որոնց կբաշխենք ընթերցման բեռի մի մասը: Եթե հարցումներ կամ բեռներ չկան, մենք անջատում ենք կրկնօրինակները: Առաջին ատյանը վարպետն է, իսկ մնացածը կրկնօրինակներ են։
Այս գաղափարն իրականացվում է տվյալների բազայում, որը կոչվում է Aurora Serverless AWS: Սկզբունքը պարզ է. արտաքին հավելվածներից ստացված հարցումներն ընդունվում են վստահված անձանց նավատորմի կողմից: Տեսնելով ծանրաբեռնվածության աճը՝ այն տրամադրում է հաշվողական ռեսուրսներ նախապես տաքացված նվազագույն օրինակներից. կապը կատարվում է հնարավորինս արագ: Անջատելու դեպքերը տեղի են ունենում նույն կերպ:
Ավրորայի ներսում կա Ավրորայի հզորությունների միավոր, ACU հայեցակարգը: Սա (պայմանականորեն) օրինակ է (սերվեր): Յուրաքանչյուր կոնկրետ ACU կարող է լինել վարպետ կամ ստրուկ: Յուրաքանչյուր հզորության միավոր ունի իր RAM-ը, պրոցեսորը և նվազագույն սկավառակը: Ըստ այդմ, մեկը վարպետ է, մնացածը կարդացվում են միայն կրկնօրինակներ։
Այս «Ավրորա» հզորության միավորների թիվը կարգավորելի պարամետր է: Նվազագույն քանակը կարող է լինել մեկ կամ զրո (այս դեպքում տվյալների բազան չի աշխատում, եթե չկան հարցումներ):
Երբ բազան հարցումներ է ստանում, պրոքսի նավատորմը բարձրացնում է Aurora CapacityUnits-ը՝ ավելացնելով համակարգի կատարողականի ռեսուրսները: Ռեսուրսների ավելացման և նվազման հնարավորությունը թույլ է տալիս համակարգին «խաբել» ռեսուրսները. ավտոմատ կերպով ցուցադրել առանձին ACU-ներ (դրանք փոխարինելով նորերով) և դուրս բերել բոլոր ընթացիկ թարմացումները հանված ռեսուրսների համար:
Aurora Serverless բազան կարող է մեծացնել ընթերցման բեռը: Բայց փաստաթղթում սա ուղղակիորեն չի ասվում: Այն կարող է թվալ, որ նրանք կարող են բարձրացնել բազմաբնույթ վարպետ: Կախարդություն չկա:
Այս տվյալների բազան հարմար է անկանխատեսելի մուտք ունեցող համակարգերի վրա հսկայական գումարներ ծախսելուց խուսափելու համար: Օրինակ, MVP կամ մարքեթինգային այցեքարտերի կայքեր ստեղծելիս մենք սովորաբար չենք ակնկալում կայուն բեռ: Համապատասխանաբար, եթե մուտք չկա, մենք չենք վճարում օրինակների համար։ Երբ անսպասելի ծանրաբեռնվածություն է տեղի ունենում, օրինակ՝ կոնֆերանսից կամ գովազդային արշավից հետո, մարդկանց բազմությունը այցելում է կայք, և բեռը կտրուկ մեծանում է, Aurora Serverless-ը ավտոմատ կերպով վերցնում է այս բեռը և արագ միացնում բացակայող ռեսուրսները (ACU): Հետո համաժողովն անցնում է, բոլորը մոռանում են նախատիպի մասին, սերվերները (ACU) մթնում են, և ծախսերը իջնում են զրոյի՝ հարմար:
Այս լուծումը հարմար չէ կայուն ծանրաբեռնվածության համար, քանի որ այն չի մեծացնում գրելու բեռը: Այս բոլոր միացումներն ու ռեսուրսների անջատումները տեղի են ունենում այսպես կոչված «մասշտաբային կետում»՝ ժամանակի մի կետ, երբ տվյալների բազան չի ապահովվում գործարքով կամ ժամանակավոր աղյուսակներով: Օրինակ, մեկ շաբաթվա ընթացքում մասշտաբի կետը կարող է տեղի չունենալ, և բազան աշխատում է նույն ռեսուրսների վրա և պարզապես չի կարող ընդլայնվել կամ կրճատվել:
Կախարդություն չկա, դա սովորական PostgreSQL է: Բայց մեքենաների ավելացման և դրանց անջատման գործընթացը մասամբ ավտոմատացված է։
Դիզայնով առանց սերվերի
Aurora Serverless-ը հին տվյալների բազա է, որը վերագրված է ամպի համար՝ օգտվելու Serverless-ի որոշ առավելություններից: Եվ հիմա ես ձեզ կպատմեմ բազայի մասին, որն ի սկզբանե գրվել է ամպի համար, առանց սերվերի մոտեցման համար՝ Serverless-by-design: Այն անմիջապես մշակվեց՝ առանց ենթադրելու, որ այն կաշխատի ֆիզիկական սերվերների վրա:
Այս բազան կոչվում է Snowflake: Այն ունի երեք հիմնական բլոկ:
Առաջինը մետատվյալների բլոկն է: Սա արագ հիշողության ծառայություն է, որը լուծում է անվտանգության, մետատվյալների, գործարքների և հարցումների օպտիմալացման հետ կապված խնդիրներ (ցուցված է ձախ կողմում գտնվող նկարում):
Երկրորդ բլոկը հաշվարկների համար վիրտուալ հաշվողական կլաստերների մի շարք է (նկարում կա կապույտ շրջանակների հավաքածու):
Երրորդ բլոկը տվյալների պահպանման համակարգ է, որը հիմնված է S3-ի վրա: S3-ը AWS-ում առանց հարթության օբյեկտների պահեստավորում է, որը նման է առանց հարթության Dropbox-ին բիզնեսի համար:
Տեսնենք, թե ինչպես է աշխատում Snowflake-ը՝ ենթադրելով սառը սկիզբ: Այսինքն, կա տվյալների բազա, տվյալները բեռնված են դրա մեջ, չկան գործող հարցումներ։ Համապատասխանաբար, եթե տվյալների շտեմարան հարցումներ չկան, ապա մենք բարձրացրել ենք հիշողության արագ մետատվյալների ծառայությունը (առաջին բլոկ): Իսկ մենք ունենք S3 պահեստավորում, որտեղ պահվում են աղյուսակի տվյալները՝ բաժանված այսպես կոչված միկրոբաժանումների։ Պարզության համար. եթե աղյուսակը պարունակում է գործարքներ, ապա միկրոբաժանումները գործարքների օրերն են: Ամեն օր առանձին միկրոբաժան է, առանձին ֆայլ։ Եվ երբ տվյալների բազան գործում է այս ռեժիմով, դուք վճարում եք միայն տվյալների զբաղեցրած տարածքի համար։ Ավելին, մեկ նստատեղի չափը շատ ցածր է (հատկապես հաշվի առնելով զգալի սեղմումը): Մետատվյալների ծառայությունը նույնպես անընդհատ աշխատում է, բայց հարցումները օպտիմալացնելու համար ձեզ շատ ռեսուրսներ պետք չեն, և ծառայությունը կարելի է համարել shareware:
Հիմա եկեք պատկերացնենք, որ օգտվողը եկել է մեր տվյալների բազա և ուղարկել SQL հարցում: SQL հարցումն անմիջապես ուղարկվում է Մետատվյալների ծառայություն՝ մշակման: Համապատասխանաբար, հարցումը ստանալուց հետո այս ծառայությունը վերլուծում է հարցումը, առկա տվյալները, օգտվողի թույլտվությունները և, եթե ամեն ինչ լավ է, կազմում է հարցումը մշակելու պլան:
Այնուհետև ծառայությունը սկսում է հաշվողական կլաստերի գործարկումը: Հաշվողական կլաստերը հաշվարկներ կատարող սերվերների կլաստեր է: Այսինքն՝ սա կլաստեր է, որը կարող է պարունակել 1 սերվեր, 2 սերվեր, 4, 8, 16, 32՝ այնքան, որքան ցանկանում եք։ Դուք հարցում եք նետում և անմիջապես սկսվում է այս կլաստերի գործարկումը: Դա իսկապես վայրկյաններ է պահանջում:
Հաջորդը, կլաստերի մեկնարկից հետո, ձեր հարցումը մշակելու համար անհրաժեշտ միկրոբաժանումները սկսում են պատճենվել S3-ից կլաստերի մեջ: Այսինքն, եկեք պատկերացնենք, որ SQL հարցումը կատարելու համար ձեզ անհրաժեշտ է երկու բաժին մեկ աղյուսակից և մեկը՝ երկրորդից: Այս դեպքում միայն երեք անհրաժեշտ բաժանմունքները կպատճենվեն կլաստերի մեջ, և ոչ բոլոր աղյուսակներն ամբողջությամբ։ Ահա թե ինչու, և հենց այն պատճառով, որ ամեն ինչ գտնվում է մեկ տվյալների կենտրոնում և միացված է շատ արագ կապուղիներով, փոխանցման ողջ գործընթացը տեղի է ունենում շատ արագ՝ վայրկյանների ընթացքում, շատ հազվադեպ՝ րոպեների ընթացքում, եթե մենք չենք խոսում ինչ-որ հրեշավոր խնդրանքների մասին: Համապատասխանաբար, միկրոբաժանումները պատճենվում են հաշվողական կլաստերին, և ավարտից հետո SQL հարցումը կատարվում է այս հաշվողական կլաստերի վրա։ Այս հարցման արդյունքը կարող է լինել մեկ տող, մի քանի տող կամ աղյուսակ. դրանք ուղարկվում են արտաքինից օգտվողին, որպեսզի նա կարողանա ներբեռնել այն, ցուցադրել այն իր BI գործիքում կամ օգտագործել այն այլ կերպ:
Յուրաքանչյուր SQL հարցում կարող է ոչ միայն կարդալ ագրեգատներ նախկինում բեռնված տվյալներից, այլ նաև բեռնել/ստեղծել նոր տվյալներ տվյալների բազայում: Այսինքն, դա կարող է լինել հարցում, որը, օրինակ, նոր գրառումներ է տեղադրում մեկ այլ աղյուսակի մեջ, ինչը հանգեցնում է հաշվողական կլաստերի վրա նոր բաժանման հայտնվելուն, որն, իր հերթին, ավտոմատ կերպով պահվում է մեկ S3 պահեստում:
Վերևում նկարագրված սցենարը՝ սկսած օգտատիրոջ ժամանումից մինչև կլաստերի բարձրացում, տվյալների բեռնում, հարցումների կատարում, արդյունքների ստացում, վճարվում է բարձրացված վիրտուալ հաշվողական կլաստերի, վիրտուալ պահեստի օգտագործման րոպեներով: Փոխարժեքը տատանվում է կախված AWS գոտուց և կլաստերի չափից, բայց միջինում այն կազմում է ժամում մի քանի դոլար: Չորս մեքենաներից բաղկացած կլաստերը երկու անգամ ավելի թանկ է, քան երկու մեքենաների կլաստերը, իսկ ութ մեքենաներից բաղկացած կլաստերը դեռ երկու անգամ թանկ է: Առկա են 16, 32 մեքենաների տարբերակներ՝ կախված հարցումների բարդությունից: Բայց դուք վճարում եք միայն այն րոպեների համար, երբ կլաստերը իրականում աշխատում է, քանի որ երբ հարցումներ չկան, մի տեսակ հանում եք ձեր ձեռքերը և 5-10 րոպե սպասելուց հետո (կարգավորվող պարամետր) այն ինքնուրույն դուրս կգա, ազատել ռեսուրսները և դառնալ ազատ:
Միանգամայն իրատեսական սցենարն այն է, երբ հարցում եք ուղարկում, կլաստերը հայտնվում է, համեմատաբար, մեկ րոպեի ընթացքում այն հաշվում է ևս մեկ րոպե, այնուհետև հինգ րոպե փակվում է, և դուք վերջում վճարում եք այս կլաստերի գործարկման յոթ րոպեի համար, և ոչ ամիսներով ու տարիներով:
Առաջին սցենարը նկարագրված է Snowflake-ի օգտագործումը մեկ օգտագործողի կարգավորումներում: Հիմա պատկերացնենք, որ օգտատերերը շատ են, ինչն ավելի մոտ է իրական սցենարին։
Ենթադրենք, մենք ունենք շատ վերլուծաբաններ և Tableau-ի զեկույցներ, որոնք անընդհատ ռմբակոծում են մեր տվյալների բազան մեծ թվով պարզ վերլուծական SQL հարցումներով:
Բացի այդ, ասենք, որ մենք ունենք տվյալների հնարամիտ գիտնականներ, ովքեր փորձում են հրեշավոր բաներ անել տվյալների միջոցով, գործում են տասնյակ տերաբայթներով, վերլուծում են տվյալների միլիարդավոր և տրիլիոն տողեր:
Վերը նկարագրված երկու տեսակի ծանրաբեռնվածության համար Snowflake-ը թույլ է տալիս բարձրացնել տարբեր հզորությունների մի քանի անկախ հաշվողական կլաստերներ: Ավելին, այս հաշվողական կլաստերներն աշխատում են ինքնուրույն, բայց ընդհանուր հետևողական տվյալներով:
Մեծ թվով թեթև հարցումների համար դուք կարող եք բարձրացնել 2-3 փոքր կլաստերներ, մոտավորապես 2 մեքենա յուրաքանչյուրում: Այս վարքագիծը կարող է իրականացվել, ի թիվս այլ բաների, օգտագործելով ավտոմատ կարգավորումները: Այսպիսով, դուք ասում եք, «Ձյան փաթիլ, բարձրացրեք մի փոքր կլաստեր: Եթե դրա վրա բեռը մեծանում է որոշակի պարամետրից բարձր, բարձրացրեք նմանատիպ երկրորդը, երրորդը: Երբ բեռը սկսում է թուլանալ, մարե՛ք ավելցուկը»։ Այնպես որ, ինչքան էլ վերլուծաբաններ գան ու սկսեն հաշվետվություններ նայել, բոլորը բավարար ռեսուրս ունեն։
Միևնույն ժամանակ, եթե վերլուծաբանները քնած են, և ոչ ոք չի նայում հաշվետվություններին, ապա կլաստերները կարող են ամբողջությամբ մթնել, և դուք դադարում եք վճարել դրանց համար:
Միևնույն ժամանակ, ծանր հարցումների համար (Data Scientists-ից), դուք կարող եք բարձրացնել մեկ շատ մեծ կլաստեր 32 մեքենաների համար: Այս կլաստերը նույնպես կվճարվի միայն այն րոպեների և ժամերի համար, երբ ձեր հսկա հարցումը գործարկվում է այնտեղ:
Վերը նկարագրված հնարավորությունը թույլ է տալիս կլաստերների բաժանել ոչ միայն 2, այլև ավելի շատ տեսակի ծանրաբեռնվածություն (ETL, մոնիտորինգ, հաշվետվությունների նյութականացում,...):
Եկեք ամփոփենք Snowflake-ը: Հիմքը համատեղում է գեղեցիկ գաղափարը և իրագործելի իրականացումը: ManyChat-ում մենք օգտագործում ենք Snowflake-ը մեր ունեցած բոլոր տվյալները վերլուծելու համար: Մենք չունենք երեք կլաստեր, ինչպես օրինակում, այլ 5-ից 9-ը՝ տարբեր չափերի: Որոշ առաջադրանքների համար ունենք սովորական 16 մեքենա, 2 մեքենա, ինչպես նաև գերփոքր 1 մեքենա։ Նրանք հաջողությամբ բաշխում են բեռը և թույլ են տալիս մեզ շատ բան խնայել։
Տվյալների բազան հաջողությամբ մեծացնում է կարդալու և գրելու բեռը: Սա հսկայական տարբերություն է և հսկայական առաջընթաց՝ համեմատած նույն «Ավրորայի» հետ, որը կրում էր միայն ընթերցանության բեռը: Snowflake-ը թույլ է տալիս մեծացնել ձեր գրելու ծանրաբեռնվածությունը այս հաշվողական կլաստերների միջոցով: Այսինքն, ինչպես նշեցի, ManyChat-ում մենք օգտագործում ենք մի քանի կլաստերներ, փոքր և գերփոքր կլաստերները հիմնականում օգտագործվում են ETL-ի համար՝ տվյալների բեռնման համար։ Իսկ վերլուծաբաններն արդեն ապրում են միջին կլաստերների վրա, որոնց վրա բացարձակապես չի ազդում ETL բեռը, ուստի նրանք շատ արագ են աշխատում:
Համապատասխանաբար, տվյալների բազան լավ հարմարեցված է OLAP առաջադրանքների համար: Սակայն, ցավոք, այն դեռ կիրառելի չէ OLTP-ի ծանրաբեռնվածության համար: Նախ, այս տվյալների բազան սյունակային է՝ դրանից բխող բոլոր հետևանքներով: Երկրորդ, մոտեցումն ինքնին, երբ յուրաքանչյուր հարցման համար, անհրաժեշտության դեպքում, դուք բարձրացնում եք հաշվողական կլաստեր և այն լցնում տվյալների հետ, ցավոք, դեռ բավականաչափ արագ չէ OLTP բեռների համար: OLAP առաջադրանքների համար վայրկյաններ սպասելը նորմալ է, բայց OLTP առաջադրանքների համար դա անընդունելի է, 100 ms ավելի լավ կլիներ, կամ 10 ms ավելի լավ:
Լրիվ
Առանց սերվերի տվյալների բազան հնարավոր է բազան բաժանելով քաղաքացիություն չունեցող և պետական մասերի: Դուք նկատած կլինեք, որ վերը նշված բոլոր օրինակներում Stateful մասը, համեմատաբար, S3-ում պահպանում է միկրոբաժանումներ, իսկ քաղաքացիություն չունեցողն օպտիմիզատորն է, աշխատում է մետատվյալների հետ և լուծում անվտանգության խնդիրները, որոնք կարող են բարձրացվել որպես անկախ թեթև քաղաքացիություն չունեցող ծառայություններ:
SQL հարցումների կատարումը կարող է նաև ընկալվել որպես թեթև վիճակի ծառայություններ, որոնք կարող են հայտնվել առանց սերվերի ռեժիմում, ինչպես օրինակ՝ Snowflake հաշվողական կլաստերները, ներբեռնել միայն անհրաժեշտ տվյալները, կատարել հարցումը և «դուրս գալ»:
Առանց սերվերի արտադրության մակարդակի տվյալների բազաները արդեն հասանելի են օգտագործման համար, դրանք աշխատում են։ Այս առանց սերվերի տվյալների բազաները արդեն պատրաստ են OLAP-ի առաջադրանքները լուծելու համար: Ցավոք, OLTP առաջադրանքների համար դրանք օգտագործվում են... նրբություններով, քանի որ կան սահմանափակումներ։ Սա մի կողմից մինուս է։ Բայց, մյուս կողմից, սա հնարավորություն է։ Թերևս ընթերցողներից մեկը կգտնի OLTP տվյալների բազան ամբողջովին առանց սերվերի դարձնելու միջոց՝ առանց Ավրորայի սահմանափակումների։
Հուսով եմ, որ ձեզ հետաքրքիր է թվում: Առանց սերվերի ապագան 🙂
Source: www.habr.com