Dovoľte mi rozprávať technický príbeh.
Pred mnohými rokmi som vyvíjal aplikáciu so zabudovanými funkciami spolupráce. Bol to praktický experimentálny stack, ktorý využíval plný potenciál raného Reactu a CouchDB. V reálnom čase synchronizoval údaje prostredníctvom JSON. . Používal sa vo vnútornej práci spoločnosti, ale široká použiteľnosť a potenciál v iných oblastiach boli zrejmé.
Keď sme sa snažili predávať túto technológiu potenciálnym klientom, narazili sme na neočakávanú prekážku. V ukážkovom videu naša technológia vyzerala a fungovala skvele, tu neboli žiadne problémy. Video presne ukazovalo, ako to funguje, a nič nebolo simulované. Vymysleli sme a zakódovali realistický scenár použitia programu.
V skutočnosti to bola práve táto vec, ktorá sa stala problémom. Naša ukážka fungovala presne tak, ako simulovali fungovanie svojich aplikácií všetci ostatní. Konkrétne, informácie sa okamžite prenášali z bodu A do bodu B, aj keď išlo o veľké mediálne súbory. Po prihlásení každý používateľ videl nové záznamy. Pomocou aplikácie mohli rôzni používatelia spoločně pracovať jasne na tých istých projektoch, aj v prípade prerušeného pripojenia na Internet niekde na vidieku. Takéto niečo implicitne naznačuje akékoľvek video o produkte zostrihané v After Effects.
Napriek tomu, že všetci vedeli, na čo slúži tlačidlo Obnoviť, nikto úplne nechápal, že webové aplikácie, ktoré nás žiadajú o vytvorenie, sú zvyčajne vystavené svojim obmedzeniam. A že ak už nie sú potrebné, používateľský zážitok bude úplne iný. Väčšinou si všimli, že sa dá 'chatovať', zanechávajúc ostatným poznámky, a tak sa pýtali, čím je to odlišné od Slacku. Uf!
Dizajn každodennej synchronizácie
Ak máte už skúsenosti s vývojom softvéru, mali by vás rozčuľovať potreba pamätať si, že väčšina ľudí nemôže len tak pozrieť na obrázok rozhrania a pochopiť, čo bude robiť pri interakcii s ním. Nehovoriac o tom, čo sa deje vo vnútri samotného programu. Vedieť, čo môže sa stane — je do veľkej miery výsledkom vedomosti o tom, čo sa nemôže stať a čo by sa nemalo stať. Na to je potrebné nielen to, čo softvér robí, ale aj to, ako sú jeho jednotlivé časti vzájomne zladené a komunikujú.
Klasickým príkladom je používateľ, ktorý sa dvadsať minút pozerá na spinner.gif, premýšľajúc, kedy sa práca konečne skončí. Vývojár by pochopil, že proces pravdepodobne zamrzol a že gif nikdy nezmizne zo obrazovky. Táto animácia imituje vykonávanie úlohy, avšak nie je spojená s jej stavom. V takýchto prípadoch niektorí technici radi zdvíhajú obočie, ohromení mierou neporozumenia používateľov. Ale všimnite si, kto z nich ukazuje na točiace sa hodiny a hovorí, že v skutočnosti stojí na mieste?
O to ide v hodnote reálneho času. Dnes sa databázy reálneho času stále veľmi zriedka používajú a mnohí ich považujú za podozrivé. Väčšina týchto databáz sa aktívne prikláňa k štýlu NoSQL, kvôli čomu sa zvyčajne používajú riešenia založené na Mongo, na ktoré by sa malo radšej zabudnúť. Pre mňa to však znamená pohodlie pri práci s CouchDB a tiež štúdium návrhu štruktúr, ktoré budú schopné plniť údaje nielen nejakým byrokratickým pracovníkom. Myslím, že svoj čas investujem efektívnejšie.
Ale pravdivou témou tohto príspevku je to, čo používam dnes. Nie z vlastného výberu, ale kvôli ľahostajne a slepo praktizovanej firemnej politike. Preto poskytnem Úplne Čestné a Nezaujaté porovnanie dvoch tesne súvisiacich produktov na prácu s databázami reálneho času od Google.
V názvoch oboch je slovo Fire. Jeden si pamätám s láskou. Druhý pre mňa predstavuje iný druh ohňa. Nepospechám si s ich názvami, pretože akonáhle to urobím, stretneme sa s prvým veľkým problémom – menami.
Prvý sa nazýva Firebase Real-Time Database, a druhý – Firebase Cloud Firestore. Obe sú produktmi z Firebase suite Google. Ich API sa nazývajú, príslušne, firebase.database(…) a firebase.firestore(…).
Stalo sa to preto, že Real-Time Database – je to jednoducho pôvodný Firebase pred jeho akvizíciou Google v roku 2014. Potom sa v Google rozhodli vytvoriť ako paralelný produkt kópiu Firebase založenú na big data spoločnosti, a nazvali ju Firestore with a cloud. Dúfam, že ste sa ešte nezamotali. Ak sa predsa len zamotali, nebojte sa, sám som túto časť článku prepisoval desaťkrát.
Pretože je potrebné uviesť Firebase v otázke o Firebase, a Firestore v otázke o Firebase, aspoň aby vás pochopili pred niekoľkými rokmi na Stack Overflow.
Keby existovala cena za najhoršie pomenovanie softvérových produktov, tento prípad by určite bol jedným z kandidátov. Hammingova vzdialenosť medzi týmito názvami je tak malá, že mätie aj skúsených inžinierov, ktorých prsty píšu jedno meno, hoci hlava myslí na iné. Tieto plány s veľkým rozčarovaním skrachovali, boli vymyslené s najlepšími úmyslami; naplnili proroctvo, že databáza bude v plameňoch. A vôbec si nerobím žarty. Človek, ktorý vymyslel takúto schému pomenovania, bol príčinou krvi, potu a sĺz.
Pyrrhova víťazstvo
Mohli by ste si myslieť, že Firestore je nahrada Firebase, jeho nástupca ďalšej generácie, ale to by bola omyl. Firestore určite nie je vhodný na to, aby nahradil Firebase. Zdá sa, že niekto z neho vytrhol všetko zaujímavé a väčšinu zostávajúceho zamieňal rôznymi spôsobmi.
Napriek tomu rýchly pohľad na tieto dva produkty môže zmiasť: zdá sa, že robia to isté, cez väčšinou rovnaké API a dokonca v rovnakej databázovej relácii. Rozdiely sú takmer neviditeľné a odkryjú sa iba pri dôkladnom porovnaní rozsiahlej dokumentácie. Alebo keď sa pokúšate portovať perfektne fungujúci kód na Firebase, aby fungoval s Firestore. Už vtedy zistíte, že rozhranie databázy sa zapne, hneď ako sa pokúsite vykonať ťahanie myšou v reálnom čase. Opakujem, nemám žart.
Klient Firebase je zdvorilý v tom zmysle, že vyrovnáva zmeny a vykonáva automatické pokusy o opätovné obnovenie, pričom prioritu dostáva posledná zápisová operácia. Avšak Firestore má obmedzenie na 1 zápisovú operáciu na dokument na používateľa za sekundu, a toto obmedzenie je uvalené serverom. Pri práci s ním sa musíte sami postarať o obchádzanie tohto obmedzenia a implementáciu obmedzovača frekvencie aktualizácií, aj keď len skúšate vytvoriť svoju aplikáciu. To znamená, že Firestore je databáza v reálnom čase bez klienta v reálnom čase, ktorý sa maskuje ako taká pomocou API.
Na tomto miestě začíname vidieť prvé znaky zmyslu existencie Firestore. Možno sa mýlim, ale mám podozrenie, že niekto vysoko v vedení Google sa po kúpe Firebase pozrel a jednoducho povedal: „Nie, bože, nie. To je neprijateľné. Len nie pod mojím vedením.“
Objavil sa zo svojich komnát a vyhlásil:
„Jeden veľký dokument JSON? Nie. Rozdelíte dáta na samostatné dokumenty, každý z nich bude mať maximálnu veľkosť 1 megabajt.“
Zdá sa, že takéto obmedzenie neprežije prvé stretutie s akoukoľvek dostatočne motivovanou používateľskou základňou. Viete, že je to tak. Napríklad v našej práci máme viac ako tisíc päťsto prezentácií a to je úplne normálne.
S takýmto obmedzením sa budete musieť zmieriť s faktom, že jeden „dokument“ v databáze nebude vyzerať ako žiadny objekt, ktorý by používateľ mohol nazvať dokumentom.
„Polia polí, ktoré môžu rekurzívne obsahovať iné prvky? Nie. Polia budú obsahovať iba objekty alebo čísla fixnej dĺžky, ako to zamýšľal Pán.“
Ak ste teda dúfali, že umiestnite do svojej Firestore GeoJSON, objavíte, že je to nemožné. Nedovolí sa nič jednorozmerné. Dúfam, že máte radi Base64 a/alebo JSON v JSON.
„Import a export JSON cez HTTP, nástroje príkazového riadku alebo administračná konzola? Nie. Môžete iba exportovať a importovať dáta do Google Cloud Storage. Tak sa zdá, že sa to teraz nazýva. A keď hovorím 'vy', myslím iba na tých, ktorí majú oprávnenia Project Owner. Ostatní môžu ísť vytvoriť lístok.“
Ako vidíte, model dát FireBase je ľahko opísateľný. Obsahuje jeden obrovský dokument JSON, ktorý spája kľúče JSON s URL cestami. Ak zapíšete pomocou HTTP PUT v / FireBase nasledujúce:
{
"hello": "world"
} Potom GET /hello vráti "world".Vo väčšine to funguje presne tak, ako očakávate. Kolekcia objektov FireBase /my-collection/:id je ekvivalentná slovníku JSON {"my-collection": {...}} v koreňovom adresári, obsah ktorého je dostupný v /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}To funguje skvele, ak má každý vložený záznam ID bez kolízií, na čo má systém štandardné riešenie.
Inými slovami, databáza je 100% kompatibilná s JSON (*) a skvele funguje s HTTP, napríklad s CouchDB. Väčšinou ju však používate prostredníctvom API v reálnom čase, ktoré abstrahuje websockets, autorizáciu a predplatné. Administračná konzola má obe možnosti, čo umožňuje vykonávať úpravy v reálnom čase a importovať/exportovať JSON. Ak sa vo svojom kóde budete držať toho istého, prekvapí vás, aké množstvo špecializovaného kódu zmizne, keď pochopíte, že patch a diff JSON umožňujú vyriešiť 90% rutinných úloh pri správe stálych stavov.
Model dát Firestore je podobný JSON, ale v niektorých kritických aspektoch sa od neho líši. Už som spomínal absenciu polí vo vnútri polí. Model sub-collections spočíva v tom, že sú to koncepty prvej triedy, oddelené od dokumentu JSON, ktorý ich obsahuje. Pretože neexistuje pripravená serializácia, na získanie a zápis dát je potrebný špecializovaný spôsob vykonávania kódu. Na spracovanie vlastných kolekcií je potrebné písať vlastné skripty a nástroje. Administračná konzola vám umožňuje vykonať iba malé zmeny po jednom poli naraz a nemá možnosti importu/exportu.
Vzali databázu NoSQL v reálnom čase a premenili ju na pomalú ne-SQL s automatickým zlúčením a oddeleným stĺpcom ne-JSON. Niečo ako GraftQL.
Hot Java
Ak mal byť Firestore spoľahlivejší a škálovateľnejší, irónia spočíva v tom, že priemerný vývojár získa menej spoľahlivé riešenie ako pri výbere FireBase „z krabice“. Softvér, ktorý potrebuje Mrzutý Administrátor Databázy, si vyžaduje takú úroveň úsilia a kalibrácie odborníkov, že je to jednoducho nerealistické pre oblasť, kde by mal byť dobrý produkt. Je to podobné ako fakt, že HTML5 Canvas nie je náhradou za Flash, ak neexistujú nástroje na vývoj a prehrávač. Navyše, Firestore sa utápa v snahe o čistotu dát a sterilnú validáciu, čo jednoducho nezodpovedá tomu, ako priemerný obchodný používateľ rád pracuje: pre neho nič nemusí byť dokonalé, pretože na konci všetko je len koncept.
Hlavnou nevýhodou FireBase je to, že klient bol vytvorený o niekoľko rokov skôr, než mal, ešte pred tým, ako väčšina webových vývojárov poznala imutabilitu. Z tohto dôvodu FireBase predpokladá, že budete meniť dáta, a preto nevyužíva výhody zabezpečovanej imutability. Okrem toho nevyužíva dáta opakovane v odoslaných snímkach pre používateľa, čo znemožňuje jednoduché vykonávanie porovnaní. Pre veľké dokumenty je jeho mechanizmus transakcií založený na meniteľných rozdieloch jednoducho nedostatočný. Chlapci, už máme WeakMap v JavaScripte. To je pohodlné.
Ak dáte dátam správny tvar a nepovytiahnete stromy príliš veľké, môžete tento problém obísť. Ale zaujíma ma, či by FireBase bol oveľa zaujímavejší, keby vývojári vydali skutočne dobré klientské API, ktoré by využívalo imutabilitu v kombinácii so serióznymi praktickými radami o štruktúre databáz. Namiesto toho sa zdá, že sa pokúsili opraviť niečo, čo nie je rozbité, a od toho sa to zhoršilo.
Neviem všetku logiku, ktorá stála za vytvorením Firestore. Rozprávanie o motiváciách, ktoré vznikajú vo vnútri čiernej skrinky, je tiež časťou zábavy. Takéto postavenie dvoch mimoriadne podobných, ale nesrovnateľných databáz sa vyskytuje dosť zriedka. Ako keby si niekto pomyslel: „Firebase je len funkcia, ktorú môžeme emulovať v Google Cloud“, ale pritom ešte neotvoril koncept definovania požiadaviek reálneho sveta alebo vytvárania užitočných riešení, ktoré by spĺňali všetky tieto požiadavky. „Nech o tom rozmýšľajú vývojári. Stačí spraviť užívateľské rozhranie pekné... A môžem pridať viac ohňa?“
Chápem pár vecí o dátových štruktúrach. Určite vidím, že koncept „všetko v jednom veľkom strome JSON“ je pokusom abstrahovať z databázy akýkoľvek pocit veľkorozmernej štruktúry. Očakávať, že softvér sa jednoducho vyrovná akémukoľvek pochybnému fraktálu dátovej štruktúry, je jednoducho šialené. Ani si nemusím predstavovať, ako zlé to môže byť, robil som prísne audity kódu a videl som niečo, čo si ani vy, ľudia, neviete predstaviť.. Ale tiež viem, ako vyzerajú dobré štruktúry, a Môžem si predstaviť svet, v ktorom by Firestore pôsobila celkom logicky a tí, ktorí ju vytvorili, by si mysleli, že odvedli dobrú prácu. Ale nežijeme v tomto svete.
Podpora pre vytváranie dotazov vo FireBase je zlá podľa akýchkoľvek štandardov, prakticky neexistuje. Určite si vyžaduje zlepšenie alebo aspoň prehodnotenie. Ale Firestore nie je o veľa lepšia, pretože je obmedzená rovnakými jednorozmernými indexmi, aké má jednoduché SQL. Ak potrebujete dotazy, ktoré ľudia vykonávajú s chaotickými dátami, potrebujete fulltextové vyhľadávanie, filtre na niekoľko rozsahov a ľubovoľné poradie určené používateľom. Pri bližšom preskúmaní sú funkcie jednoduchého SQL samy o sebe príliš obmedzené. Okrem toho sú jediné SQL dotazy, ktoré ľudia môžu vykonávať v produkcii — rýchle dotazy. Na to budete potrebovať špecializované riešenie na indexovanie s premyslenými dátovými štruktúrami. Pre všetko ostatné by malo byť minimálne inkrementálne map-reduce alebo niečo podobné.
Ak sa pozriete na informácie o tom v dokumentoch Google, dúfam, že vás nasmerujú k niečomu ako BigTable a BigQuery. Avšak všetky tieto riešenia sú sprevádzané takým objemom hustého žargónu firemných predajov, že sa rýchlo vrátite späť a začnete hľadať niečo iné.
Posledná vec, ktorú potrebujete v prípade databázy v reálnom čase — je niečo vytvorené ľuďmi a pre ľudí pracujúcich na základe platového podkontraktu.
(*) To je vtip, neexistuje takéto pojatie ako .
Na základe reklamy
Hľadáte server na ladenie projektov, vývoj a hosting? Ste presne náš klient 🙂 Denné paušály serverov rôznych konfigurácií, antiDDoS a licencie Windows už sú zahrnuté v cene.
Zdroj: habr.com
