Laat me een technisch verhaal vertellen.
Vele jaren geleden was ik een applicatie aan het ontwikkelen waarin samenwerkingsfuncties waren ingebouwd. Het was een gebruiksvriendelijke experimentele stapel die profiteerde van het volledige potentieel van de vroege React en CouchDB. Het synchroniseerde gegevens in realtime via JSON . Het werd intern binnen het bedrijf gebruikt, maar de brede toepasbaarheid en potentie op andere gebieden was duidelijk.
Toen we deze technologie aan potentiële klanten probeerden te verkopen, kwamen we een onverwacht obstakel tegen. In de demovideo zag en werkte onze technologie prima, geen problemen. De video liet precies zien hoe het werkt en imiteerde niets. We bedachten en codeerden een realistisch scenario voor het gebruik van het programma.
In feite werd dit het probleem. Onze demo werkte precies zoals alle anderen hun applicaties simuleerden. Concreet werd informatie onmiddellijk van A naar B overgebracht, zelfs als het om grote mediabestanden ging. Na het inloggen zag elke gebruiker nieuwe vermeldingen. Met behulp van de applicatie konden verschillende gebruikers duidelijk samenwerken aan dezelfde projecten, zelfs als de internetverbinding ergens in het dorp werd onderbroken. Dit wordt impliciet geïmpliceerd in elke productvideo in After Effects.
Hoewel iedereen wist waar de knop Vernieuwen voor diende, begreep niemand echt dat de webapplicaties die ze ons vroegen te bouwen doorgaans aan hun eigen beperkingen onderhevig waren. En dat als ze niet meer nodig zijn, de gebruikerservaring compleet anders zal zijn. Ze merkten vooral dat ze konden ‘chatten’ door briefjes achter te laten voor de mensen met wie ze aan het praten waren, dus vroegen ze zich af hoe dit anders was dan bijvoorbeeld Slack. Opluchting!
Ontwerp van dagelijkse synchronisaties
Als je ervaring hebt met softwareontwikkeling, moet het zenuwslopend zijn om te bedenken dat de meeste mensen niet zomaar naar een afbeelding van een interface kunnen kijken en begrijpen wat deze zal doen als ze ermee interacteren. Om nog maar te zwijgen van wat er in het programma zelf gebeurt. Kennis dat kan gebeuren is grotendeels het resultaat van weten wat niet kan gebeuren en wat niet zou moeten gebeuren. Dit vereist niet alleen wat de software doet, maar ook hoe de afzonderlijke onderdelen ervan zijn gecoördineerd en met elkaar communiceren.
Een klassiek voorbeeld hiervan is een gebruiker die naar een spinner.gif, benieuwd wanneer de werkzaamheden eindelijk klaar zullen zijn. De ontwikkelaar zou zich gerealiseerd hebben dat het proces waarschijnlijk vastliep en dat de gif nooit van het scherm zou verdwijnen. Deze animatie simuleert de uitvoering van een taak, maar is niet gerelateerd aan de staat ervan. In dergelijke gevallen rollen sommige techneuten graag met hun ogen, verbaasd over de omvang van de verwarring bij de gebruiker. Merk echter op hoeveel van hen naar de draaiende klok wijzen en zeggen dat deze feitelijk stilstaat?
Dit is de essentie van real-time waarde. Tegenwoordig worden realtime databases nog steeds weinig gebruikt en veel mensen bekijken ze met argwaan. De meeste van deze databases neigen sterk naar de NoSQL-stijl en daarom gebruiken ze meestal op Mongo gebaseerde oplossingen, die je het beste kunt vergeten. Voor mij betekent dit echter dat ik me op mijn gemak moet voelen bij het werken met CouchDB, en dat ik structuren moet leren ontwerpen die meer dan alleen een bureaucraat met gegevens kan vullen. Ik denk dat ik mijn tijd beter gebruik.
Maar het echte onderwerp van dit bericht is wat ik vandaag gebruik. Niet uit vrije keuze, maar vanwege het onverschillig en blindelings toegepaste bedrijfsbeleid. Daarom geef ik een volledig eerlijke en onbevooroordeelde vergelijking van twee nauw verwante realtime databaseproducten van Google.
Beiden hebben het woord Vuur in hun naam. Eén ding herinner ik me met veel plezier. Het tweede voor mij is een ander soort vuur. Ik heb geen haast om hun namen te zeggen, want als ik dat eenmaal doe, komen we het eerste grote probleem tegen: namen.
De eerste wordt gebeld Firebase realtime database, en ten tweede - Firebase Cloud Firestore. Het zijn allebei producten van Firebase-suite Googlen. Hun API's worden respectievelijk aangeroepen firebase.database(…) и firebase.firestore(…).
Dit gebeurde omdat Realtime database - het is gewoon het origineel Firebase vóór de aankoop door Google in 2014. Toen besloot Google om een parallel product te creëren kopiëren Firebase is gebaseerd op een big data-bedrijf en noemde het Firestore met een cloud. Ik hoop dat je nog niet in de war bent. Als je nog steeds in de war bent, maak je geen zorgen, ik heb dit deel van het artikel zelf tien keer herschreven.
Omdat je het moet aangeven Firebase in de Firebase-vraag, en brandweerkazerne in een vraag over Firebase, tenminste om je een paar jaar geleden te laten begrijpen op Stack Overflow.
Als er een prijs zou bestaan voor de slechtste ervaring met softwarenaamgeving, zou dit zeker een van de kanshebbers zijn. De Hamming-afstand tussen deze namen is zo klein dat het zelfs ervaren ingenieurs in verwarring brengt, wier vingers de ene naam typen terwijl hun hoofd aan een andere denkt. Dit zijn goedbedoelde plannen die jammerlijk mislukken; ze vervulden de profetie dat de database in brand zou staan. En ik maak helemaal geen grapje. De persoon die dit naamgevingsschema bedacht heeft, zorgde voor bloed, zweet en tranen.
Pyrrusoverwinning
Je zou denken dat Firestore dat wel is vervanging Firebase, de afstammeling van de volgende generatie, maar dat zou misleidend zijn. Firestore is niet gegarandeerd een geschikte vervanging voor Firebase. Het lijkt erop dat iemand al het interessante eruit heeft gehaald en de rest op verschillende manieren heeft verward.
Een snelle blik op de twee producten kan u echter in verwarring brengen: ze lijken hetzelfde te doen, via in principe dezelfde API's en zelfs in dezelfde databasesessie. De verschillen zijn subtiel en komen alleen aan het licht door zorgvuldig vergelijkend onderzoek van uitgebreide documentatie. Of wanneer u code probeert over te zetten die perfect werkt op Firebase, zodat deze werkt met Firestore. Zelfs dan kom je erachter dat de database-interface oplicht zodra je in realtime met de muis probeert te slepen en neerzetten. Ik herhaal: ik maak geen grapje.
De Firebase-client is beleefd in de zin dat hij wijzigingen buffert en automatisch updates probeert uit te voeren die prioriteit geven aan de laatste schrijfbewerking. Firestore heeft echter een limiet van 1 schrijfbewerking per document per gebruiker per seconde, en deze limiet wordt afgedwongen door de server. Wanneer u ermee werkt, is het aan u om er een weg omheen te vinden en een updatesnelheidsbegrenzer te implementeren, zelfs als u alleen maar uw applicatie probeert te bouwen. Dat wil zeggen, Firestore is een realtime database zonder een realtime client, die zich voordoet als een database die een API gebruikt.
Hier beginnen we de eerste tekenen te zien van het bestaansrecht van Firestore. Ik heb het misschien mis, maar ik vermoed dat iemand hoog in het management van Google na de aankoop naar Firebase heeft gekeken en eenvoudigweg heeft gezegd: 'Nee, oh mijn God, nee. Dit is niet aanvaardbaar. Alleen niet onder mijn leiding."
Hij verscheen uit zijn kamers en verklaarde:
“Eén groot JSON-document? Nee. Je splitst de gegevens op in afzonderlijke documenten, die elk niet groter zijn dan 1 megabyte.”
Het lijkt erop dat een dergelijke beperking de eerste ontmoeting met een voldoende gemotiveerde gebruikersbasis niet zal overleven. Je weet dat het zo is. Op het werk hebben we bijvoorbeeld meer dan anderhalfduizend presentaties, en dit is volkomen normaal.
Met deze beperking wordt u gedwongen het feit te accepteren dat één "document" in de database niet zal lijken op een object dat een gebruiker een document zou kunnen noemen.
"Arrays van arrays die recursief andere elementen kunnen bevatten? Nee. Arrays zullen alleen objecten of getallen met een vaste lengte bevatten, zoals God het bedoeld heeft."
Dus als u hoopte GeoJSON in uw Firestore te plaatsen, zult u merken dat dit niet mogelijk is. Niets dat niet eendimensionaal is, is aanvaardbaar. Ik hoop dat je Base64 en/of JSON binnen JSON leuk vindt.
“JSON importeren en exporteren via HTTP, opdrachtregelhulpmiddelen of beheerderspaneel? Nee. U kunt alleen gegevens exporteren en importeren naar Google Cloud Storage. Zo heet het nu, denk ik. En als ik 'jij' zeg, richt ik me alleen tot degenen die over de inloggegevens voor een projecteigenaar beschikken. Alle anderen kunnen kaartjes gaan maken."
Zoals u kunt zien, is het FireBase-datamodel eenvoudig te beschrijven. Het bevat één enorm JSON-document dat JSON-sleutels koppelt aan URL-paden. Als je schrijft met HTTP PUT в / FireBase is het volgende:
{
"hello": "world"
}
de GET /hello zal terugkeren "world". In principe werkt het precies zoals je zou verwachten. Verzameling FireBase-objecten /my-collection/:id gelijk aan een JSON-woordenboek {"my-collection": {...}} in de root, waarvan de inhoud beschikbaar is in /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Dit werkt prima als elke insert een botsingsvrije ID heeft, waarvoor het systeem een standaardoplossing heeft.
Met andere woorden: de database is 100% JSON(*)-compatibel en werkt uitstekend met HTTP, zoals CouchDB. Maar in principe gebruik je het via een realtime API die websockets, autorisatie en abonnementen abstraheert. Het beheerderspaneel heeft beide mogelijkheden, waardoor zowel realtime bewerken als JSON-import/export mogelijk is. Als u hetzelfde in uw code doet, zult u verbaasd zijn over de hoeveelheid gespecialiseerde code die wordt verspild als u zich realiseert dat patch- en diff-JSON 90% van de routinetaken van het afhandelen van de persistente status oplost.
Het Firestore-gegevensmodel is vergelijkbaar met JSON, maar verschilt op enkele cruciale punten. Ik noemde al het gebrek aan arrays binnen arrays. Het model voor subcollecties is dat het eersteklas concepten zijn, los van het JSON-document dat ze bevat. Omdat hiervoor geen kant-en-klare serialisatie bestaat, is een gespecialiseerd codepad nodig om gegevens op te halen en te schrijven. Om uw eigen collecties te verwerken, moet u uw eigen scripts en tools schrijven. In het beheerderspaneel kunt u slechts één veld tegelijk kleine wijzigingen aanbrengen en beschikt het niet over import-/exportmogelijkheden.
Ze namen een realtime NoSQL-database en veranderden deze in een langzame niet-SQL met auto-join en een aparte niet-JSON-kolom. Iets als GraftQL.
Heet Java
Als Firestore betrouwbaarder en schaalbaarder zou zijn, dan is de ironie dat de gemiddelde ontwikkelaar met een minder betrouwbare oplossing zal eindigen dan wanneer hij out-of-the-box voor FireBase kiest. Het soort software dat de chagrijnige databasebeheerder nodig heeft, vereist een niveau van inspanning en talent dat eenvoudigweg onrealistisch is voor de niche waarin het product goed zou moeten zijn. Dit is vergelijkbaar met hoe HTML5 Canvas helemaal geen vervanging is voor Flash als er geen ontwikkeltools en een speler zijn. Bovendien zit Firestore vast in een verlangen naar gegevenszuiverheid en steriele validatie die eenvoudigweg niet aansluit bij de manier waarop de gemiddelde zakelijke gebruiker houdt van werken: voor hem is alles optioneel, want tot het einde toe is alles een schets.
Het grootste nadeel van FireBase is dat de client zijn tijd een aantal jaren vooruit was, voordat de meeste webontwikkelaars op de hoogte waren van onveranderlijkheid. Hierdoor gaat FireBase ervan uit dat u de gegevens wijzigt en maakt daarom geen gebruik van de door de gebruiker geleverde onveranderlijkheid. Bovendien hergebruikt het de gegevens niet in de snapshots die het aan de gebruiker doorgeeft, wat diff veel moeilijker maakt. Voor grote documenten is het veranderlijke, op diff gebaseerde transactiemechanisme eenvoudigweg ontoereikend. Jongens, dat hebben we al gedaan WeakMap in JavaScript. Het is comfortabel.
Als je de gegevens de gewenste vorm geeft en de bomen niet te volumineus maakt, kan dit probleem worden omzeild. Maar ik ben benieuwd of FireBase veel interessanter zou zijn als de ontwikkelaars een echt goede client-API zouden uitbrengen die onveranderlijkheid zou gebruiken, gecombineerd met serieus praktisch advies over databaseontwerp. In plaats daarvan leken ze te proberen te repareren wat niet kapot was, en dat maakte het nog erger.
Ik ken niet alle logica achter de oprichting van Firestore. Speculeren over de motieven die binnen de zwarte doos ontstaan, maakt ook deel uit van het plezier. Deze nevenschikking van twee uiterst vergelijkbare maar onvergelijkbare databases is vrij zeldzaam. Het is alsof iemand dacht: "Firebase is slechts een functie die we kunnen emuleren in Google Cloud", maar heeft nog niet het concept ontdekt van het identificeren van vereisten uit de echte wereld of het creëren van bruikbare oplossingen die aan al deze vereisten voldoen. “Laat de ontwikkelaars erover nadenken. Maak de gebruikersinterface gewoon mooi... Kun je meer vuur toevoegen?'
Ik begrijp een paar dingen over datastructuren. Ik zie het concept "alles in één grote JSON-boom" absoluut als een poging om elk gevoel van grootschalige structuur uit de database te abstraheren. Verwachten dat software eenvoudigweg elke dubieuze datastructuurfractal aankan, is gewoon krankzinnig. Ik hoef me niet eens voor te stellen hoe erg de dingen zouden kunnen zijn, ik heb rigoureuze code-audits gedaan en Ik heb dingen gezien waar jullie nooit van hadden gedroomd. Maar ik weet ook hoe goede structuren eruitzien, и . Ik kan me een wereld voorstellen waarin Firestore logisch lijkt en de mensen die het hebben gemaakt zouden denken dat ze het goed hebben gedaan. Maar wij leven niet in deze wereld.
De ondersteuning voor zoekopdrachten van FireBase is in alle opzichten slecht en bestaat vrijwel niet. Het behoeft zeker verbetering of op zijn minst herziening. Maar Firestore is niet veel beter omdat het beperkt is tot dezelfde eendimensionale indexen als in gewone SQL. Als je zoekopdrachten nodig hebt die mensen uitvoeren op basis van chaotische gegevens, heb je zoeken in de volledige tekst, filters met meerdere bereiken en een aangepaste, door de gebruiker gedefinieerde volgorde nodig. Bij nader inzien zijn de functies van gewone SQL op zichzelf te beperkt. Bovendien zijn snelle query's de enige SQL-query's die mensen in productie kunnen uitvoeren. U heeft een aangepaste indexeringsoplossing met slimme datastructuren nodig. Voor al het andere zou er op zijn minst een incrementele map-reduce of iets dergelijks moeten zijn.
Als je in Google Documenten naar informatie hierover zoekt, word je hopelijk in de richting van zoiets als BigTable en BigQuery verwezen. Al deze oplossingen gaan echter gepaard met zoveel compact zakelijk verkoopjargon dat u snel zult terugkeren en op zoek gaat naar iets anders.
Het laatste wat je wilt met een realtime database is iets dat is gemaakt door en voor mensen op managementsalarisschalen.
(*) Dit is een grap, er bestaat niet zoiets als .
Als advertentie
Zoeken naar voor het debuggen van projecten, een server voor ontwikkeling en hosting? Jij bent zeker onze klant 🙂 Dagelijkse prijzen voor servers met verschillende configuraties, anti-DDoS- en Windows-licenties zijn al bij de prijs inbegrepen.
Bron: www.habr.com