Ես վերջերս իմացա դա (ասում են լիցենզիայի փոփոխության պատճառով)։ Սա ինձ ստիպեց մտածել, քանի որ վերջին մի քանի տարիների ընթացքում ես տեսել եմ բազմաթիվ հոդվածներ այն մասին, թե որքան սարսափելի է MongoDB-ն և ինչպես ոչ ոք չպետք է օգտագործի այն: Բայց այս ընթացքում MongoDB-ն դարձել է շատ ավելի հասուն արտադրանք: Ինչ է պատահել? Արդյո՞ք ամբողջ ատելությունը պայմանավորված է նոր DBMS-ի վաղ շուկայավարման սխալներով: Թե՞ մարդիկ պարզապես օգտագործում են MongoDB-ն սխալ վայրերում:
Եթե կարծում եք, որ ես պաշտպանում եմ MongoDB-ն, խնդրում ենք կարդալ հոդվածի վերջում։
Նոր միտում
Ես աշխատում եմ ծրագրային ապահովման ոլորտում ավելի շատ տարիներ, քան կարող եմ ասել, բայց դեռևս բացահայտվել եմ մեր արդյունաբերության վրա հայտնված միտումների մի փոքր մասի հետ: Ես ականատես եմ եղել 4GL-ի, AOP-ի, Agile-ի, SOA-ի, Web 2.0-ի, AJAX-ի, Blockchain-ի աճին... ցանկն անվերջ է: Ամեն տարի նոր միտումներ են հայտնվում։ Ոմանք արագորեն անհետանում են, իսկ մյուսները հիմնովին փոխում են ծրագրային ապահովման մշակման ձևը:
Յուրաքանչյուր նոր միտում առաջացնում է ընդհանուր ոգևորություն. մարդիկ կամ ցատկում են նավի վրա, կամ տեսնում են ուրիշների կողմից առաջացած աղմուկը և հետևում ամբոխին: Այս գործընթացը ծածկագրված է Gartner-ի կողմից . Չնայած հակասական, այս ժամանակացույցը մոտավորապես նկարագրում է, թե ինչ է տեղի ունենում տեխնոլոգիաների հետ, նախքան դրանք ի վերջո օգտակար դառնալը:
Բայց ժամանակ առ ժամանակ հայտնվում է նոր նորամուծություն (կամ ունի երկրորդ գալուստ, ինչպես այս դեպքում) պայմանավորված միայն մեկ կոնկրետ իրագործմամբ։ NoSQL-ի դեպքում աղմուկը մեծապես պայմանավորված էր MongoDB-ի առաջացմամբ և երկնաքարային աճով: MongoDB-ն չսկսեց այս միտումը. փաստորեն, խոշոր ինտերնետ ընկերությունները սկսեցին խնդիրներ ունենալ մեծ քանակությամբ տվյալների մշակման հետ, ինչը հանգեցրեց ոչ հարաբերական տվյալների բազաների վերադարձին: Ընդհանուր շարժումը սկսվեց այնպիսի նախագծերով, ինչպիսիք են Google-ի Bigtable-ը և Facebook-ի Cassandra-ն, բայց հենց MongoDB-ն դարձավ NoSQL տվյալների բազայի ամենահայտնի և հասանելի իրականացումը, որին ծրագրավորողներից շատերը հասանելի էին:
Նշում. Դուք կարող եք մտածել, որ ես շփոթում եմ փաստաթղթերի տվյալների բազաները սյունակային տվյալների բազաների, բանալիների/արժեքների պահեստների կամ տվյալների պահեստների բազմաթիվ այլ տեսակների հետ, որոնք պատկանում են ընդհանուր NoSQL սահմանմանը: Եվ դու ճիշտ ես: Բայց այդ ժամանակ քաոս էր տիրում։ Բոլորը տարված են NoSQL-ով, այն դարձել է բոլորը բացարձակապես անհրաժեշտ է, չնայած շատերը չեն տեսնում տարբերությունները տարբեր տեխնոլոգիաների մեջ: Շատերի համար MongoDB-ն դարձել է հոմանիշ է NoSQL.
Եվ մշակողները հարձակվեցին դրա վրա: Առանց սխեմաների տվյալների բազայի գաղափարը, որը կախարդական կերպով չափում է ցանկացած խնդիր, բավականին գայթակղիչ էր: Մոտավորապես 2014-ին թվում էր, որ ամենուր, որտեղ մեկ տարի առաջ օգտագործվում էր հարաբերական տվյալների բազա, ինչպիսիք են MySQL, Postgres կամ SQL Server, սկսեցին տեղակայել MongoDB տվյալների բազաները: Երբ հարցնում են, թե ինչու, դուք կարող եք պատասխան ստանալ սովորական «սա ցանցի մասշտաբն է» բառից մինչև ավելի մտածված «իմ տվյալները շատ թույլ կառուցվածք ունեն և լավ տեղավորվում են տվյալների բազայում առանց սխեմայի»:
Կարևոր է հիշել, որ MongoDB-ն և փաստաթղթերի տվյալների բազաները ընդհանրապես լուծում են մի շարք խնդիրներ ավանդական հարաբերական տվյալների բազաների հետ.
- Խիստ սխեմաՀարաբերական տվյալների բազայի դեպքում, եթե դուք դինամիկ կերպով գեներացված տվյալներ ունեք, դուք ստիպված կլինեք կա՛մ ստեղծել տվյալների պատահական «տարբեր» սյունակներ, կա՛մ օգտագործել տվյալների բլոկներ այնտեղ, կա՛մ օգտագործել կոնֆիգուրացիան: ...Այս ամենն ունի էական թերություններ:
- Սանդղակավորման դժվարությունԵթե այնքան շատ տվյալներ կան, որ դրանք չեն տեղավորվում մեկ սերվերի վրա, MongoDB-ն առաջարկել է մեխանիզմներ, որոնք թույլ կտան այն մասշտաբավորել բազմաթիվ մեքենաների վրա:
- Շղթայի բարդ փոփոխություններՈչ միգրացիա: Հարաբերական տվյալների բազայում տվյալների բազայի կառուցվածքի փոփոխությունը կարող է հսկայական խնդիր լինել (հատկապես երբ շատ տվյալներ կան): MongoDB-ն կարողացավ մեծապես պարզեցնել գործընթացը: Եվ դա այնքան դյուրին դարձրեց, որ դուք կարող եք պարզապես թարմացնել շղթան, երբ գնում եք և շատ արագ առաջ շարժվում:
- Ձայնագրման կատարումMongoDB-ի կատարումը լավ էր, հատկապես, երբ ճիշտ կազմաձևված էր: Նույնիսկ MongoDB-ի արտապատկերված կոնֆիգուրացիան, որի համար այն հաճախ քննադատվում էր, ցույց տվեց որոշ տպավորիչ կատարողական թվեր:
Բոլոր ռիսկերը ձեր վրա են
MongoDB-ի պոտենցիալ օգուտները հսկայական էին, հատկապես որոշակի դասերի խնդիրների համար: Եթե դուք կարդաք վերը նշված ցանկը առանց համատեքստը հասկանալու և առանց փորձի, կարող եք տպավորություն ստեղծվել, որ MongoDB-ն իսկապես հեղափոխական DBMS է: Միակ խնդիրն այն էր, որ վերը թվարկված առավելությունները ուղեկցվում էին մի շարք նախազգուշացումներով, որոնցից մի քանիսը թվարկված են ստորև:
Արդար լինելու համար, ոչ ոք 10gen/MongoDB Inc. չեմ ասի, որ հետևյալը ճիշտ չէ, սրանք ընդամենը փոխզիջումներ են.
- Կորած գործարքներԳործարքները շատ հարաբերական տվյալների բազաների հիմնական հատկանիշն են (ոչ բոլորը, բայց մեծ մասը): Գործարքը նշանակում է, որ դուք կարող եք ատոմային կերպով կատարել բազմաթիվ գործողություններ և կարող եք ապահովել, որ տվյալները մնան հետևողական: Անշուշտ, NoSQL տվյալների բազայի դեպքում գործարքների հնարավորությունը կարող է լինել մեկ փաստաթղթում, կամ կարող եք օգտագործել երկփուլ կոմիտներ՝ գործարքների իմաստաբանություն ստանալու համար: Բայց դուք ինքներդ պետք է իրականացնեք այս ֆունկցիոնալությունը... ինչը կարող է բարդ և ժամանակատար խնդիր լինել: Հաճախ դուք չեք հասկանում, որ խնդիր կա, մինչև չտեսնեք, որ տվյալների բազայի տվյալները հայտնվում են անվավեր վիճակներով, քանի որ գործողությունների ատոմականությունը չի կարող երաշխավորվել: Նշում. Շատերն ինձ ասացին, որ MongoDB 4.0-ը գործարքներ է ներկայացրել անցյալ տարի, բայց որոշ սահմանափակումներով: Հոդվածից ելքը մնում է նույնը. գնահատեք, թե որքանով է տեխնոլոգիան համապատասխանում ձեր կարիքներին:
- Հարաբերական ամբողջականության կորուստ (օտար բանալիներ)Եթե ձեր տվյալները փոխհարաբերություններ ունեն, ապա դուք պետք է դրանք կիրառեք հավելվածում: Այս հարաբերությունները հարգող տվյալների շտեմարան ունենալը մեծ աշխատանք կհեռացնի հավելվածից և, հետևաբար, ձեր ծրագրավորողներից:
- Տվյալների կառուցվածքը կիրառելու ունակության բացակայությունԽիստ սխեմաները երբեմն կարող են մեծ խնդիր լինել, բայց դրանք նաև տվյալների լավ կառուցվածքի հզոր մեխանիզմ են, եթե խելամտորեն օգտագործվեն: Փաստաթղթերի տվյալների բազաները, ինչպիսին է MongoDB-ն, ապահովում են սխեմայի անհավանական ճկունություն, բայց այս ճկունությունը վերացնում է տվյալները մաքուր պահելու պատասխանատվությունը: Եթե դուք հոգ չտաք դրանց մասին, կվերջացնեք ձեր հավելվածում շատ կոդ գրելու համար, որպեսզի հաշվի առնեք այն տվյալները, որոնք ձեր ակնկալած ձևով չեն պահվում: Ինչպես հաճախ ենք ասում մեր Simple Thread ընկերությունում... հավելվածը մի օր կվերագրվի, բայց տվյալները հավերժ կապրեն: Նշում. MongoDB-ն աջակցում է սխեմայի ստուգմանը. այն օգտակար է, բայց չի տալիս նույն երաշխիքները, ինչ հարաբերական տվյալների բազայում: Նախ, սխեմայի ստուգման ավելացումը կամ փոփոխությունը չի ազդում հավաքածուի առկա տվյալների վրա: Դուք պետք է ապահովեք, որ դուք թարմացնեք տվյալները նոր սխեմայի համաձայն: Ինքներդ որոշեք, թե արդյոք դա բավարար է ձեր կարիքների համար:
- Հարցման մայրենի լեզու / գործիքի էկոհամակարգի կորուստSQL-ի գալուստը բացարձակ հեղափոխություն էր, և դրանից հետո ոչինչ չի փոխվել: Դա անհավանական հզոր լեզու է, բայց նաև բավականին բարդ: Տվյալների տվյալների բազայի հարցումները JSON հատվածներից բաղկացած նոր լեզվով կառուցելու անհրաժեշտությունը համարվում է մեծ հետընթաց այն մարդկանց կողմից, ովքեր ունեն SQL-ի հետ աշխատելու փորձ: Գոյություն ունի գործիքների մի ամբողջ աշխարհ, որոնք փոխազդում են SQL տվյալների բազաների հետ՝ սկսած IDE-ներից մինչև հաշվետվության գործիքներ: Տեղափոխվելով տվյալների շտեմարան, որը չի աջակցում SQL-ին, նշանակում է, որ դուք չեք կարող օգտագործել այս գործիքների մեծ մասը, կամ դուք պետք է տվյալները թարգմանեք SQL՝ դրանք օգտագործելու համար, ինչը կարող է ավելի դժվար լինել, քան կարծում եք:
Շատ ծրագրավորողներ, ովքեր դիմել են MongoDB-ին, իրականում չէին հասկանում փոխզիջումները և հաճախ սկզբում սուզվում էին այն տեղադրել որպես իրենց հիմնական տվյալների պահեստ: Դրանից հետո հաճախ աներևակայելի դժվար էր վերադառնալ:
Ի՞նչ կարելի էր այլ կերպ անել։
Ոչ բոլորն էին գլխով թռչկոտում ու խփում հատակին: Բայց շատ նախագծեր տեղադրեցին MongoDB-ն այն վայրերում, որտեղ այն պարզապես չէր տեղավորվում, և նրանք ստիպված կլինեն երկար տարիներ ապրել դրա հետ: Եթե այս կազմակերպությունները որոշ ժամանակ ծախսեին և մեթոդաբար մտածեին իրենց տեխնոլոգիական ընտրությունների շուրջ, ապա շատերը տարբեր ընտրություն կկատարեին:
Ինչպե՞ս ընտրել ճիշտ տեխնոլոգիա: Եղել են մի քանի փորձեր՝ ստեղծելու տեխնոլոգիական գնահատման համակարգված շրջանակ, ինչպես, օրինակ и , բայց ինձ թվում է, որ դա ավելորդ բարդություն է։
Շատ տեխնոլոգիաներ կարելի է խելացիորեն գնահատել՝ տալով ընդամենը երկու հիմնական հարց: Խնդիրը մարդկանց գտնելն է, ովքեր կարող են պատասխանել դրանց պատասխանատու կերպով՝ ժամանակ տրամադրելով պատասխանները գտնելու և առանց կողմնակալության:
Եթե որևէ խնդրի չեք բախվում, ապա ձեզ նոր գործիք պետք չէ: Կետ.
Հարց 1. Ի՞նչ խնդիրներ եմ ես փորձում լուծել:
Եթե որևէ խնդրի չեք բախվում, ապա ձեզ նոր գործիք պետք չէ: Կետ. Կարիք չկա լուծում փնտրել, հետո խնդիր հորինել։ Եթե դուք չեք հանդիպել այնպիսի խնդրի, որը նոր տեխնոլոգիան զգալիորեն ավելի լավ է լուծում, քան ձեր գոյություն ունեցող տեխնոլոգիան, այստեղ քննարկելու բան չկա: Եթե դուք մտածում եք այս տեխնոլոգիան օգտագործելու մասին, քանի որ տեսել եք, որ ուրիշներն օգտագործում են այն, մտածեք, թե ինչ խնդիրներ են նրանք բախվում և հարցրեք՝ արդյոք դուք ունեք այդ խնդիրները: Հեշտ է ընդունել տեխնոլոգիան, քանի որ ուրիշներն են օգտագործում այն, խնդիրն այն է, որ հասկանաս՝ արդյոք դու բախվում ես նույն խնդիրների հետ:
Հարց 2. Ի՞նչ եմ ես բաց թողնում:
Սա միանշանակ ավելի բարդ հարց է, քանի որ դուք պետք է խորամուխ լինեք և լավ ըմբռնեք ինչպես հին, այնպես էլ նոր տեխնոլոգիաները: Երբեմն դու իրականում չես կարող հասկանալ նորը, քանի դեռ դրա հետ ինչ-որ բան չես կառուցել կամ չունենաս այդ փորձն ունեցող մեկին:
Եթե դուք ոչ մեկը չունեք, ապա իմաստ ունի մտածել այս գործիքի արժեքը որոշելու համար հնարավոր նվազագույն ներդրումների մասին: Եվ երբ ներդրումներ կատարեք, որքանո՞վ դժվար կլինի փոխել որոշումը:
Մարդիկ միշտ փչացնում են ամեն ինչ
Երբ փորձում եք հնարավորինս անաչառ պատասխանել այս հարցերին, հիշեք մի բան՝ ստիպված կլինեք պայքարել մարդկային բնության հետ: Կան մի շարք ճանաչողական կողմնակալություններ, որոնք պետք է հաղթահարվեն՝ տեխնոլոգիան արդյունավետ գնահատելու համար: Ահա ընդամենը մի քանիսը.
- - Նրա մասին բոլորը գիտեն, բայց նրա հետ պայքարելը դեռևս դժվար է: Պարզապես համոզվեք, որ տեխնոլոգիան իրականում համապատասխանում է ձեր իրական կարիքներին:
- — Շատ մշակողներ հակված են թերագնահատել տեխնոլոգիաները, որոնց հետ երկար ժամանակ աշխատել են և գերագնահատել նոր տեխնոլոգիաների առավելությունները: Միայն ծրագրավորողները չեն, բոլորը ենթակա են այս ճանաչողական կողմնակալությանը:
- - Մենք հակված ենք տեսնելու այն, ինչ կա և տեսադաշտից կորցնում ենք այն, ինչ բացակայում է: Սա կարող է հանգեցնել քաոսի, երբ զուգակցվում է նորության էֆեկտի հետ, քանի որ դուք ոչ միայն էապես գերագնահատում եք նոր տեխնոլոգիան, այլև անտեսում եք դրա թերությունները:.
Օբյեկտիվ գնահատումը հեշտ չէ, սակայն հիմքում ընկած ճանաչողական կողմնակալության ըմբռնումը կօգնի ձեզ ավելի ռացիոնալ որոշումներ կայացնել:
Ամփոփում
Ամեն անգամ, երբ նորամուծություն է հայտնվում, երկու հարցի պետք է մեծ խնամքով պատասխանել.
- Արդյո՞ք այս գործիքը լուծում է իրական խնդիր:
- Մենք լա՞վ ենք հասկանում փոխզիջումները։
Եթե չեք կարող վստահորեն պատասխանել այս երկու հարցերին, մի քանի քայլ հետ գնացեք և մտածեք.
Արդյո՞ք MongoDB-ն ճիշտ ընտրություն էր: Իհարկե այո; Ինչպես շատ ինժեներական տեխնոլոգիաների դեպքում, սա կախված է բազմաթիվ գործոններից: Նրանց թվում, ովքեր պատասխանել են այս երկու հարցերին, շատերն են օգտվել MongoDB-ից և շարունակում են դա անել: Նրանց համար, ովքեր չեն սովորել, ես հուսով եմ, որ դուք արժեքավոր և ոչ շատ ցավոտ դաս եք սովորել գովազդային ցիկլով անցնելու մասին:
Հրաժարում պատասխանատվությունից
Ես ուզում եմ պարզաբանել, որ MongoDB-ի հետ ոչ սիրո, ոչ էլ ատելության հարաբերություններ ունեմ: Մենք պարզապես չենք ունեցել այնպիսի խնդիրներ, որոնք MongoDB-ն լավագույնս հարմար է լուծելու համար: Ես գիտեմ, որ 10gen/MongoDB Inc. սկզբում շատ համարձակ էր՝ սահմանելով անապահով լռելյայններ և առաջ մղելով MongoDB-ն ամենուր (հատկապես հաքաթոններում)՝ որպես ցանկացած տվյալների հետ աշխատելու ունիվերսալ լուծում: Հավանաբար դա վատ որոշում էր։ Բայց դա հաստատում է այստեղ նկարագրված մոտեցումը. այս խնդիրները կարելի է շատ արագ հայտնաբերել նույնիսկ տեխնոլոգիայի մակերեսային գնահատմամբ:
Source: www.habr.com