Denne databasen er i brann…

La meg fortelle en teknisk historie.

For mange år siden utviklet jeg en applikasjon med innebygde samarbeidsfunksjoner. Det var en praktisk eksperimentell stabel, hvor hele potensialet til tidlig React og CouchDB ble utnyttet. Den synkroniserte data i sanntid via JSON. OT. Den ble brukt i selskapets interne arbeid, men den brede anvendeligheten og potensialet i andre områder var åpenbare.

Da vi forsøkte å selge denne teknologien til potensielle kunder, støtte vi på en uventet hindring. I demonstrasjonsvideoen så teknologien vår flott ut og fungerte perfekt, uten problemer. Videoen viste nøyaktig hvordan den fungerer, og ingenting ble simulert. Vi kom opp med og kodet et realistisk bruks-scenario for programvaren.


Det var faktisk dette som ble problemet. Demoen vår fungerte akkurat slik som alle andre som simulerte funksjonaliteten til applikasjonene sine. Spesielt ble informasjonen umiddelbart overført fra A til B, selv når det gjaldt store mediefiler. Etter innlogging så hver bruker nye oppføringer. Med applikasjonen kunne forskjellige brukere samarbeide presist om de samme prosjektene, selv når internettforbindelsen var ustabil et sted på landet. Det var implisitt underforstått i enhver videopresentasjon om produktet laget i After Effects.

Selv om alle visste hva Refresh-knappen var til for, forsto ingen at nettapplikasjonene de ba oss om å lage ofte hadde sine egne begrensninger. Og at hvis de ikke lenger var nødvendige, ville brukeropplevelsen være helt annerledes. Hovedsakelig la de merke til at de kunne "prate" og legge igjen merknader til hverandre, så de begynte å spørre hva som skiller dette fra for eksempel Slack. Uff!

Design av daglig synchronisering

Hvis du allerede har erfaring med programvareutvikling, må det irritere deg å huske at de fleste mennesker ikke kan se på et bilde av grensesnittet og forstå hva det vil gjøre ved interaksjon. For ikke å snakke om hva som skjer innside selve programmet. Å vite at finne ut at brukeren har deaktivert animasjons-effektene og dermed også deaktivere ulike animasjonsmuligheter på nettsiden, for eksempel fjerne skjelvingseffekten på knapper som brukes for å tiltrekke seg oppmerksomhet; å skje — er i stor grad et resultat av kunnskap om hva som ikke kan skje og hva som ikke bør skje. Dette krever en mental modell ikke bare av hva programvaren gjør, men også av hvordan de enkelte delene er koordinert og kommuniserer med hverandre.

Et klassisk eksempel på dette er en bruker som i løpet av tjue minutter stirrer på spinner.gif, og undrer seg over når arbeidet endelig vil bli fullført. Utvikleren ville ha forstått at prosessen sannsynligvis har hengt seg opp, og at gif-en aldri vil forsvinne fra skjermen. Denne animasjonen imiterer arbeidsutførelsen, men har ingen forbindelse med tilstanden til den. I slike tilfeller liker noen teknikere å rulle med øynene, fascinert av graden av misforståelse blant brukerne. Men legg merke til, hvem av dem peker på de roterende klokkene og sier at de faktisk står stille?

Dette er essensen av verdien av sanntid. I dag blir databaser for sanntid fortsatt brukt svært lite, og mange ser på dem med mistillit. De fleste av disse databasene tenderer mot NoSQL-stil, noe som gjør at man vanligvis bruker løsninger basert på Mongo, som det er best å glemme. Men for meg betyr dette komfort i arbeidet med CouchDB, samt å lære seg å designe strukturer som ikke bare en eller annen byråkrat vil klare å fylle med data. Jeg tror jeg bruker tiden min mer effektivt.

Men den virkelige temaen for dette innlegget er det jeg bruker i dag. Ikke av min egen valg, men på grunn av en likegyldig og blindt anvendt bedrifts-politikk. Derfor vil jeg gi en Helt Ærlig og Upartisk sammenligning av to nært beslektede produkter for arbeid med sanntids-databaser fra Google.

I begge navn finnes ordet Fire. Det ene husker jeg med ømhet. Det andre for meg er en annen type ild. Jeg haster ikke med å si navnene deres, fordi så snart jeg gjør det, vil vi møte det første store problemet — navnene.

Det første kalles Firebase Real-Time Database, og det andre — Firebase Cloud Firestore. Begge er produkter fra Firebase suite Google. Deres API-er kalles, henholdsvis, firebase.database(…) og firebase.firestore(…).

Det skjedde fordi Real-Time Database — det er bare den opprinnelige Firebase før det ble kjøpt av Google i 2014. Deretter bestemte Google seg for å lage en kopi som et parallelt produkt Firebase basert på big data fra selskapet, og de kalte det Firestore med skybasert lagring. Jeg håper du ikke er blitt forvirret ennå. Hvis du er det, ikke bekymre deg, jeg skrev denne delen av artikkelen ti ganger.

Fordi det er nødvendig å spesifisere Firebase i spørsmålet om Firebase, og Firestore i spørsmålet om Firebase, i det minste for at folk skulle forstå deg for noen år siden på Stack Overflow.

Hvis det fantes en pris for dårligst navngiving av programvareprodukter, ville dette definitivt vært en seriøs kandidat. Hamming-avstanden mellom disse navnene er så liten at det forvirrer selv erfarne ingeniører, som skriver ett navn selv om tankene deres tenker på et annet. Dette er mislykkede planer, oppfunnet med de beste intensjoner; de oppfyller profetien om at databasen skulle brenne. Jeg tuller ikke. Personen som fant på et slikt navngivningssystem, har forårsaket blod, svette og tårer.

Pyrrhussseier

Man skulle tro at Firestore er en erstatning for Firebase, dens etterfølger av neste generasjon, men det ville vært en misforståelse. Firestore kan absolutt ikke betraktes som en erstatning for Firebase. Det ser ut til at noen har kuttet ut alt det interessante fra det, og forvirret det meste av det som er igjen på forskjellige måter.

Men et raskt blikk på de to produktene kan forvirre deg: det ser ut til at de gjør det samme, gjennom stort sett de samme API-ene og til og med i den samme datasettet. Forskjellene er subtile og oppdages kun ved nøye sammenligning av den omfattende dokumentasjonen. Eller når du prøver å portere perfekt fungerende kode fra Firebase for å få det til å fungere med Firestore. Allerede da oppdager du at databasegrensesnittet lyser opp så snart du prøver å gjøre drag-and-drop i sanntid med musa. Jeg gjentar, jeg tuller ikke.

Firebase-klienten er vennlig i den forstand at den bufferer endringer og utfører automatiske gjentakelsesforsøk på oppdateringer, der den gir prioritet til den sist utførte skriveoperasjonen. Imidlertid har Firestore en begrensning på 1 skriveoperasjon per dokument per bruker per sekund, og denne begrensningen håndheves av serveren. Når du jobber med det, må du selv finne en måte å omgå dette på og implementere en hastighetsbegrensning for oppdateringer, selv når du bare prøver å lage applikasjonen din. Med andre ord er Firestore en sanntidsdatabase uten en sanntidsklient, som forkles som en selv med API.

Her begynner vi å se de første tegnene på meningen med Firestore. Kanskje tar jeg feil, men jeg mistenker at noen høyt oppe i ledelsen hos Google etter oppkjøpet så på Firebase og bare sa: «Nei, Gud nei. Dette er uakseptabelt. Ikke under min ledelse.»

Han kom ut fra sine kammer og proklamerte:

«Én stor JSON-dokument? Nei. Du må dele opp dataene i separate dokumenter, hver med en størrelse på ikke mer enn 1 megabyte.»

Det virker som en slik begrensning ikke vil overleve første møte med en hvilken som helst tilstrekkelig motivert brukerbase. Du vet at det er sant. Hos oss på jobben, for eksempel, har vi over 1500 presentasjoner, og det er helt normalt.

Med en slik begrensning må du akseptere at ett «dokument» i databasen ikke vil ligne noe objekt som brukeren måtte kalle et dokument.

«Arrays av arrays, som kan inneholde andre elementer rekursivt? Nei. Arrays vil bare inneholde objekter eller tall med fast lengde, som opprinnelig ment av Skaperen.»

Så hvis du håpet å plassere GeoJSON i din Firestore, vil du oppdage at det er umulig. Det er ikke tillatt å ha noe ikke-en-dimensjonalt. Jeg håper du liker Base64 og/eller JSON inne i JSON.

«Import og eksport av JSON via HTTP, kommandolinjeverktøy eller administrasjonspanel? Nei. Du kan bare eksportere og importere data i Google Cloud Storage. Sånn ser det ut for øyeblikket. Og når jeg sier 'du', mener jeg bare de som har myndighet som Project Owner. Alle andre kan gå og opprette billetter.»

Som du kan se, er Firebase-datamodellen lett å beskrive. Den inneholder ett stort JSON-dokument som kobler JSON-nøkler med URL-stier. Hvis du skriver inn ved hjelp av HTTP PUT i / Firebase følgende:

{
  "hello": "world"
}

Da GET /hello vil returnere "world". Generelt fungerer dette akkurat som du forventer. Firebase-samlingen av objekter /my-collection/:id er ekvivalent med et JSON-ordbok {"my-collection": {...}} i roten, innholdet som er tilgjengelig i /my-collection:

{
  "id1": {...object},
  "id2": {...object},
  "id3": {...object},
  \// ...
}

Dette fungerer utmerket hvis hver innsats har ID-er uten kollisjoner, noe systemet har en standardløsning for.

Med andre ord er databasen 100 % kompatibel med JSON (*) og fungerer utmerket med HTTP, for eksempel med CouchDB. Men hovedsakelig bruker du den gjennom et sanntids-API som abstraherer websockets, autorisering og abonnementer. Administrasjonspanelet har begge muligheter, som lar deg redigere i sanntid og importere/eksportere JSON. Hvis du holder deg til det samme i koden din, vil du bli overrasket over hvor mye spesialisert kode som forsvinner når du forstår at patch og diff JSON løser 90 % av de rutinemessige oppgavene knyttet til håndtering av permanent tilstand.

Firestore-datamodellen ligner på JSON, men avviker fra den i noen kritiske aspekter. Jeg har allerede nevnt fraværet av arrays inne i arrays. Sub-collections-modellen er slik at de er førstklassige konsepter, adskilt fra det inneholdende JSON-dokumentet. Siden det ikke finnes noen klar serialisering for dette, kreves det en spesialisert kodekjøring for å hente og skrive data. For å håndtere egne samlinger må det skrives egne skripter og verktøy. Administrasjonspanelet lar deg bare gjøre små endringer ett felt om gangen, og har ingen import-/eksportfunksjoner.

De tok en sanntids NoSQL-database og gjorde den til en sakte ikke-SQL med automatisk sammenslåing og en separat kolonne for ikke-JSON. Noe i stil med GraftQL.

Hot Java

Hvis Firestore skulle bli mer pålitelig og skalerbart, er ironien at den gjennomsnittlige utvikleren får en mindre pålitelig løsning enn ved å velge FireBase "rett ut av boksen". Programvaren som den Pirkete Databasesjefen trenger, krever et slikt nivå av innsats og kaliber av spesialister, at det rett og slett ikke er realistisk for nisjen der det antas at et godt produkt skal være. Det er litt som at HTML5 Canvas absolutt ikke er en erstatning for Flash, hvis det ikke finnes utviklingsverktøy og avspillere. Dessuten er Firestore dømt til å streve for datarenslighet og steril validering, noe som rett og slett ikke samsvarer med hvordan den gjennomsnittlige bedriftsbrukeren liker å arbeide: fordi for ham er alt valgfritt, ettersom alt er et utkast helt til slutten.

Den største begrensningen med FireBase er at klienten ble laget flere år før sin tid, lenge før de fleste webutviklere visste om immutabilitet. På grunn av dette antar FireBase at du vil endre data, og dermed utnytter ikke fordelene ved brukerskapt immutabilitet. I tillegg bruker den ikke dataene på nytt i sendte snapshots til brukeren, noe som gjør diff-utførelse mye vanskeligere. For store dokumenter er dens transaksjonsmekanisme basert på endrede diffs helt utilstrekkelig. Folkens, vi har allerede WeakMap det i JavaScript. Det er praktisk.

Hvis man former dataene på riktig måte og ikke lager trærne for omfattende, kan man omgå dette problemet. Men jeg er nysgjerrig på om FireBase ville blitt mye mer interessant dersom utviklerne hadde gitt ut et virkelig godt klient-API som bruker immutabilitet i kombinasjon med seriøse praktiske råd om databasens struktur. I stedet ser det ut til at de har prøvd å fikse noe som ikke er ødelagt, og det har blitt verre.

Jeg kjenner ikke all logikk som lå til grunn for opprettelsen av Firestore. Resonnementene rundt motivene som oppstår inne i en svart boks - det er også en del av underholdningen. En slik sammenligning av to ekstremt like, men uimotståelige databaser oppstår ganske sjelden. Som om noen tenkte: "Firebase er bare en funksjon som vi kan emulere i Google Cloud", men har ennå ikke oppdaget konseptet med å definere krav fra den virkelige verden eller å lage nyttige løsninger som oppfyller alle disse kravene. «La utviklerne tenke på det. Bare gjør UI-en vakker... Kan vi legge til mer fyr?»

Jeg forstår et par ting om datakonstruksjoner. Jeg ser helt klart at konseptet med «alt i ett stort JSON-tre» er et forsøk på å abstrahere enhver følelse av stor-skala-struktur fra databasen. Å forvente at programvaren bare skal håndtere hvilken som helst tvilsom fraktal av datakonstruksjoner er bare galskap. Jeg trenger ikke engang å forestille meg hvor ille det kan være; jeg har gjennomført strenge kodeauditter og sett ting som dere mennesker ikke engang kan drømme om.. Men jeg vet også hvordan gode strukturer ser ut, hvordan man bruker dem, og hvorfor det er nødvendig å gjøre det.Jeg kan forestille meg en verden der Firestore ville virke helt logisk, og menneskene som laget den ville trodd at de hadde gjort en god jobb. Men vi lever ikke i denne verden.

Støtten for å bygge forespørselen i FireBase er dårlig etter enhver standard; den eksisterer så og si ikke. Den trenger absolutt forbedring, eller i det minste en revisjon. Men Firestore er ikke mye bedre, siden den er begrenset av de samme en-dimensjonale indeksene som finnes i enkel SQL. Hvis du trenger forespørslene som folk gjør med kaotiske data, så kreves det fulltekstsøk, filtre på flere områder og vilkårlig rekkefølge direkte av brukeren. Når man ser nøye på den enkle SQL-funksjonen, er den i seg selv for begrenset. I tillegg er de eneste SQL-forespørslene som folk kan utføre i produksjon, raske forespørslene. Du vil trenge en spesialdesignet løsning for indeksering med gjennomtenkte datakonstruksjoner. For alt annet, bør det i det minste være inkrementell map-reduce eller noe lignende.

Hvis du leter etter informasjon om dette i Googles dokumenter, håper jeg du blir peket i retning av noe som BigTable og BigQuery. Men alle disse løsningene er akkompagnert av en mengde tett salgsspråk, slik at du raskt vil gå tilbake og begynne å lete etter noe annet.

Det siste du trenger i tilfelle en sanntidsdatabase, er noe skapt av mennesker og for mennesker som jobber på en lønnsskala for ledere.

(*) Dette er en spøk, det finnes ikke et begrep som kompatibilitet med JSON på 100%.

Advertising

Ser du etter — virtuell dedikert server. en server for debugging av prosjekter og hosting? Da er du virkelig vår kunde 🙂 Daglig betaling for servere i forskjellige konfigurasjoner, antiDDoS og Windows-lisenser er allerede inkludert i prisen.

Kilde: habr.com