Leiskite papasakoti techninę istoriją.
Prieš daugelį metų kūriau programą su įmontuotomis bendradarbiavimo funkcijomis. Tai buvo vartotojui patogus eksperimentinis paketas, kuriame buvo išnaudotas visas ankstyvųjų React ir CouchDB potencialas. Jis sinchronizavo duomenis realiuoju laiku per JSON . Jis buvo naudojamas įmonės viduje, tačiau jos platus pritaikymas ir potencialas kitose srityse buvo aiškus.
Bandydami parduoti šią technologiją potencialiems klientams, susidūrėme su netikėta kliūtimi. Demonstraciniame vaizdo įraše mūsų technologija atrodė ir veikė puikiai, jokių problemų nebuvo. Vaizdo įrašas tiksliai parodė, kaip tai veikia, ir nieko nemėgdžiojo. Sugalvojome ir užkodavome realų programos naudojimo scenarijų.
Tiesą sakant, tai tapo problema. Mūsų demonstracinė versija veikė tiksliai taip, kaip visi kiti modeliavo savo programas. Tiksliau, informacija buvo akimirksniu perkelta iš A į B, net jei tai buvo dideli daugialypės terpės failai. Prisijungęs kiekvienas vartotojas pamatė naujus įrašus. Naudodamiesi programa, skirtingi vartotojai galėtų aiškiai dirbti kartu su tais pačiais projektais, net jei interneto ryšys nutrūktų kažkur kaime. Tai netiesiogiai numanoma bet kuriame „After Effects“ iškirptame produkto vaizdo įraše.
Nors visi žinojo, kam skirtas mygtukas Atnaujinti, niekas iš tikrųjų nesuprato, kad žiniatinklio programoms, kurias jie paprašė sukurti, paprastai taikomi savo apribojimai. Ir kad jei jų nebereikės, vartotojo patirtis bus visiškai kitokia. Jie dažniausiai pastebėdavo, kad gali „pakalbėti“ palikdami užrašus žmonėms, su kuriais kalbasi, todėl domėjosi, kuo tai skiriasi nuo, pavyzdžiui, „Slack“. Fu!
Kasdienio sinchronizavimo dizainas
Jei turite programinės įrangos kūrimo patirties, reikia prisiminti, kad dauguma žmonių negali tiesiog pažvelgti į sąsajos paveikslėlį ir suprasti, ką ji veiks, kai su ja sąveikauja. Jau nekalbant apie tai, kas vyksta pačioje programoje. Žinojimas, kad galima įvykti daugiausia yra žinojimo, kas negali atsitikti ir kas neturėtų atsitikti, rezultatas. Tai reikalauja ne tik tai, ką daro programinė įranga, bet ir kaip atskiros jos dalys derinamos ir bendrauja tarpusavyje.
Klasikinis to pavyzdys yra vartotojas, žiūrintis į a verpėjas.gif, įdomu, kada pagaliau darbai bus baigti. Kūrėjas būtų suvokęs, kad procesas greičiausiai įstrigo ir gif niekada nedings iš ekrano. Ši animacija imituoja darbo atlikimą, bet nesusijusi su jo būsena. Tokiais atvejais kai kurie technikos specialistai mėgsta pavartyti akis, stebisi vartotojų painiavos mastu. Tačiau atkreipkite dėmesį, kiek iš jų rodo į besisukantį laikrodį ir sako, kad jis iš tikrųjų stovi?
Tai yra realaus laiko vertės esmė. Šiomis dienomis realaus laiko duomenų bazės vis dar labai mažai naudojamos ir daugelis žmonių į jas žiūri įtariai. Dauguma šių duomenų bazių yra linkusios į NoSQL stilių, todėl jos dažniausiai naudoja Mongo pagrindu sukurtus sprendimus, kuriuos geriausia pamiršti. Tačiau man tai reiškia, kad reikia patogiai dirbti su CouchDB, taip pat išmokti kurti struktūras, kurias ne tik biurokratas gali užpildyti duomenimis. Manau, kad geriau išnaudoju savo laiką.
Tačiau tikroji šio įrašo tema yra tai, ką aš naudoju šiandien. Ne dėl pasirinkimo, o dėl abejingai ir aklai taikomos įmonių politikos. Taigi pateiksiu visiškai teisingą ir nešališką dviejų glaudžiai susijusių „Google“ duomenų bazių produktų palyginimą realiuoju laiku.
Abiejų pavadinimuose yra žodis Ugnis. Vieną dalyką prisimenu su meile. Antras dalykas man yra kitokio tipo ugnis. Neskubu sakyti jų vardų, nes kai tai padarysiu, susidursime su pirmąja didele problema – vardais.
Pirmasis vadinamas „Firebase“ realiojo laiko duomenų bazėir antra - Firebase Cloud Firestore. Abu jie yra produktai iš Firebase komplektas Google. Jų API vadinamos atitinkamai firebase.database(…) и firebase.firestore(…).
Taip atsitiko todėl, Realaus laiko duomenų bazė - Tai tik originalas "Firebase" prieš jį įsigijant „Google“ 2014 m. Tada „Google“ nusprendė sukurti kaip paralelinį produktą kopija „Firebase“, pagrįsta didelių duomenų įmone, ir pavadino ją „Firestore“ su debesimi. Tikiuosi dar nesusipainiojai. Jei vis dar esate pasimetę, nesijaudinkite, aš pats perrašiau šią straipsnio dalį dešimt kartų.
Nes reikia nurodyti "Firebase" „Firebase“ klausime ir Firestore į klausimą apie „Firebase“, bent jau tam, kad suprastumėte prieš kelerius metus „Stack Overflow“.
Jei būtų apdovanotas už prasčiausią programinės įrangos įvardijimo patirtį, tai tikrai būtų vienas iš pretendentų. Hamingo atstumas tarp šių pavadinimų yra toks mažas, kad supainioja net patyrusius inžinierius, kurių pirštai rašo vieną vardą, o galva galvoja apie kitą. Tai gerų ketinimų planai, kurie apgailėtinai žlunga; jie išpildė pranašystę, kad duomenų bazė užsidegs. Ir aš visai nejuokauju. Asmuo, sugalvojęs šią įvardijimo schemą, sukėlė kraujo, prakaito ir ašarų.
Piro pergalė
Galima manyti, kad „Firestore“ yra pakeitimas „Firebase“, jos naujos kartos palikuonis, tačiau tai būtų klaidinanti. Negarantuojama, kad „Firestore“ bus tinkamas „Firebase“ pakaitalas. Panašu, kad kažkas iš jo išpjovė viską, kas įdomu, o daugumą likusiųjų įvairiais būdais supainiojo.
Tačiau greitas žvilgsnis į du produktus gali jus suklaidinti: atrodo, kad jie daro tą patį, per iš esmės tas pačias API ir netgi toje pačioje duomenų bazės sesijoje. Skirtumai yra subtilūs ir atskleidžiami tik kruopščiai palyginus išsamią dokumentaciją. Arba kai bandote perkelti kodą, kuris puikiai veikia Firebase, kad jis veiktų su Firestore. Net tada jūs sužinosite, kad duomenų bazės sąsaja užsidega, kai tik bandote vilkti ir nuleisti pele realiuoju laiku. Pasikartosiu, aš nejuokauju.
„Firebase“ klientas yra mandagus ta prasme, kad jis saugo pakeitimus ir automatiškai bando atnaujinti naujinimus, kurie teikia pirmenybę paskutinei rašymo operacijai. Tačiau „Firestore“ riboja 1 įrašymo operaciją vienam dokumentui vienam vartotojui per sekundę, ir šį apribojimą nustato serveris. Dirbdami su juo, jūs turite rasti būdą, kaip jį apeiti ir įdiegti naujinimo greičio ribotuvą, net kai tik bandote kurti programą. Tai reiškia, kad „Firestore“ yra realaus laiko duomenų bazė be realaus laiko kliento, kuris maskuojasi kaip naudojant API.
Čia pradedame matyti pirmuosius Firestore raison d'être požymius. Galiu klysti, bet įtariu, kad kažkas iš aukšto Google vadovybės po pirkimo pažvelgė į Firebase ir tiesiog pasakė: „Ne, Dieve, ne. Tai nepriimtina. Tik ne man vadovaujant“.
Jis pasirodė iš savo kambarių ir pareiškė:
„Vienas didelis JSON dokumentas? Nr. Duomenis išskaidysite į atskirus dokumentus, kurių kiekvienas bus ne didesnis kaip 1 megabaitas.
Atrodo, kad toks apribojimas neišgyvens pirmą kartą susidūrus su pakankamai motyvuota vartotojų baze. Žinai, kad taip. Pavyzdžiui, darbe turime daugiau nei pusantro tūkstančio pristatymų, ir tai yra visiškai normalu.
Turėdami šį apribojimą, būsite priversti susitaikyti su tuo, kad vienas „dokumentas“ duomenų bazėje nebus panašus į jokį objektą, kurį vartotojas galėtų pavadinti dokumentu.
„Masyvai, kuriuose gali rekursyviai būti kitų elementų? Nr. Masyvuose bus tik fiksuoto ilgio objektai arba skaičiai, kaip Dievas numatė.
Taigi, jei tikėjotės įdėti GeoJSON į savo Firestore, pamatysite, kad tai neįmanoma. Nieko nevienodo nėra priimtina. Tikiuosi, kad jums patinka Base64 ir (arba) JSON JSON.
„JSON importavimas ir eksportavimas naudojant HTTP, komandinės eilutės įrankius arba administratoriaus skydelį? Nr. Galėsite tik eksportuoti ir importuoti duomenis į „Google Cloud Storage“. Taip, manau, dabar vadinasi. Ir kai sakau „tu“, kreipiuosi tik į tuos, kurie turi projekto savininko kredencialus. Visi kiti gali eiti ir kurti bilietus“.
Kaip matote, „FireBase“ duomenų modelį lengva apibūdinti. Jame yra vienas didžiulis JSON dokumentas, susiejantis JSON raktus su URL keliais. Jei rašote su HTTP PUT в / „FireBase“ yra tokia:
{
"hello": "world"
}
The GET /hello grįš "world". Iš esmės tai veikia tiksliai taip, kaip tikitės. FireBase objektų kolekcija /my-collection/:id atitinka JSON žodyną {"my-collection": {...}} šaknyje, kurios turinys pasiekiamas /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Tai veikia gerai, jei kiekvienas įdėklas turi be susidūrimo ID, kuriam sistema turi standartinį sprendimą.
Kitaip tariant, duomenų bazė yra 100 % JSON(*) suderinama ir puikiai veikia su HTTP, pvz., CouchDB. Tačiau iš esmės jūs jį naudojate per realiojo laiko API, kuri ištraukia žiniatinklio lizdus, autorizaciją ir prenumeratas. Administratoriaus skydelis turi abi galimybes, leidžiančias redaguoti realiuoju laiku ir importuoti / eksportuoti JSON. Jei tą patį padarysite savo kode, nustebsite, kiek specializuoto kodo bus iššvaistoma, kai suprasite, kad pataisų ir skirtumų JSON išsprendžia 90% įprastų nuolatinės būsenos tvarkymo užduočių.
„Firestore“ duomenų modelis yra panašus į JSON, tačiau skiriasi kai kuriais svarbiais būdais. Jau minėjau, kad masyvuose trūksta masyvų. Subrinkinių modelis turi būti pirmos klasės sąvokos, atskirtos nuo JSON dokumento, kuriame jos yra. Kadangi tam nėra paruošto serializavimo, duomenims gauti ir įrašyti reikalingas specializuotas kodo kelias. Norėdami apdoroti savo kolekcijas, turite parašyti savo scenarijus ir įrankius. Administratoriaus skydelis leidžia atlikti nedidelius pakeitimus tik po vieną lauką ir neturi importavimo / eksportavimo galimybių.
Jie paėmė realaus laiko NoSQL duomenų bazę ir pavertė ją lėta ne SQL su automatiniu prisijungimu ir atskiru ne JSON stulpeliu. Kažkas panašaus į GraftQL.
Karšta Java
Jei „Firestore“ turėtų būti patikimesnis ir keičiamo dydžio, ironija ta, kad vidutinis kūrėjas suras mažiau patikimą sprendimą nei „FireBase“ pasirinkimas. Tokiai programinei įrangai, kurios reikia Grumpy duomenų bazės administratoriui, reikia pastangų ir talento, kuris yra tiesiog nerealus nišoje, kurioje produktas turėtų būti geras. Tai panašu į tai, kad HTML5 Canvas visiškai nepakeičia Flash, jei nėra kūrimo įrankių ir grotuvo. Be to, „Firestore“ yra įklimpęs į duomenų grynumo ir sterilaus patvirtinimo troškimą, kuris tiesiog neatitinka paprasto verslo vartotojo. mėgsta dirbti: jam viskas neprivaloma, nes iki pat pabaigos viskas yra juodraštis.
Pagrindinis „FireBase“ trūkumas yra tas, kad klientas buvo sukurtas keleriais metais anksčiau, nei dauguma žiniatinklio kūrėjų sužinojo apie nekintamumą. Dėl šios priežasties „FireBase“ daro prielaidą, kad pakeisite duomenis, todėl nesinaudoja vartotojo teikiamu nekintamumu. Be to, jis pakartotinai nenaudoja momentinių nuotraukų duomenų, kuriuos perduoda vartotojui, o tai apsunkina skirtumą. Dideliems dokumentams jo kintamu skirtumu pagrįstas operacijų mechanizmas yra tiesiog netinkamas. Vaikinai, mes jau turime WeakMap JavaScript. Tai patogu.
Jei duomenims suteiksite norimą formą ir nepadarysite medžių per dideli, šią problemą galima išvengti. Tačiau man įdomu, ar „FireBase“ būtų daug įdomesnė, jei kūrėjai išleistų tikrai gerą kliento API, naudojančią nekintamumą kartu su rimtais praktiniais patarimais dėl duomenų bazės kūrimo. Atrodė, kad jie bandė pataisyti tai, kas nebuvo sugedusi, ir tai pablogino situaciją.
Nežinau visos „Firestore“ kūrimo logikos. Spėliojimas apie motyvus, kylančius juodosios dėžės viduje, taip pat yra linksmybių dalis. Šis dviejų itin panašių, bet nepalyginamų duomenų bazių sugretinimas yra gana retas. Tai tarsi kažkas pagalvojo: „Firebase“ yra tik funkcija, kurią galime imituoti „Google Cloud“, tačiau dar neatrado realaus pasaulio reikalavimų nustatymo ar naudingų sprendimų, atitinkančių visus tuos reikalavimus, koncepcijos. „Tegul kūrėjai galvoja apie tai. Tiesiog padarykite vartotojo sąsają gražią... Ar galite pridėti daugiau ugnies?
Suprantu keletą dalykų apie duomenų struktūras. Aš neabejotinai vertinu sąvoką „viskas viename dideliame JSON medyje“ kaip bandymą iš duomenų bazės ištraukti bet kokį didelio masto struktūros pojūtį. Tikėtis, kad programinė įranga tiesiog susidoros su bet kokiu abejotinu duomenų struktūros fraktalu, yra tiesiog beprotiška. Aš net neturiu įsivaizduoti, kaip viskas gali būti blogai, aš atlikau griežtą kodo auditą ir Mačiau dalykų, apie kuriuos jūs, žmonės, niekada nesvajojote. Bet aš taip pat žinau, kaip atrodo geros struktūros, и . Įsivaizduoju pasaulį, kuriame „Firestore“ atrodytų logiška, o ją sukūrę žmonės manytų, kad atliko gerą darbą. Bet mes gyvename ne šiame pasaulyje.
Pagal bet kokius standartus „FireBase“ užklausų palaikymas yra prastas ir jo praktiškai nėra. Jį tikrai reikia tobulinti ar bent jau peržiūrėti. Tačiau „Firestore“ nėra daug geresnė, nes ji apsiriboja tais pačiais vienmačiais indeksais, esančiais paprastame SQL. Jei jums reikia užklausų, kurias žmonės vykdo pagal chaotiškus duomenis, jums reikia viso teksto paieškos, kelių diapazonų filtrų ir pasirinktinio vartotojo nustatyto užsakymo. Atidžiau pažvelgus, paprasto SQL funkcijos yra per daug ribotos. Be to, vienintelės SQL užklausos, kurias žmonės gali vykdyti gamyboje, yra greitosios užklausos. Jums reikės pasirinktinio indeksavimo sprendimo su apgalvotomis duomenų struktūromis. Dėl viso kito turėtų būti bent jau laipsniškas žemėlapio mažinimas ar kažkas panašaus.
Jei ieškosite informacijos apie tai „Google“ dokumentuose, tikimės, kad būsite nukreipti į kažką panašaus į „BigTable“ ir „BigQuery“. Tačiau visus šiuos sprendimus lydi tiek tankaus įmonių pardavimų žargono, kad greitai atsigręžsite ir pradėsite ieškoti kažko kito.
Paskutinis dalykas, kurio jums reikia naudojant realaus laiko duomenų bazę, yra kažkas, ką sukūrė vadovų darbo užmokesčio skalėje esantys žmonės.
(*) Tai pokštas, tokio dalyko kaip nėra .
Dėl reklamos teisių
Ieškoti derinimo projektams, serveris plėtrai ir prieglobai? Jūs neabejotinai esate mūsų klientas 🙂 Įvairių konfigūracijų serverių, anti-DDoS ir Windows licencijų dienos įkainiai jau įskaičiuoti į kainą.
Šaltinis: www.habr.com