Հոդվածի թարգմանությունը պատրաստվել է դասընթացի մեկնարկի նախօրեին .
Փաստեր:
- Չափազանց կարևոր է սխեմայի մշակումը, չնայած այն ընտրովի է MongoDB-ում:
- Նմանապես, ինդեքսները պետք է համապատասխանեն ձեր սխեմային և մուտքի օրինաչափություններին:
- Խուսափեք մեծ առարկաներ և մեծ զանգվածներ օգտագործելուց:
- Զգույշ եղեք MongoDB կարգավորումների հետ, հատկապես երբ խոսքը վերաբերում է անվտանգությանն ու հուսալիությանը:
- MongoDB-ն չունի հարցումների օպտիմիզատոր, այնպես որ դուք պետք է զգույշ լինեք հարցումների գործողություններ կատարելիս:
Ես շատ երկար ժամանակ աշխատել եմ տվյալների բազաների հետ, բայց միայն վերջերս եմ հայտնաբերել MongoDB-ն: Կան մի քանի բաներ, որոնք ես կցանկանայի, որ իմանայի նախքան դրա հետ աշխատելը: Երբ մարդն արդեն ունի որոշակի ոլորտում փորձ, նա նախապես պատկերացումներ ունի, թե ինչ են տվյալների բազաները և ինչով են զբաղվում: Ուրիշների համար ավելի հեշտ հասկանալու հույսով ներկայացնում եմ տարածված սխալների ցանկը։
MongoDB սերվերի ստեղծում առանց նույնականացման
Ցավոք, MongoDB-ն լռելյայն տեղադրվում է առանց նույնականացման: Տեղական մուտք ունեցող աշխատակայանի համար այս պրակտիկան նորմալ է: Բայց քանի որ MongoDB-ն բազմաֆունկցիոնալ համակարգ է, որը սիրում է մեծ քանակությամբ հիշողություն օգտագործել, ավելի լավ կլինի, եթե այն տեղադրեք հնարավորինս շատ RAM ունեցող սերվերի վրա, նույնիսկ եթե այն օգտագործելու եք միայն զարգացման համար: Սերվերի վրա լռելյայն պորտի միջոցով տեղադրումը կարող է խնդրահարույց լինել, հատկապես, եթե հարցումում կարող է կատարվել որևէ Javascript կոդ (օրինակ. $where որպես գաղափար ).
Կան նույնականացման մի քանի մեթոդներ, բայց ամենահեշտը օգտատիրոջ ID/գաղտնաբառ սահմանելն է: Օգտագործեք այս գաղափարը, մինչ մտածում եք շքեղ նույնականացման մասին՝ հիմնված . Ինչ վերաբերում է անվտանգությանը, MongoDB-ն պետք է անընդհատ թարմացվի, և գրանցամատյանները միշտ պետք է ստուգվեն չարտոնված մուտքի համար: Օրինակ, ես սիրում եմ ընտրել մեկ այլ նավահանգիստ որպես լռելյայն նավահանգիստ:
Մի մոռացեք կապել ձեր հարձակման մակերեսը MongoDB-ին
պարունակում է լավ խորհուրդներ ցանցի ներխուժման և տվյալների արտահոսքի ռիսկը նվազեցնելու համար: Հեշտ է դա հեռացնել և ասել, որ զարգացման սերվերը անվտանգության բարձր մակարդակի կարիք չունի: Այնուամենայնիվ, դա այնքան էլ պարզ չէ, և սա վերաբերում է բոլոր MongoDB սերվերներին: Մասնավորապես, եթե չկա օգտագործելու համոզիչ պատճառ , կամ , դուք պետք է անջատեք կամայական կոդի օգտագործումը JavaScript-ում՝ գրելով կազմաձևման ֆայլում . Քանի որ տվյալների ֆայլերը գաղտնագրված չեն ստանդարտ MongoDB-ում, իմաստ ունի գործարկել MongoDB-ով , որն ունի ամբողջական մուտք դեպի ֆայլեր, միայն դրան սահմանափակ հասանելիությամբ և օպերացիոն համակարգի սեփական ֆայլերի մուտքի վերահսկման հնարավորություններով:
Սխալ շղթայի մշակման ժամանակ
MongoDB-ն չի օգտագործում սխեմա: Բայց դա չի նշանակում, որ սխեման պետք չէ։ Եթե դուք պարզապես ցանկանում եք փաստաթղթեր պահել առանց որևէ հետևողական օրինաչափության, դրանք պահելը կարող է արագ և հեշտ լինել, բայց հետագայում դրանք վերականգնելը կարող է դժվար լինել: .
Դասական հոդված» Այն արժե կարդալ, և նման առանձնահատկություններ երրորդ կողմի Studio 3T գործիքում արժե օգտագործել սխեմաների կանոնավոր ստուգման համար:
Մի մոռացեք տեսակավորման կարգը
Տեսակավորման կարգը մոռանալը կարող է ավելի շատ հիասթափություն և ավելի շատ ժամանակ վատնել, քան ցանկացած այլ սխալ կազմաձևում: Լռելյայն օգտագործում է MongoBD-ն . Բայց դա դժվար թե ինչ-որ մեկին օգտակար լինի։ Անցյալ դարի 80-ական թվականներին ուլունքների, կաֆտանների և գանգուր բեղերի հետ մեկտեղ տարօրինակ անախրոնիզմներ էին համարվում տառազգայուն, շեշտը զգայուն, երկուական տեսակները: Այժմ դրանց օգտագործումն աններելի է։ Իրական կյանքում «մոտոցիկլետը» նույնն է, ինչ «մոտոցիկլետը»։ Իսկ «Բրիտանիան» ու «Բրիտանիան» նույն տեղն են։ Փոքրատառը պարզապես մեծատառի մեծատառ համարժեքն է: Եվ մի ստիպեք ինձ սկսել դիակրիտիկների տեսակավորումը: MongoDB-ում տվյալների շտեմարան ստեղծելիս օգտագործեք շեշտադրումներով համադրում և , որոնք համապատասխանում են լեզվին և . Սա շատ ավելի հեշտ կդարձնի լարային տվյալների որոնումը:
Ստեղծեք հավաքածուներ մեծ փաստաթղթերով
MongoDB-ն ուրախ է հյուրընկալել մեծ փաստաթղթեր մինչև 16 ՄԲ հավաքածուներում, և Նախատեսված է 16 ՄԲ-ից ավելի մեծ փաստաթղթերի համար: Բայց միայն այն պատճառով, որ մեծ փաստաթղթեր կարող են տեղադրվել այնտեղ, դրանք այնտեղ պահելը լավ գաղափար չէ: MongoDB-ն լավագույնս կաշխատի, եթե դուք պահում եք առանձին փաստաթղթեր, որոնք ունեն մի քանի կիլոբայթ չափ, դրանք ավելի շատ վերաբերվում են որպես լայն SQL աղյուսակի տողեր: Խոշոր փաստաթղթերը խնդիրների աղբյուր կլինեն .
Մեծ զանգվածներով փաստաթղթերի ստեղծում
Փաստաթղթերը կարող են պարունակել զանգվածներ: Լավագույնն այն է, որ զանգվածի տարրերի թիվը հեռու է քառանիշ թվից: Եթե տարրերը հաճախ ավելացվեն զանգվածին, ապա այն կգերազանցի այն պարունակող փաստաթուղթը և պետք է լինի , ինչը նշանակում է, որ անհրաժեշտ կլինի . Մեծ զանգվածով փաստաթուղթը նորից ինդեքսավորելիս ինդեքսները հաճախ վերագրվում են, քանի որ կա , որը պահպանում է իր ինդեքսը։ Այս վերաինդեքսավորումը նույնպես տեղի է ունենում, երբ փաստաթուղթը տեղադրվում կամ ջնջվում է:
MongoDB-ն ունի մի բան, որը կոչվում է , որն ապահովում է փաստաթղթերի աճի հնարավորություն՝ այս խնդիրը նվազագույնի հասցնելու համար:
Դուք կարող եք մտածել, որ դուք կարող եք անել առանց զանգվածի ինդեքսավորման: Ցավոք սրտի, ինդեքսների բացակայությունը կարող է ձեզ այլ խնդիրներ առաջացնել: Քանի որ փաստաթղթերը սկանավորվում են սկզբից մինչև վերջ, զանգվածի վերջում տարրերի որոնումը կտևի ավելի երկար, և նման փաստաթղթի հետ կապված գործողությունների մեծ մասը կկատարվի .
Մի մոռացեք, որ ագրեգացման փուլերի հերթականությունը կարևոր է
Հարցման օպտիմիզատորով տվյալների բազայի համակարգում ձեր գրած հարցումները բացատրություններ են այն մասին, թե ինչ եք ուզում ստանալ, այլ ոչ թե ինչպես ստանալ այն: Այս մեխանիզմը գործում է ռեստորանում պատվիրելու անալոգիայով. սովորաբար պարզապես ճաշատեսակ եք պատվիրում և խոհարարին մանրամասն հրահանգներ չեք տալիս։
MongoDB-ում դուք հրահանգում եք խոհարարին: Օրինակ, դուք պետք է համոզվեք, որ տվյալները անցնում են reduce որքան հնարավոր է շուտ խողովակաշարում օգտագործելով $match и $project, և տեսակավորումը տեղի է ունենում միայն դրանից հետո reduce, և որ որոնումը կատարվում է ձեր ուզած հերթականությամբ: Հարցման օպտիմիզատոր ունենալը, որը վերացնում է ավելորդ աշխատանքը, օպտիմալ կերպով հաջորդականացնում է քայլերը և ընտրում միացման տեսակները, կարող է փչացնել ձեզ: MongoDB-ի հետ դուք ավելի շատ վերահսկողություն ունեք հարմարավետության գնով:
Գործիքներ, ինչպիսիք են կհեշտացնի ագրեգացիոն հարցումների կառուցումը . Aggregation Editor ֆունկցիան թույլ է տալիս կիրառել խողովակաշարի հայտարարությունները մեկ փուլով և ստուգել մուտքային և ելքային տվյալները յուրաքանչյուր փուլում՝ ավելի հեշտ վրիպազերծման համար:
Արագ ձայնագրման օգտագործումը
Երբեք մի սահմանեք MongoDB գրելու տարբերակները, որպեսզի ունենան բարձր արագություն, բայց ցածր հուսալիություն: Այս ռեժիմը «ֆայլ և մոռացիր» արագ է թվում, քանի որ հրամանը վերադարձվում է նախքան գրելը: Եթե համակարգը խափանում է նախքան տվյալները սկավառակի վրա գրելը, այն կկորչի և կհայտնվի անհամապատասխան վիճակում: Բարեբախտաբար, 64-բիթանոց MongoDB-ում գրանցումը միացված է:
MMAPv1 և WiredTiger պահեստավորման շարժիչները դա կանխելու համար օգտագործում են գրանցում, թեև WiredTiger-ը կարող է վերականգնել մինչև վերջին հետևողականությունը , եթե գրանցումն անջատված է:
Journaling-ը ապահովում է, որ տվյալների բազան վերականգնվելուց հետո գտնվում է հետևողական վիճակում և պահպանում է բոլոր տվյալները մինչև այն գրվի մատյանում: Ձայնագրությունների հաճախականությունը կազմաձևվում է պարամետրի միջոցով .
Գրառումների մեջ համոզվելու համար համոզվեք, որ գրանցումը միացված է կազմաձևման ֆայլում ), իսկ ձայնագրությունների հաճախականությունը համապատասխանում է այն տեղեկատվության քանակին, որը դուք կարող եք թույլ տալ կորցնել:
Տեսակավորում առանց ինդեքսի
Որոնելիս և համախմբելիս հաճախ անհրաժեշտություն է առաջանում տեսակավորել տվյալները: Հուսանք, որ դա արվում է վերջնական փուլերից մեկում՝ արդյունքը զտելուց հետո՝ տեսակավորվող տվյալների քանակը նվազեցնելու համար: Եվ նույնիսկ այս դեպքում, տեսակավորման համար ձեզ հարկավոր կլինի . Դուք կարող եք օգտագործել մեկ կամ բարդ ինդեքս:
Եթե չկա համապատասխան ցուցանիշ, MongoDB-ն կանի առանց դրա: Բոլոր փաստաթղթերի ընդհանուր չափի հիշողության սահմանափակում կա 32 ՄԲ , և եթե MongoDB-ն հասնի այս սահմանին, ապա այն կամ սխալ կուղարկի, կամ կվերադառնա .
Որոնել առանց ինդեքսի աջակցության
Որոնման հարցումները կատարում են SQL-ում JOIN գործողության նման գործառույթ: Լավ աշխատելու համար նրանց անհրաժեշտ է որպես օտար բանալի օգտագործվող բանալու արժեքի ինդեքսը: Սա ակնհայտ չէ, քանի որ օգտագործումը չի արտացոլվում explain(). Նման ինդեքսները ի լրումն են գրված ինդեքսին explain(), որն իր հերթին օգտագործվում է խողովակաշարերի օպերատորների կողմից $match и $sort, երբ նրանք հանդիպում են խողովակաշարի սկզբում։ Ինդեքսներն այժմ կարող են ընդգրկել ցանկացած փուլ .
Հրաժարվելով բազմակի թարմացումներից
մեթոդ օգտագործվում է գոյություն ունեցող փաստաթղթի մի մասը կամ ամբողջ փաստաթղթի մի մասը փոխելու համար, մինչև ամբողջական փոխարինում, կախված ձեր նշած պարամետրից . Այն, ինչ այնքան էլ ակնհայտ չէ, այն է, որ այն չի մշակի հավաքածուի բոլոր փաստաթղթերը, քանի դեռ չեք սահմանել տարբերակը թարմացնել բոլոր փաստաթղթերը, որոնք համապատասխանում են պահանջի չափանիշներին:
Մի մոռացեք հեշ աղյուսակում բանալիների հերթականության կարևորության մասին
JSON-ում օբյեկտը բաղկացած է զրոյական չափի կամ ավելի անուն/արժեք զույգերի չդասավորված հավաքածուից, որտեղ անունը տող է, իսկ արժեքը՝ տող, թիվ, բուլյան, զրոյական, օբյեկտ կամ զանգված:
Ցավոք, BSON-ը որոնելիս մեծ ուշադրություն է դարձնում կարգի վրա: MongoDB-ում ներկառուցված օբյեկտներում ստեղների հերթականությունը Այսինքն, { firstname: "Phil", surname: "factor" } - սա նույնը չէ, ինչ { { surname: "factor", firstname: "Phil" }. Այսինքն՝ դուք պետք է պահպանեք անուն/արժեք զույգերի հերթականությունը ձեր փաստաթղթերում, եթե ցանկանում եք վստահ լինել, որ դրանք կգտնեք:
Մի շփոթվեք "Դատարկ" и "չսահմանված"
Արժեք "չսահմանված" երբեք վավեր չէր JSON-ում, ըստ JSON (ECMA-404 Բաժին 5), թեև այն օգտագործվում է JavaScript-ում: Ավելին, BSON-ի համար այն հնացած է և փոխարկվում է $null, որը միշտ չէ, որ լավ լուծում է։ .
Օգտագործում $limit() առանց $sort()
Շատ հաճախ, երբ դուք զարգանում եք MongoDB-ում, օգտակար է պարզապես տեսնել արդյունքի նմուշը, որը կվերադարձվի հարցումից կամ ագրեգացիայից: Այս առաջադրանքի համար ձեզ հարկավոր կլինի $limit(), բայց այն երբեք չպետք է լինի վերջնական կոդում, քանի դեռ չեք օգտագործել այն նախկինում $sort. Այս մեխանիկը անհրաժեշտ է, քանի որ հակառակ դեպքում դուք չեք կարող երաշխավորել արդյունքի հերթականությունը, և դուք չեք կարողանա հուսալիորեն դիտել տվյալները: Արդյունքի վերևում դուք կստանաք տարբեր գրառումներ՝ կախված տեսակավորման տեսակից: Հուսալիորեն աշխատելու համար հարցումները և ագրեգացիաները պետք է լինեն դետերմինիստական, այսինքն՝ թողարկեն նույն արդյունքները ամեն անգամ, երբ դրանք կատարվում են: Կոդ, որը պարունակում է $limit(), բայց ոչ $sort, որոշիչ չի լինի և կարող է հետագայում առաջացնել սխալներ, որոնք դժվար կլինի գտնել:
Ամփոփում
MongoDB-ից հիասթափվելու միակ միջոցը այն ուղղակիորեն համեմատելն է տվյալների բազայի մեկ այլ տեսակի հետ, ինչպիսին է DBMS-ը, կամ օգտագործել դրա օգտագործումը՝ հիմնվելով որոշակի ակնկալիքների վրա: Դա նման է նարինջը պատառաքաղի հետ համեմատելուն: Տվյալների բազայի համակարգերը ծառայում են հատուկ նպատակների: Ավելի լավ է պարզապես հասկանալ և գնահատել այս տարբերությունները ինքներդ ձեզ համար: Ամոթ կլիներ ճնշում գործադրել MongoDB մշակողների վրա մի ճանապարհի վրա, որը նրանց ստիպեց անցնել DBMS ճանապարհով: Ես ուզում եմ տեսնել հին խնդիրների լուծման նոր և հետաքրքիր ուղիներ, ինչպիսիք են տվյալների ամբողջականության ապահովումը և տվյալների համակարգերի ստեղծումը, որոնք դիմացկուն են ձախողման և վնասակար հարձակումների նկատմամբ:
MongoDB-ի կողմից ACID գործարքների ներդրումը 4.0 տարբերակում լավ օրինակ է նորարարական ձևով կարևոր բարելավումների ներդրման համար: Բազմափաստաթղթային և բազմաքաղքարտ գործարքներն այժմ ատոմային են: Հնարավոր է նաև կարգավորել կողպեքներ ձեռք բերելու և խցանված գործարքները դադարեցնելու համար պահանջվող ժամանակը, ինչպես նաև փոխել մեկուսացման մակարդակը:
Կարդալ ավելին:
Source: www.habr.com