Kjo bazë të dhënash është në flakë…

Më lejoni të tregoj një histori teknike.

Shumë vite më parë, unë zhvillova një aplikacion me funksione bashkëpunimi të integruara. Ishte një eksperiment i përshtatshëm, në të cilin u shfrytëzua potenciali i plotë i React të hershëm dhe CouchDB. Ai sinkronizonte të dhënat në kohë reale përmes JSON. OT. Ai u përdor në punën e brendshme të kompanisë, megjithatë aplikueshmëria e gjerë dhe potenciali në fusha të tjera ishin të dukshme.

Duke u përpjekur të shesim këtë teknologji klientëve potencialë, u përballëm me një pengesë të papritur. Në videon demonstruese, teknologjia jonë dukej dhe funksiononte shkëlqyeshëm, nuk kishte asnjë problem këtu. Video tregon atë që funksionon, dhe nuk kishte asgjë të imituar. Ne shpikëm dhe koduam një skenar realist të aplikimit të programit.


Faktikisht, kjo u bë problemi. Demo jonë funksionoi pikërisht siç e imitonte punën e aplikacioneve të tjera. Në veçanti, informacioni përsohej menjëherë nga A në B, edhe nëse ishin skedarë të mëdhenj media. Pasi kyçeshin, çdo përdorues shihte shënime të reja. Me aplikacionin, përdorues të ndryshëm mund të punonin së bashku në projekte të njëjta, madje edhe në rast se kishte ndërprerje të lidhjes së internetit diku në fshat. Në mënyrë të nënkuptuar, diçka e tillë nënkuptohej në çdo video të prerë në After Effects për produktin.

Pavarësisht se të gjithë dinin për çfarë shërben butoni Refresh, askush nuk kuptonte se aplikacionet web që na kërkonin të zhvillonim, zakonisht ishin të ndjeshme ndaj kufizimeve të tyre. Dhe se nëse ata nuk do të ishin më të nevojshëm, përvoja e përdoruesit do të ishte krejt ndryshe. Në përgjithësi, ata vërejnë se ishte e mundur të "bisedonin", duke lënë shënime për biseduesit, prandaj pyetën se çfarë e dallonte këtë nga, për shembull, Slack. Uf-f-f!

Dizajni i sinkronizimeve të përditshme

Nëse keni përvojë në zhvillimin e softuerit, ndjenja që duhet të kujtoni se shumica e njerëzve nuk mund të shikojnë thjesht një imazh të ndërfaqes dhe të kuptojnë se çfarë do të bëjë kur të ndërveprojnë me të, duhet t'ju nervozojë. Për të mos përmendur se çfarë ndodh brenda programit të vetë. Dija se mund të ndodhi - është në një masë të madhe rezultat i njohurisë se çfarë nuk mund të ndodhë dhe çfarë nuk duhet të ndodhë. Për këtë nevojitet modeli mendor jo vetëm i asaj që bënë softueri, por edhe i mënyrës se si janë të koordinuara dhe komunikojnë mes tyre pjesët e tij të veçanta.

Një shembull klasik i kësaj është përdoruesi, i cili, për njëzet minuta, shikon në spinner.gif, duke menduar kur do të përfundojë puna. Zhvilluesi do të kuptonte se procesi, me siguri, është ngrirë dhe se gif-i kurrë nuk do të largohet nga ekrani. Kjo animacion imiton procesin e punës, por nuk është e lidhur me gjendjen e saj. Në raste të tilla, disa teknikë kanë tendencë të rrokullisen sytë, duke u habitur nga shkalla e keqkuptimit të përdoruesve. Por vëreni, kush prej tyre tregon për orët duke thënë se ato në të vërtetë qëndrojnë pa lëvizur?

Kjo është thelbi i vlerës së kohës reale. Sot, bazat e të dhënave në kohë reale përdoren ende shumë pak, dhe shumë njerëz iu qasen atyre me dyshime. Shumica e këtyre bazave të të dhënave tendencojnë aktivisht në stilin NoSQL, prandaj zakonisht përdoren zgjidhje të bazuara në Mongo, për të cilat është më mirë të harrohen. Sidoqoftë, për mua kjo do të thotë ngushëllim në punën me CouchDB, si dhe studimi i projektimit të strukturave që do të jenë në gjendje të mbushen me të dhëna jo vetëm nga ndonjë burokrat. Mendoj që po e shpenzoj kohën time më mirë.

Por temi i vërtetë i kësaj postimi është ajo që unë përdor sot. Jo me zgjedhjen time, por për shkak të politikës korporative të aplikuar me indiferencë dhe verbëri. Prandaj, do të jap një Krahasim Tepër të Drejtë dhe Të Paanshëm të dy produkteve të ngushta të lidhura me punën me bazat e të dhënave në kohë reale të Google.

Në emrat e të dyve ka fjalën Fire. Njëra më rikujton me dashuri. Tjetra për mua është një lloj tjetër zjarri. Nuk kam ngut të them emrat e tyre, sepse sa herë që ta bëj këtë, ne do të përballemi me problemin e parë të madh - emrat.

Një e para quhet Firebase Real-Time Database, ndërsa e dyta - Firebase Cloud Firestore. Të dy janë produkte nga Firebase suite Google. API-të e tyre quhen, përkatësisht, firebase.database(…) dhe firebase.firestore(…).

Kjo ndodhi sepse Real-Time Database është thjesht origjinali Firebase para blerjes së tij nga Google në vitin 2014. Pastaj në Google vendosën të krijojnë një produkt të paralel, një kopje Firebase është një platformë e bazuar në të dhëna të mëdha, dhe e quajtën Firestore me një cloud. Shpresoj që ende nuk jeni ngatërruar. Nëse jeni ngatërruar, mos u shqetësoni, unë e kam ridizajnuar këtë pjesë të artikullit dhjetë herë.

Sepse nevojitet të sqaroni Firebase në lidhje me Firebase, dhe Firestore në lidhje me Firebase, të paktën për t'ju kuptuar disa vite më parë në Stack Overflow.

Nëse do të ekzistonte një çmim për emërtimin më të keq të produkteve softuerike, ky rast padyshim do të ishte një nga pretendentët. Distanca Hamming midis këtyre emrave është aq e vogël, sa ndërlikon madje inxhinierët e përvojës, të cilët shkruajnë një emër, megjithëse mendja e tyre mendon për një tjetër. Këto janë plane që kanë dështuar me disfatë, të menduara me qëllime të mira; ata realizuan profeci për atë se si baza e të dhënave do të ishte në flakë. Dhe nuk po bëj shaka. Njeriu që krijoi një skemë emërtimi të tillë ka shkaktuar gjak, djersë dhe lot.

Fitorja e Pirros

Mund të mendoni se Firestore është një zëvendësim i Firebase, pasardhësi i tij i gjeneratës së ardhshme, por do të ishte një iluzion. Firestore padyshim nuk është i përshtatshëm për të qenë një zëvendësim i Firebase. Duket se dikush e ka hequr nga ai gjithçka interesante dhe një pjesë të madhe të mbetur ka ngatërruar në mënyra të ndryshme.

Megjithatë, një shikim i shpejtë në të dy produktet mund t'ju ngatërrojë: duket se ato bëjnë të njëjtën gjë, përmes API-ve kryesisht të njëjtë dhe madje në të njëjtën seancë të të dhënave. Dallimet janë të pakta dhe zbulohet vetëm gjatë studimeve të kujdesshme të dokumentacionit të gjerë. Ose kur përpiqeni të portoni kodin që punon perfekt me Firebase në mënyrë që të funksionojë me Firestore. Në atë moment, kuptoni se ndërfaqja e bazës së të dhënave ndizet sa herë që përpiqeni të kryeni tërheqjen e miut në kohë reale. Po e përsëris, nuk bëj shaka.

Klienti Firebase është i sjellshëm në kuptimin që ai buferon ndryshimet dhe realizon automatikisht përsëritjen e përpjekjeve për përditësim, ku prioriteti i jepet operacionit të fundit të shkrimit. Megjithatë, Firestore ka një kufizim prej 1 operacioni shkrimi për dokument për përdorues në sekondë, dhe ky kufizim vendoset nga serveri. Kur punoni me të, ju duhet të gjeni vetë një mënyrë për ta anashkaluar atë dhe të implementoni një kufizues të frekuencës së përditësimeve, edhe kur thjesht po përpiqeni të krijoni aplikacionin tuaj. Kjo do të thotë se Firestore është një bazë të dhënash në kohë reale pa një klient të kohës reale, i cili maskohet si i tillë përmes API-së.

Në këtë pikë, ne fillojmë të shohim shenjat e para të domethënies së ekzistencës së Firestore. Ndoshta po gaboj, por dyshoj se dikush nga drejtuesit e lartë të Google ka parë pas blerjes në Firebase dhe thjesht ka thënë: “Jo, o Zot, jo. Kjo është e papranueshme. Vetëm jo nën drejtimin tim”.

Ai doli nga selia e tij dhe shpalli:

“Një dokument të madh JSON? Jo. Ju do të ndani të dhënat në dokumente të veçanta, çdo një prej të cilave do të ketë një madhësi jo më shumë se 1 megabajt.”

Duket se një kufizim i tillë nuk do ta përballojë përballjen e parë me një bazë përdoruesish mjaft të motivuar. E dini se kështu është. Në punën tonë, për shembull, kemi më shumë se një mijë e pesëqind prezantime, dhe kjo është Plotësisht Normale.

Me një kufizim të tillë, do të jeni të detyruar të pranoni faktin se një “dokument” në bazën e të dhënave nuk do të ngjajë me asnjë objekt që përdoruesi mund ta quajë dokument.

“Mënyrat e skenarëve që mund të përmbajnë recursively elemente të tjera? Jo. Ato do të përmbajnë vetëm objekte ose numra me gjatësi fikse, ashtu siç e është menduar nga Zoti.”

Prandaj, nëse shpresonit të vendosni GeoJSON tuaj në Firestore, do të zbuloni se kjo nuk është e mundur. Nuk lejohet asgjë njëdimensionale. Shpresoj se ju pëlqen Base64 dhe/ose JSON brenda JSON.

“Import dhe eksport JSON përmes HTTP, mjete linje komande ose panel administratori? Jo. Ju do të mund të eksportoni dhe importoni vetëm të dhëna në Google Cloud Storage. Kështu, duket se quhet tani. Dhe kur them ‘ju’, po flas vetëm për ata që kanë autorizimin e Pronarit të Projektit. Të tjerët mund të shkojnë dhe të krijojnë bileta.”

Si e shihni, modeli i të dhënave FireBase është lehtësisht i përshkrueshëm. Ai përmban një dokument të madh JSON që lidh çelësat JSON me rrugët URL. Nëse regjistroni duke HTTP PUT në / FireBase si më poshtë:

{
  "hello": "world"
}

Atëherë GET /hello do të kthejë "world". Në thelb, kjo funksionon pikërisht siç e prisni. Klllka e objekteve FireBase /my-collection/:id është ekuivalente me një fjalor JSON {"my-collection": {...}} në rrënjë, përmbajtja e së cilës është e disponueshme në /my-collection:

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

Kjo funksionon shkëlqyeshëm nëse çdo insertim ka ID pa kolizione, për të cilën sistemi ka një zgjidhje standarde.

Me fjalë të tjera, databaza është 100% e përputhshme me JSON (*) dhe funksionon shkëlqyeshëm me HTTP, si me CouchDB. Por kryesisht e përdorni atë përmes API-së në kohë reale, e cila abstrakton websockets, autorizimin dhe abonimet. Paneli i administratorit ka të dyja mundësitë, duke lejuar redaktimin në kohë reale dhe importimin/exportimin e JSON. Nëse në kodin tuaj qëndroni të njëjtin parim, do të habiteni sa shumë kod të specializuar do të humbasë, kur të kuptoni se patch dhe diff JSON lejojnë të zgjidhni 90% të detyrave rutinë për trajtimin e gjendjes së qëndrueshme.

Modeli i të dhënave Firestore është i ngjashëm me JSON, por ndryshon nga ai në disa aspekte kritike. E përmenda tashmë mungesën e masivave brenda masivave. Modeli i sub-collections është që ato të jenë koncepte të klasës së parë, të ndara nga dokumenti JSON që i përmban. Meqë për këtë nuk ka një serializim të gatshëm, për marrjen dhe shkrimin e të dhënave kërkohet një rrugë e specializuar për ekzekutimin e kodit. Për të trajtuar koleksionet tuaja duhet të shkruani skriptet dhe mjetet tuaja. Paneli i administratorit ju lejon të bëni vetëm ndryshime të vogla në një fushë në një kohë dhe nuk ka mundësi importimi/exportimi.

Ata morën databazën NoSQL në kohë reale dhe e shndërruan atë në një SQL të ngadaltë me auto-ndërfutje dhe një kolonë të veçantë jo-JSON. Diçka në frymën e GraftQL.

Java e nxehtë

Nëse Firestore do të duhej të bëhej më e besueshme dhe e shkallëzueshme, ironia është se zhvilluesi mesatar do të marrë një zgjidhje më pak të besueshme sesa duke zgjedhur FireBase "nga kutia". Softueri që i nevojitet një Administratori të Ankesave të Bazave të Dhënash kërkon një nivel të tillë përpjekjeje dhe specialistësh që është thjesht nerealist për nişën, në të cilën, në mënyrë të supozuar, duhet të ketë një produkt të mirë. Kjo duket si të thuash se HTML5 Canvas nuk është zëvendësim për Flash, nëse nuk ka mjete zhvillimi dhe player. Për më tepër, Firestore është mbërthyer në përpjekjet e tij për pastërtinë e të dhënave dhe validimin steril, që thjesht nuk i përshtatet asaj që përdoruesi mesatar i biznesit e do të punojë: për të, gjithçka është opsionale, sepse deri në fund të fundit gjithçka është një skicë.

Mungesa kryesore e FireBase është se klienti u krijua disa vite përpara afatit të tij, edhe para se shumica e zhvilluesve të uebit të merrnin vesh rreth imutabilitetit. Si rezultat, FireBase supozon se do të ndryshoni të dhënat, prandaj nuk shfrytëzon avantazhet e imutabilitetit të siguruar nga përdoruesi. Për më tepër, ai nuk përdor të dhënat sërish në snapshotet e dërguara përdoruesit, duke e bërë shumë më të vështirë kryerjen e diferencave. Për dokumente të mëdha, mekanizmi i saj i transaksioneve të bazuara në diferencat e ndryshueshme është thjesht i paafshe për të, WeakMap në JavaScript. Kjo është e dobishme.

Nëse i jepni të dhënave formën e duhur dhe nuk e bëni pemën shumë të madhe, atëherë kjo problem mund të shmanget. Por më kuriozitet, do të ishte FireBase më interesante nëse zhvilluesit do të publikojnë një API klienti të vërtetë të mirë, që përdor imutabilitetin së bashku me këshilla të rëndësishme praktike për strukturën e bazave të dhënash. Në vend të kësaj ata, duket se përpiqen të rregullojnë atë që nuk është e prishur, dhe nga kjo bëhet më keq.

Nuk e di të gjithë logjikën që qëndronte pas krijimit të Firestore. Racionalizimet për motivet që lindin brenda një katërcaku të zi janë gjithashtu pjesë e argëtimit. Ky përballim i dy bazave të dhënash jashtëzakonisht të ngjashme, por të pa krahasueshme, ndodh mjaft rrallë. Sikur dikush të kishte menduar: "Firebase është thjesht një funksion që mund ta emulojmë në Google Cloud", por kjo, ende nuk e ka hapur për vete konceptin e përcaktimit të kërkesave të botës reale ose krijimit të zgjidhjeve të dobishme që plotësojnë të gjitha këto kërkesa. «Le të mendojnë për këtë zhvilluesit. Thjesht bëni UI-in të bukur... A mund të shtoni më shumë zjarr?»

Unë kuptoj disa gjëra rreth strukturave të të dhënave. E shoh qartë se koncepti i «gjithçkaje në një pemë të madhe JSON» është një përpjekje për të abstraktuar nga baza e të dhënave çdo ndjenjë të strukturës në shkallë të gjerë. Të presësh që softueri të përballojë çdo fraktal të dyshimtë të strukturës së të dhënave — është thjesht çmenduri. Nuk kam nevojë ta imagjinoj sa keq mund të jetë, kam kryer auditime të ashpra të kodit dhe kam parë gjëra që ju, njerëzit, nuk i keni parë as në ëndrrat tuaja.. Por unë gjithashtu e di se si duken strukturat e mira, si t'i përdorim ato, dhe pse kjo duhet të bëhet.. Mund ta imagjinoj një botë ku Firestore do të dukej krejtësisht logjike, dhe ata që e krijuan atë do ta shikonin se kishin bërë një punë të mirë. Por ne nuk jetojmë në këtë botë.

Mbështetja për ndërtimin e kërkesave në FireBase është e dobët sipas çdo standardi, pothuajse nuk ekziston. Ajo definitivisht kërkon përmirësim ose të paktën një rishikim. Por Firestore nuk është shumë më mirë, pasi është e kufizuar nga të njëjtat indekse një-dimensional si në SQL të thjeshtë. Nëse ju nevojiten kërkesa që njerëzit i kryejnë me të dhëna kaotike, atëherë kërkohet një kërkim me tekste të plota, filtrat në disa intervale dhe një renditje të rastësishme nga përdoruesi. Duke e shqyrtuar me kujdes, funksionet e SQL të thjeshta janë vetë shumë të kufizuara. Përveç kësaj, SQL-të e vetme që njerëzit mund të kryejnë në prodhim janë kërkesat e shpejta. Ju do të keni nevojë për një zgjidhje të specializuar për indeksim me struktura të mirëpërcaktuara të të dhënave. Për gjithçka tjetër, të paktën duhet të ketë një map-reduce incremental ose diçka të ngjashme.

Nëse kërkoni informacion për këtë në dokumentet e Google, shpresoj se do t'ju tregojnë drejt diçkaje si BigTable dhe BigQuery. Megjithatë, të gjitha këto zgjidhje shoqërohen me një volum të tillë të zhargonit të shitjeve korporative, saqë shpejt do të ktheheni mbrapsht dhe do të filloni të kërkoni diçka tjetër.

E fundit që ju nevojitet në rastin e një baze të dhënash në kohë reale — është diçka e krijuar nga njerëz dhe për njerëz që punojnë sipas një shkalle pagash për udhëheqjen.

(*) Kjo është një shaka, nuk ekziston një koncept si përputhshmëria me JSON 100%.

Me lejen e reklamës

Jeni duke kërkuar VDS për debugimin e projekteve, server për zhvillim dhe hostim? Ju jeni klienti ynë 🙂 Tarifimi ditor për serverë me konfiguracione të ndryshme, antiDDoS dhe licencat Windows përfshihen në çmim.

Burimi: habr.com