Հե՜յ Հաբր։
Ես Միշա Բուտրիմովն եմ, ուզում եմ մի փոքր պատմել Կասանդրայի մասին։ Իմ պատմությունը օգտակար կլինի նրանց համար, ովքեր երբեք չեն հանդիպել NoSQL տվյալների շտեմարաններին. այն ունի իրականացման բազմաթիվ առանձնահատկություններ և որոգայթներ, որոնց մասին դուք պետք է իմանաք: Եվ եթե դուք Oracle-ից կամ որևէ այլ հարաբերական տվյալների բազայից բացի այլ բան չեք տեսել, այս բաները կփրկեն ձեր կյանքը:
Ի՞նչ լավ բան կա Կասանդրայի մասին: Դա NoSQL տվյալների բազա է, որը նախագծված է առանց ձախողման մեկ կետի, որը լավ մասշտաբներով է: Եթե Ձեզ անհրաժեշտ է ավելացնել մի քանի տերաբայթ տվյալների բազայի համար, դուք պարզապես հանգույցներ եք ավելացնում ռինգում: Ընդլայնե՞լ այն այլ տվյալների կենտրոնի վրա: Կլաստերին ավելացրեք հանգույցներ: Բարձրացնե՞լ մշակված RPS-ը: Կլաստերին ավելացրեք հանգույցներ: Այն աշխատում է նաև հակառակ ուղղությամբ։
Էլ ինչո՞վ է նա լավ: Խոսքը վերաբերում է բազմաթիվ խնդրանքներին: Բայց որքա՞ն է շատ։ 10, 20, 30, 40 հազար հարցում վայրկյանում շատ չէ։ 100 հազար հարցում վայրկյանում ձայնագրման համար՝ նույնպես։ Կան ընկերություններ, որոնք ասել են, որ վայրկյանում 2 միլիոն հարցում են պահում։ Նրանք, հավանաբար, պետք է հավատան դրան:
Եվ սկզբունքորեն, Կասանդրան մեկ մեծ տարբերություն ունի հարաբերական տվյալներից՝ այն բոլորովին նման չէ նրանց։ Եվ սա շատ կարևոր է հիշել.
Ամեն ինչ չէ, որ նույն տեսքն ունի, նույնն է աշխատում
Մի անգամ մի գործընկեր եկավ ինձ մոտ և հարցրեց. «Ահա CQL Cassandra հարցման լեզու, և այն ունի ընտրված հայտարարություն, ունի որտեղ, ունի և: Նամակներ եմ գրում ու չի ստացվում։ Ինչո՞ւ»: Կասանդրային որպես հարաբերական տվյալների շտեմարան վերաբերվելը դաժան ինքնասպանություն գործելու կատարյալ միջոց է: Եվ ես դա չեմ քարոզում, Ռուսաստանում դա արգելված է։ Դուք պարզապես սխալ կնախագծեք:
Օրինակ, հաճախորդը գալիս է մեզ մոտ և ասում. «Եկեք ստեղծենք տվյալների բազա հեռուստասերիալների համար, կամ տվյալների բազա բաղադրատոմսերի գրացուցակի համար: Այնտեղ կունենանք ուտելիքի ուտեստներ կամ դրանում սերիալների ու դերասանների ցանկ»։ Մենք ուրախությամբ ասում ենք. «Եկեք գնանք»: Ուղղակի ուղարկեք երկու բայթ, մի քանի նշան և վերջ, ամեն ինչ կաշխատի շատ արագ և հուսալի: Եվ ամեն ինչ լավ է, քանի դեռ հաճախորդները չեն գալիս ու ասում, որ տնային տնտեսուհիները նույնպես հակառակ խնդիրն են լուծում՝ ապրանքների ցանկ ունեն, և ուզում են իմանալ, թե ինչ ուտեստ են ուզում պատրաստել։ Դու մեռած ես։
Դա պայմանավորված է նրանով, որ Cassandra-ն հիբրիդային տվյալների բազա է. այն միաժամանակ ապահովում է հիմնական արժեք և պահպանում է տվյալները լայն սյունակներում: Java-ում կամ Kotlin-ում այն կարելի է նկարագրել այսպես.
Map<RowKey, SortedMap<ColumnKey, ColumnValue>>
Այսինքն՝ քարտեզ, որը պարունակում է նաև տեսակավորված քարտեզ։ Այս քարտեզի առաջին բանալին Row ստեղնն է կամ Partition ստեղնը՝ բաժանման ստեղնը: Երկրորդ բանալին, որն արդեն տեսակավորված քարտեզի բանալին է, Clustering ստեղնն է:
Տվյալների բազայի բաշխվածությունը պատկերացնելու համար եկեք գծենք երեք հանգույց։ Այժմ դուք պետք է հասկանաք, թե ինչպես կարելի է քայքայել տվյալները հանգույցների: Որովհետև եթե մենք ամեն ինչ խցկենք մեկում (ի դեպ, կարող է լինել հազար, երկու հազար, հինգ, այնքան, որքան ցանկանում եք), դա իրականում բաշխման մասին չէ: Հետևաբար, մեզ անհրաժեշտ է մաթեմատիկական ֆունկցիա, որը կվերադարձնի թիվ։ Պարզապես մի թիվ, երկար ինտ, որը կընկնի ինչ-որ միջակայքի մեջ: Եվ մենք կունենանք մեկ հանգույց, որը պատասխանատու է մեկ տիրույթի համար, երկրորդը՝ երկրորդի, n-րդը՝ n-րդի համար:
Այս թիվը վերցվում է հեշ ֆունկցիայի միջոցով, որը կիրառվում է այն բանի վրա, որը մենք անվանում ենք Partition key: Սա այն սյունակն է, որը նշված է Հիմնական բանալիների հրահանգում, և սա այն սյունակն է, որը կլինի քարտեզի առաջին և ամենահիմնական բանալին: Այն որոշում է, թե որ հանգույցը ինչ տվյալներ կստանա: Կասանդրայում աղյուսակ է ստեղծվում գրեթե նույն շարահյուսությամբ, ինչ SQL-ում.
CREATE TABLE users (
user_id uu id,
name text,
year int,
salary float,
PRIMARY KEY(user_id)
)
Հիմնական բանալին այս դեպքում բաղկացած է մեկ սյունակից, և այն նաև բաժանման բանալին է:
Ինչպե՞ս կգործեն մեր օգտատերերը: Ոմանք կգնան մի հանգույց, ոմանք՝ մյուսը, իսկ ոմանք՝ երրորդ: Արդյունքը սովորական հեշ աղյուսակ է, որը նաև հայտնի է որպես քարտեզ, որը նաև հայտնի է որպես բառարան Python-ում կամ պարզ Key արժեքների կառուցվածք, որից մենք կարող ենք կարդալ բոլոր արժեքները, կարդալ և գրել բանալիով:
Ընտրեք. երբ թույլատրել զտումը վերածվում է ամբողջական սկանավորման կամ ինչ չանել
Եկեք գրենք որոշ ընտրովի հայտարարություն. select * from users where, userid = . Ստացվում է այնպես, ինչպես Oracle-ում. գրում ենք select, նշում ենք պայմանները և ամեն ինչ աշխատում է, օգտատերերը ստանում են: Բայց եթե ընտրում եք, օրինակ, ծննդյան որոշակի տարի ունեցող օգտատեր, Կասանդրան բողոքում է, որ չի կարող կատարել խնդրանքը։ Քանի որ նա ընդհանրապես ոչինչ չգիտի այն մասին, թե ինչպես ենք մենք բաշխում տվյալները ծննդյան տարվա մասին, նա ունի միայն մեկ սյունակ, որը նշված է որպես բանալի: Հետո նա ասում է. «Լավ, ես դեռ կարող եմ կատարել այս խնդրանքը: Ավելացնել թույլատրելի զտիչ: Մենք ավելացնում ենք հրահանգը, ամեն ինչ աշխատում է: Եվ այս պահին սարսափելի բան է տեղի ունենում.
Երբ մենք աշխատում ենք թեստային տվյալների վրա, ամեն ինչ լավ է: Եվ երբ դուք հարցում եք կատարում արտադրության մեջ, որտեղ մենք ունենք, օրինակ, 4 միլիոն ձայնագրություն, ապա մեզ համար ամեն ինչ այնքան էլ լավ չէ։ Որովհետև թույլատրել ֆիլտրումը հրահանգ է, որը թույլ է տալիս Cassandra-ին հավաքել այս աղյուսակի բոլոր տվյալները բոլոր հանգույցներից, բոլոր տվյալների կենտրոններից (եթե դրանք շատ են այս կլաստերում), և միայն դրանից հետո զտել այն: Սա Full Scan-ի անալոգն է, և հազիվ թե որևէ մեկը հիացած լինի դրանով:
Եթե մեզ անհրաժեշտ լինեին միայն ID-ով օգտվողներ, մենք լավ կլիներ այս հարցում: Բայց երբեմն մեզ անհրաժեշտ է այլ հարցումներ գրել և ընտրության վրա այլ սահմանափակումներ դնել: Հետևաբար, մենք հիշում ենք. այս ամենը քարտեզ է, որն ունի բաժանման բանալի, բայց դրա ներսում տեսակավորված քարտեզ է:
Եվ նա նաև ունի բանալի, որը մենք անվանում ենք Կլաստերի բանալին: Այս բանալին, որն իր հերթին բաղկացած է մեր ընտրած սյունակներից, որոնց օգնությամբ Կասանդրան հասկանում է, թե ինչպես են իր տվյալները ֆիզիկապես դասավորված և տեղակայվելու են յուրաքանչյուր հանգույցի վրա։ Այսինքն՝ որոշ Partition ստեղնի համար Clustering ստեղնը ձեզ հստակ կպատմի, թե ինչպես կարելի է տվյալները մղել այս ծառի մեջ, ինչ տեղ է այն զբաղեցնելու այնտեղ:
Սա իսկապես ծառ է, այնտեղ պարզապես կոչվում է համեմատիչ, որին օբյեկտի տեսքով փոխանցում ենք սյունակների որոշակի հավաքածու, և այն նաև նշվում է որպես սյունակների ցանկ։
CREATE TABLE users_by_year_salary_id (
user_id uuid,
name text,
year int,
salary float,
PRIMARY KEY((year), salary, user_id)
Ուշադրություն դարձրեք Հիմնական բանալի հրահանգին, որի առաջին փաստարկը (մեր դեպքում՝ տարին) միշտ բաժանման բանալին է: Այն կարող է բաղկացած լինել մեկ կամ մի քանի սյունակից, դա նշանակություն չունի։ Եթե կան մի քանի սյունակներ, ապա այն պետք է նորից հանվի փակագծերում, որպեսզի լեզվի նախապրոցեսորը հասկանա, որ սա Հիմնական բանալին է, իսկ դրա հետևում մնացած բոլոր սյունակները Clustering ստեղնն են: Այս դեպքում դրանք կփոխանցվեն համեմատիչում այն հերթականությամբ, որով հայտնվում են: Այսինքն՝ առաջին սյունակն ավելի նշանակալից է, երկրորդը՝ պակաս նշանակալից եւ այլն։ Ինչպես գրում ենք, օրինակ, հավասար է տվյալների դասերի դաշտերին. մենք թվարկում ենք դաշտերը, և դրանց համար գրում ենք, թե որոնք են ավելի մեծ, որոնք ավելի փոքր: Կասանդրայում սրանք, համեմատաբար, տվյալների դասի դաշտերն են, որոնց վրա կկիրառվեն դրա համար գրված հավասարները:
Մենք սահմանում ենք տեսակավորում և սահմանափակումներ ենք դնում
Պետք է հիշել, որ տեսակավորման կարգը (նվազող, աճող, ինչ էլ որ լինի) սահմանվում է բանալին ստեղծման նույն պահին, և այն հնարավոր չէ փոխել ավելի ուշ: Այն ֆիզիկապես որոշում է, թե ինչպես են դասավորվելու տվյալները և ինչպես են դրանք պահպանվելու: Եթե Ձեզ անհրաժեշտ է փոխել Clustering ստեղնը կամ տեսակավորման կարգը, դուք պետք է ստեղծեք նոր աղյուսակ և տվյալներ փոխանցեք դրան: Սա չի աշխատի գոյություն ունեցողի հետ:
Մենք մեր սեղանը լցրեցինք օգտատերերով և տեսանք, որ նրանք ընկել են ռինգ՝ սկզբում ըստ ծննդյան տարեթվի, իսկ հետո՝ յուրաքանչյուր հանգույցի վրա՝ ըստ աշխատավարձի և օգտագործողի ID-ի: Այժմ մենք կարող ենք ընտրել՝ սահմանափակումներ դնելով։
Մեր աշխատանքայինը նորից հայտնվում է where, and, և մենք ստանում ենք օգտվողներ, և ամեն ինչ նորից լավ է: Բայց եթե մենք փորձենք օգտագործել «Clustering» ստեղնի միայն մի մասը և ավելի քիչ նշանակալից մեկը, ապա Cassandra-ն անմիջապես կբողոքի, որ չի կարող գտնել այն տեղը մեր քարտեզում, որտեղ այս օբյեկտը, որն ունի այս դաշտերը զրոյական համեմատիչի համար, և այս մեկը: դա հենց նոր էր դրված, - որտեղ նա պառկած է: Ես ստիպված կլինեմ նորից հավաքել բոլոր տվյալները այս հանգույցից և զտել այն: Եվ սա Full Scan-ի անալոգն է հանգույցի ներսում, սա վատ է:
Ցանկացած անհասկանալի իրավիճակում ստեղծեք նոր աղյուսակ
Եթե մենք ուզում ենք օգտատերերին թիրախավորել ըստ ID-ի, տարիքի կամ աշխատավարձի, ի՞նչ պետք է անենք: Ոչինչ։ Պարզապես օգտագործեք երկու սեղան: Եթե Ձեզ անհրաժեշտ է օգտատերերին հասնել երեք տարբեր եղանակներով, կլինեն երեք աղյուսակներ: Անցել են այն ժամանակները, երբ մենք տարածք խնայում էինք պտուտակի վրա: Սա ամենաէժան ռեսուրսն է։ Այն արժե շատ ավելի քիչ, քան արձագանքման ժամանակը, ինչը կարող է վնասակար լինել օգտագործողի համար: Օգտագործողի համար շատ ավելի հաճելի է մեկ վայրկյանում ինչ-որ բան ստանալը, քան 10 րոպեում։
Մենք փոխանակում ենք անհարկի տարածքը և աննորմալացված տվյալները լավ մասշտաբի և հուսալի գործելու հնարավորության համար: Ի վերջո, փաստորեն, մի կլաստեր, որը բաղկացած է երեք տվյալների կենտրոնից, որոնցից յուրաքանչյուրն ունի հինգ հանգույց, տվյալների պահպանման ընդունելի մակարդակով (երբ ոչինչ կորած չէ), կարող է ամբողջությամբ գոյատևել տվյալների մեկ կենտրոնի մահից հետո: Եվ ևս երկու հանգույց մնացած երկուսում: Եվ միայն սրանից հետո են սկսվում խնդիրները։ Սա բավականին լավ ավելորդություն է, արժե մի քանի լրացուցիչ SSD կրիչներ և պրոցեսորներ: Հետևաբար, Cassandra-ն օգտագործելու համար, որը երբեք SQL չէ, որում չկան հարաբերություններ, արտաքին բանալիներ, դուք պետք է իմանաք պարզ կանոններ։
Մենք նախագծում ենք ամեն ինչ ըստ ձեր ցանկության: Հիմնական բանը տվյալները չեն, այլ այն, թե ինչպես է հավելվածը պատրաստվում աշխատել դրա հետ։ Եթե նրան անհրաժեշտ է ստանալ տարբեր տվյալներ տարբեր ձևերով կամ նույն տվյալները տարբեր ձևերով, մենք պետք է դրանք դնենք հավելվածի համար հարմար ձևով: Հակառակ դեպքում մենք կձախողենք Full Scan-ում, իսկ Կասանդրան մեզ ոչ մի առավելություն չի տա։
Տվյալների ապանորմալացումը նորմ է: Մենք մոռանում ենք նորմալ ձևերի մասին, մենք այլևս չունենք հարաբերական տվյալների բազաներ։ Եթե 100 անգամ ինչ-որ բան դնենք, այն 100 անգամ կպառկի։ Դա դեռ ավելի էժան է, քան կանգ առնելը:
Մենք ընտրում ենք բաժանման ստեղները, որպեսզի դրանք նորմալ բաշխվեն։ Մենք չենք ուզում, որ մեր բանալիների հաշը ընկնի մեկ նեղ տիրույթում: Այսինքն՝ վերը նշված օրինակի ծննդյան տարեթիվը վատ օրինակ է։ Ավելի ճիշտ, լավ է, եթե մեր օգտատերերը նորմալ բաշխված լինեն ըստ ծննդյան տարեթվի, իսկ վատը, եթե խոսքը 5-րդ դասարանի աշակերտների մասին է, այնտեղ բաժանումը այնքան էլ լավ չի լինի։
Տեսակավորումն ընտրվում է մեկ անգամ՝ Clustering Key-ի ստեղծման փուլում: Եթե այն փոխվի, մենք ստիպված կլինենք թարմացնել մեր աղյուսակը այլ բանալիով:
Եվ ամենակարևորը. եթե մեզ անհրաժեշտ լինի նույն տվյալները 100 տարբեր ձևերով առբերել, ապա կունենանք 100 տարբեր աղյուսակներ:
Source: www.habr.com