Lad mig fortælle en teknisk historie.
For mange år siden udviklede jeg en applikation med indbyggede samarbejdsfunktioner. Det var en brugervenlig eksperimentel stak, der udnyttede det fulde potentiale af tidlig React og CouchDB. Det synkroniserede data i realtid via JSON . Den blev brugt internt i virksomheden, men dens brede anvendelighed og potentiale på andre områder var tydelig.
Mens vi forsøgte at sælge denne teknologi til potentielle kunder, stødte vi på en uventet forhindring. I demovideoen så vores teknologi ud og fungerede godt, ingen problemer der. Videoen viste præcis, hvordan det fungerer og efterlignede ikke noget. Vi fandt på og kodede et realistisk scenarie for brug af programmet.
Faktisk blev dette problemet. Vores demo fungerede præcis som alle andre simulerede deres applikationer. Specifikt blev information øjeblikkeligt overført fra A til B, selvom det var store mediefiler. Efter at have logget ind, så hver bruger nye poster. Ved at bruge applikationen kunne forskellige brugere arbejde klart sammen om de samme projekter, selvom internetforbindelsen blev afbrudt et sted i landsbyen. Dette er implicit underforstået i enhver produktvideo, der er klippet i After Effects.
Selvom alle vidste, hvad Opdater-knappen var til for, var der ingen, der rigtig forstod, at de webapplikationer, de bad os om at bygge, normalt var underlagt deres egne begrænsninger. Og at hvis de ikke længere er nødvendige, bliver brugeroplevelsen en helt anden. De lagde mest mærke til, at de kunne "chatte" ved at efterlade noter til folk, de talte med, så de undrede sig over, hvordan det var anderledes end for eksempel Slack. Pyha!
Design af daglige synkroniseringer
Hvis du har erfaring med softwareudvikling, må det være nervepirrende at huske, at de fleste mennesker ikke bare kan se på et billede af en grænseflade og forstå, hvad den vil gøre, når de interagerer med den. For ikke at tale om, hvad der sker inde i selve programmet. Vid det kan ske er i høj grad resultatet af at vide, hvad der ikke kan ske, og hvad der ikke bør ske. Dette kræver ikke kun hvad softwaren gør, men også hvordan dens individuelle dele er koordineret og kommunikerer med hinanden.
Et klassisk eksempel på dette er en bruger, der stirrer på en spinner.gif, spekulerer på, hvornår arbejdet endelig er færdigt. Udvikleren ville have indset, at processen sandsynligvis sad fast, og at gif'en aldrig ville forsvinde fra skærmen. Denne animation simulerer udførelsen af et job, men er ikke relateret til dets tilstand. I sådanne tilfælde kan nogle teknikere godt lide at rulle med øjnene, forbløffet over omfanget af brugerforvirring. Læg dog mærke til, hvor mange af dem, der peger på det roterende ur og siger, at det faktisk står stille?
Dette er essensen af realtidsværdi. I disse dage er realtidsdatabaser stadig meget lidt brugt, og mange mennesker ser dem med mistænksomhed. De fleste af disse databaser hælder kraftigt til NoSQL-stilen, hvorfor de normalt bruger Mongo-baserede løsninger, som bedst glemmes. For mig betyder dette dog at blive fortrolig med at arbejde med CouchDB, samt lære at designe strukturer, som mere end blot nogle bureaukrater kan fylde med data. Jeg tror, jeg bruger min tid bedre.
Men det virkelige emne for dette indlæg er, hvad jeg bruger i dag. Ikke ved valg, men på grund af ligegyldigt og blindt anvendt virksomhedspolitik. Så jeg vil give en fuldstændig retfærdig og upartisk sammenligning af to tæt relaterede Google-databaseprodukter i realtid.
Begge har ordet Ild i deres navne. En ting husker jeg med glæde. Den anden ting for mig er en anden type brand. Jeg har ikke travlt med at sige deres navne, for når jeg først gør det, vil vi løbe ind i det første store problem: navne.
Den første hedder Firebase realtidsdatabase, og for det andet - Firebase Cloud Firestore. Begge er produkter fra Firebase suite Google. Deres API'er kaldes hhv firebase.database(…) и firebase.firestore(…).
Dette skete pga Realtidsdatabase - det er bare originalen Firebase før det blev købt af Google i 2014. Så besluttede Google at skabe som et parallelt produkt kopi Firebase baseret på big data-virksomhed, og kaldte det Firestore med en sky. Jeg håber ikke du er forvirret endnu. Hvis du stadig er forvirret, så bare rolig, jeg har selv omskrevet denne del af artiklen ti gange.
Fordi du skal indikere Firebase i Firebase-spørgsmålet, og Firestore i et spørgsmål om Firebase, i det mindste for at få dig til at forstå for nogle år siden på Stack Overflow.
Hvis der var en pris for den værste softwarenavneoplevelse, ville dette helt sikkert være en af kandidaterne. Hamming-afstanden mellem disse navne er så lille, at den forvirrer selv erfarne ingeniører, hvis fingre skriver et navn, mens deres hoveder tænker på et andet. Det er velmenende planer, der mislykkes dybt; de opfyldte profetien om, at databasen ville brænde. Og jeg laver overhovedet ikke sjov. Den person, der fandt på dette navneskema, forårsagede blod, sved og tårer.
Pyrrhus sejr
Man skulle tro, at Firestore er udskiftning Firebase, dens næste generations efterkommer, men det ville være vildledende. Firestore er ikke garanteret en passende erstatning for Firebase. Det ser ud som om nogen har klippet alt interessant ud fra det og forvirret det meste af resten på forskellige måder.
Et hurtigt blik på de to produkter kan dog forvirre dig: de ser ud til at gøre det samme, gennem stort set de samme API'er og endda i den samme databasesession. Forskellene er subtile og afsløres kun ved omhyggelig sammenlignende undersøgelse af omfattende dokumentation. Eller når du forsøger at portere kode, der fungerer perfekt på Firebase, så det fungerer med Firestore. Allerede da finder du ud af, at databasegrænsefladen lyser, så snart du forsøger at trække og slippe med musen i realtid. Jeg gentager, jeg laver ikke sjov.
Firebase-klienten er høflig i den forstand, at den buffer ændringer og automatisk gentager opdateringer, der prioriterer den sidste skriveoperation. Firestore har dog en grænse på 1 skrivehandling pr. dokument pr. bruger pr. sekund, og denne grænse håndhæves af serveren. Når du arbejder med det, er det op til dig at finde en vej rundt om det og implementere en opdateringshastighedsbegrænser, selv når du bare prøver at bygge din applikation. Det vil sige, at Firestore er en realtidsdatabase uden en realtidsklient, som udgiver sig som en ved hjælp af en API.
Her begynder vi at se de første tegn på Firestores eksistensberettigelse. Jeg kan tage fejl, men jeg formoder, at nogen højt oppe i Googles ledelse kiggede på Firebase efter købet og blot sagde: ”Nej, åh min Gud, nej. Dette er uacceptabelt. Bare ikke under min ledelse."
Han dukkede op fra sine kamre og erklærede:
"Et stort JSON-dokument? Ingen. Du opdeler dataene i separate dokumenter, som hver ikke vil være mere end 1 megabyte store."
Det ser ud til, at en sådan begrænsning ikke vil overleve det første møde med en tilstrækkeligt motiveret brugerbase. Det ved du godt. På arbejdet har vi for eksempel mere end halvandet tusinde præsentationer, og det er helt normalt.
Med denne begrænsning vil du blive tvunget til at acceptere det faktum, at ét "dokument" i databasen ikke vil ligne noget objekt, som en bruger kan kalde et dokument.
"Arrays af arrays, der rekursivt kan indeholde andre elementer? Ingen. Arrays vil kun indeholde objekter eller tal med fast længde, som Gud havde til hensigt."
Så hvis du håbede på at sætte GeoJSON ind i din Firestore, vil du opdage, at dette ikke er muligt. Intet ikke-endimensionelt er acceptabelt. Jeg håber, du kan lide Base64 og/eller JSON i JSON.
"JSON importere og eksportere via HTTP, kommandolinjeværktøjer eller admin panel? Ingen. Du vil kun kunne eksportere og importere data til Google Cloud Storage. Det er hvad det hedder nu, tror jeg. Og når jeg siger "dig", henvender jeg mig kun til dem, der har projektejeroplysninger. Alle andre kan gå hen og lave billetter."
Som du kan se, er FireBase-datamodellen nem at beskrive. Den indeholder et enormt JSON-dokument, der forbinder JSON-nøgler med URL-stier. Hvis du skriver med HTTP PUT в / FireBase er følgende:
{
"hello": "world"
}
At GET /hello kommer tilbage "world". Grundlæggende fungerer det præcis som du forventer. Samling af FireBase-objekter /my-collection/:id svarende til en JSON-ordbog {"my-collection": {...}} i roden, hvis indhold er tilgængeligt i /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Dette fungerer fint, hvis hver indsats har et kollisionsfrit ID, som systemet har en standardløsning til.
Med andre ord er databasen 100 % JSON(*) kompatibel og fungerer godt med HTTP, såsom CouchDB. Men dybest set bruger du det gennem en realtids-API, der abstraherer websockets, autorisation og abonnementer. Adminpanelet har begge muligheder, hvilket tillader både realtidsredigering og JSON-import/eksport. Hvis du gør det samme i din kode, vil du blive overrasket over, hvor meget specialiseret kode der vil blive spildt, når du indser, at patch and diff JSON løser 90 % af rutineopgaverne med at håndtere persistent state.
Firestore-datamodellen ligner JSON, men adskiller sig på nogle kritiske måder. Jeg har allerede nævnt manglen på arrays i arrays. Modellen for undersamlinger er, at de skal være førsteklasses koncepter, adskilt fra JSON-dokumentet, der indeholder dem. Da der ikke er nogen færdig serialisering til dette, kræves der en specialiseret kodesti for at hente og skrive data. For at behandle dine egne samlinger skal du skrive dine egne scripts og værktøjer. Admin panelet giver dig kun mulighed for at foretage små ændringer et felt ad gangen og har ikke import/eksport muligheder.
De tog en NoSQL-database i realtid og forvandlede den til en langsom ikke-SQL med auto-join og en separat ikke-JSON-kolonne. Noget som GraftQL.
Hot Java
Hvis Firestore skulle være mere pålidelig og skalerbar, så er ironien, at den gennemsnitlige udvikler vil ende med en mindre pålidelig løsning end at vælge FireBase ud af boksen. Den slags software, som Grumpy Database Administrator har brug for, kræver et niveau af indsats og talent, der simpelthen er urealistisk for den niche, produktet formodes at være godt til. Dette svarer til, hvordan HTML5 Canvas slet ikke er en erstatning for Flash, hvis der ikke er nogen udviklingsværktøjer og en afspiller. Derudover er Firestore bundet af et ønske om datarenhed og steril validering, der simpelthen ikke stemmer overens med den gennemsnitlige forretningsbruger. elsker at arbejde: for ham er alt valgfrit, for indtil det sidste er alt et udkast.
Den største ulempe ved FireBase er, at klienten blev oprettet flere år forud for sin tid, før de fleste webudviklere kendte til uforanderlighed. På grund af dette antager FireBase, at du vil ændre dataene og udnytter derfor ikke brugernes uforanderlighed. Derudover genbruger den ikke dataene i de snapshots, den sender til brugeren, hvilket gør forskellen meget sværere. For store dokumenter er dens mutable diff-baserede transaktionsmekanisme simpelthen utilstrækkelig. Gutter, det har vi allerede WeakMap i JavaScript. Det er behageligt.
Hvis du giver dataene den ønskede form og ikke gør træerne for voluminøse, så kan dette problem omgås. Men jeg er spændt på, om FireBase ville være meget mere interessant, hvis udviklerne frigav en rigtig god klient-API, der brugte uforanderlighed kombineret med nogle seriøse praktiske råd om databasedesign. I stedet så de ud til at prøve at reparere det, der ikke var gået i stykker, og det gjorde det værre.
Jeg kender ikke al logikken bag oprettelsen af Firestore. At spekulere i de motiver, der opstår inde i den sorte boks, er også en del af det sjove. Denne sammenstilling af to ekstremt ens, men uforlignelige databaser er ret sjælden. Det er som nogen tænkte: "Firebase er bare en funktion, som vi kan efterligne i Google Cloud", men har endnu ikke opdaget konceptet med at identificere virkelige krav eller skabe nyttige løsninger, der opfylder alle disse krav. "Lad udviklerne tænke over det. Bare gør brugerfladen smuk... Kan du tilføje mere ild?”
Jeg forstår et par ting om datastrukturer. Jeg ser bestemt "alt i ét stort JSON-træ"-konceptet som et forsøg på at abstrahere enhver følelse af storskalastruktur fra databasen. At forvente, at software simpelthen kan klare enhver tvivlsom datastruktur fraktal er simpelthen vanvittigt. Jeg behøver ikke engang at forestille mig, hvor slemt ting kunne være, jeg har lavet strenge koderevisioner og Jeg så ting, som I aldrig drømte om. Men jeg ved også, hvordan gode strukturer ser ud, и . Jeg kan forestille mig en verden, hvor Firestore ville virke logisk, og de mennesker, der skabte den, ville synes, de gjorde et godt stykke arbejde. Men vi lever ikke i denne verden.
FireBases forespørgselsunderstøttelse er dårlig efter enhver standard og er praktisk talt ikke-eksisterende. Det trænger bestemt til forbedring eller i det mindste revision. Men Firestore er ikke meget bedre, fordi det er begrænset til de samme endimensionelle indekser, der findes i almindelig SQL. Hvis du har brug for forespørgsler, som folk kører på kaotiske data, har du brug for fuldtekstsøgning, multi-range filtre og brugerdefineret brugerdefineret rækkefølge. Ved nærmere eftersyn er funktionerne i almindelig SQL for begrænsede i sig selv. Derudover er de eneste SQL-forespørgsler, folk kan køre i produktionen, hurtige forespørgsler. Du skal bruge en tilpasset indekseringsløsning med gennemtænkte datastrukturer. For alt andet skal der i det mindste være inkrementel kort-reducering eller noget lignende.
Hvis du søger i Google Docs for information om dette, vil du forhåbentlig blive peget i retning af noget som BigTable og BigQuery. Alle disse løsninger er dog ledsaget af så meget tæt virksomhedssalgsjargon, at du hurtigt vender tilbage og begynder at lede efter noget andet.
Det sidste, du ønsker med en realtidsdatabase, er noget, der er lavet af og for folk på ledelsens lønskalaer.
(*) Dette er en joke, der er ikke noget, der hedder .
Om reklamernes rettigheder
Leder efter til debugging-projekter, en server til udvikling og hosting? Du er bestemt vores kunde 🙂 Daglig prissætning for servere med forskellige konfigurationer, anti-DDoS og Windows-licenser er allerede inkluderet i prisen.
Kilde: www.habr.com