Lad mig fortælle en teknisk historie.
For mange år siden udviklede jeg en applikation med indbyggede samarbejdsfunktioner. Det var et praktisk eksperimentelt stack, der udnyttede det fulde potentiale af tidlig React og CouchDB. Den synkroniserede data i realtid via JSON. . Den blev brugt i virksomhedens interne arbejde, men den brede anvendelighed og potentiale i andre områder var åbenlyse.
Da vi forsøgte at sælge denne teknologi til potentielle kunder, stødte vi på en uventet forhindring. I demo-videoen så vores teknologi fremragende ud og fungerede perfekt, der var ingen problemer. Videoen viste præcist, hvordan det fungerer, og der blev ikke imiteret noget. Vi designede og kodede et realistisk anvendelsesscenario for programmet.
Faktisk blev det et problem. Vores demo fungerede præcist som de andre applikationer imiterede. Konkret blev informationer øjeblikkeligt overført fra A til B, selvom det var store mediefiler. Efter login så hver bruger nye indlæg. Ved hjælp af applikationen kunne forskellige brugere arbejde præcist sammen om de samme projekter, selv i tilfælde af en ustabil internetforbindelse et eller andet sted i landsbyen. Dette var implicit i enhver klippet After Effects video om produktet.
Selvom alle vidste, hvad knappen Opdatering skulle bruges til, forstod ingen overhovedet, at de webapplikationer, de bad os om at skabe, oftest var begrænsede. Og at hvis de ikke længere var nødvendige, ville brugeroplevelsen være helt anderledes. I det store hele bemærkede de, at de kunne 'chattere' ved at efterlade noter til hinanden, så de spørgte sig selv, hvad der adskilte det fra for eksempel Slack. Uff!
Design af daglig synkronisering
Hvis du allerede har erfaring med softwareudvikling, så må det irritere dig, at du skal huske, at de fleste mennesker ikke kan kaste et blik på en grænseflade og forstå, hvad den vil gøre, når de interagerer med den. Slet ikke at nævne hvad der sker inde i selve programmet. Viden om, hvad kan der kan ske — er i høj grad et resultat af viden om, hvad der ikke kan ske, og hvad der ikke bør ske. Det kræver ikke kun hvad softwaren gør, men også hvordan dens dele er koordineret og kommunikere med hinanden.
Et klassisk eksempel på dette er en bruger, der i tyve minutter ser på spinner.gif, og gætter på, hvornår arbejdet endelig slutter. Udvikleren ville forstå, at processen sandsynligvis er låst, og at gif'en aldrig vil forsvinde fra skærmen. Denne animation imiterer udførelsen af arbejdet, men har ikke noget at gøre med dets tilstand. I sådanne tilfælde elsker nogle teknikere at rulle med øjnene over, hvor fuldstændig brugerne tager fejl. Men bemærk, hvem af dem peger på de roterende ure og siger, at de faktisk er immobile?
Dette er essensen af værdien af realtid. I dag anvendes realtidsdatabaser stadig meget sjældent, og mange har en mistænksom holdning til dem. De fleste af disse databaser er stærkt tilbøjelige til NoSQL-stilen, hvilket normalt fører til brug af løsninger baseret på Mongo, som det er bedst at glemme. Men for mig betyder det komforten ved at arbejde med CouchDB samt studerende i design af strukturer, der ikke kun kan fyldes af en eller anden bureaukrat. Jeg mener, at jeg bruger min tid mere optimalt.
Men det egentlige emne for dette indlæg er, hvad jeg bruger i dag. Ikke efter eget valg, men på grund af den ligegyldige og blindt anvendte virksomhedspolitik. Derfor vil jeg give en Helt Ærlig og Upartisk sammenligning af to tæt relaterede produkter til at arbejde med realtidsdatabaser fra Google.
Begge har ordet Fire i deres navne. Det ene husker jeg med ømhed. Det andet er for mig en anden form for ild. Jeg skyndte mig ikke med at nævne deres navne, fordi så snart jeg gør det, møder vi det første store problem - med navnene.
Den første hedder Firebase Real-Time Database, og den anden - Firebase Cloud Firestore. Begge er produkter fra Firebase suite Google. Deres API'er kaldes henholdsvis firebase.database(…) og firebase.firestore(…).
Det skete, fordi Real-Time Database simpelthen er den oprindelige Firebase før Google købte det i 2014. Derefter besluttede Google at skabe en parallelt produkt baseret på big data fra virksomheden - og kaldte den Firestore with a cloud. Jeg håber, du ikke er blevet forvirret endnu. Hvis du alligevel er blevet forvirret, skal du ikke bekymre dig, jeg har selv skrevet dette afsnit ti gange om. Fordi det er nødvendigt at angive Firebase, der er baseret på virksomhedens big data, og de kaldte det Firestore with a cloud. Jeg håber, du ikke er blevet forvirret. Hvis du stadig er forvirret, så behøver du ikke bekymre dig, jeg har selv skrevet denne del af artiklen ti gange.
Fordi det er nødvendigt at angive Firebase i spørgsmålet om Firebase, og Firestore i spørgsmålet om Firebase, i det mindste for at du kunne blive forstået for flere år siden på Stack Overflow.
Hvis der fandtes en pris for det dårligste navngivning af softwareprodukter, ville dette tilfælde helt sikkert blive en af de nominerede. Hamming-afstanden mellem disse navne er så lille, at den forvirrer erfarne ingeniører, hvis fingre skriver et navn, selvom hovedet tænker på et andet. Dette er elendigt mislykkede planer, skabt med de bedste intentioner; de har opfyldt profetien om, at databasen ville gå op i flammer. Og jeg spøger ikke. Manden, der fandt på sådan et navngivningssystem, har forårsaget blod, sved og tårer.
Pyrrhussejr
Man kunne tro, at Firestore er en erstatning for Firebase, dens næste generation, men det ville være en misforståelse. Firestore passer bestemt ikke som en erstatning for Firebase. Det virker som om, nogen har skåret alt det interessante ud af den, og forvirret det meste af det resterende på forskellige måder.
Men et hurtigt blik på de to produkter kan forvirre dig: det ser ud til, at de gør præcis det samme, gennem stort set de samme API'er og endda i den samme databasesession. Forskellene er subtile og opdages kun ved en grundig komparativ gennemgang af den omfattende dokumentation. Eller når du prøver at portere kode, der fungerer perfekt på Firebase, så det fungerer med Firestore. Allerede da finder du ud af, at databasegrænsefladen lyser op, så snart du forsøger at trække og slippe med musen i realtid. Jeg gentager, jeg spøger ikke.
Firebase-klienten er venlig på den måde, at den buffer ændringer og udfører automatisk genforsøg på opdateringer, hvor den prioriterer den seneste skriveoperation. Men Firestore har en grænse på 1 skriveoperation pr. dokument pr. bruger pr. sekund, og denne grænse pålægges af serveren. Når du arbejder med det, skal du selv finde en måde at omgå det på og implementere en hastighedsgrænser for opdateringer, selv når du bare prøver at bygge din applikation. Det vil sige, Firestore er en realtidsdatabase uden en realtidsklient, som camoufleres som en ved hjælp af API.
Her begynder vi at se de første tegn på meningen med Firestore. Måske tager jeg fejl, men jeg har en mistanke om, at nogen højt oppe i Googles ledelse så på Firebase efter opkøbet og sagde: „Nej, gud nej, det er uacceptabelt. Kun ikke under mit lederskab.“
Han trådte frem fra sine gemakker og proklamerede:
„Én stor JSON-dokument? Nej. Du skal opdele dataene i separate dokumenter, hver af dem må ikke overstige 1 megabyte.“
Det ser ud til, at en sådan begrænsning ikke vil overleve første møde med en hvilken som helst tilstrækkeligt motiveret brugerbase. Du ved, det er sandt. Hos os på arbejdet, for eksempel, har vi over 1500 præsentationer, og det er helt normalt.
Med en sådan begrænsning bliver du nødt til at acceptere, at ét „dokument“ i databasen ikke vil ligne nogen objekter, som brugeren kunne kalde et dokument.
„Arrays af arrays, som kan indeholde andre elementer rekursivt? Nej. Arrays vil kun indeholde objekter eller tal af fast længde, som Herren tilelskede det.“
Så hvis du håbede på at placere din Firestore GeoJSON, vil du opdage, at det er umuligt. Intet dimensionelt er tilladt. Håber du elsker Base64 og/eller JSON inden for JSON.
„Import og eksport af JSON via HTTP, kommandolinjeværktøjer eller administrationspanelet? Nej. Du kan kun eksportere og importere data til Google Cloud Storage. Sådan ser det i øjeblikket ud. Og når jeg siger „du“, refererer jeg kun til de, der har beføjelser som Project Owner. Alle andre kan gå og oprette sager.“
Som du kan se, er det let at beskrive FireBase datamodel. Den indeholder et stort JSON-dokument, der forbinder JSON-nøgler med URL-stier. Hvis du registrerer med HTTP PUT i / FireBase følgende:
{
"hello": "world"
} Så GET /hello vil returnere "world". Generelt fungerer det lige sådan, som du forventer. Samlingen af objekter i FireBase /my-collection/:id t svarer til en JSON-ordbog {"my-collection": {...}} i roden, hvis indhold er tilgængeligt i /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Det fungerer glimrende, hvis hver indsættelse har ID'er uden kollisioner, hvilket der findes en standardløsning til i systemet.
Med andre ord er databasen 100 % kompatibel med JSON (*) og fungerer fremragende med HTTP, som for eksempel CouchDB. Men i det væsentlige bruger man den gennem et realtids-API, som abstraherer websockets, godkendelse og abonnementer. Adminpanelet har begge muligheder, hvilket gør det muligt at redigere i realtid og at importere/eksportere JSON. Hvis du holder dig til det i din kode, vil du blive overrasket over, hvor meget specialiseret kode der forsvinder, når du indser, at patch og diff JSON kan løse 90 % af de rutinemæssige opgaver inden for vedvarende tilstand.
Firestore's datamodel ligner JSON, men adskiller sig fra den på nogle kritisk vigtige punkter. Jeg har allerede nævnt manglen på arrays inden for arrays. Idéen med sub-samlinger er, at de er første klasses koncepter, adskilt fra det overordnede JSON-dokument. Da der ikke er nogen klar serialisering til dette, kræver det en specialiseret kodeudførelse for at hente og skrive data. For at håndtere egne samlinger skal der skrives egne scripts og værktøjer. Adminpanelet tillader kun små ændringer ét felt ad gangen og har ikke import/eksportmuligheder.
De tog en realtids NoSQL-database og gjorde den til en langsom ikke-SQL med auto-sammenslutning og en separat kolonne for ikke-JSON. Noget i stil med GraftQL.
Hot Java
Hvis Firestore skulle blive mere pålidelig og skalerbar, er ironien, at den gennemsnitlige udvikler får en mindre pålidelig løsning end hvis de havde valgt FireBase 'out-of-the-box'. Den software, som den Grumpy Database Administrator har brug for, kræver et sådant niveau af indsats og specialister, at det simpelthen er urealistisk for den niche, hvor der formodentlig skulle være et godt produkt. Det minder om, hvordan HTML5 Canvas slet ikke er en erstatning for Flash, hvis der ikke er udviklingsværktøjer og en afspiller. Desuden er Firestore sunket i stræben efter datarenshed og steril validering, som blot ikke stemmer overens med, hvordan den gennemsnitlige forretningsbruger gerne arbejder: for ham er intet nødvendigt, fordi alt til slut er et udkast.
Den primære ulempe ved FireBase er, at klienten blev oprettet flere år før sin tid, endnu før de fleste webudviklere blev klar over immutabilitet. På grund af dette antager FireBase, at du vil ændre data, og derfor udnytter den ikke fordelene ved brugergenereret immutabilitet. Desuden genbruger den ikke data i de snapshots, der gives til brugeren, hvilket gør det meget vanskeligere at udføre diff. For store dokumenter er dens transaktionsmekanisme baseret på ændrede diff simpelthen utilstrækkelig. Folk, vi har jo allerede WeakMap i JavaScript. Det er praktisk.
Hvis man giver dataene den rette form og ikke gør træerne for store, kan man omgå dette problem. Men jeg er nysgerrig, ville FireBase være meget mere interessant, hvis udviklerne havde udgivet et virkelig godt klient-API, der bruger immutabilitet i kombination med alvorlige praktiske råd vedrørende databasedesign. I stedet ser det ud til, at de har forsøgt at reparere noget, der ikke var i stykker, og det er blevet værre.
Jeg kender ikke hele logikken, der lå til grund for oprettelsen af Firestore. At ræsonnere om motiverne, der opstår inden for en sort boks, er også en del af underholdningen. Sådan en opposition mellem to ekstremt lignende men uforenelige databaser er ret sjælden. Som om nogen tænkte: «Firebase er bare en funktion, som vi kan emulere i Google Cloud», men på samme tid endnu ikke har opdaget konceptet med at definere virkelige verdens krav eller skabe nyttige løsninger, der imødekommer alle disse krav. «Lad os lade udviklerne tænke over det. Bare gør UI'en smuk... Kan vi tilføje mere ild?»
Jeg forstår et par ting om datastrukturer. Jeg kan tydeligt se, at konceptet "alt i et stort JSON-træ" er et forsøg på at abstrahere enhver følelse af storskala struktur fra databasen. At forvente, at softwaren bare kan håndtere enhver tvivlsom fraktal af datastrukturen — det er bare vanvid. Jeg behøver ikke engang at forestille mig, hvor slemt det kan være, jeg har foretaget strenge kodegennemgange og set ting, som I mennesker ikke engang kan drømme om.. Men jeg ved også, hvordan gode strukturer ser ud, og Jeg kan forestille mig en verden, hvor Firestore ville give fuldstændig mening, og de mennesker, der skabte det, ville tro, de gjorde et godt stykke arbejde. Men vi lever ikke i denne verden.
Støtten til opbygning af forespørgsler i FireBase er dårlig efter enhver standard, den findes næsten ikke. Det kræver bestemt forbedring eller i det mindste en revision. Men Firestore er ikke meget bedre, da den er begrænset af de samme en-dimensionale indekser, der findes i simpel SQL. Hvis du har brug for forespørgsler, som folk udfører med kaotiske data, kræves der fuldtekst søgning, filtre på flere intervaller og vilkårlig brugerdefineret rækkefølge. Ved nærmere eftersyn er mulighederne i simpel SQL for begrænsede. Desuden er de eneste SQL-forespørgsler, som folk kan udføre i produktionen — hurtige forespørgsler. Du får brug for en specialiseret løsning til indeksering med gennemtænkte datastrukturer. Til alt andet skal der i det mindste være en inkrementel map-reduce eller noget lignende.
Hvis du søger information om dette i Googles dokumentation, håber jeg, at du vil blive henvist til noget som BigTable og BigQuery. Men alle disse løsninger er besværet med en sådan mængde tungt salgssprog, at du hurtigt vil vende tilbage og begynde at lede efter noget andet.
Det sidste, du har brug for i en realtidsdatabase, er noget skabt af mennesker og til mennesker, der arbejder efter en lønstruktur for ledelsen.
(*) Det er en vittighed, der findes ikke noget som .
Annoncering
Leder du efter en server til fejlfinding af projekter, udvikling og hosting? Du er helt sikkert vores kunde 🙂 Daglig prissætning af servere i de mest forskellige konfigurationer, antiDDoS og Windows-licenser er allerede inkluderet i prisen.
Kilde: habr.com
