Denna databas brinner...

Låt mig berätta en teknisk historia.

För många år sedan utvecklade jag en applikation med inbyggda samarbetsfunktioner. Det var en bekväm experimentell stack som utnyttjade den fulla potentialen hos tidig React och CouchDB. Den synkroniserade data i realtid via JSON. OT. Den användes i företagets interna arbete, men det var uppenbart att dess breda tillämpbarhet och potential i andra områden var tydlig.

När vi försökte sälja denna teknik till potentiella kunder stötte vi på ett oväntat hinder. I demovideon såg vår teknik ut att fungera utmärkt, och det fanns inga problem här. Videon visade exakt hur det fungerade, och inget simulerades. Vi kom på och kodade ett realistiskt användningsscenario för programmet.


Problemet blev faktiskt just detta. Vår demo fungerade precis som alla andra som simulerade funktionerna i sina applikationer. Specifikt, informationen överfördes omedelbart från A till B, även om det handlade om stora mediafiler. Efter inloggning såg varje användare nya poster. Med hjälp av applikationen kunde olika användare samarbeta tydligt på samma projekt, även om internetanslutningen avbröts någonstans i byn. Detta underförstått är vad som visas i vilket klipp som helst som klippts i After Effects om produkten.

Trots att alla visste vad knappen Refresh var bra för, förstod ingen vad webbtjänsterna de bad oss skapa vanligtvis var begränsade av. Och att om de inte längre behövdes skulle användarupplevelsen se helt annorlunda ut. Oftast märkte de att man kunde 'chatta' och lämna meddelanden till andra, så de undrade vad som skiljde sig från exempelvis Slack. Uff!

Design av vardagliga synkroniseringar

Om du redan har erfarenhet av mjukvaruutveckling måste det irritera dig att komma ihåg att de flesta människor inte kan ta en titt på en skärmbild av gränssnittet och förstå vad det kommer att göra när de interagerar med det. För att inte tala om vad som pågår inuti själva programmet. Kunskapen om vad hantera plötsliga kraschar och visa användbara detaljer för felsökning, som stacktrace. Att skicka felmeddelanden har förenklats — det räcker att klicka på länken. som kan hända är till stor del resultaten av kunskapen om vad som inte kan hända och vad som inte bör hända. Detta krävs. mental modell inte bara vad programvaran gör, utan också hur dess olika delar samverkar och kommunicerar.

Ett klassiskt exempel på detta är en användare som under tjugo minuter tittar på spinner.gif, och undrar när arbetet äntligen kommer att slutföras. Utvecklaren skulle ha förstått att processen troligen har frusit, och att gif:en aldrig kommer att försvinna från skärmen. Denna animation imiterar ett arbete, men är inte kopplad till dess tillstånd. I sådana fall brukar vissa tekniker rulla med ögonen, förvånade över hur vilseledda användarna är. Men märk vem av dem som pekar på de snurrande klockorna och säger att de faktiskt står stilla?

Det är kärnan i värdet av realtid. Idag används realtidsdatabaser fortfarande mycket lite, och många är misstänksamma mot dem. De flesta sådana databaser lutar sig aktivt mot NoSQL-stilen, vilket gör att man ofta använder lösningar baserade på Mongo, som det är bäst att glömma. Men för mig betyder det en bekväm arbetsmiljö med CouchDB, samt att studera design av strukturer som inte bara en byråkrat kan fylla med data. Jag tror att jag använder min tid mer effektivt.

Men ämnet för detta inlägg är vad jag faktiskt använder idag. Inte av eget val, utan på grund av en likgiltig och blindt tillämpad företagsstrategi. Därför kommer jag att ge en Helt Ärlig och Opartisk jämförelse av två nära relaterade produkter för att arbeta med realtidsdatabaser från Google.

I båda namnen finns ordet Fire. Det ena minns jag med ömhet. Det andra för mig är en annan typ av eld. Jag skyndar mig inte att säga deras namn, eftersom så snart jag gör det, kommer vi att möta det första stora problemet — namnen.

Den första heter Firebase Real-Time Database, och den andra — Firebase Cloud Firestore. Båda är produkter från Firebase suite Google. Deras API:er heter, respektive, firebase.database(…) och firebase.firestore(…).

Det hände så att Real-Time Database är helt enkelt originalet Firebase innan dess köptes av Google 2014. Därefter beslutade Google att skapa en parallell produkt som en kopia av Firebase baserat på företagets big data, och kallade den Firestore with a cloud. Jag hoppas att du inte blivit förvirrad. Om du trots allt har blivit förvirrad, oroa dig inte, jag har själv skrivit om denna del av artikeln tio gånger.

För det är viktigt att påpeka Firebase i fråga om Firebase, och Firestore i fråga om Firebase, åtminstone för att ni skulle bli förstådda för några år sedan på Stack Overflow.

Om det fanns ett pris för den sämsta namngivningen av programvaruprodukter, skulle detta fall definitivt vara en av pristagarna. Hamming-avståndet mellan dessa namn är så litet att det förvirrar även erfarna ingenjörer vars fingrar skriver ett namn medan huvudet tänker på ett annat. Det här är misslyckade planer som skapades med de bästa avsikter; de har uppfyllt profetian om att databasen skulle vara i brand. Och jag skämtar inte. Personen som kom på ett sådant namngivningssystem har orsakat blod, svett och tårar.

Pyrrhusseger

Man skulle kunna tro att Firestore är en ersättning för Firebase, dess efterföljare i nästa generation, men det skulle vara en missuppfattning. Firestore passar garanterat inte som en ersättning för Firebase. Det verkar som om någon har skurit bort allt intressant från det och förvirrat stor del av det kvarvarande på olika sätt.

Dock kan en snabb blick på de två produkterna lura dig: det verkar som om de gör ungefär samma sak, genom för det mesta liknande API och till och med i samma databas-session. Skillnaderna är svåra att upptäcka och märks först vid noggrant jämförande studier av omfattande dokumentation. Eller när man försöker portera perfekt fungerande Firebase-kod så att den fungerar med Firestore. Redan då upptäcker du att databasgränssnittet glöder så snart du försöker utföra drag-and-drop i realtid. Jag upprepar, jag skämtar inte.

Firebase-klienten är artig i den bemärkelsen att den buffrar ändringar och gör automatiska omförsök för uppdateringar, där den senaste skrivoperationen prioriteras. Men Firestore har en begränsning på 1 skrivoperation per dokument per användare per sekund, och denna begränsning tillämpas av servern. När du arbetar med den måste du själv hitta sätt att kringgå den och implementera en skopbegränsare för uppdateringar, även när du bara försöker skapa din applikation. Det vill säga Firestore är en databas för realtid utan en klient för realtid, som maskerar sig själv som en med hjälp av API.

Här börjar vi se de första tecknen på syftet med Firestore. Kanske har jag fel, men jag misstänker att någon högt upp i Googles ledning såg på Firebase efter köpet och bara sa: "Nej, herregud, nej. Det här är oacceptabelt. Inte under min ledning."

Han kom ut från sina rum och utropade:

„En stor JSON-dokument? Nej. Du kommer att dela upp data i separata dokument, var och en med en storlek på högst 1 megabyte.”

Det verkar som en sådan begränsning inte kommer att överleva det första mötet med en tillräckligt motiverad användarbas. Du vet att det är sant. På vårt arbete, till exempel, har vi drygt ett och ett halvt tusen presentationer, och det är Helt Normalt.

Med en sådan begränsning kommer du att behöva acceptera faktum att ett "dokument" i databasen inte kommer att likna något objekt som en användare skulle kalla ett dokument.

„Array av arrayer som kan rekursivt innehålla andra element? Nej. Arrayer kommer endast att innehålla objekt eller fasta längdnummer, precis som Herren avsåg.”

Så om du hoppades att kunna placera GeoJSON i din Firestore, kommer du att upptäcka att det är omöjligt. Inga icke-en-dimensionella element är tillåtna. Jag hoppas att du gillar Base64 och/eller JSON inuti JSON.

„Import och export av JSON via HTTP, kommandoradsverktyg eller adminpanel? Nej. Du kan endast exportera och importera data i Google Cloud Storage. Så verkar det nu heta. Och när jag säger "du", riktar jag mig endast till dem som har befogenheter som Projektägare. Alla andra kan gå och skapa biljetter.”

Som ni ser, är FireBases datamodell lätt att beskriva. Den innehåller ett enormt JSON-dokument som kopplar JSON-nycklar till URL-vägar. Om du skriver med HTTP PUT på / FireBase följande:

{
  "hello": "world"
}

Då GET /hello kommer att returnera "world". I huvudsak fungerar det precis som du förväntar dig. Samlingen av FireBase-objekt /my-collection/:id är likvärdig med en JSON-dictionary {"my-collection": {...}} i roten, vars innehåll är tillgängligt i /my-collection:

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

Det fungerar utmärkt om varje insättning har ID utan kollisioner, för vilket det finns en standardlösning i systemet.

Med andra ord är databasen 100 % kompatibel med JSON (*) och fungerar utmärkt med HTTP, som exempelvis CouchDB. Men främst använder du den via ett realtids-API som abstraherar websockets, autentisering och prenumerationer. Administrationspanelen har båda funktionerna, vilket gör det möjligt att både redigera i realtid och importera/exportera JSON. Om du följer samma mönster i din kod kommer du att bli förvånad över hur mycket specialiserad kod som försvinner när du inser att patch och diff JSON löser 90 % av de rutinmässiga uppgifterna för att hantera det permanenta tillståndet.

Firestore datamodell liknar JSON, men skiljer sig från det på några kritiskt viktiga punkter. Jag har redan nämnt avsaknaden av arrayer inom arrayer. Sub-kollektioner är koncept av första klass, separata från sitt innehållande JSON-dokument. Eftersom det inte finns någon färdig serialisering för detta, krävs en specialiserad kodkörningsväg för att hämta och skriva data. För att hantera egna kollektioner måste du skriva egna skript och verktyg. Administrationspanelen tillåter dig att göra små ändringar ett fält i taget och har inga import/export-funktioner.

De tog en realtids NoSQL-databas och gjorde den till en långsam icke-SQL med auto-sammanslagning och en separat kolumn som inte är JSON. Något i stil med GraftQL.

Het Java

Om Firestore skulle bli mer pålitligt och skalbart, är ironin att den genomsnittliga utvecklaren får en mindre pålitlig lösning än om man väljde Firebase "ur lådan". Den programvara som den Grinande Databasadministratören behöver kräver en sådan nivå av insats och kompetens att det helt enkelt är orealistiskt för en nisch där man förväntar sig en bra produkt. Det är som att HTML5 Canvas inte på något sätt kan ersätta Flash utan utvecklingsverktyg och spelare. Dessutom har Firestore drabbats av en besatthet av datarenslighet och steril validering som helt enkelt inte matchar hur en genomsnittlig affärsanvändare föredrar att arbeta: för honom är ingenting nödvändigt, eftersom allt till slut är ett utkast.

Den största nackdelen med FireBase är att klienten skapades flera år tidigare än planerat, långt innan de flesta webbutvecklare kände till immutabilitet. Därför förutsätter FireBase att du kommer att förändra data, och utnyttjar inte fördelarna med användarens immutabilitet. Dessutom återanvänder den inte data i de snapshots som skickas till användaren, vilket gör det mycket svårare att utföra diff. För stora dokument är dess transaktionsmekanism baserad på föränderliga diff helt enkelt otillräcklig. Vi har ju redan WeakMap i JavaScript. Det är bekvämt.

Om man ger data rätt form och inte gör träden för omfattande, kan man kringgå detta problem. Men jag undrar om FireBase skulle bli mycket mer intressant om utvecklarna släppte en verkligt bra klient-API som använde immutabilitet i kombination med seriös praktisk vägledning om databasstruktur. Istället verkar de ha försökt fixa något som inte är trasigt, och det har blivit sämre.

Jag känner inte till all logik som låg bakom skapandet av Firestore. Funderingar om motivationer som uppstår inom en svart låda är också en del av underhållningen. Sådan kontrast mellan två extremt liknande men oför jämförbara databaser är ganska sällsynt. Som om någon tänkte: «Firebase är bara en funktion som vi kan emulera i Google Cloud», men samtidigt inte har förstått konceptet att definiera verkliga krav eller skapa användbara lösningar som uppfyller alla dessa krav. «Låt utvecklarna tänka på det. Gör bara UI:t snyggt... Kan vi lägga till mer eld?»

Jag förstår några saker om datastrukturer. Jag ser tydligt att konceptet "allt i ett stort JSON-träd" är ett försök att avskilja databasen från en känsla av stor skala. Att förvänta sig att mjukvaran bara klarar av en tveksam fraktal av datastrukturen är ren galenskap. Jag behöver inte ens föreställa mig hur illa allt kan bli, jag har gjort strikta kodgranskningar och sett saker som ni människor inte ens kan drömma om. Men jag vet också hur bra strukturer ser ut, hur man använder dem och och varför man bör göra det.Jag kan föreställa mig en värld där Firestore skulle verka fullt logisk, och de som skapade den skulle tro att de hade gjort ett gott arbete. Men vi lever inte i denna värld.

Stödet för att bygga frågor i FireBase är dåligt enligt vilken standard som helst, det finns nästan inget. Det kräver definitivt förbättring eller åtminstone en översyn. Men Firestore är inte mycket bättre, eftersom den är begränsad till de samma endimensionella index som finns i enkel SQL. Om du behöver frågor som människor utför med kaotiska data, så behövs fulltextsökning, filter på flera intervall och en godtycklig användardefinierad ordning. Vid noggrann granskning är funktionerna i enkel SQL själva för begränsade. Dessutom är de enda SQL-frågor som människor kan utföra i produktion snabba frågor. Du kommer att behöva en specialanpassad lösning för indexing med genomtänkta datastrukturer. För allt annat bör det åtminstone finnas en inkrementell map-reduce eller något liknande.

Om du söker information om detta i Googles dokumentation, hoppas jag att du blir hänvisad till något som BigTable och BigQuery. Men alla dessa lösningar åtföljs av en mängd tjock företagsjargong, så du kommer snabbt att återvända och börja söka efter något annat.

Det sista du behöver i en realtidsdatabas är något som skapats av människor och för människor som arbetar enligt löneskala för ledningen.

(*) Det är ett skämt, det finns inget begrepp som 100% JSON-kompatibilitet.

I reklamens namn

Letar du efter är en virtuell dedikerad server. en server för utveckling och hosting av projekt? Då är du precis vår kund 🙂 Dygnsprissättning för servrar av olika konfigurationer, antiDDoS och Windows-licenser ingår redan i priset.

Källa: habr.com