Naj povem eno tehnično zgodbo.
Pred mnogimi leti sem razvijal aplikacijo z vgrajenimi funkcijami za sodelovanje. To je bil uporabniku prijazen eksperimentalni sklad, ki je izkoristil ves potencial zgodnjih React in CouchDB. Podatke je sinhroniziral v realnem času prek JSON . Uporabljali so ga interno v podjetju, vendar sta bila jasna njegova široka uporabnost in potencial na drugih področjih.
Ko smo poskušali to tehnologijo prodati potencialnim strankam, smo naleteli na nepričakovano oviro. V predstavitvenem videu je bila naša tehnologija videti in je delovala odlično, brez težav. Video je natančno pokazal, kako deluje, in ni posnemal ničesar. Izmislili in zakodirali smo realen scenarij uporabe programa.
Pravzaprav je to postal problem. Naš demo je deloval točno tako, kot so vsi drugi simulirali svoje aplikacije. Natančneje, informacije so bile takoj prenesene iz A v B, tudi če so bile velike medijske datoteke. Po prijavi je vsak uporabnik videl nove vnose. Z uporabo aplikacije so lahko različni uporabniki jasno sodelovali na istih projektih, tudi če je bila internetna povezava prekinjena nekje v vasi. To je implicitno implicirano v vsakem video izrezu izdelka v After Effects.
Čeprav so vsi vedeli, čemu je namenjen gumb Osveži, nihče ni zares razumel, da so bile spletne aplikacije, ki so jih zahtevali od nas, običajno podvržene njihovim lastnim omejitvam. In da bo, če jih ne bomo več potrebovali, uporabniška izkušnja povsem drugačna. Večinoma so opazili, da lahko »klepetajo« tako, da sogovornikom puščajo zapiske, zato so se spraševali, kako se to razlikuje od na primer Slacka. Fuj!
Oblikovanje vsakodnevnih sinhronizacij
Če imate izkušnje z razvojem programske opreme, vam mora biti živce parajoče, če se spomnite, da večina ljudi ne more samo pogledati slike vmesnika in razumeti, kaj bo naredil, ko bo z njim komuniciral. Da ne omenjam dogajanja znotraj samega programa. Spoznanje, da lahko dogajanje je v veliki meri posledica zavedanja, kaj se ne more zgoditi in kaj se ne bi smelo zgoditi. To zahteva ne samo, kaj počne programska oprema, ampak tudi, kako so njeni posamezni deli usklajeni in komunicirajo med seboj.
Klasičen primer tega je uporabnik, ki strmi v spinner.gif, se sprašuje, kdaj bodo dela končno končana. Razvijalec bi ugotovil, da se je postopek verjetno zataknil in da gif ne bo nikoli izginil z zaslona. Ta animacija simulira izvajanje opravila, vendar ni povezana z njegovim stanjem. V takih primerih nekateri tehniki radi zavijajo z očmi, presenečeni nad obsegom zmede uporabnikov. Vendar opazite, koliko jih pokaže na vrtečo se uro in reče, da dejansko miruje?
To je bistvo vrednosti v realnem času. Dandanes se baze podatkov v realnem času še vedno zelo malo uporabljajo in mnogi ljudje nanje gledajo s sumom. Večina teh baz podatkov se močno nagiba k slogu NoSQL, zato običajno uporabljajo rešitve, ki temeljijo na Mongu, na katere je najbolje pozabiti. Vendar zame to pomeni, da se naučim udobno delati s CouchDB, pa tudi naučiti se oblikovati strukture, ki jih lahko napolni s podatki več kot le kakšen birokrat. Mislim, da bolje izkoriščam svoj čas.
Toda prava tema te objave je tisto, kar uporabljam danes. Ne po lastni izbiri, ampak zaradi brezbrižno in slepo vodenih korporativnih politik. Zato bom zagotovil popolnoma pošteno in nepristransko primerjavo dveh tesno povezanih Googlovih produktov zbirke podatkov v realnem času.
Oba imata v imenu besedo Ogenj. Ene stvari se rada spominjam. Druga stvar zame je drugačna vrsta ognja. Ne mudi se mi povedati njihova imena, ker ko enkrat to storim, bomo naleteli na prvo veliko težavo: imena.
Prvi se imenuje Zbirka podatkov Firebase v realnem časuin drugič - Firebase Cloud Firestore. Oba sta izdelka iz Komplet Firebase Google. Njihovi API-ji se imenujejo oz firebase.database(…) и firebase.firestore(…).
To se je zgodilo zaradi Baza podatkov v realnem času - to je samo original Firebase pred nakupom s strani Googla leta 2014. Potem se je Google odločil ustvariti kot vzporedni izdelek kopirati Firebase temelji na velikem podatkovnem podjetju in ga imenuje Firestore z oblakom. Upam, da še niste zmedeni. Če ste še vedno zmedeni, ne skrbite, sam sem ta del članka prepisal desetkrat.
Ker morate navesti Firebase v vprašanju Firebase in Ognjišče v vprašanju o Firebase, vsaj da bi razumeli pred nekaj leti na Stack Overflow.
Če bi obstajala nagrada za najslabšo izkušnjo poimenovanja programske opreme, bi bil to zagotovo eden od kandidatov. Hammingova razdalja med temi imeni je tako majhna, da zmede celo izkušene inženirje, katerih prsti tipkajo eno ime, njihova glava pa razmišlja o drugem. To so dobronamerni načrti, ki klavrno propadejo; izpolnili so prerokbo, da bo baza podatkov gorela. In sploh se ne hecam. Oseba, ki se je domislila te sheme poimenovanja, je povzročila kri, znoj in solze.
Pirova zmaga
Človek bi mislil, da je Firestore zamenjava Firebase, njegov naslednik naslednje generacije, vendar bi bilo to zavajajoče. Ni zagotovljeno, da bo Firestore primerna zamenjava za Firebase. Videti je, kot da je nekdo iz njega izrezal vse zanimivo, večino ostalih pa na različne načine zamešal.
Vendar pa vas lahko hiter pogled na oba izdelka zmede: zdi se, da delata isto stvar, prek v bistvu istih API-jev in celo v isti seji zbirke podatkov. Razlike so subtilne in jih razkrije šele natančna primerjalna študija obsežne dokumentacije. Ali ko poskušate prenesti kodo, ki popolnoma deluje na Firebase, tako da deluje s Firestore. Že takrat ugotovite, da vmesnik baze podatkov zasveti takoj, ko poskusite povleči in spustiti z miško v realnem času. Ponavljam, ne hecam se.
Odjemalec Firebase je vljuden v smislu, da shrani spremembe v medpomnilnik in samodejno znova poskusi posodobitve, ki dajejo prednost zadnji operaciji pisanja. Vendar ima Firestore omejitev 1 operacije pisanja na dokument na uporabnika na sekundo in to omejitev uveljavlja strežnik. Ko delate z njim, morate sami najti način, kako ga zaobiti in implementirati omejevalnik hitrosti posodabljanja, tudi ko samo poskušate zgraditi svojo aplikacijo. To pomeni, da je Firestore baza podatkov v realnem času brez odjemalca v realnem času, ki se pretvarja, da uporablja API.
Tukaj začnemo videti prve znake raison d'être Firestore. Morda se motim, vendar sumim, da je nekdo na visokem položaju v vodstvu Googla po nakupu pogledal Firebase in preprosto rekel: »Ne, o moj bog, ne. To je nesprejemljivo. Samo ne pod mojim vodstvom."
Pojavil se je iz svojih prostorov in izjavil:
»En velik dokument JSON? št. Podatke boste razdelili v ločene dokumente, od katerih vsak ne bo večji od 1 megabajta.«
Zdi se, da takšna omejitev ne bo preživela prvega srečanja s kakšno dovolj motivirano bazo uporabnikov. Veš, da je. V službi imamo na primer več kot tisoč in pol predstavitev in to je povsem normalno.
S to omejitvijo boste prisiljeni sprejeti dejstvo, da en "dokument" v bazi podatkov ne bo podoben nobenemu predmetu, ki bi ga uporabnik lahko imenoval dokument.
"Matrike nizov, ki lahko rekurzivno vsebujejo druge elemente? št. Matrike bodo vsebovale samo predmete ali številke fiksne dolžine, kot je Bog nameraval."
Torej, če ste upali, da boste GeoJSON postavili v svojo Firestore, boste ugotovili, da to ni mogoče. Nič neenodimenzionalnega ni sprejemljivo. Upam, da vam je všeč Base64 in/ali JSON znotraj JSON.
»Uvoz in izvoz JSON prek HTTP, orodij ukazne vrstice ali skrbniške plošče? št. Podatke boste lahko izvažali in uvažali samo v Google Cloud Storage. Tako se zdaj imenuje, mislim. In ko rečem "vi", se obrnem samo na tiste, ki imajo poverilnice lastnika projekta. Vsi ostali lahko ustvarijo vstopnice."
Kot lahko vidite, je podatkovni model FireBase enostavno opisati. Vsebuje en ogromen dokument JSON, ki povezuje ključe JSON s potmi URL. Če pišete z HTTP PUT в / FireBase je sledeče:
{
"hello": "world"
}
Thats GET /hello se bo vrnil "world". V bistvu deluje točno tako, kot bi pričakovali. Zbirka objektov FireBase /my-collection/:id enakovreden slovarju JSON {"my-collection": {...}} v korenu, katerega vsebina je dostopna v /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}To deluje dobro, če ima vsak vložek ID brez kolizij, za kar ima sistem standardno rešitev.
Z drugimi besedami, zbirka podatkov je 100 % združljiva z JSON(*) in odlično deluje s HTTP, kot je CouchDB. Toda v bistvu ga uporabljate prek API-ja v realnem času, ki abstrahira spletne vtičnice, avtorizacijo in naročnine. Skrbniška plošča ima obe zmožnosti, omogoča tako urejanje v realnem času kot uvoz/izvoz JSON. Če storite enako v svoji kodi, boste presenečeni nad tem, koliko specializirane kode bo izgubljene, ko ugotovite, da popravek in diff JSON rešita 90 % rutinskih nalog obravnave trajnega stanja.
Podatkovni model Firestore je podoben JSON, vendar se razlikuje v nekaterih kritičnih pogledih. Omenil sem že pomanjkanje nizov znotraj nizov. Model za podzbirke je, da so prvorazredni koncepti, ločeni od dokumenta JSON, ki jih vsebuje. Ker za to ni pripravljene serializacije, je za pridobivanje in zapisovanje podatkov potrebna posebna kodna pot. Za obdelavo lastnih zbirk morate napisati lastne skripte in orodja. Skrbniška plošča vam omogoča samo majhne spremembe enega polja naenkrat in nima možnosti uvoza/izvoza.
Vzeli so bazo podatkov NoSQL v realnem času in jo spremenili v počasno bazo brez SQL s samodejnim združevanjem in ločenim stolpcem, ki ni JSON. Nekaj takega kot GraftQL.
Vroča Java
Če naj bi bil Firestore bolj zanesljiv in razširljiv, potem je ironija, da bo povprečen razvijalec na koncu dobil manj zanesljivo rešitev kot takojšnjo izbiro FireBase. Vrsta programske opreme, ki jo potrebuje Grumpy Database Administrator, zahteva raven truda in kaliber talenta, ki je preprosto nerealno za nišo, v kateri naj bi bil izdelek dober. To je podobno kot HTML5 Canvas sploh ni nadomestilo za Flash, če ni razvojnih orodij in predvajalnika. Poleg tega je Firestore ujet v željo po čistosti podatkov in sterilni validaciji, ki preprosto ni v skladu s tem, kako povprečni poslovni uporabnik rad dela: zanj je vse neobvezno, saj je do konca vse osnutek.
Glavna pomanjkljivost FireBase je, da je bil odjemalec ustvarjen nekaj let pred svojim časom, preden je večina spletnih razvijalcev vedela za nespremenljivost. Zaradi tega FireBase predpostavlja, da boste spremenili podatke, in zato ne izkorišča nespremenljivosti, ki jo zagotovi uporabnik. Poleg tega ne uporabi znova podatkov v posnetkih, ki jih posreduje uporabniku, zaradi česar je diff veliko težji. Za velike dokumente je njegov spremenljivi transakcijski mehanizem, ki temelji na razlikah, preprosto neustrezen. Fantje, že imamo WeakMap v JavaScriptu. Udobno je.
Če podatkom daste želeno obliko in drevesa ne naredite preveč obsežna, se lahko tej težavi izognete. Vendar me zanima, ali bi bil FireBase veliko bolj zanimiv, če bi razvijalci izdali res dober odjemalski API, ki bi uporabljal nespremenljivost v kombinaciji z nekaj resnimi praktičnimi nasveti o načrtovanju baze podatkov. Namesto tega se je zdelo, da poskušajo popraviti tisto, kar ni bilo pokvarjeno, in to je stanje poslabšalo.
Ne poznam vse logike v ozadju nastanka Firestore. Del zabave je tudi ugibanje o motivih, ki se porajajo v črni skrinjici. Ta jukstapozicija dveh izjemno podobnih, a neprimerljivih baz podatkov je precej redka. Kot da je nekdo mislil: "Firebase je le funkcija, ki jo lahko posnemamo v Google Cloudu", vendar še ni odkril koncepta prepoznavanja zahtev iz resničnega sveta ali ustvarjanja uporabnih rešitev, ki izpolnjujejo vse te zahteve. »Naj razvijalci razmislijo o tem. Samo naredite uporabniški vmesnik lep ... Lahko dodate več ognja?«
Razumem nekaj stvari o podatkovnih strukturah. Vsekakor vidim koncept "vse v enem velikem drevesu JSON" kot poskus abstrahiranja kakršnega koli občutka strukture velikega obsega iz baze podatkov. Pričakovati, da se bo programska oprema preprosto spopadla s katerim koli dvomljivim fraktalom strukture podatkov, je preprosto noro. Sploh si ni treba predstavljati, kako slabe bi lahko bile stvari, opravil sem stroge revizije kode in Videl sem stvari, o katerih se vam niti sanjalo ni. Vem pa tudi, kako izgledajo dobre strukture, и . Lahko si predstavljam svet, v katerem bi se Firestore zdel logičen in bi ljudje, ki so ga ustvarili, mislili, da so dobro opravili svoje delo. Ampak mi ne živimo v tem svetu.
Podpora za poizvedbe FireBase je po vseh standardih slaba in je praktično ni. Vsekakor potrebuje izboljšave ali vsaj popravke. Toda Firestore ni veliko boljši, ker je omejen na iste enodimenzionalne indekse, ki jih najdemo v navadnem SQL. Če potrebujete poizvedbe, ki jih ljudje izvajajo na kaotičnih podatkih, potrebujete iskanje po celotnem besedilu, filtre z več razponi in vrstni red po meri, ki ga določi uporabnik. Po natančnejšem pregledu so funkcije navadnega SQL preveč omejene same po sebi. Poleg tega so edine poizvedbe SQL, ki jih lahko izvajajo v proizvodnji, hitre poizvedbe. Potrebovali boste rešitev za indeksiranje po meri s premišljeno strukturo podatkov. Za vse ostalo bi moralo obstajati vsaj incremental map-reduce ali kaj podobnega.
Če iščete informacije o tem v Google Dokumentih, upajmo, da boste usmerjeni v nekaj, kot sta BigTable in BigQuery. Vse te rešitve pa spremlja toliko zgoščenega korporativnega prodajnega žargona, da se boste hitro obrnili nazaj in začeli iskati nekaj drugega.
Zadnja stvar, ki si jo želite pri podatkovni bazi v realnem času, je nekaj, kar so naredili ljudje na vodstvenih plačilnih lestvicah in zanje.
(*) To je šala, tega ni .
O pravicah oglaševanja
Iskati za razhroščevanje projektov, strežnik za razvoj in gostovanje? Zagotovo ste naša stranka 🙂 Dnevne cene za strežnike različnih konfiguracij, anti-DDoS in Windows licence so že vključene v ceno.
Vir: www.habr.com