Kjo bazë të dhënash është në zjarr...

Më lejoni të tregoj një histori teknike.

Shumë vite më parë, po zhvilloja një aplikacion me veçori bashkëpunimi të integruara në të. Ishte një pirg eksperimental miqësor për përdoruesit që përfitoi nga potenciali i plotë i React dhe CouchDB të hershëm. Ai sinkronizonte të dhënat në kohë reale përmes JSON OT. Ai u përdor brenda kompanisë, por zbatueshmëria dhe potenciali i tij i gjerë në fusha të tjera ishte i qartë.

Gjatë përpjekjes për t'ia shitur këtë teknologji klientëve të mundshëm, hasëm në një pengesë të papritur. Në videon demonstruese, teknologjia jonë dukej dhe funksionoi shkëlqyeshëm, pa asnjë problem. Videoja tregoi saktësisht se si funksionon dhe nuk imitonte asgjë. Ne dolëm me dhe koduam një skenar realist për përdorimin e programit.


Në fakt, ky u bë problemi. Demoja jonë funksionoi pikërisht ashtu si të gjithë të tjerët simuluan aplikacionet e tyre. Në mënyrë të veçantë, informacioni u transferua menjëherë nga A në B, edhe nëse ishin skedarë të mëdhenj mediatikë. Pas hyrjes, çdo përdorues pa hyrje të reja. Duke përdorur aplikacionin, përdorues të ndryshëm mund të punonin së bashku qartësisht në të njëjtat projekte, edhe nëse lidhja me internetin ndërpritet diku në fshat. Kjo nënkuptohet në mënyrë implicite në çdo video të produktit të prerë në After Effects.

Edhe pse të gjithë e dinin se për çfarë shërbente butoni Refresh, askush nuk e kuptoi vërtet se aplikacionet në internet që ata na kërkuan të ndërtonim zakonisht i nënshtroheshin kufizimeve të tyre. Dhe se nëse nuk nevojiten më, përvoja e përdoruesit do të jetë krejtësisht e ndryshme. Ata kryesisht vunë re se mund të "bisedonin" duke lënë shënime për njerëzit me të cilët po flisnin, kështu që pyesnin veten se si ndryshonte kjo, për shembull, Slack. Eh!

Dizajni i sinkronizimeve të përditshme

Nëse keni përvojë në zhvillimin e softuerit, duhet të jetë nervoz të mbani mend se shumica e njerëzve nuk mund të shikojnë thjesht një foto të një ndërfaqeje dhe të kuptojnë se çfarë do të bëjë kur ndërveprojnë me të. Për të mos përmendur atë që ndodh brenda vetë programit. Dije se mund të ndodhë është kryesisht rezultat i njohjes së asaj që nuk mund të ndodhë dhe çfarë nuk duhet të ndodhë. Kjo kërkon model mendor jo vetëm atë që bën softveri, por edhe mënyrën se si pjesët e tij individuale koordinohen dhe komunikojnë me njëra-tjetrën.

Një shembull klasik i kësaj është një përdorues që shikon në a spinner.gif, duke menduar se kur do të përfundojë puna më në fund. Zhvilluesi do ta kishte kuptuar se procesi me siguri kishte ngecur dhe se gif-i nuk do të zhdukej kurrë nga ekrani. Ky animacion simulon ekzekutimin e një pune, por nuk lidhet me gjendjen e saj. Në raste të tilla, disa teknikë pëlqejnë të rrotullojnë sytë, të habitur nga shkalla e konfuzionit të përdoruesit. Megjithatë, vini re se sa prej tyre tregojnë drejt orës rrotulluese dhe thonë se ajo është në të vërtetë e palëvizshme?

Ky është thelbi i vlerës në kohë reale. Këto ditë, bazat e të dhënave në kohë reale janë ende shumë pak të përdorura dhe shumë njerëz i shohin ato me dyshim. Shumica e këtyre bazave të të dhënave anojnë shumë drejt stilit NoSQL, kjo është arsyeja pse ato zakonisht përdorin zgjidhje të bazuara në Mongo, të cilat harrohen më së miri. Megjithatë, për mua kjo do të thotë të ndihem rehat duke punuar me CouchDB, si dhe të mësosh të dizenjosh struktura që më shumë sesa thjesht një burokrat mund t'i mbushë me të dhëna. Mendoj se po e shfrytëzoj më mirë kohën time.

Por tema e vërtetë e këtij postimi është ajo që po përdor sot. Jo me zgjedhje, por për shkak të politikave të korporatave të zbatuara në mënyrë indiferente dhe verbërisht. Kështu që unë do të siguroj një krahasim plotësisht të drejtë dhe të paanshëm të dy produkteve të lidhura ngushtë të bazës së të dhënave të Google në kohë reale.

Të dy kanë fjalën Zjarr në emrat e tyre. Një gjë e mbaj mend me dashuri. Gjëja e dytë për mua është një lloj tjetër zjarri. Nuk nxitoj t'i them emrat, sepse sapo t'i them, do të hasim në problemin e parë të madh: emrat.

I pari quhet Baza e të dhënave në kohë reale të Firebase, dhe e dyta - Firebase Cloud Firestore. Të dyja janë produkte nga Komplet Firebase Google. API-të e tyre quhen përkatësisht firebase.database(…) и firebase.firestore(…).

Kjo ndodhi sepse Baza e të dhënave në kohë reale - është thjesht origjinali Firebase përpara blerjes së tij nga Google në 2014. Pastaj Google vendosi të krijojë si një produkt paralel kopjoj Firebase bazohet në kompaninë e të dhënave të mëdha dhe e quajti atë Firestore me një re. Shpresoj të mos jeni ngatërruar akoma. Nëse jeni akoma konfuz, mos u shqetësoni, unë vetë e rishkrova këtë pjesë të artikullit dhjetë herë.

Sepse ju duhet të tregoni Firebase në pyetjen Firebase, dhe Zjarrfikës në një pyetje rreth Firebase, të paktën për t'ju bërë të kuptoni disa vite më parë në Stack Overflow.

Nëse do të kishte një çmim për përvojën më të keqe të emërtimit të softuerit, ky do të ishte padyshim një nga pretendentët. Distanca Hamming midis këtyre emrave është aq e vogël sa që ngatërron edhe inxhinierët me përvojë, gishtat e të cilëve shkruajnë një emër ndërsa kokat e tyre mendojnë për një tjetër. Këto janë plane me qëllime të mira që dështojnë keq; ata përmbushën profecinë se baza e të dhënave do të ishte në zjarr. Dhe nuk po bëj shaka fare. Personi që doli me këtë skemë emërtimi shkaktoi gjak, djersë dhe lot.

Fitorja e Pirros

Dikush do të mendonte se Firestor është zëvendësim Firebase, pasardhësi i gjeneratës së ardhshme, por kjo do të ishte mashtruese. Firestore nuk është e garantuar të jetë një zëvendësues i përshtatshëm për Firebase. Duket sikur dikush ka hequr çdo gjë interesante prej saj dhe ka ngatërruar shumicën e pjesës tjetër në mënyra të ndryshme.

Sidoqoftë, një vështrim i shpejtë në të dy produktet mund t'ju ngatërrojë: ata duket se bëjnë të njëjtën gjë, në thelb të njëjtat API dhe madje në të njëjtën seancë të bazës së të dhënave. Dallimet janë delikate dhe zbulohen vetëm nga studimi i kujdesshëm krahasues i dokumentacionit të gjerë. Ose kur po përpiqeni të portoni kodin që funksionon në mënyrë perfekte në Firebase në mënyrë që të funksionojë me Firestore. Edhe atëherë zbuloni se ndërfaqja e bazës së të dhënave ndizet sapo përpiqeni të zvarritni dhe lëshoni me miun në kohë reale. E përsëris, nuk po bëj shaka.

Klienti Firebase është i sjellshëm në kuptimin që i ruan ndryshimet dhe riprovon automatikisht përditësimet që i japin përparësi operacionit të fundit të shkrimit. Megjithatë, Firestore ka një kufi prej 1 operacioni shkrimi për dokument për përdorues në sekondë, dhe ky kufi zbatohet nga serveri. Kur punoni me të, ju takon juve të gjeni një rrugëdalje dhe të zbatoni një kufizues të shpejtësisë së përditësimit, edhe kur thjesht po përpiqeni të ndërtoni aplikacionin tuaj. Kjo do të thotë, Firestore është një bazë të dhënash në kohë reale pa një klient në kohë reale, e cila maskohet si një duke përdorur një API.

Këtu fillojmë të shohim shenjat e para të arsyes së ekzistencës së Firestore. Mund të jem i gabuar, por dyshoj se dikush i lartë në menaxhmentin e Google shikoi Firebase pas blerjes dhe thjesht tha: "Jo, oh zot, jo. Kjo është e papranueshme. Thjesht jo nën udhëheqjen time”.

Ai doli nga dhoma e tij dhe tha:

“Një dokument i madh JSON? Nr. Ju do t'i ndani të dhënat në dokumente të veçanta, secila prej të cilave nuk do të jetë më shumë se 1 megabajt në madhësi."

Duket se një kufizim i tillë nuk do t'i mbijetojë takimit të parë me ndonjë bazë përdoruesi mjaft të motivuar. Ti e di që është. Në punë, për shembull, kemi më shumë se një mijë e gjysmë prezantime, dhe kjo është krejtësisht normale.

Me këtë kufizim, do të detyroheni të pranoni faktin se një "dokument" në bazën e të dhënave nuk do t'i ngjajë asnjë objekti që një përdorues mund ta quajë dokument.

"Rreth vargjesh që mund të përmbajnë elementë të tjerë në mënyrë rekursive? Nr. Vargjet do të përmbajnë vetëm objekte ose numra me gjatësi fikse, siç synoi Perëndia."

Pra, nëse shpresonit të vendosni GeoJSON në Firestore tuaj, do të zbuloni se kjo nuk është e mundur. Asgjë jo njëdimensionale nuk është e pranueshme. Shpresoj t'ju pëlqejë Base64 dhe/ose JSON brenda JSON.

“Importimi dhe eksportimi i JSON përmes HTTP, mjeteve të linjës së komandës apo panelit të administratorit? Nr. Ju do të jeni në gjendje të eksportoni dhe importoni të dhëna vetëm në Google Cloud Storage. Kështu quhet tani, mendoj. Dhe kur them "ti", po u drejtohem vetëm atyre që kanë kredencialet e pronarit të projektit. Të gjithë të tjerët mund të shkojnë dhe të krijojnë bileta”.

Siç mund ta shihni, modeli i të dhënave FireBase është i lehtë për t'u përshkruar. Ai përmban një dokument të madh JSON që lidh çelësat JSON me shtigjet e URL-së. Nëse shkruani me HTTP PUT в / FireBase është si më poshtë:

{
  "hello": "world"
}

atëherë GET /hello do te kthehen "world". Në thelb funksionon pikërisht ashtu siç prisni. Koleksioni i objekteve FireBase /my-collection/:id 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 mirë nëse çdo futje ka një ID pa përplasje, për të cilën sistemi ka një zgjidhje standarde.

Me fjalë të tjera, baza e të dhënave është 100% e pajtueshme me JSON(*) dhe funksionon shkëlqyeshëm me HTTP, siç është CouchDB. Por në thelb ju e përdorni atë përmes një API në kohë reale që abstrakton bazat e internetit, autorizimin dhe abonimet. Paneli i administratorit ka të dyja aftësitë, duke lejuar si redaktimin në kohë reale ashtu edhe importin/eksportin e JSON. Nëse bëni të njëjtën gjë në kodin tuaj, do të habiteni se sa kod i specializuar do të harxhohet kur të kuptoni se patch dhe diff JSON zgjidh 90% të detyrave rutinë të trajtimit të gjendjes së vazhdueshme.

Modeli i të dhënave Firestore është i ngjashëm me JSON, por ndryshon në disa mënyra kritike. Unë përmenda tashmë mungesën e vargjeve brenda vargjeve. Modeli për nën-koleksionet është që ato të jenë koncepte të klasit të parë, të ndara nga dokumenti JSON që i përmban. Meqenëse nuk ka serizim të gatshëm për këtë, kërkohet një shteg kodi i specializuar për të marrë dhe shkruar të dhëna. Për të përpunuar koleksionet tuaja, duhet të shkruani skriptet dhe mjetet tuaja. Paneli i administratorit ju lejon të bëni ndryshime të vogla vetëm një fushë në një kohë dhe nuk ka aftësi importi/eksporti.

Ata morën një bazë të dhënash NoSQL në kohë reale dhe e kthyen atë në një të ngadaltë jo-SQL me bashkim automatik dhe një kolonë të veçantë jo-JSON. Diçka si GraftQL.

Java e nxehtë

Nëse Firestore supozohej të ishte më i besueshëm dhe më i shkallëzueshëm, atëherë ironia është se zhvilluesi mesatar do të përfundojë me një zgjidhje më pak të besueshme sesa zgjedhja e FireBase jashtë kutisë. Lloji i softuerit për të cilin ka nevojë Administratori i bazës së të dhënave Grumpy kërkon një nivel përpjekjeje dhe kalibër talenti që është thjesht jorealist për vendin ku produkti supozohet të jetë i mirë. Kjo është e ngjashme me mënyrën se si HTML5 Canvas nuk është aspak një zëvendësim për Flash nëse nuk ka mjete zhvillimi dhe një lojtar. Për më tepër, Firestore është zhytur në një dëshirë për pastërti të të dhënave dhe vërtetim steril që thjesht nuk përputhet me mënyrën se si përdoruesi mesatar i biznesit i pëlqen të punojë: për të gjithçka është fakultative, sepse deri në fund gjithçka është një draft.

Disavantazhi kryesor i FireBase është se klienti u krijua disa vite përpara kohës së tij, përpara se shumica e zhvilluesve të uebit të dinin për pandryshueshmërinë. Për shkak të kësaj, FireBase supozon se ju do të ndryshoni të dhënat dhe për këtë arsye nuk përfiton nga pandryshueshmëria e ofruar nga përdoruesi. Për më tepër, ai nuk i ripërdor të dhënat në fotografitë që i kalon përdoruesit, gjë që e bën dallimin shumë më të vështirë. Për dokumente të mëdha, mekanizmi i tij i ndryshueshëm i transaksioneve i bazuar në ndryshime është thjesht i pamjaftueshëm. Djema, ne tashmë e kemi WeakMap në JavaScript. Është komode.

Nëse i jepni të dhënave formën e dëshiruar dhe nuk i bëni pemët shumë voluminoze, atëherë ky problem mund të anashkalohet. Por jam kurioz nëse FireBase do të ishte shumë më interesant nëse zhvilluesit lëshonin një API vërtet të mirë të klientit që përdor pandryshueshmërinë e kombinuar me disa këshilla praktike serioze për hartimin e bazës së të dhënave. Në vend të kësaj, ata dukej se përpiqeshin të rregullonin atë që nuk ishte prishur, dhe kjo e përkeqësoi atë.

Nuk e di të gjithë logjikën pas krijimit të Firestore. Spekulimi për motivet që lindin brenda kutisë së zezë është gjithashtu pjesë e argëtimit. Ky ballafaqim i dy bazave të të dhënave jashtëzakonisht të ngjashme por të pakrahasueshme është mjaft i rrallë. Është sikur dikush të mendonte: "Firebase është vetëm një funksion që ne mund ta imitojmë në Google Cloud", por nuk e ka zbuluar ende konceptin e identifikimit të kërkesave të botës reale ose krijimit të zgjidhjeve të dobishme që plotësojnë të gjitha këto kërkesa. “Lërini zhvilluesit të mendojnë për këtë. Thjesht bëjeni të bukur UI... A mund të shtoni më shumë zjarr?”

Unë kuptoj disa gjëra në lidhje me strukturat e të dhënave. Unë definitivisht e shoh konceptin "gjithçka në një pemë të madhe JSON" si një përpjekje për të abstraguar çdo kuptim të strukturës në shkallë të gjerë nga baza e të dhënave. Të presësh që softueri thjesht të përballet me çdo fraktal të dyshimtë të strukturës së të dhënave është thjesht i çmendur. Unë as nuk duhet të imagjinoj se sa të këqija mund të jenë gjërat, unë kam bërë auditime rigoroze të kodit dhe Unë pashë gjëra që ju njerëz nuk i keni ëndërruar kurrë. Por unë gjithashtu e di se si duken strukturat e mira, si t'i përdorni ato и pse duhet bërë kjo. Mund ta imagjinoj një botë ku Firestore do të dukej logjike dhe njerëzit që e krijuan do të mendonin se bënë një punë të mirë. Por ne nuk jetojmë në këtë botë.

Mbështetja e pyetjeve të FireBase është e dobët nga çdo standard dhe praktikisht nuk ekziston. Duhet patjetër përmirësim ose të paktën rishikim. Por Firestore nuk është shumë më i mirë sepse është i kufizuar në të njëjtat indekse njëdimensionale që gjenden në SQL të thjeshtë. Nëse keni nevojë për pyetje që njerëzit drejtojnë në të dhëna kaotike, keni nevojë për kërkim me tekst të plotë, filtra me shumë diapazon dhe renditje të personalizuara të përcaktuara nga përdoruesi. Pas një inspektimi më të afërt, funksionet e SQL të thjeshtë janë shumë të kufizuara më vete. Për më tepër, të vetmet pyetje SQL që njerëzit mund të ekzekutojnë në prodhim janë pyetjet e shpejta. Do t'ju duhet një zgjidhje e personalizuar indeksimi me struktura të zgjuara të të dhënave. Për çdo gjë tjetër, të paktën duhet të ketë reduktim në rritje të hartës ose diçka të ngjashme.

Nëse kërkoni informacion në lidhje me këtë në Dokumentet e Google, shpresojmë se do të drejtoheni në drejtimin e diçkaje si BigTable dhe BigQuery. Megjithatë, të gjitha këto zgjidhje shoqërohen me zhargon aq të dendur të shitjeve të korporatave, saqë shpejt do të ktheheni dhe do të filloni të kërkoni diçka tjetër.

Gjëja e fundit që dëshironi me një bazë të dhënash në kohë reale është diçka e krijuar nga dhe për njerëzit në shkallët e pagave të menaxhimit.

(*) Kjo është një shaka, nuk ka gjë të tillë si 100% i pajtueshëm me JSON.

Për të Drejtat e Reklamimit

Duke kërkuar për VDS për korrigjimin e projekteve, një server për zhvillim dhe pritje? Ju jeni padyshim klienti ynë 🙂 Çmimet ditore për serverë të konfigurimeve të ndryshme, licencat anti-DDoS dhe Windows janë tashmë të përfshira në çmim.

Burimi: www.habr.com