Engedje meg, hogy meséljek egy technikai történetet.
Sok évvel ezelőtt egy olyan alkalmazást fejlesztettem, amelyben kollaborációs funkciók voltak beépítve. Ez egy kényelmes kísérleti stack volt, amely a korai React és CouchDB teljes potenciálját kihasználta. Valós időben szinkronizálta az adatokat JSON-on keresztül. . Ezt a vállalat belső munkáiban használták, de a széleskörű alkalmazhatóság és a többi területen rejlő potenciál világos volt.
Amikor próbáltuk eladni a potenciális ügyfeleknek ezt a technológiát, váratlan akadályba ütköztünk. A bemutató videóban a technológiánk remekül nézett ki és működött, itt semmiféle probléma nem volt. A videó pontosan azt mutatta, hogyan működik, és semmi nem volt manipulálva benne. Egy valósághű használati forgatókönyvet találtunk ki és kódoltunk.
Valójában ez lett a probléma. A demónk pontosan úgy működött, ahogy mindenki más is utánozta az alkalmazásainak működését. Konkrétan az információ azonnal átkerült A-ból B-be, még akkor is, ha nagy médiafájlokról volt szó. A belépés után minden felhasználó új bejegyzéseket látott. Az alkalmazás segítségével a különböző felhasználók világosan tudtak együtt dolgozni ugyanazokon a projekteken, még ha valahol a faluban megszakadt is az internetkapcsolat. Ez utóbbira bármely After Effects-ben készült termékvideóban közvetve utalnak.
Bár mindenki tudta, mire való a Frissítés gomb, senki nem értette meg, hogy a webalkalmazások, amelyeket kérnek tőlünk, általában korlátozásokkal bírnak. És hogy ha ezek már nem szükségesek, a felhasználói tapasztalat teljesen más lesz. Főként azt vették észre, hogy lehet "csetelni", jegyzeteket hagyva a beszélgetőpartnereiknek, ezért azon tűnődtek, miben különbözik ez például a Slacktől. Hűha!
A mindennapi szinkronizálások tervezése
Ha már van szoftverfejlesztési tapasztalata, a legidegesítőbb dolog az, hogy emlékeznie kell arra, hogy a legtöbb ember nem képes egyszerűen ránézni a felhasználói felület képére és megérteni, mit fog tenni, amikor kölcsönhatásba lép vele. Nem is beszélve arról, mi történik magában a programban. Az, hogy mi képes történhet — nagymértékben azon tudás eredménye, hogy mi nem történhet meg és mi nem is kellene, hogy megtörténjen. Ehhez szükséges nemcsak arra, amit a szoftver csinál, hanem arra is, hogyan vannak összhangban és hogyan kommunikálnak egymással az egyes részei.
A klasszikus példa erre egy felhasználó, aki húsz percig nézi a spinner.gif, találgatva, mikor ér véget végre a folyamat. A fejlesztő megértené, hogy a folyamat valószínűleg lefagyott, és hogy a gif soha nem fog eltűnni a képernyőről. Ez az animáció imitálja a munka elvégzését, de nincs köze a tényleges állapotához. Ilyen esetekben egyes technikai szakemberek szeretik a szemüket forgatni, csodálkozva a felhasználók tévedésének mértékén. De észrevetted, hogy ki mutat a forgó órákra, és mondja, hogy valójában mozdulatlanok?
Ez a valós idejű értékének lényege. Manapság a valós idejű adatbázisokat még mindig nagyon kevésbé használják, és sokan gyanakvással viseltetnek irántuk. A legtöbb ilyen adatbázis aktívan hajlik a NoSQL stílushoz, ezért általában a Mongo alapú megoldásokat használják, amelyeket jobb lenne elfelejteni. De számomra ez a CouchDB-vel való kényelmes munka és olyan struktúrák tervezésének tanulmányozását jelenti, amelyeket nemcsak valamilyen bürokrata tud feltölteni adatokkal. Azt hiszem, jobban kihasználom az időmet.
De a posztom valódi témája az, amit ma használok. Nem a választásom miatt, hanem a közömbösen és vakon alkalmazott vállalati politika miatt. Ezért bemutatok egy Teljesen Őszinte és Pártatlan összehasonlítást két, szorosan összefonódó termékről, amelyek valós idejű adatbázisokkal foglalkoznak a Google-től.
Mindkét névben szerepel a Fire szó. Az egyiket szeretettel emlékezem, a másik számomra másfajta tüzet jelent. Nem sietek kimondani a nevüket, mert amint ezt megteszem, szembesülnünk kell az első nagy problémával – a nevekkel.
Az első neve Firebase Real-Time Database, a második pedig Firebase Cloud Firestore. Mindkettő a Firebase suite Google-től. Az API-juk neve, megfelelően, firebase.database(…) és firebase.firestore(…).
Így alakult, mert a Real-Time Database csupán a forrása Firebase a Google általi megvásárlás előtt, 2014-ben. Ezután a Google úgy döntött, hogy párhuzamos termékként létrehozza a másolatát Firebase a cég big data-jának alapjával, és elnevezte Firestore-nak egy felhőben. Remélem, még nem zavarodtál össze. Ha mégis összezavarodtál, ne aggódj, én magam tízszer írtam át ezt a cikk részét.
Mert meg kell mutatni Firebase a Firebase-szal kapcsolatban, és Firestore a Firebase-szal kapcsolatban, legalábbis, hogy néhány évvel ezelőtt a Stack Overflow-n megértsenek.
Ha létezne díj a legrosszabb szoftvertermékek elnevezéséért, akkor ez a példa határozottan egyik jelölt lenne. A Hamming-távolság e nevek között annyira kicsi, hogy még a tapasztalt mérnököket is összezavarja, akiknek az ujjaik egy nevet írnak be, miközben a fejük másra gondol. Ezek kudarccal végződött tervek, amelyeket a legjobb szándékkal találtak ki; beteljesítették azt a próféciát, hogy az adatbázis lángba fog borulni. És egyáltalán nem viccelek. Az a személy, aki ilyen elnevezési sémát alkotott, vér, verejték és könnyek okozója lett.
Pyrrhoszi győzelem
El lehetne gondolkodni azon, hogy a Firestore egy helyettesítője a Firebase-nek, a következő generációs utódjának, de ez tévedés lenne. A Firestore nem alkalmas a Firebase helyettesítésére. Úgy tűnik, hogy valaki mindent érdekeset eltávolított belőle, míg a maradékot különböző módokon összezavarta.
Azonban egy gyors pillantás a két termékre megtévesztő lehet: úgy tűnik, mintha ugyanazt csinálnák, lényegében azonos API-kon keresztül, és még ugyanabban az adatbázis-munkamenetben is. A különbségek alig észlelhetők, és csak alapos összehasonlító tanulmányozással deríthetők ki a terjedelmes dokumentációban. Vagy amikor megpróbálod portolni a tökéletesen működő Firebase kódot, hogy az Firestore-ban is működjön. Már akkor kiderül, hogy az adatbázis felülete lángra lobban, amint megpróbálod az egérrel valós időben áthúzni. Ismétlem, nem viccelek.
A Firebase kliens udvarias abban az értelemben, hogy pufferezi a módosításokat és automatikus ismétlési kísérleteket hajt végre, ahol az utolsó írási művelet élvez prioritást. Azonban a Firestore-nak van egy korlátozása, miszerint 1 írási művelet lehet egy dokumentummal egy felhasználóra másodpercenként, és ezt a korlátozást a szerver alkalmazza. Amikor ezzel dolgozol, neked magadnak kell megtalálnod a módját, hogy kijátszd, és megvalósítsd a frissítési ráta korlátozót, még akkor is, amikor csak az alkalmazásod létrehozására próbálsz törekedni. Tehát a Firestore egy valós idejű adatbázis, amely valós idejű kliens nélkül működik, amely API-n keresztül álcázza magát.
Ezen kezdjük látni a Firestore létezésének első jeleit. Lehet, hogy tévedek, de gyanítom, hogy valaki a Google vezetésében, miután megvásárolták a Firebase-t, egyszerűen azt mondta: „Nem, istenem, nem. Ez elfogadhatatlan. Csak ne az én irányításom alatt.”
Kijött a szobájából, és azt hirdette:
„Egy nagy JSON dokumentum? Nem. Külön dokumentumokra kell bontanod az adatokat, mindegyik maximum 1 megabájtos mérettel.”
Úgy tűnik, hogy egy ilyen korlátozás nem fogja túlélni az első találkozást egy eléggé motivált felhasználói bázissal. Tudod, hogy így van. Nálunk például több mint ezerötszáz prezentáció van, és ez Teljesen Normális.
Egy ilyen korlátozással el kell fogadnod, hogy egy 'dokumentum' az adatbázisban nem hasonlít majd arra az objektumra, amit a felhasználó dokumentumnak nevezne.
„Tömbök tömbje, amelyek rekurzívan más elemeket tartalmazhatnak? Nem. A tömbök csak fix hosszúságú objektumokat vagy számokat tartalmazhatnak, ahogyan azt az Úr megalkotta.”
Tehát, ha azt remélted, hogy GeoJSON-t helyezhetsz a Firestore-ba, akkor felfedezed, hogy ez lehetetlen. Semmilyen nem egydimenziós dolog nem megengedett. Remélem, szeretsz Base64-et és/vagy JSON-t JSON-ban.
„JSON importálása és exportálása HTTP-n keresztül, parancssori eszközök vagy adminisztrációs panel? Nem. Csak a Google Cloud Storage-ba tudod exportálni és importálni az adatokat. Úgy tűnik, most így hívják. És amikor azt mondom, hogy 'te', akkor csak azokra utalok, akik Project Owner hatalommal bírnak. Mindenki más menjen és jegyeket hozzon létre.”
Ahogy látod, a FireBase adatmodellje könnyen leírható. Ez tartalmaz egy hatalmas JSON dokumentumot, amely a JSON kulcsokat összekapcsolja az URL utakkal. Ha ezt írod a HTTP PUT be. / FireBase-nek:
{
"hello": "world"
} Akkor GET /hello visszaadja "world". Alapvetően így működik, ahogy várod. A FireBase objektumgyűjtemény /my-collection/:id egyenértékű egy JSON szótárral {"my-collection": {...}} a gyökérben, amelynek tartalma elérhető itt: /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Ez nagyszerűen működik, ha minden beszúrás egyedi ID-vel rendelkezik, amire a rendszernek van egy szabványos megoldása.
Más szavakkal, az adatbázis 100%-ban kompatibilis a JSON-nal (*) és kiválóan működik a HTTP-val, például a CouchDB-vel. De alapvetően valós idejű API-n keresztül használja, amely elvonja a websockets, az azonosítást és az előfizetéseket. Az adminisztrátori panel mindkét lehetőséget biztosít, lehetővé téve a valós idejű szerkesztést és a JSON importálását/exportálását. Ha a kódjában ehhez fogja magát tartani, meglepődni fog, hogy mennyi speciális kód tűnik el, amikor rájön, hogy a JSON patch és diff 90%-át megoldja a rutin feladatoknak a tartós állapotok kezelésében.
A Firestore adatmodell hasonlít a JSON-ra, de néhány alapvető szempontból eltér tőle. Már említettem, hogy nem léteznek tömbök a tömbökben. A sub-collection model az, hogy ezek első osztályú fogalmak, különállóak a tartalmazó JSON dokumentumtól. Mivel erre nincs kész szérializáció, az adatok lekérdezéséhez és írásához különleges kód végrehajtási útvonalra van szükség. A saját gyűjtemények kezeléséhez saját szkripteket és eszközöket kell írni. Az adminisztrátori panel csak kis változtatásokat tesz lehetővé, egy mezőnként, és nem rendelkezik importálási/exportálási funkciókkal.
Egy valós idejű NoSQL adatbázist vettek, és lassú nem-SQL-lé alakították át, automatikus egyesítéssel és külön oszloppal, ami nem JSON. Valami hasonló a GraftQL-hoz.
Forró Java
Ha a Firestone-nak megbízhatóbbá és skálázhatóbbá kellene válnia, akkor az irónia, hogy az átlagos fejlesztő egy kevésbé megbízható megoldást kap, mint a FireBase „do boxból”. Az a szoftver, amire a Morgós Adatbázis-adminisztrátornak szüksége van, olyan szintű erőfeszítéseket és szakértelmet igényel, hogy ez egyszerűen irreális a niche-ben, ahol feltételezhetően jó terméknek kell lennie. Olyan ez, mint amikor az HTML5 Canvas valójában nem helyettesíti a Flash-t, ha nincsenek fejlesztői eszközök és lejátszó. Sőt, a Firestore a tiszta adatok és a steril validálás iránti törekvésében olyan mélyre merült, ami egyszerűen nem felel meg ahhoz, ahogyan az átlagos üzleti felhasználó szeret dolgozni: számára ez nem kötelező, mert a végsőkig minden vázlat.
A FireBase fő hátránya, hogy az ügyfél több évvel a határidő előtt készült el, még mielőtt a legtöbb webfejlesztő tudomást szerzett volna a változatlanságról. Emiatt a FireBase azt feltételezi, hogy adatokat fog módosítani, ezért nem használja ki a felhasználó által biztosított változatlanság előnyeit. Ezen kívül nem használja újra az adatokat a felhasználónak átadott pillanatképeken, ami megnehezíti a különbségek megállapítását. Nagyobb dokumentumok esetén a módosításokra alapozott tranzakciós mechanizmusa egyszerűen nem elegendő. Fiúk, már van nekünk WeakMap JavaScriptben. Ez kényelmes.
Ha megfelelő formát adunk az adatoknak, és nem tesszük túl naggyá a fákat, akkor ezt a problémát meg lehet kerülni. De érdekelne, hogy a FireBase sokkal érdekesebb lenne-e, ha a fejlesztők kiadnának egy igazán jó kliens API-t, amely a változatlanságot valódi adatbázis-struktúra ajánlásaival kombinálná. Ehelyett úgy tűnik, hogy megpróbálták megjavítani azt, ami nincs elromolva, és ezzel csak rontottak rajta.
Nem tudom az összes logikát, ami a Firestore megalkotásának hátterében állt. Az okokkal való elmélkedés egy fekete dobozban szórakoztató rész is. Az ilyen két rendkívül hasonló, de összehasonlíthatatlan adatbázis ellentéte elég ritka. Mintha valaki azt gondolta volna: „A Firebase csak egy funkció, amelyet a Google Cloudban tudunk émálizálni”, de még nem fedezte fel a valós világ igényeinek meghatározásának vagy olyan hasznos megoldások létrehozásának koncepcióját, amelyek megfelelnek minden ilyen követelménynek. „A fejlesztők majd gondolkodjanak ezen. Csak csináljatok egy szép UI-t… És lehet, hogy tegyünk rá több tüzet?”
Tudok pár dolgot az adatstruktúrákról. Pontosan látom, hogy a „mindent egy nagy JSON fában” koncepció megpróbálja az adatbázisból bármilyen nagyszabású struktúrával kapcsolatos érzést eltüntetni. Elvárni, hogy a szoftver egyszerűen kezelni tudja a kétes adatstruktúrákra épülő fraktálokat, egyszerűen őrültség. Még csak képzelni sem kell, mennyire rossz lehet a helyzet, mivel szigorú kódellenőrzéseket végeztem és láttam olyan dolgokat, amikről ti, emberek, még álmodni sem mertetek. De tudom, hogyan néz ki egy jó struktúra, és Elképzelhetek egy olyan világot, ahol a Firestore teljesen logikusnak tűnne, és az azt létrehozó emberek úgy vélnék, hogy jól végezték a munkájukat. De mi nem ebben a világban élünk.
A FireBase query-k építésének támogatása minden standard szerint rossz, szinte nem is létezik. Határozottan javításra vagy legalább felülvizsgálatra szorul. A Firestore sem sokkal jobb, mivel meg van kötve az egyszerű SQL hasonló egy dimenziós indexeivel. Ha olyan lekérdezésekre van szüksége, amelyeket az emberek végeznek kaotikus adatokkal, akkor teljesszöveg-keresésre, többszörös tartomány szűrőkre és tetszés szerinti felhasználói sorrendre van szükség. A sima SQL funkciókat alaposan megvizsgálva önmagukban túl korlátozottak. Továbbá, az egyetlen SQL lekérdezések, amelyeket az emberek produkcióban végrehajtanak, a gyors lekérdezések. Szüksége lesz egy speciális indexelési megoldásra átgondolt adatszerkezetekkel. Minden máshoz legalább fokozatos Map-Reduce-ra vagy valami hasonlóra lesz szüksége.
Ha információt keres erről a Google dokumentumaiban, remélhetőleg egy BigTable vagy BigQuery felé irányítanak. Azonban ezekhez a megoldásokhoz annyi sűrű vállalati zsargon kapcsolódik, hogy gyorsan visszatérsz, és elkezdesz valami mást keresni.
Az utolsó dolog, amire egy valós idejű adatbázis esetén szükséged van — az valami, amit emberek hoztak létre és emberek számára készült, miközben a fizetések alapján dolgoznak.
(*) Ez vicc, nincs olyan fogalom, mint .
Hirdetés
Keresed egy debug projektekhez, fejlesztői és hosting szervert? Akkor te biztosan a mi ügyfelünk vagy 🙂 Napidíjas szerverek különböző konfigurációkban, antiDDoS és Windows licencek is benne vannak az árban.
Forrás: habr.com
