La meg fortelle en teknisk historie.
For mange år siden utviklet jeg en applikasjon med samarbeidsfunksjoner innebygd. Det var en brukervennlig eksperimentell stack som utnyttet det fulle potensialet til tidlig React og CouchDB. Den synkroniserte data i sanntid via JSON . Den ble brukt internt i selskapet, men dens brede anvendelighet og potensial på andre områder var tydelig.
Mens vi prøvde å selge denne teknologien til potensielle kunder, møtte vi en uventet hindring. I demovideoen så teknologien vår ut og fungerte bra, ingen problemer der. Videoen viste nøyaktig hvordan det fungerer og imiterte ingenting. Vi kom opp med og kodet et realistisk scenario for bruk av programmet.
Faktisk ble dette problemet. Vår demo fungerte akkurat slik alle andre simulerte applikasjonene sine. Nærmere bestemt ble informasjon umiddelbart overført fra A til B, selv om det var store mediefiler. Etter pålogging så hver bruker nye oppføringer. Ved å bruke applikasjonen kunne forskjellige brukere jobbe tydelig sammen om de samme prosjektene, selv i tilfelle en intermitterende Internett-tilkobling et sted i landsbyen. Dette er implisitt i alle produktvideoklipp i After Effects.
Selv om alle visste hva Oppdater-knappen var for, var det ingen som virkelig forsto at nettapplikasjonene de ba oss bygge, vanligvis var underlagt sine egne begrensninger. Og at hvis de ikke lenger er nødvendige, blir brukeropplevelsen en helt annen. De la stort sett merke til at de kunne "chatte" ved å legge igjen notater til folk de snakket med, så de lurte på hvordan dette var forskjellig fra for eksempel Slack. Puh!
Design av daglige synkroniseringer
Hvis du har erfaring med programvareutvikling, må det være nervepirrende å huske at folk flest ikke bare kan se på et bilde av et grensesnitt og forstå hva det vil gjøre når de samhandler med det. For ikke å snakke om hva som skjer inne i selve programmet. Kjenne til det kan skje er i stor grad et resultat av å vite hva som ikke kan skje og hva som ikke bør skje. Dette krever ikke bare hva programvaren gjør, men også hvordan dens individuelle deler er koordinert og kommuniserer med hverandre.
Et klassisk eksempel på dette er en bruker som stirrer på en spinner.gif, lurer på når arbeidet endelig skal være ferdig. Utvikleren ville ha innsett at prosessen sannsynligvis satt fast og at gif-en aldri ville forsvinne fra skjermen. Denne animasjonen simulerer utførelsen av en jobb, men er ikke relatert til dens tilstand. I slike tilfeller liker noen teknologer å himle med øynene, overrasket over omfanget av brukerforvirring. Legg imidlertid merke til hvor mange av dem som peker på den roterende klokken og sier at den faktisk står stille?
Dette er essensen av sanntidsverdi. I disse dager er sanntidsdatabaser fortsatt svært lite brukt, og mange ser på dem med mistenksomhet. De fleste av disse databasene lener seg tungt mot NoSQL-stilen, og det er derfor de vanligvis bruker Mongo-baserte løsninger, som er best å glemme. For meg betyr dette imidlertid å bli komfortabel med å jobbe med CouchDB, samt lære å designe strukturer som mer enn bare noen byråkrater kan fylle med data. Jeg tror jeg bruker tiden min bedre.
Men det virkelige temaet for dette innlegget er det jeg bruker i dag. Ikke ved valg, men på grunn av likegyldig og blindt anvendt bedriftspolitikk. Så jeg vil gi en fullstendig rettferdig og objektiv sammenligning av to nært beslektede Google-databaseprodukter i sanntid.
Begge har ordet Fire i navnene sine. En ting husker jeg med glede. Den andre tingen for meg er en annen type brann. Jeg har ikke hastverk med å si navnene deres, for når jeg først gjør det, vil vi støte på det første store problemet: navn.
Den første heter Firebase sanntidsdatabase, og andre - Firebase Cloud Firestore. Begge er produkter fra Firebase-suite Google. API-ene deres kalles hhv firebase.database(…) и firebase.firestore(…).
Dette skjedde pga Sanntidsdatabase - det er bare originalen Fire før det ble kjøpt av Google i 2014. Da bestemte Google seg for å lage som et parallelt produkt kopiere Firebase basert på big data-selskap, og kalte det Firestore med en sky. Jeg håper du ikke er forvirret ennå. Hvis du fortsatt er forvirret, ikke bekymre deg, jeg har selv skrevet om denne delen av artikkelen ti ganger.
Fordi du må indikere Fire i Firebase-spørsmålet, og Firestore i et spørsmål om Firebase, i det minste for å få deg til å forstå for noen år siden på Stack Overflow.
Hvis det var en pris for den verste programvarenavneopplevelsen, ville dette definitivt vært en av kandidatene. Hamming-avstanden mellom disse navnene er så liten at den forvirrer selv erfarne ingeniører hvis fingre skriver ett navn mens hodet tenker på et annet. Dette er velmente planer som mislykkes; de oppfylte profetien om at databasen skulle brenne. Og jeg tuller ikke i det hele tatt. Personen som kom opp med dette navneskjemaet forårsaket blod, svette og tårer.
Pyrrhusseier
Man skulle tro at Firestore er det erstatning Firebase, dens neste generasjons etterkommer, men det ville være misvisende. Firestore er ikke garantert en passende erstatning for Firebase. Det ser ut som noen har kuttet ut alt interessant fra det, og forvirret det meste av resten på forskjellige måter.
Imidlertid kan et raskt blikk på de to produktene forvirre deg: de ser ut til å gjøre det samme, gjennom stort sett de samme APIene og til og med i samme databaseøkt. Forskjellene er subtile og avsløres kun ved en nøye komparativ studie av omfattende dokumentasjon. Eller når du prøver å portere kode som fungerer perfekt på Firebase slik at den fungerer med Firestore. Allerede da finner du ut at databasegrensesnittet lyser så snart du prøver å dra og slippe med musen i sanntid. Jeg gjentar, jeg tuller ikke.
Firebase-klienten er høflig i den forstand at den bufrer endringer og prøver automatisk på nytt oppdateringer som gir prioritet til den siste skriveoperasjonen. Firestore har imidlertid en grense på 1 skriveoperasjon per dokument per bruker per sekund, og denne grensen håndheves av serveren. Når du jobber med det, er det opp til deg å finne en vei rundt det og implementere en oppdateringshastighetsbegrenser, selv når du bare prøver å bygge applikasjonen din. Det vil si at Firestore er en sanntidsdatabase uten en sanntidsklient, som gir seg ut som en som bruker en API.
Her begynner vi å se de første tegnene til Firestores eksistensberettigelse. Jeg kan ta feil, men jeg mistenker at noen høyt oppe i Googles ledelse så på Firebase etter kjøpet og bare sa: «Nei, herregud, nei. Dette er uakseptabelt. Bare ikke under min ledelse."
Han dukket opp fra sine kamre og erklærte:
"Et stort JSON-dokument? Nei. Du vil dele opp dataene i separate dokumenter, som hver ikke vil være mer enn 1 megabyte store.»
Det ser ut til at en slik begrensning ikke vil overleve det første møtet med en tilstrekkelig motivert brukerbase. Du vet det er det. På jobben har vi for eksempel mer enn halvannet tusen presentasjoner, og dette er helt normalt.
Med denne begrensningen vil du bli tvunget til å akseptere det faktum at ett "dokument" i databasen ikke vil ligne på noe objekt som en bruker kan kalle et dokument.
"Arrays av arrays som rekursivt kan inneholde andre elementer? Nei. Arrays vil bare inneholde objekter eller tall med fast lengde, slik Gud hadde tenkt."
Så hvis du håpet å sette GeoJSON inn i Firestore, vil du oppdage at dette ikke er mulig. Ingenting ikke-endimensjonalt er akseptabelt. Jeg håper du liker Base64 og/eller JSON i JSON.
"JSON importere og eksportere via HTTP, kommandolinjeverktøy eller adminpanel? Nei. Du vil bare kunne eksportere og importere data til Google Cloud Storage. Det er det det heter nå, tror jeg. Og når jeg sier «du», henvender jeg meg bare til de som har prosjekteier-legitimasjon. Alle andre kan gå og lage billetter."
Som du kan se, er FireBase-datamodellen enkel å beskrive. Den inneholder ett enormt JSON-dokument som knytter JSON-nøkler til URL-baner. Hvis du skriver med HTTP PUT в / FireBase er følgende:
{
"hello": "world"
}
den GET /hello vil returnere "world". I utgangspunktet fungerer det akkurat som du forventer. Samling av FireBase-objekter /my-collection/:id tilsvarende en JSON-ordbok {"my-collection": {...}} i roten, hvis innhold er tilgjengelig i /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Dette fungerer fint dersom hver innsats har en kollisjonsfri ID, som systemet har en standardløsning for.
Databasen er med andre ord 100 % JSON(*)-kompatibel og fungerer utmerket med HTTP, slik som CouchDB. Men i utgangspunktet bruker du det gjennom en sanntids-API som abstraherer websockets, autorisasjon og abonnementer. Administrasjonspanelet har begge funksjonene, og tillater både sanntidsredigering og JSON-import/eksport. Hvis du gjør det samme i koden din, vil du bli overrasket over hvor mye spesialisert kode som blir bortkastet når du innser at patch og diff JSON løser 90 % av rutineoppgavene med å håndtere vedvarende tilstand.
Firestore-datamodellen ligner på JSON, men skiller seg på noen kritiske måter. Jeg har allerede nevnt mangelen på matriser i matriser. Modellen for undersamlinger er at de skal være førsteklasses konsepter, atskilt fra JSON-dokumentet som inneholder dem. Siden det ikke finnes noen ferdig serialisering for dette, kreves det en spesialisert kodebane for å hente og skrive data. For å behandle dine egne samlinger, må du skrive dine egne skript og verktøy. Administrasjonspanelet lar deg bare gjøre små endringer ett felt om gangen, og har ikke import/eksportmuligheter.
De tok en sanntids NoSQL-database og gjorde den om til en langsom ikke-SQL med auto-join og en separat ikke-JSON-kolonne. Noe sånt som GraftQL.
Hot Java
Hvis Firestore skulle være mer pålitelig og skalerbar, så er ironien at den gjennomsnittlige utvikleren vil ende opp med en mindre pålitelig løsning enn å velge FireBase ut av esken. Den typen programvare som Grumpy Database Administrator trenger krever et nivå av innsats og talent som rett og slett er urealistisk for nisjen produktet er ment å være godt på. Dette ligner på hvordan HTML5 Canvas ikke er en erstatning for Flash i det hele tatt hvis det ikke finnes utviklingsverktøy og en spiller. Dessuten er Firestore fast i et ønske om datarenhet og steril validering som rett og slett ikke stemmer overens med hvordan den gjennomsnittlige forretningsbrukeren elsker å jobbe: for ham er alt valgfritt, for helt til slutten er alt et utkast.
Den største ulempen med FireBase er at klienten ble opprettet flere år forut for sin tid, før de fleste nettutviklere visste om uforanderlighet. På grunn av dette antar FireBase at du vil endre dataene og drar derfor ikke nytte av brukerforutsatt uforanderlighet. I tillegg gjenbruker den ikke dataene i øyeblikksbildene den sender til brukeren, noe som gjør diff mye vanskeligere. For store dokumenter er dens foranderlige diff-baserte transaksjonsmekanisme rett og slett utilstrekkelig. Gutter, det har vi allerede WeakMap i JavaScript. Det er behagelig.
Hvis du gir dataene ønsket form og ikke gjør trærne for voluminøse, kan dette problemet omgås. Men jeg er nysgjerrig på om FireBase ville vært mye mer interessant hvis utviklerne ga ut en virkelig god klient-API som brukte uforanderlighet kombinert med noen seriøse praktiske råd om databasedesign. I stedet så de ut til å prøve å fikse det som ikke var ødelagt, og det gjorde det verre.
Jeg kjenner ikke all logikken bak etableringen av Firestore. Å spekulere i motivene som oppstår inne i den svarte boksen er også en del av moroa. Denne sammenstillingen av to ekstremt like, men uforlignelige databaser er ganske sjelden. Det er som noen trodde: "Firebase er bare en funksjon som vi kan emulere i Google Cloud", men har ennå ikke oppdaget konseptet med å identifisere virkelige krav eller lage nyttige løsninger som oppfyller alle disse kravene. "La utviklerne tenke på det. Bare gjør brukergrensesnittet vakkert... Kan du legge til mer ild?»
Jeg forstår et par ting om datastrukturer. Jeg ser definitivt på konseptet "alt i ett stort JSON-tre" som et forsøk på å abstrahere enhver følelse av storskala struktur fra databasen. Å forvente at programvare bare skal takle enhver tvilsom datastrukturfraktal er rett og slett sinnsykt. Jeg trenger ikke engang å forestille meg hvor ille ting kan være, jeg har gjort strenge koderevisjoner og Jeg så ting dere aldri drømte om. Men jeg vet også hvordan gode strukturer ser ut, и . Jeg kan forestille meg en verden der Firestore ville virke logisk og menneskene som skapte den ville synes de gjorde en god jobb. Men vi lever ikke i denne verden.
FireBases spørringsstøtte er dårlig etter noen standard og er praktisk talt ikke-eksisterende. Det trenger definitivt forbedring eller i det minste revisjon. Men Firestore er ikke mye bedre fordi det er begrenset til de samme endimensjonale indeksene som finnes i vanlig SQL. Hvis du trenger spørringer som folk kjører på kaotiske data, trenger du fulltekstsøk, multi-range-filtre og tilpasset brukerdefinert rekkefølge. Ved nærmere ettersyn er funksjonene til vanlig SQL for begrensede alene. I tillegg er de eneste SQL-spørringene folk kan kjøre i produksjon raske spørringer. Du trenger en tilpasset indekseringsløsning med gjennomtenkte datastrukturer. For alt annet bør det i det minste være inkrementell kartreduksjon eller noe lignende.
Hvis du søker i Google Docs for informasjon om dette, vil du forhåpentligvis bli pekt i retning av noe som BigTable og BigQuery. Alle disse løsningene er imidlertid ledsaget av så mye tett bedriftssalgssjargong at du raskt vil snu og begynne å lete etter noe annet.
Det siste du ønsker med en sanntidsdatabase er noe laget av og for personer på lederlønnsskalaer.
(*) Dette er en spøk, det er ikke noe som heter .
Om rettighetene til annonsering
Ser etter for feilsøkingsprosjekter, en server for utvikling og hosting? Du er definitivt vår klient 🙂 Daglig prissetting for servere med ulike konfigurasjoner, anti-DDoS og Windows-lisenser er allerede inkludert i prisen.
Kilde: www.habr.com