Բարև Խաբրովսկի բնակիչներ։ Ինչպես միշտ, մենք շարունակում ենք կիսվել հետաքրքիր նյութերով նոր դասընթացների մեկնարկին ընդառաջ։ Այսօր, հատկապես ձեզ համար, մենք հոդված ենք հրապարակել Google Cloud Spanner-ի մասին՝ դասընթացի մեկնարկին համընկնող։ .
Սկզբնապես հրապարակվել է .
Որպես ընկերություն, որն առաջարկում է ամպի վրա հիմնված POS լուծումներ ամբողջ աշխարհում մանրածախ վաճառողներին, ռեստորատորներին և առցանց վաճառողներին, Lightspeed-ը օգտագործում է տվյալների բազայի մի քանի տարբեր տիպի հարթակներ՝ գործարքային, վերլուծական և որոնման օգտագործման տարբեր դեպքերի համար: Տվյալների բազայի այս հարթակներից յուրաքանչյուրն ունի իր ուժեղ և թույլ կողմերը: Հետևաբար, երբ Google-ը շուկա ներկայացրեց Cloud Spanner-ը` խոստումնալից առանձնահատկություններ, որոնք չտեսնված են հարաբերական տվյալների շտեմարանների աշխարհում, ինչպիսիք են գրեթե անսահմանափակ հորիզոնական մասշտաբայնությունը և 99,999% ծառայության մակարդակի համաձայնագիրը (SLA), — մենք չէինք կարող բաց թողնել մեր ձեռքը բռնելու հնարավորությունը:
Cloud Spanner-ի հետ մեր փորձի համապարփակ ակնարկ տրամադրելու համար, ինչպես նաև գնահատման չափանիշները, որոնք մենք օգտագործել ենք, մենք կանդրադառնանք հետևյալ թեմաներին.
- Մեր գնահատման չափանիշները
- Cloud Spanner-ը մի խոսքով
- Մեր գնահատականը
- Մեր գտածոները
1. Մեր գնահատման չափանիշները
Նախքան Cloud Spanner-ի առանձնահատկությունները, դրա նմանություններն ու տարբերությունները շուկայի այլ լուծումների հետ, նախ խոսենք այն հիմնական օգտագործման դեպքերի մասին, որոնք մենք մտքում ունեինք, երբ մտածում էինք, թե որտեղ տեղակայել Cloud Spanner-ը մեր ենթակառուցվածքում.
- Որպես SQL տվյալների բազայի (գերակշռող) ավանդական լուծման փոխարինում
- Ինչպես կատարել OLTP լուծում OLAP աջակցությամբ
Նշում: Պարզության և համեմատության հեշտության համար այս հոդվածը համեմատում է Cloud Spanner-ը GCP Cloud SQL և Amazon AWS RDS լուծումների ընտանիքների MySQL տարբերակների հետ:
Cloud Spanner-ի օգտագործումը որպես ավանդական SQL տվյալների բազայի լուծման փոխարինում
Շրջակա միջավայրում ավանդական տվյալների բազաները, երբ տվյալների բազայի հարցման պատասխանի ժամանակը մոտենում է կամ նույնիսկ գերազանցում է նախապես սահմանված հայտի շեմերը (հիմնականում օգտագործողների և/կամ հարցումների քանակի ավելացման պատճառով), կան մի քանի եղանակներ՝ արձագանքման ժամանակը ընդունելի մակարդակի հասցնելու համար: Այնուամենայնիվ, այս լուծումների մեծ մասը ներառում է ձեռքի միջամտություն:
Օրինակ, առաջին քայլը, որը պետք է ձեռնարկվի, պետք է դիտարկել կատարողականի հետ կապված տվյալների բազայի տարբեր պարամետրերը և կարգավորել դրանք, որպեսզի լավագույնս համապատասխանեն հավելվածների օգտագործման դեպքերի օրինակներին: Եթե դա բավարար չէ, կարող եք ընտրել տվյալների բազայի մասշտաբը ուղղահայաց կամ հորիզոնական:
Հավելվածի ուղղահայաց մասշտաբը ենթադրում է սերվերի օրինակի թարմացում՝ սովորաբար ավելացնելով ավելի շատ պրոցեսորներ/միջուկներ, ավելի շատ RAM, ավելի արագ պահեստավորում և այլն: Ավելի շատ ապարատային ռեսուրսների ավելացումը հանգեցնում է տվյալների բազայի արդյունավետության բարձրացմանը, որը չափվում է հիմնականում երկրորդ գործարքներում, և գործարքների հետաձգումը OLTP համակարգերի համար: Հարաբերական տվյալների բազայի համակարգեր (որոնք օգտագործում են բազմաշերտ մոտեցում), ինչպիսին է MySQL-ը լավ սանդղակի ուղղահայաց:
Այս մոտեցման մի քանի թերություններ կան, բայց ամենաակնհայտը շուկայում սերվերի առավելագույն չափն է: Ամենամեծ սերվերի օրինակի սահմանին հասնելուց հետո մնում է միայն մեկ տարբերակ՝ հորիզոնական մասշտաբավորում:
Հորիզոնական մասշտաբավորումը մոտեցում է, որտեղ ավելի շատ սերվերներ են ավելացվում կլաստերին՝ իդեալականորեն բարձրացնելով կատարումը գծային կերպով, քանի որ սերվերների քանակն ավելանում է: Մեծամասնությունը ավանդական Տվյալների բազայի համակարգերը լավ չեն չափվում հորիզոնական կամ ընդհանրապես չեն մասշտաբվում: Օրինակ, MySQL-ը կարող է հորիզոնական մասշտաբել կարդալու գործողությունների համար՝ ավելացնելով ստրուկ ընթերցողներ, բայց չի կարող հորիզոնական մասշտաբել գրելու համար:
Մյուս կողմից, իր բնույթով, Cloud Spanner-ը կարող է հեշտությամբ հարթել հորիզոնական՝ նվազագույն միջամտությամբ:
Լիովին ներկայացված DBMS որպես ծառայություն պետք է գնահատել տարբեր տեսանկյուններից. Որպես հիմք՝ մենք վերցրել ենք ամպի մեջ ամենահայտնի DBMS-ը՝ Google-ի, GCP Cloud SQL-ի և Amazon-ի համար՝ AWS RDS-ի համար: Մեր գնահատման ժամանակ մենք կենտրոնացել ենք հետևյալ կատեգորիաների վրա.
- Առանձնահատկությունների քարտեզագրում՝ SQL, DDL, DML ծավալ; կապի գրադարաններ/միակցիչներ, գործարքների աջակցություն և այլն:
- Զարգացման աջակցություն. հեշտ մշակում և փորձարկում:
- Ադմինիստրացիայի աջակցություն. օրինակների կառավարում, օրինակ՝ մեծացնել/նվազեցնել և կատարելագործել օրինակները; SLA, կրկնօրինակում և վերականգնում; անվտանգություն/մուտքի վերահսկում:
Օգտագործելով Cloud Spanner-ը որպես OLAP-ով միացված OLTP լուծում
Թեև Google-ը բացահայտորեն չի պնդում, որ Cloud Spanner-ը նախատեսված է վերլուծական մշակման համար, այն ունի որոշ հատկանիշներ այլ շարժիչների հետ, ինչպիսիք են Apache Impala & Kudu-ն և YugaByte-ը, որոնք նախատեսված են OLAP աշխատանքային ծանրաբեռնվածության համար:
Նույնիսկ եթե փոքր հավանականություն կար, որ Cloud Spanner-ը ներառեր հետևողական մասշտաբային HTAP (հիբրիդային գործարքների/վերլուծական մշակում) շարժիչ՝ (քիչ թե շատ) օգտագործելի OLAP գործառույթների հավաքածուով, մենք կարծում ենք, որ այն արժանի կլիներ մեր ուշադրությանը:
Սա նկատի ունենալով, մենք դիտարկեցինք հետևյալ կատեգորիաները.
- Տվյալների բեռնում, ինդեքսներ և բաժանման աջակցություն
- Հարցման կատարում և DML
2. Cloud Spanner-ը մի խոսքով
Google Spanner-ը կլաստերային հարաբերական տվյալների բազայի կառավարման համակարգ է (RDBMS), որը Google-ն օգտագործում է իր մի քանի ծառայությունների համար: Google-ն այն ընդհանուր առմամբ հասանելի դարձրեց Google Cloud Platform-ի օգտատերերին 2017 թվականի սկզբին:
Ահա Cloud Spanner-ի որոշ հատկանիշներ.
- Բարձր հետևողական մասշտաբային RDBMS կլաստեր. օգտագործում է ապարատային ժամանակի համաժամացում՝ տվյալների հետևողականությունն ապահովելու համար:
- Խաչասեղանի գործարքների աջակցություն. Գործարքները կարող են ընդգրկել մի քանի աղյուսակներ՝ պարտադիր չէ, որ սահմանափակվեն մեկ աղյուսակով (ի տարբերություն Apache HBase-ի կամ Apache Kudu-ի):
- Հիմնական բանալիների վրա հիմնված աղյուսակներ. Բոլոր աղյուսակները պետք է ունենան հայտարարված հիմնական բանալի (PC), որը կարող է բաղկացած լինել աղյուսակի մի քանի սյունակներից: Աղյուսակային տվյալները պահվում են համակարգչի կարգով, ինչը այն դարձնում է շատ արդյունավետ և արագ համակարգչի որոնման համար: Ինչպես համակարգչի վրա հիմնված մյուս համակարգերը, իրականացումը պետք է մոդելավորվի՝ հաշվի առնելով նախապես նախագծված օգտագործման դեպքերը՝ հասնելու համար .
- Գծավոր սեղաններ. Սեղանները կարող են ֆիզիկական կախվածություն ունենալ միմյանցից: Երեխաների աղյուսակի տողերը կարող են համընկնել մայր աղյուսակի տողերի հետ: Այս մոտեցումը արագացնում է հարաբերությունների որոնումը, որոնք կարող են հայտնաբերվել տվյալների մոդելավորման փուլում, ինչպիսիք են հաճախորդների և նրանց հաշիվ-ապրանքագրերի համատեղ տեղակայումը:
- Ինդեքսներ. Cloud Spanner-ն աջակցում է երկրորդական ինդեքսներին: Ինդեքսը բաղկացած է ինդեքսավորված սյունակներից և ԱՀ-ի բոլոր սյունակներից: Ցանկության դեպքում ինդեքսը կարող է պարունակել նաև այլ ոչ ինդեքսավորված սյունակներ: Ինդեքսը կարող է փոխկապակցվել մայր աղյուսակի հետ՝ հարցումներն արագացնելու համար: Մի քանի սահմանափակումներ են կիրառվում ինդեքսների նկատմամբ, օրինակ՝ ինդեքսում պահվող լրացուցիչ սյունակների առավելագույն քանակը: Բացի այդ, ինդեքսների միջոցով հարցումները կարող են լինել ոչ այնքան պարզ, որքան մյուս RDBMS-ներում:
«Cloud Spanner-ն ինքնաբերաբար ընտրում է ինդեքսը միայն հազվադեպ դեպքերում: Մասնավորապես, Cloud Spanner-ը ավտոմատ կերպով չի ընտրում երկրորդական ինդեքս, եթե հարցումը պահանջում է որևէ սյունակ, որը չի պահվում: .
- Ծառայության մակարդակի համաձայնագիր (SLA). տեղակայում մեկ տարածաշրջանում SLA 99,99%; բազմատարածաշրջանային տեղակայումներ 99,999% SLA-ով: Թեև SLA-ն ինքնին պարզապես համաձայնություն է և ոչ մի երաշխիք, ես կարծում եմ, որ Google-ի մարդիկ ունեն որոշակի ծանր տվյալներ՝ նման ուժեղ պնդում անելու համար: (Հիման համար՝ 99,999%-ը նշանակում է ամսական 26,3 վայրկյան ծառայության անհասանելիություն:)
- Ավելին,
Նշում: Apache Tephra նախագիծը ավելացնում է ընդլայնված գործարքների աջակցություն Apache HBase-ին (այժմ իրականացվում է նաև Apache Phoenix-ում որպես բետա):
3. Մեր գնահատականը
Այսպիսով, մենք բոլորս կարդացել ենք Google-ի պնդումները Cloud Spanner-ի առավելությունների մասին՝ գործնականում անսահմանափակ հորիզոնական մասշտաբում՝ պահպանելով բարձր հետևողականությունը և շատ բարձր SLA: Չնայած այս պահանջներին, ամեն դեպքում, չափազանց դժվար է իրականացնել, սակայն մեր նպատակը դրանք հերքելը չէր։ Փոխարենը, եկեք կենտրոնանանք այլ բաների վրա, որոնց մասին շատ են հետաքրքրում տվյալների բազայի օգտատերերը՝ հավասարություն և օգտագործելիություն:
Մենք գնահատեցինք Cloud Spanner-ը որպես Sharded MySQL-ի փոխարինող
Google Cloud SQL-ը և Amazon AWS RDS-ը՝ ամպային շուկայում ամենահայտնի OLTP DBMS-ներից երկուսը, ունեն շատ մեծ հնարավորություններ: Այնուամենայնիվ, այս տվյալների բազաները մեկ հանգույցի չափից ավելի մեծացնելու համար դուք պետք է կատարեք հավելվածի բաժանումը: Այս մոտեցումը լրացուցիչ բարդություն է ստեղծում ինչպես հավելվածների, այնպես էլ վարչարարության համար: Մենք նայեցինք, թե ինչպես է Spanner-ը տեղավորվում մի քանի բեկորներ մեկ օրինակում միավորելու սցենարի մեջ և ինչ հատկանիշներ (եթե այդպիսիք կան) կարող է անհրաժեշտ լինել զոհաբերել:
SQL, DML և DDL աջակցություն, ինչպես նաև միակցիչ և գրադարաններ:
Նախ, երբ սկսում եք ցանկացած տվյալների բազայից, դուք պետք է ստեղծեք տվյալների մոդել: Եթե կարծում եք, որ կարող եք միացնել JDBC Spanner-ը ձեր սիրած SQL գործիքին, կտեսնեք, որ դուք կարող եք հարցումներ կատարել ձեր տվյալների հետ, բայց չեք կարող օգտագործել այն աղյուսակ ստեղծելու կամ փոփոխելու (DDL) կամ որևէ ներդիրի/թարմացման/ջնջման համար։ գործողություններ (DML): Google-ի պաշտոնական JDBC-ն չի աջակցում դրանցից որևէ մեկին:
«Վարորդները ներկայումս չեն աջակցում DML կամ DDL հայտարարությունները»:
Բանակի փաստաթղթեր
Իրավիճակն ավելի լավ չէ GCP վահանակի դեպքում. կարող եք ուղարկել միայն SELECT հարցումներ: Բարեբախտաբար, կա JDBC վարորդ, որն աջակցում է համայնքի DML-ին և DDL-ին, ներառյալ գործարքները . Թեև այս դրայվերը չափազանց օգտակար է, Google-ի սեփական JDBC վարորդի բացակայությունը զարմանալի է: Բարեբախտաբար, Google-ն առաջարկում է բավականին լայն աջակցություն հաճախորդների գրադարանների համար (հիմնված gRPC-ի վրա)՝ C#, Go, Java, node.js, PHP, Python և Ruby:
Cloud Spanner հատուկ API-ների գրեթե պարտադիր օգտագործումը (JDBC-ում DDL-ի և DML-ի բացակայության պատճառով) հանգեցնում է որոշ սահմանափակումների՝ կապված կոդերի տարածքների համար, ինչպիսիք են կապի լողավազանները կամ տվյալների բազայի պարտադիր շրջանակները (օրինակ՝ Spring MVC): Սովորաբար, JDBC-ն օգտագործելիս դուք ազատ եք ընտրել ձեր սիրած կապի լողավազանը (օրինակ՝ HikariCP, DBCP, C3PO և այլն), որը փորձարկված է և լավ է աշխատում: Պատվերով Spanner API-ների դեպքում մենք պետք է հիմնվենք շրջանակների/պարտադիր լողավազանների/սեսիաների վրա, որոնք մենք ինքներս ենք ստեղծել:
Առաջնային բանալին (PC) կենտրոնացված դիզայնը թույլ է տալիս Cloud Spanner-ին շատ արագ լինել ԱՀ-ի միջոցով տվյալներ մուտք գործելիս, բայց նաև ներկայացնում է հարցումների որոշ խնդիրներ:
- Դուք չեք կարող թարմացնել առաջնային բանալու արժեքը. Դուք նախ պետք է ջնջեք մուտքագրումը բնօրինակ ԱՀ-ից և նորից տեղադրեք այն նոր արժեքով: (Սա նման է այլ համակարգչի վրա հիմնված տվյալների բազայի/պահեստավորման շարժիչների:)
- Ցանկացած UPDATE և DELETE հայտարարությունները WHERE-ում պետք է նշեն PC, հետևաբար չեն կարող լինել դատարկ DELETE բոլոր հայտարարությունները. միշտ պետք է լինի ենթահարկ, օրինակ՝ UPDATE xxx WHERE id IN (Ընտրեք id FROM աղյուսակից 1)
- Ավտոմատ ավելացման տարբերակի բացակայություն կամ նմանատիպ որևէ այլ բան, որը սահմանում է PC դաշտի հաջորդականությունը: Որպեսզի դա աշխատի, համապատասխան արժեքը պետք է ստեղծվի հավելվածի կողմից:
Երկրորդական ինդեքսներ.
Google Cloud Spanner-ն ունի ներկառուցված աջակցություն երկրորդական ինդեքսների համար: Սա շատ գեղեցիկ հատկանիշ է, որը միշտ չէ, որ առկա է այլ տեխնոլոգիաներում: Apache Kudu-ն ներկայումս ընդհանրապես չի աջակցում երկրորդական ինդեքսներին, իսկ Apache HBase-ն ուղղակիորեն չի աջակցում ինդեքսներին, բայց կարող է դրանք ավելացնել Apache Phoenix-ի միջոցով:
Kudu-ի և HBase-ի ինդեքսները կարող են մոդելավորվել որպես առանձին աղյուսակ՝ առաջնային բանալիների տարբեր կազմով, սակայն հիմնական աղյուսակի և հարակից ինդեքսների աղյուսակների վրա կատարված գործողությունների ատոմականությունը պետք է կատարվի կիրառման մակարդակով և աննշան չէ՝ ճիշտ իրականացնելը:
Ինչպես նշվեց Cloud Spanner-ի վերանայման մեջ, դրա ինդեքսները կարող են տարբերվել MySQL ինդեքսներից: Հետևաբար, հարցումներ կառուցելիս և պրոֆիլներ կազմելիս պետք է հատուկ խնամք ցուցաբերել՝ ապահովելու համար, որ պատշաճ ինդեքսն օգտագործվի այնտեղ, որտեղ դա անհրաժեշտ է:
Ներկայացուցչությո՞ւնը:
Տվյալների բազայում շատ հայտնի և օգտակար օբյեկտ է դիտումները: Նրանք կարող են օգտակար լինել մեծ թվով օգտագործման դեպքերի համար. իմ երկու ֆավորիտներն են տրամաբանական վերացական շերտը և անվտանգության շերտը: Ցավոք, Cloud Spanner-ը ՉԻ աջակցում դիտումները: Այնուամենայնիվ, սա միայն մասամբ է մեզ սահմանափակում, քանի որ սյունակի մակարդակում մուտքի թույլտվությունների հստակություն չկա, որտեղ դիտումները կարող են կենսունակ լուծում լինել:
Տեսեք Cloud Spanner-ի փաստաթղթերը մի բաժնի համար, որը մանրամասնում է քվոտաներն ու սահմանափակումները (), մասնավորապես կա մեկը, որը կարող է խնդրահարույց լինել որոշ հավելվածների համար. Ակնհայտ է, որ սա կարող է մեծ խոչընդոտ հանդիսանալ տվյալների բազայի համար, որը նախատեսված է ավելի քան 100 տվյալների բազաների մասշտաբով: Բարեբախտաբար, Google-ի մեր տեխնիկական ներկայացուցչի հետ խոսելուց հետո մենք պարզեցինք, որ այս սահմանաչափը կարող է գրեթե ցանկացած արժեքի հասցնել Google Աջակցության միջոցով:
Զարգացման աջակցություն?
Cloud Spanner-ն առաջարկում է բավականին պատշաճ ծրագրավորման լեզվի աջակցություն իր API-ի հետ աշխատելու համար: Պաշտոնապես աջակցվող գրադարանները գտնվում են C#, Go, Java, node.js, PHP, Python և Ruby ոլորտներում: Փաստաթղթերը բավականին մանրամասն են, բայց ինչպես այլ առաջադեմ տեխնոլոգիաների դեպքում, համայնքը բավականին փոքր է տվյալների բազայի ամենատարածված տեխնոլոգիաների համեմատ, ինչը կարող է հանգեցնել ավելի շատ ժամանակ ծախսելու ավելի քիչ տարածված օգտագործման դեպքեր կամ խնդիրներ լուծելու համար:
Իսկ ի՞նչ կասեք տեղական զարգացմանն աջակցելու մասին:
Մենք չենք գտել «Cloud Spanner»-ի օրինակը ներսում: Ամենամոտ բանը, որ մենք ստացանք, Docker պատկերն էր: , որը սկզբունքորեն նման է, բայց գործնականում շատ տարբեր։ Օրինակ, CockroachDB-ն կարող է օգտագործել PostgreSQL JDBC: Քանի որ զարգացման միջավայրը պետք է հնարավորինս մոտ լինի արտադրական միջավայրին, Cloud Spanner-ը իդեալական չէ, քանի որ այն պետք է հիմնվի Spanner-ի ամբողջական օրինակի վրա: Ծախսերը խնայելու համար կարող եք ընտրել մեկ տարածաշրջանային օրինակ:
Ադմինիստրացիայի աջակցություն.
Cloud Spanner-ի օրինակ ստեղծելը շատ պարզ է: Պարզապես պետք է ընտրել բազմատարածաշրջանային կամ մեկ տարածաշրջանային օրինակ ստեղծելու միջև, նշել տարածաշրջան(ներ)ը և հանգույցների քանակը: Մեկ րոպեից էլ քիչ ժամանակում ձեր օրինակը կգործարկվի:
Մի քանի տարրական չափումներ ուղղակիորեն հասանելի են Google Console-ի Spanner էջից: Ավելի մանրամասն դիտումները հասանելի են Stackdriver-ի միջոցով, որտեղ կարող եք նաև սահմանել մետրային շեմեր և զգուշացման քաղաքականություն:
Մատչելիություն ռեսուրսների՞:
MySQL-ն առաջարկում է լայնածավալ և շատ հատիկավոր կարգավորումներ օգտատիրոջ թույլտվությունների/դերերի համար: Դուք կարող եք հեշտությամբ կարգավորել մուտքը դեպի կոնկրետ աղյուսակ կամ նույնիսկ դրա սյունակների ենթաբազմություն: Cloud Spanner-ն օգտագործում է Google-ի Identity & Access Management (IAM) գործիքը, որը թույլ է տալիս միայն քաղաքականություններ և թույլտվություններ սահմանել շատ բարձր մակարդակի վրա: Առավել հատիկավոր տարբերակը տվյալների բազայի մակարդակի լուծումն է, որը չի տեղավորվում արտադրական օգտագործման դեպքերի մեծ մասում: Այս սահմանափակումը ստիպում է ձեզ լրացուցիչ անվտանգության միջոցներ ավելացնել ձեր կոդը, ենթակառուցվածքը կամ երկուսն էլ՝ Spanner ռեսուրսների չարտոնված օգտագործումը կանխելու համար:
Պահուստավորումներ.
Պարզ ասած, Cloud Spanner-ում կրկնօրինակներ չկան: Թեև Google-ի SLA-ի բարձր պահանջները կարող են երաշխավորել, որ դուք չեք կորցնի որևէ տվյալ ապարատային կամ տվյալների բազայի խափանումների, մարդկային սխալների, հավելվածի թերությունների և այլնի պատճառով: Մենք բոլորս գիտենք կանոնը. բարձր հասանելիությունը չի կարող փոխարինել ձայնային պահուստավորման ռազմավարությանը: Ներկայումս տվյալների կրկնօրինակման միակ միջոցը տվյալների բազայից ծրագրային կերպով փոխանցելն է առանձին պահեստային միջավայր:
Հարցում կատարե՞լ:
Մենք օգտագործել ենք Yahoo!-ն տվյալների բեռնման և հարցումների փորձարկման համար: Cloud Serving Benchmark. Ստորև բերված աղյուսակը ցույց է տալիս YCSB-ի ծանրաբեռնվածությունը B՝ կարդալու և գրելու 95% հարաբերակցությամբ:
* Բեռնվածության փորձարկումն իրականացվել է n1-standard-32 Compute Engine (CE) (32 vCPU, 120 ԳԲ հիշողություն) վրա, և փորձարկման օրինակը երբեք չի եղել թեստերի խոչընդոտ:
** Մեկ YCSB օրինակում շղթաների առավելագույն քանակը 400 է: Ընդհանուր առմամբ 2400 շղթա ստանալու համար պետք է իրականացվեին YCSB թեստերի վեց զուգահեռ օրինակներ:
Նայելով հենանիշի արդյունքներին, մասնավորապես պրոցեսորի բեռնվածության և TPS-ի համակցմանը, մենք կարող ենք հստակ տեսնել, որ Cloud Spanner-ը բավականին լավ է չափվում: Մեծ թվով թելերով ստեղծված ծանր բեռը փոխհատուցվում է Cloud Spanner կլաստերի մեծ թվով հանգույցներով: Թեև հետաձգումը բավականին բարձր է թվում, հատկապես 2400 թելերով աշխատելիս, ավելի ճշգրիտ թվեր ստանալու համար կարող է անհրաժեշտ լինել հաշվողական շարժիչի 6 փոքր օրինակների հետ կրկին փորձարկում: Յուրաքանչյուր օրինակ կանցկացնի մեկ YCSB թեստ՝ 6 զուգահեռ թեստերով մեկ մեծ CE օրինակի փոխարեն: Այսպիսով, ավելի հեշտ կլինի տարբերակել Cloud Spanner-ի հարցման հետաձգումը և Cloud Spanner-ի և փորձարկումն իրականացնող CE օրինակի միջև ցանցային կապի միջոցով ավելացված ուշացումը:
Ինչպե՞ս է Cloud Spanner-ը գործում որպես OLAP:
Բաժանման?
Տվյալների բաժանումը ֆիզիկապես և/կամ տրամաբանորեն անկախ հատվածների, որոնք կոչվում են միջնապատեր, շատ տարածված հասկացություն է, որը կարելի է գտնել OLAP շարժիչների մեծ մասում: Միջնորմները կարող են զգալիորեն բարելավել հարցումների կատարումը և տվյալների բազայի պահպանումը: Բաժանման մեջ ավելի խորանալը կլինի առանձին հոդված(ներ), ուստի եկեք պարզապես նշենք բաժանման և ենթաբաժինների սխեմա ունենալու կարևորությունը: Տվյալները բաժանման և նույնիսկ ավելի ենթաբաժանումների բաժանելու ունակությունը վերլուծական հարցումների կատարման բանալին է:
Cloud Spanner-ը չի աջակցում միջնորմները որպես այդպիսին: Այն ներքին տվյալների բաժանում է այսպես կոչված պառակտում-ներ հիմնված առաջնային բանալիների տիրույթների վրա: Բաժանումն իրականացվում է ավտոմատ կերպով՝ Cloud Spanner կլաստերի բեռը հավասարակշռելու համար: Cloud Spanner-ի շատ օգտակար հատկանիշը մայր աղյուսակի հիմնական բեռնվածության բաժանումն է (աղյուսակ, որը միախառնված չէ մյուսի հետ): Բանալն ավտոմատ կերպով հայտնաբերում է, թե արդյոք այն պարունակում է պառակտում տվյալներ, որոնք ավելի հաճախ են կարդացվում, քան մյուսներում պառակտում-այ, և կարող է որոշել հետագա բաժանումը: Այս կերպ ավելի շատ հանգույցներ կարող են ներգրավվել հարցման մեջ, ինչը նաև արդյունավետորեն մեծացնում է թողունակությունը:
Տվյալների բեռնում:
Cloud Spanner մեթոդը զանգվածային տվյալների համար նույնն է, ինչ սովորական բեռնման դեպքում: Առավելագույն արդյունավետության հասնելու համար դուք պետք է հետևեք որոշ ուղեցույցների, ներառյալ.
- Տեսակավորեք ձեր տվյալները ըստ հիմնական բանալիի:
- Բաժանիր դրանք 10-ի *հանգույցների քանակը առանձին բաժիններ.
- Ստեղծեք աշխատանքային առաջադրանքների մի շարք, որոնք զուգահեռաբար բեռնում են տվյալները:
Այս տվյալների բեռնումն օգտագործում է Cloud Spanner-ի բոլոր հանգույցները:
Մենք օգտագործել ենք YCSB աշխատանքային ծանրաբեռնվածություն A՝ 10 միլիոն տողերի տվյալների բազա ստեղծելու համար:
* Բեռնվածության փորձարկումն իրականացվել է n1-standard-32 հաշվողական շարժիչով (32 vCPU, 120 ԳԲ հիշողություն), և փորձարկման օրինակը երբեք չի եղել թեստերի խոչընդոտ:
** Մեկ հանգույցի տեղադրումը խորհուրդ չի տրվում արտադրական ծանրաբեռնվածության համար:
Ինչպես նշվեց վերևում, Cloud Spanner-ը ավտոմատ կերպով մշակում է բաժանումները՝ ելնելով դրանց ծանրաբեռնվածությունից, ուստի արդյունքները բարելավվում են մի քանի անընդմեջ թեստային կրկնություններից հետո: Այստեղ ներկայացված արդյունքները մեր ստացած լավագույն արդյունքներն են: Նայելով վերը նշված թվերին՝ մենք կարող ենք տեսնել, թե ինչպես է Cloud Spanner-ը մասշտաբվում (լավ), քանի որ կլաստերի հանգույցների թիվը մեծանում է: Առանձնահատուկ թվերն են չափազանց ցածր միջին ուշացումները, որոնք հակասում են խառը ծանրաբեռնվածության արդյունքներին (95% կարդալ և 5% գրել), ինչպես նկարագրված է վերը նշված բաժնում:
Սանդղակա՞ն:
Cloud Spanner հանգույցների քանակի ավելացումն ու նվազումը մեկ սեղմումով խնդիր է: Եթե ցանկանում եք արագ բեռնել տվյալները, կարող եք մտածել ձեր օրինակը առավելագույնի հասցնելու մասին (մեր դեպքում դա եղել է 25 հանգույց ԱՄՆ-Արևելյան տարածաշրջանում) և այնուհետև կրճատել ձեր սովորական բեռնման համար իրավասու հանգույցների թիվը, երբ բոլոր տվյալները մուտքագրվեն: տվյալների բազան՝ նկատի ունենալով 2TB/հանգույցի սահմանաչափը:
Մեզ հիշեցրին այս սահմանի մասին նույնիսկ շատ ավելի փոքր տվյալների բազայի դեպքում: Բեռնվածության փորձարկումների մի քանի փորձարկումներից հետո մեր տվյալների բազան մոտավորապես 155 ԳԲ էր, և երբ փոքրացվեց մինչև 1 հանգույցի օրինակ, մենք ստացանք հետևյալ սխալը.
Մեզ հաջողվեց նվազեցնել 25-ից մինչև 2 դեպք, բայց մենք խրված էինք երկու հանգույցներում:
Cloud Spanner կլաստերի հանգույցների քանակի ավելացումն ու նվազումը կարող է ավտոմատացվել REST API-ի միջոցով: Սա կարող է հատկապես օգտակար լինել զբաղված աշխատանքային ժամերին համակարգի ավելացած բեռը նվազեցնելու համար:
OLAP հարցումների կատարումը:
Մենք ի սկզբանե նախատեսում էինք զգալի ժամանակ հատկացնել Spanner-ի մեր գնահատմանը այս մասի վրա: Մի քանի SELECT COUNT-ից հետո մենք անմիջապես հասկացանք, որ փորձարկումը կարճ է լինելու, և որ Spanner-ը չի լինի հարմար շարժիչ OLAP-ի համար: Անկախ կլաստերի հանգույցների քանակից, 10M տողերի աղյուսակում տողերի քանակի ընտրությունը տևեց 55-ից 60 վայրկյան: Բացի այդ, ցանկացած հարցում, որն ավելի շատ հիշողություն էր պահանջում միջանկյալ արդյունքները պահելու համար, ձախողվեց OOM սխալով:
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
TPC-H հարցումների որոշ թվեր կարելի է գտնել Թոդ Լիպկոնի հոդվածում , սլայդներ 42 և 43: Այս թվերը համապատասխանում են մեր սեփական արդյունքներին (ցավոք,):
4. Մեր եզրակացությունները
Հաշվի առնելով Cloud Spanner-ի առանձնահատկությունների ներկայիս վիճակը, դժվար է պատկերացնել, որ այն պարզ փոխարինում է ձեր առկա OLTP լուծմանը, հատկապես, երբ ձեր կարիքները գերազանցում են այն: Զգալի քանակությամբ ժամանակ պետք է ծախսվի Cloud Spanner-ի թերությունների շուրջ լուծումներ ստեղծելու համար:
Երբ մենք սկսեցինք Cloud Spanner-ի գնահատումը, մենք ակնկալում էինք, որ դրա կառավարման առանձնահատկությունները կհամապատասխանեն Google SQL-ի այլ լուծումներին կամ առնվազն շատ հեռու չեն լինի դրանցից: Բայց մեզ զարմացրեց կրկնօրինակների իսպառ բացակայությունը և ռեսուրսների հասանելիության շատ սահմանափակ վերահսկողությունը: Էլ չեմ խոսում դիտումների, տեղական զարգացման միջավայրի, չաջակցվող հաջորդականությունների, JDBC առանց DML և DDL աջակցության և այլնի մասին:
Այսպիսով, որտե՞ղ է գնում մեկը, ով պետք է մասշտաբի գործարքների տվյալների բազան: Թվում է, թե շուկայում չկա մեկ լուծում, որը համապատասխանում է օգտագործման բոլոր դեպքերին: Կան բազմաթիվ փակ և բաց կոդով լուծումներ (որոնցից մի քանիսը նշված են այս հոդվածում), որոնցից յուրաքանչյուրն ունի իր ուժեղ և թույլ կողմերը, բայց դրանցից ոչ մեկը չի առաջարկում SaaS 99,999% SLA և բարձր հետևողականությամբ: Եթե բարձր SLA-ն ձեր հիմնական նպատակն է, և դուք հակված չեք ստեղծելու հատուկ բազմաամպ լուծում, Cloud Spanner-ը կարող է լինել այն լուծումը, որը դուք փնտրում եք: Բայց դուք պետք է տեղյակ լինեք դրա բոլոր սահմանափակումներին:
Արդարության համար, Cloud Spanner-ը հանրությանը թողարկվեց միայն 2017-ի գարնանը, ուստի ողջամիտ է ակնկալել, որ դրա ներկայիս որոշ թերություններ կարող են ի վերջո վերանալ (հուսով եմ), և երբ դրանք անհետանան, դա կարող է փոխել խաղի փոփոխությունը: Ի վերջո, Cloud Spanner-ը Google-ի համար պարզապես կողմնակի նախագիծ չէ: Google-ն այն օգտագործում է որպես Google-ի այլ արտադրանքների հիմք: Եվ երբ Google-ը վերջերս փոխարինեց Megastore-ը Google Cloud Storage-ում Cloud Spanner-ով, այն թույլ տվեց Google Cloud Storage-ին դառնալ խիստ հետևողական գլոբալ մասշտաբով օբյեկտների ցուցակների համար (ինչը դեռևս այդպես չէ: ).
Այնպես որ, դեռ հույս կա... հույս ունենք։
Այսքանը: Ինչպես հոդվածի հեղինակը, մենք նույնպես շարունակում ենք հուսալ, բայց ի՞նչ կարծիքի եք այս մասին։ Գրեք մեկնաբանություններում
Բոլորին հրավիրում ենք այցելել մեր որի շրջանակներում մենք ձեզ մանրամասն կպատմենք դասընթացի մասին OTUS-ից:
Source: www.habr.com