Այս տվյալների բազան վառվում է...

Մի տեխնիկական պատմություն պատմեմ.

Շատ տարիներ առաջ ես մշակում էի հավելված, որի մեջ ներկառուցված են համագործակցության առանձնահատկություններ: Դա օգտագործողի համար հարմար փորձնական փաթեթ էր, որն օգտվեց վաղ React-ի և CouchDB-ի ողջ ներուժից: Այն իրական ժամանակում համաժամացրել է տվյալները JSON-ի միջոցով OT. Այն օգտագործվում էր ընկերության ներսում, սակայն դրա լայն կիրառելիությունն ու ներուժը այլ ոլորտներում պարզ էր:

Այս տեխնոլոգիան պոտենցիալ հաճախորդներին վաճառելիս մենք հանդիպեցինք անսպասելի խոչընդոտի: Դեմո տեսանյութում մեր տեխնոլոգիան հիանալի տեսք ուներ և աշխատում էր, այնտեղ խնդիրներ չկան: Տեսանյութը ցույց է տվել, թե ինչպես է այն աշխատում և ոչինչ չի ընդօրինակել։ Մենք մշակեցինք և կոդավորեցինք ծրագրի օգտագործման իրատեսական սցենարը:


Փաստորեն, սա դարձավ խնդիրը։ Մեր ցուցադրությունն աշխատեց ճիշտ այնպես, ինչպես բոլորը մոդելավորում էին իրենց հավելվածները: Մասնավորապես, տեղեկատվությունն ակնթարթորեն փոխանցվել է A-ից B, նույնիսկ եթե դրանք մեծ մեդիա ֆայլեր են: Մուտք գործելուց հետո յուրաքանչյուր օգտվող տեսավ նոր գրառումներ: Օգտագործելով հավելվածը՝ տարբեր օգտատերեր կարող էին հստակորեն միասին աշխատել նույն նախագծերի վրա, նույնիսկ եթե գյուղում ինչ-որ տեղ ինտերնետ կապն ընդհատվեր: Սա անուղղակիորեն ենթադրվում է ցանկացած արտադրանքի տեսանյութում, որը կտրված է After Effects-ում:

Թեև բոլորը գիտեին, թե ինչի համար է «Թարմացնել» կոճակը, ոչ ոք իրականում չհասկացավ, որ վեբ հավելվածները, որոնք նրանք խնդրել էին մեզ ստեղծել, սովորաբար ենթարկվում էին իրենց սահմանափակումներին: Եվ եթե դրանք այլևս կարիք չունենան, օգտագործողի փորձը բոլորովին այլ կլինի: Նրանք հիմնականում նկատեցին, որ կարող են «շփվել»՝ գրառումներ թողնելով մարդկանց համար, ում հետ խոսում էին, ուստի մտածում էին, թե ինչով է սա տարբերվում, օրինակ, Slack-ից: Ֆու՜

Առօրյա համաժամացման ձևավորում

Եթե ​​դուք ունեք ծրագրային ապահովման մշակման փորձ, ապա պետք է նյարդային լինի հիշել, որ մարդկանց մեծամասնությունը չի կարող պարզապես նայել ինտերֆեյսի նկարին և հասկանալ, թե ինչ է այն անելու դրա հետ շփվելիս: Էլ չեմ ասում, թե ինչ է կատարվում հենց ծրագրի ներսում։ Իմացեք, որ կարող տեղի ունենալը մեծապես արդյունք է իմանալու, թե ինչ չի կարող լինել և ինչ չպետք է լինի: Սա պահանջում է մտավոր մոդել ոչ միայն այն, ինչ անում է ծրագրաշարը, այլ նաև ինչպես են դրա առանձին մասերը համակարգվում և շփվում միմյանց հետ:

Դրա դասական օրինակն այն օգտվողն է, որը նայում է a spinner.gif, մտածելով, թե վերջապես երբ կավարտվի աշխատանքը։ Մշակողը կհասկանար, որ գործընթացը հավանաբար խրված է, և որ gif-ը երբեք չի անհետանա էկրանից։ Այս անիմացիան մոդելավորում է աշխատանքի կատարումը, բայց կապված չէ դրա վիճակի հետ: Նման դեպքերում որոշ տեխնոլոգներ սիրում են աչքերը կլորացնել՝ զարմանալով օգտատերերի շփոթության աստիճանից: Այնուամենայնիվ, ուշադրություն դարձրեք, թե նրանցից քանիսը ցույց են տալիս պտտվող ժամացույցը և ասում, որ այն իրականում անշարժ է:

Սա իրական ժամանակի արժեքի էությունն է: Այս օրերին իրական ժամանակի տվյալների բազաները դեռ շատ քիչ են օգտագործվում, և շատերը կասկածանքով են դիտում դրանք: Այս տվյալների բազաներից շատերը մեծապես հակված են դեպի NoSQL ոճը, այդ իսկ պատճառով նրանք սովորաբար օգտագործում են Մոնգո վրա հիմնված լուծումներ, որոնք լավագույնս մոռացվում են: Այնուամենայնիվ, ինձ համար դա նշանակում է հարմարավետ աշխատել CouchDB-ի հետ, ինչպես նաև սովորել նախագծել կառույցներ, որոնք ավելին, քան պարզապես որոշ բյուրոկրատներ կարող են լրացնել տվյալների հետ: Կարծում եմ՝ ժամանակս ավելի լավ եմ օգտագործում:

Բայց այս գրառման իրական թեման այն է, ինչ ես օգտագործում եմ այսօր: Ոչ թե ընտրությամբ, այլ անտարբեր և կուրորեն կիրառվող կորպորատիվ քաղաքականության պատճառով։ Այսպիսով, ես կտրամադրեմ լիովին արդար և անկողմնակալ համեմատություն Google-ի իրական ժամանակի տվյալների բազայի երկու սերտորեն կապված արտադրանքների միջև:

Երկուսն էլ իրենց անուններում ունեն Կրակ բառը: Մի բան սիրով եմ հիշում. Երկրորդն ինձ համար այլ տեսակի կրակն է։ Չեմ շտապում ասել նրանց անունները, քանի որ երբ ասեմ, կբախվենք առաջին մեծ խնդրին՝ անուններին:

Առաջինը կոչվում է Firebase իրական ժամանակի տվյալների բազաև երկրորդը Firebase Cloud Firestore. Երկուսն էլ ապրանքներ են Firebase հավաքակազմ Google. Նրանց API-ները կոչվում են համապատասխանաբար firebase.database(…) и firebase.firestore(…).

Սա տեղի ունեցավ, քանի որ Իրական ժամանակի տվյալների բազա - դա ուղղակի բնօրինակն է Firebase- ը մինչև 2014 թվականին Google-ի կողմից դրա գնումը։ Հետո Google-ը որոշեց ստեղծել որպես զուգահեռ արտադրանք պատճենը Firebase-ը հիմնված է մեծ տվյալների ընկերության վրա և այն անվանեց Firestore ամպով: Հուսով եմ՝ դեռ չեք շփոթել։ Եթե ​​դեռ շփոթված եք, մի անհանգստացեք, ես ինքս տասն անգամ վերաշարադրել եմ հոդվածի այս հատվածը։

Քանի որ դուք պետք է նշեք Firebase- ը Firebase հարցում, և Հրդեհային խանութ Firebase-ի մասին հարցին, գոնե մի քանի տարի առաջ Stack Overflow-ում ձեզ հասկանալու համար:

Եթե ​​մրցանակ լիներ ծրագրային ապահովման անվանման ամենավատ փորձի համար, սա անպայման կլիներ հավակնորդներից մեկը: Համինգի հեռավորությունն այս անունների միջև այնքան փոքր է, որ շփոթեցնում է նույնիսկ փորձառու ինժեներներին, որոնց մատները տպում են մի անուն, մինչդեռ գլուխները մտածում են մեկ այլ անունի մասին: Սրանք բարեխիղճ ծրագրեր են, որոնք ձախողվում են. նրանք կատարեցին մարգարեությունը, որ տվյալների բազան կրակի մեջ է լինելու: Եվ ես ամենևին էլ չեմ կատակում: Անվանման այս սխեման հնարած անձը արյուն, քրտինք և արցունքներ է առաջացրել:

Պիրրոսի հաղթանակ

Կարելի է մտածել, որ Firestore-ն է փոխարինումը Firebase-ը, նրա հաջորդ սերնդի հետնորդը, բայց դա ապակողմնորոշիչ կլինի: Firestore-ը երաշխավորված չէ, որ Firebase-ի համար հարմար փոխարինող կլինի: Թվում է, թե ինչ-որ մեկը կտրել է ամեն ինչ հետաքրքիր, իսկ մնացածի մեծ մասը շփոթել է տարբեր ձևերով:

Այնուամենայնիվ, երկու արտադրանքներին արագ հայացք նետելը կարող է ձեզ շփոթեցնել. թվում է, որ նրանք նույն բանն են անում, հիմնականում նույն API-ների միջոցով և նույնիսկ տվյալների բազայի նույն նիստում: Տարբերությունները նուրբ են և բացահայտվում են միայն լայնածավալ փաստաթղթերի մանրակրկիտ համեմատական ​​ուսումնասիրության արդյունքում: Կամ երբ փորձում եք միացնել կոդը, որը հիանալի աշխատում է Firebase-ում, որպեսզի այն աշխատի Firestore-ի հետ: Նույնիսկ այն ժամանակ դուք պարզում եք, որ տվյալների բազայի ինտերֆեյսը լուսավորվում է հենց որ փորձում եք իրական ժամանակում մկնիկի հետ քաշել և թողնել: Կրկնում եմ՝ չեմ կատակում.

Firebase-ի հաճախորդը քաղաքավարի է այն առումով, որ այն բուֆերացնում է փոփոխությունները և ինքնաբերաբար կրկնում է թարմացումները, որոնք առաջնահերթություն են տալիս գրելու վերջին գործողությանը: Այնուամենայնիվ, Firestore-ն ունի մեկ փաստաթղթի մեկ գրելու գործողության սահմանաչափ՝ մեկ օգտատիրոջ վայրկյանում, և այս սահմանաչափը պարտադրվում է սերվերի կողմից: Երբ աշխատում եք դրա հետ, ձեզնից է կախված՝ գտնել դրա շուրջ ճանապարհը և կիրառել թարմացման արագության սահմանափակիչ, նույնիսկ երբ դուք պարզապես փորձում եք ստեղծել ձեր հավելվածը: Այսինքն, Firestore-ը իրական ժամանակի տվյալների բազա է, առանց իրական ժամանակի հաճախորդի, որը ներկայացվում է որպես API օգտագործելով:

Այստեղ մենք սկսում ենք տեսնել Firestore-ի գոյության պատճառի առաջին նշանները: Ես կարող եմ սխալվել, բայց ես կասկածում եմ, որ Google-ի ղեկավարության բարձրաստիճան ղեկավարներից մեկը գնումից հետո նայեց Firebase-ին և պարզապես ասաց. «Ոչ, Աստված իմ, ոչ: Սա անընդունելի է։ Պարզապես ոչ իմ ղեկավարությամբ»:

Նա հայտնվեց իր սենյակից և հայտարարեց.

«Մեկ մեծ JSON փաստաթուղթ. Ոչ Տվյալները կբաժանեք առանձին փաստաթղթերի, որոնցից յուրաքանչյուրի չափը կլինի 1 մեգաբայթից ոչ ավելի»։

Թվում է, որ նման սահմանափակումը չի կարող գոյատևել որևէ բավականաչափ մոտիվացված օգտատերերի բազայի հետ առաջին հանդիպման ժամանակ: Դուք գիտեք, որ դա է: Աշխատավայրում, օրինակ, մենք ունենք ավելի քան մեկուկես հազար շնորհանդեսներ, և սա լրիվ նորմալ է։

Այս սահմանափակմամբ դուք ստիպված կլինեք ընդունել այն փաստը, որ տվյալների բազայի մեկ «փաստաթուղթը» չի նմանվի որևէ օբյեկտի, որը օգտվողը կարող է անվանել փաստաթուղթ:

«Զանգվածների զանգվածներ, որոնք կարող են ռեկուրսիվորեն պարունակել այլ տարրեր: Ոչ Զանգվածները կպարունակեն միայն ֆիքսված երկարության առարկաներ կամ թվեր, ինչպես որ Աստված էր նախատեսել»:

Այսպիսով, եթե դուք հույս ունեիք տեղադրել GeoJSON-ը ձեր Firestore-ում, ապա կտեսնեք, որ դա հնարավոր չէ: Ոչ միաչափ ոչինչ ընդունելի չէ։ Հուսով եմ, որ ձեզ դուր է գալիս Base64-ը և/կամ JSON-ը JSON-ում:

«JSON ներմուծում և արտահանում HTTP-ի, հրամանի տողի գործիքների՞, թե՞ ադմինիստրատորի վահանակի միջոցով: Ոչ Դուք միայն կկարողանաք տվյալներ արտահանել և ներմուծել Google Cloud Storage: Հիմա այդպես է կոչվում, կարծում եմ։ Եվ երբ ասում եմ «դուք», ես դիմում եմ միայն նրանց, ովքեր ունեն Ծրագրի սեփականատիրոջ հավատարմագրերը: Մնացած բոլորը կարող են գնալ և տոմսեր ստեղծել»:

Ինչպես տեսնում եք, FireBase տվյալների մոդելը հեշտ է նկարագրել: Այն պարունակում է մեկ հսկայական JSON փաստաթուղթ, որը կապում է JSON ստեղները URL ուղիների հետ: Եթե ​​գրեք հետ HTTP PUT в / FireBase-ը հետևյալն է.

{
  "hello": "world"
}

The GET /hello կվերադառնա "world". Հիմնականում այն ​​աշխատում է ճիշտ այնպես, ինչպես դուք ակնկալում եք: FireBase օբյեկտների հավաքածու /my-collection/:id համարժեք է JSON բառարանին {"my-collection": {...}} արմատում, որի բովանդակությունը հասանելի է /my-collection:

{
  "id1": {...object},
  "id2": {...object},
  "id3": {...object},
  // ...
}

Սա լավ է աշխատում, եթե յուրաքանչյուր ներդիր ունի առանց բախման ID, որի համար համակարգն ունի ստանդարտ լուծում:

Այլ կերպ ասած, տվյալների բազան 100% JSON(*) համատեղելի է և հիանալի աշխատում է HTTP-ի հետ, ինչպիսին է CouchDB-ն: Բայց հիմնականում դուք այն օգտագործում եք իրական ժամանակի API-ի միջոցով, որը վերացում է վեբսոկետները, թույլտվությունները և բաժանորդագրությունները: Ադմինիստրատորի վահանակն ունի երկու հնարավորություններ՝ թույլ տալով և՛ իրական ժամանակում խմբագրում, և՛ JSON ներմուծում/արտահանում: Եթե ​​դուք նույնն անեք ձեր կոդի մեջ, կզարմանաք, թե որքան մասնագիտացված կոդ կվատնվի, երբ հասկանաք, որ կարկատելը և տարբերվող JSON-ը լուծում է մշտական ​​վիճակի հետ կապված սովորական խնդիրների 90%-ը:

Firestore տվյալների մոդելը նման է JSON-ին, սակայն տարբերվում է որոշ կարևոր ձևերով: Ես արդեն նշեցի զանգվածների ներսում զանգվածների բացակայությունը։ Ենթահավաքածուների մոդելն այն է, որ դրանք լինեն առաջին կարգի հասկացություններ՝ առանձնացված JSON փաստաթղթից, որը պարունակում է դրանք: Քանի որ դրա համար պատրաստի սերիալացում չկա, տվյալների վերբերման և գրելու համար անհրաժեշտ է մասնագիտացված կոդային ուղի: Ձեր սեփական հավաքածուները մշակելու համար դուք պետք է գրեք ձեր սեփական սցենարներն ու գործիքները: Ադմինիստրատորի վահանակը թույլ է տալիս միայն մեկ դաշտում փոքր փոփոխություններ կատարել և չունի ներմուծման/արտահանման հնարավորություններ:

Նրանք վերցրեցին իրական ժամանակի NoSQL տվյալների բազան և այն վերածեցին դանդաղ ոչ SQL-ի՝ ավտոմատ միացումով և առանձին ոչ JSON սյունակի: GraftQL-ի նման մի բան.

Թեժ Java

Եթե ​​Firestore-ը պետք է ավելի հուսալի և մասշտաբային լիներ, ապա զավեշտականն այն է, որ միջին ծրագրավորողը կհայտնվի ավելի քիչ հուսալի լուծում, քան FireBase-ն ընտրելու դեպքում: Ծրագրաշարի այն տեսակը, որին անհրաժեշտ է Grumpy Database Administrator-ը, պահանջում է ջանք և տաղանդի տրամաչափ, որը պարզապես անիրատեսական է այն տեղը, որտեղ արտադրանքը ենթադրաբար լավ է: Սա նման է նրան, թե ինչպես HTML5 Canvas-ը ընդհանրապես չի փոխարինում Flash-ին, եթե չկան զարգացման գործիքներ և նվագարկիչ: Ավելին, Firestore-ը խրված է տվյալների մաքրության և ստերիլ վավերացման ցանկության մեջ, որը պարզապես չի համընկնում միջին բիզնես օգտագործողի հետ: սիրում է աշխատելՆրա համար ամեն ինչ կամայական է, քանի որ մինչև վերջ ամեն ինչ նախագիծ է։

FireBase-ի հիմնական թերությունն այն է, որ հաճախորդը ստեղծվել է իր ժամանակից մի քանի տարի շուտ, մինչ վեբ ծրագրավորողների մեծամասնությունը գիտեր անփոփոխության մասին: Դրա պատճառով FireBase-ը ենթադրում է, որ դուք կփոխեք տվյալները և, հետևաբար, չի օգտվում օգտվողի կողմից տրամադրված անփոփոխությունից: Բացի այդ, այն չի վերօգտագործում օգտագործողին փոխանցվող լուսանկարների տվյալները, ինչը շատ ավելի դժվար է դարձնում տարբերությունը: Խոշոր փաստաթղթերի համար դրա փոփոխական տարբերության վրա հիմնված գործարքների մեխանիզմը պարզապես անբավարար է: Տղերք, մենք արդեն ունենք WeakMap JavaScript-ում: Հարմարավետ է։

Եթե ​​տվյալներին տալիս եք ցանկալի ձևը և ծառերը չափազանց ծավալուն չեն դարձնում, ապա այս խնդիրը կարելի է շրջանցել: Բայց ինձ հետաքրքիր է, արդյոք FireBase-ը շատ ավելի հետաքրքիր կլիներ, եթե մշակողները թողարկեին իսկապես լավ հաճախորդի API, որն օգտագործեր անփոփոխելիությունը տվյալների բազայի ձևավորման վերաբերյալ որոշ լուրջ գործնական խորհուրդների հետ: Փոխարենը, թվում էր, թե փորձում էին շտկել այն, ինչը չէր կոտրվել, և դա ավելի վատացրեց:

Ես չգիտեմ Firestore-ի ստեղծման ողջ տրամաբանությունը: Սև արկղի ներսում առաջացող դրդապատճառների մասին ենթադրությունները նույնպես զվարճանքի մի մասն են: Երկու չափազանց նման, բայց անհամեմատելի տվյալների բազաների այս համադրումը բավականին հազվադեպ է: Կարծես ինչ-որ մեկը մտածեր. «Firebase-ը պարզապես գործառույթ է, որը մենք կարող ենք ընդօրինակել Google Cloud-ում»:, բայց դեռ չի հայտնաբերել իրական աշխարհի պահանջները բացահայտելու կամ այդ բոլոր պահանջներին համապատասխանող օգտակար լուծումներ ստեղծելու հայեցակարգը: «Թող մշակողները մտածեն այդ մասին: Պարզապես գեղեցիկ դարձրեք UI-ը... Կարո՞ղ եք ավելի շատ կրակ ավելացնել»:

Ես հասկանում եմ մի քանի բան տվյալների կառուցվածքների մասին: Ես միանշանակ տեսնում եմ «ամեն ինչ մեկ մեծ JSON ծառի մեջ» հասկացությունը որպես տվյալների բազայից լայնածավալ կառուցվածքի ցանկացած զգացում վերացականելու փորձ: Ակնկալել, որ ծրագրաշարը պարզապես կարող է հաղթահարել ցանկացած կասկածելի տվյալների կառուցվածքի ֆրակտալ, պարզապես խելագար է: Ես նույնիսկ չպետք է պատկերացնեմ, թե ինչ վատ բաներ կարող են լինել, ես կոշտ կոդի աուդիտ եմ արել և Ես տեսա բաներ, որոնց մասին դուք երբեք չէիք երազում. Բայց ես նաև գիտեմ, թե ինչ տեսք ունեն լավ կառույցները, ինչպես օգտագործել դրանք и ինչու դա պետք է արվի. Ես կարող եմ պատկերացնել մի աշխարհ, որտեղ Firestore-ը տրամաբանական կթվա, և այն մարդիկ, ովքեր ստեղծել են այն, կկարծեն, որ իրենք լավ աշխատանք են կատարել: Բայց մենք այս աշխարհում չենք ապրում։

FireBase-ի հարցումների աջակցությունը ցածր է ցանկացած ստանդարտով և գործնականում գոյություն չունի: Այն միանշանակ բարելավման կամ գոնե վերանայման կարիք ունի: Բայց Firestore-ը շատ ավելի լավը չէ, քանի որ այն սահմանափակված է նույն միաչափ ինդեքսներով, որոնք հայտնաբերված են պարզ SQL-ում: Եթե ​​Ձեզ անհրաժեշտ են հարցումներ, որոնք մարդիկ առաջադրում են քաոսային տվյալների վրա, ձեզ անհրաժեշտ է ամբողջական տեքստի որոնում, բազմաբնույթ ֆիլտրեր և օգտագործողի կողմից սահմանված պատվերներ: Ավելի ուշադիր ուսումնասիրելուց հետո պարզ SQL-ի գործառույթները ինքնուրույն չափազանց սահմանափակ են: Բացի այդ, միակ SQL հարցումները, որոնք մարդիկ կարող են առաջադրել արտադրության մեջ, արագ հարցումներն են: Ձեզ անհրաժեշտ կլինի անհատականացված ինդեքսավորման լուծում՝ տվյալների խելացի կառուցվածքներով: Մնացած ամեն ինչի համար պետք է լինի գոնե աստիճանական քարտեզի կրճատում կամ նման բան:

Եթե ​​այս մասին տեղեկություններ փնտրեք Google Փաստաթղթերում, հուսով ենք, որ ձեզ կցուցադրեն BigTable-ի և BigQuery-ի նման մի բան: Այնուամենայնիվ, այս բոլոր լուծումներն ուղեկցվում են կորպորատիվ վաճառքի այնքան խիտ ժարգոնով, որ դուք արագ կվերադառնաք և կսկսեք այլ բան փնտրել:

Վերջին բանը, որ դուք ցանկանում եք իրական ժամանակի տվյալների բազայում, այն է, որը պատրաստված է կառավարման վճարային սանդղակով աշխատող մարդկանց կողմից և նրանց համար:

(*) Սա կատակ է, նման բան չկա 100% JSON համատեղելի.

Գովազդի իրավունքների մասին

Փնտրել VDS վրիպազերծման նախագծերի համար, սերվեր մշակման և հոսթինգի համար: Դուք հաստատ մեր հաճախորդն եք 🙂 Տարբեր կոնֆիգուրացիաների սերվերների օրական գները, հակա-DDoS և Windows լիցենզիաներն արդեն ներառված են գնի մեջ։

Source: www.habr.com