Ispričat ću jednu tehničku priču.
Prije mnogo godina razvijao sam aplikaciju s ugrađenim značajkama suradnje. Bio je to user-friendly eksperimentalni skup koji je iskoristio puni potencijal ranog Reacta i CouchDB-a. Sinkronizirao je podatke u stvarnom vremenu putem JSON-a . Korišten je interno unutar tvrtke, ali je njegova široka primjenjivost i potencijal u drugim područjima bio jasan.
Dok smo pokušavali prodati ovu tehnologiju potencijalnim klijentima, naišli smo na neočekivanu prepreku. U demo videu naša je tehnologija izgledala i radila sjajno, nema problema. Video je točno pokazao kako radi i nije ništa oponašao. Osmislili smo i kodirali realan scenarij za korištenje programa.
Zapravo, to je postao problem. Naš demo radio je točno onako kako su svi drugi simulirali svoje aplikacije. Točnije, informacije su se trenutno prenosile od A do B, čak i ako se radilo o velikim medijskim datotekama. Nakon prijave, svaki korisnik je vidio nove unose. Koristeći aplikaciju, različiti korisnici mogli su jasno raditi zajedno na istim projektima, čak i ako je internetska veza prekinuta negdje u selu. To je implicitno implicirano u bilo kojem video izrezu proizvoda u After Effectsu.
Iako su svi znali čemu služi gumb Osvježi, nitko nije shvaćao da su web aplikacije koje su od nas tražili da izradimo obično podložne vlastitim ograničenjima. I da će, ako više ne budu potrebni, korisničko iskustvo biti potpuno drugačije. Uglavnom su primijetili da mogu “čavrljati” ostavljajući bilješke za sugovornike, pa su se pitali po čemu se to razlikuje od, primjerice, Slacka. Fuj!
Dizajn svakodnevnih sinkronizacija
Ako imate iskustva u razvoju softvera, mora biti neugodno zapamtiti da većina ljudi ne može samo pogledati sliku sučelja i shvatiti što će ono učiniti u interakciji s njim. Da ne spominjemo što se događa unutar samog programa. Znanje koje može dogoditi je u velikoj mjeri rezultat znanja što se ne može dogoditi i što se ne bi trebalo dogoditi. Ovo zahtijeva ne samo što softver radi, već i kako su njegovi pojedinačni dijelovi koordinirani i međusobno komuniciraju.
Klasičan primjer ovoga je korisnik koji zuri u predilica.gif, pitajući se kada će radovi konačno biti gotovi. Programer bi shvatio da je proces vjerojatno zapeo i da gif nikada neće nestati sa zaslona. Ova animacija simulira izvršenje posla, ali nije povezana s njegovim stanjem. U takvim slučajevima neki tehničari vole kolutati očima, zadivljeni razmjerom zbunjenosti korisnika. Međutim, primijetite koliko ih pokazuje na rotirajući sat i kaže da on zapravo miruje?
Ovo je bit vrijednosti u stvarnom vremenu. Danas se baze podataka u stvarnom vremenu još uvijek vrlo malo koriste i mnogi ljudi gledaju na njih sa sumnjom. Većina ovih baza podataka snažno se oslanja na stil NoSQL, zbog čega obično koriste rješenja temeljena na Mongou, koja je najbolje zaboraviti. Međutim, za mene to znači udoban rad s CouchDB-om, kao i učenje dizajna struktura koje više od običnog birokrata može ispuniti podacima. Mislim da bolje koristim svoje vrijeme.
Ali prava tema ovog posta je ono što koristim danas. Ne svojom voljom, već zbog indiferentne i slijepo primijenjene korporativne politike. Stoga ću dati potpuno poštenu i nepristranu usporedbu dva blisko povezana Google proizvoda baze podataka u stvarnom vremenu.
I jedni i drugi u svom imenu imaju riječ Vatra. Jednog se rado sjećam. Druga stvar za mene je druga vrsta vatre. Ne žuri mi se reći njihova imena, jer kad jednom to učinim, naići ćemo na prvi veliki problem: imena.
Prvi se zove Firebase baza podataka u stvarnom vremenu, i drugo - Firebase Cloud Firestore. Oba su proizvodi iz Firebase paket Google. Njihovi API-ji nazivaju se redom firebase.database(…) и firebase.firestore(…).
Ovo se dogodilo jer Baza podataka u stvarnom vremenu - to je samo original Firebase prije nego što ga je Google kupio 2014. Tada je Google odlučio stvoriti kao paralelni proizvod kopirati Firebase baziran na big data tvrtki, a nazvao ga je Firestore s oblakom. Nadam se da još niste zbunjeni. Ako ste još uvijek zbunjeni, ne brinite, ja sam ovaj dio članka prepisao deset puta.
Jer morate naznačiti Firebase u pitanju o Firebaseu i Firestore u pitanju o Firebaseu, barem da biste razumjeli prije nekoliko godina na Stack Overflowu.
Da postoji nagrada za najgore iskustvo imenovanja softvera, ovo bi definitivno bio jedan od kandidata. Hammingova udaljenost između ovih imena toliko je mala da zbunjuje čak i iskusne inženjere čiji prsti tipkaju jedno ime dok im glava razmišlja o drugom. Ovo su dobronamjerni planovi koji neslavno propadaju; ispunili su proročanstvo da će baza biti u plamenu. I uopće se ne šalim. Osoba koja je smislila ovu shemu imenovanja izazvala je krv, znoj i suze.
Prova pobjeda
Čovjek bi pomislio da Firestore jest zamjena Firebase, njegov potomak sljedeće generacije, ali to bi dovelo u zabludu. Nije zajamčeno da će Firestore biti prikladna zamjena za Firebase. Čini se da je netko iz njega izrezao sve zanimljivo, a većinu ostalog na razne načine pobrkao.
Međutim, brzi pogled na dva proizvoda može vas zbuniti: čini se da rade istu stvar, kroz u osnovi iste API-je, pa čak i u istoj sesiji baze podataka. Razlike su suptilne i otkrivaju se tek pomnim usporednim proučavanjem opsežne dokumentacije. Ili kada pokušavate prenijeti kod koji savršeno radi na Firebaseu tako da radi s Firestoreom. Čak i tada saznate da sučelje baze podataka svijetli čim pokušate povući i ispustiti mišem u stvarnom vremenu. Ponavljam, ne šalim se.
Firebase klijent je pristojan u smislu da sprema promjene u međuspremnik i automatski ponovno pokušava ažuriranja koja daju prioritet zadnjoj operaciji pisanja. Međutim, Firestore ima ograničenje od 1 operacije pisanja po dokumentu po korisniku u sekundi, a to ograničenje provodi poslužitelj. Kada radite s njim, na vama je da nađete način da ga zaobiđete i implementirate limitator stope ažuriranja, čak i kada samo pokušavate izgraditi svoju aplikaciju. Odnosno, Firestore je baza podataka u stvarnom vremenu bez klijenta u stvarnom vremenu, koja se pretvara da koristi API.
Ovdje počinjemo vidjeti prve znakove raison d'être Firestorea. Možda griješim, ali sumnjam da je netko na visokom položaju u Googleovoj upravi pogledao Firebase nakon kupnje i jednostavno rekao: “Ne, o moj Bože, ne. Ovo je neprihvatljivo. Samo ne pod mojim vodstvom."
Pojavio se iz svojih odaja i izjavio:
“Jedan veliki JSON dokument? Ne. Podatke ćete podijeliti u zasebne dokumente, od kojih svaki neće biti veći od 1 megabajta.”
Čini se da takvo ograničenje neće preživjeti prvi susret s nekom dovoljno motiviranom bazom korisnika. Znaš da jest. Na poslu, primjerice, imamo više od tisuću i pol prezentacija i to je sasvim normalno.
Uz ovo ograničenje, bit ćete prisiljeni prihvatiti činjenicu da jedan "dokument" u bazi podataka neće nalikovati nijednom objektu koji bi korisnik mogao nazvati dokumentom.
"Nizovi nizova koji mogu rekurzivno sadržavati druge elemente? Ne. Nizovi će sadržavati samo objekte ili brojeve fiksne duljine, kao što je Bog zamislio."
Dakle, ako ste se nadali staviti GeoJSON u svoj Firestore, vidjet ćete da to nije moguće. Ništa što nije jednodimenzionalno nije prihvatljivo. Nadam se da vam se sviđa Base64 i/ili JSON unutar JSON-a.
„JSON uvoz i izvoz putem HTTP-a, alata naredbenog retka ili administratorske ploče? Ne. Podatke ćete moći izvoziti i uvoziti samo u Google Cloud Storage. Tako se sada zove, mislim. A kad kažem "vi", obraćam se samo onima koji imaju vjerodajnice vlasnika projekta. Svi ostali mogu ići i kreirati ulaznice."
Kao što vidite, FireBase model podataka lako je opisati. Sadrži jedan ogromni JSON dokument koji JSON ključeve povezuje s URL stazama. Ako pišete sa HTTP PUT в / FireBase je sljedeći:
{
"hello": "world"
}
RўRѕ GET /hello će se vratiti "world". U osnovi radi točno onako kako biste očekivali. Zbirka FireBase objekata /my-collection/:id ekvivalentan JSON rječniku {"my-collection": {...}} u korijenu, čiji je sadržaj dostupan u /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Ovo dobro funkcionira ako svaki umetak ima ID bez kolizije, za što sustav ima standardno rješenje.
Drugim riječima, baza podataka je 100% JSON(*) kompatibilna i odlično radi s HTTP-om, kao što je CouchDB. Ali u osnovi ga koristite kroz API u stvarnom vremenu koji apstrahira websockete, autorizaciju i pretplate. Administratorska ploča ima obje mogućnosti, dopuštajući uređivanje u stvarnom vremenu i JSON uvoz/izvoz. Ako učinite isto u svom kodu, iznenadit ćete se koliko će specijaliziranog koda biti uzalud potrošeno kada shvatite da patch i diff JSON rješavaju 90% rutinskih zadataka rukovanja postojanim stanjem.
Podatkovni model Firestore sličan je JSON-u, ali se razlikuje na neke kritične načine. Već sam spomenuo nedostatak nizova unutar nizova. Model za podzbirke je da budu prvoklasni koncepti, odvojeni od JSON dokumenta koji ih sadrži. Budući da za to ne postoji gotova serijalizacija, potrebna je specijalizirana staza koda za dohvaćanje i pisanje podataka. Za obradu vlastitih zbirki morate napisati vlastite skripte i alate. Administratorska ploča vam omogućuje samo male izmjene jedno po jedno polje i nema mogućnosti uvoza/izvoza.
Uzeli su NoSQL bazu podataka u stvarnom vremenu i pretvorili je u sporu ne-SQL s automatskim pridruživanjem i zasebnim stupcem koji nije JSON. Nešto kao GraftQL.
Vruća Java
Ako je Firestore trebao biti pouzdaniji i skalabilniji, onda je ironija da će prosječni programer završiti s manje pouzdanim rješenjem od odabira FireBase-a. Vrsta softvera koju treba mrzovoljni administrator baze podataka zahtijeva razinu truda i kalibar talenta koji su jednostavno nerealni za nišu u kojoj bi proizvod trebao biti dobar. Ovo je slično kao što HTML5 Canvas uopće nije zamjena za Flash ako nema razvojnih alata i playera. Štoviše, Firestore je zaglavljen u želji za čistoćom podataka i sterilnom provjerom valjanosti koja jednostavno nije u skladu s načinom na koji prosječni poslovni korisnik voli raditi: za njega je sve izborno, jer do samog kraja sve je nacrt.
Glavni nedostatak FireBase-a je taj što je klijent stvoren nekoliko godina prije svog vremena, prije nego što je većina web programera znala za nepromjenjivost. Zbog toga FireBase pretpostavlja da ćete promijeniti podatke i stoga ne iskorištava nepromjenjivost koju pruža korisnik. Osim toga, ne koristi ponovno podatke u snimkama koje prosljeđuje korisniku, što diff čini puno težim. Za velike dokumente, njegov promjenjivi transakcijski mehanizam temeljen na razlikama jednostavno je neadekvatan. Dečki, već jesmo WeakMap u JavaScriptu. Udobno je.
Ako podacima date željeni oblik i ne učinite stabla previše voluminoznim, tada se ovaj problem može zaobići. Ali zanima me bi li FireBase bio puno zanimljiviji da su programeri izdali stvarno dobar klijentski API koji koristi nepromjenjivost u kombinaciji s ozbiljnim praktičnim savjetima o dizajnu baze podataka. Umjesto toga, činilo se da pokušavaju popraviti ono što nije pokvareno, a to je pogoršalo situaciju.
Ne znam svu logiku iza stvaranja Firestorea. Nagađanje o motivima koji se pojavljuju unutar crne kutije također je dio zabave. Ovakva jukstapozicija dviju vrlo sličnih, ali neusporedivih baza podataka prilično je rijetka. Kao da je netko pomislio: "Firebase je samo funkcija koju možemo emulirati u Google Cloudu", ali još nije otkrio koncept identificiranja zahtjeva stvarnog svijeta ili stvaranja korisnih rješenja koja ispunjavaju sve te zahtjeve. “Neka programeri razmisle o tome. Samo učinite UI lijepim... Možete li dodati još vatre?"
Razumijem nekoliko stvari o strukturama podataka. Koncept "sve u jednom velikom JSON stablu" definitivno vidim kao pokušaj apstrahiranja bilo kakvog smisla velike strukture iz baze podataka. Očekivati da će se softver jednostavno nositi s bilo kojim fraktalom sumnjive strukture podataka jednostavno je suludo. Ne moram ni zamišljati koliko loše stvari mogu biti, obavio sam rigorozne revizije koda i Vidio sam stvari o kojima vi ljudi niste ni sanjali. Ali također znam kako dobre strukture izgledaju, и . Mogu zamisliti svijet u kojem bi se Firestore činio logičnim, a ljudi koji su ga stvorili mislili bi da su napravili dobar posao. Ali mi ne živimo u ovom svijetu.
Podrška za upite FireBasea loša je po svim standardima i praktički ne postoji. Definitivno treba poboljšanje ili barem reviziju. Ali Firestore nije puno bolji jer je ograničen na iste jednodimenzionalne indekse koji se nalaze u običnom SQL-u. Ako su vam potrebni upiti koje ljudi pokreću na kaotičnim podacima, potrebno vam je pretraživanje cijelog teksta, filtri s više raspona i prilagođeni korisnički definirani poredak. Nakon detaljnijeg pregleda, funkcije običnog SQL-a su previše ograničene same po sebi. Osim toga, jedini SQL upiti koje ljudi mogu pokrenuti u proizvodnji su brzi upiti. Trebat će vam prilagođeno rješenje za indeksiranje s promišljenom strukturom podataka. Za sve ostalo, trebalo bi postojati barem incremental map-reduce ili nešto slično.
Ako tražite informacije o tome u Google dokumentima, nadamo se da ćete biti usmjereni prema nečemu poput BigTablea i BigQueryja. Međutim, sva ova rješenja prati toliko gust korporativni prodajni žargon da ćete se brzo okrenuti i početi tražiti nešto drugo.
Zadnje što želite s bazom podataka u stvarnom vremenu je nešto što su izradili i za ljude na menadžerskim plaćama.
(*) Ovo je šala, ne postoji takva stvar .
O pravima oglašavanja
Tražim za debugovanje projekata, poslužitelj za razvoj i hosting? Definitivno ste naš klijent 🙂 Dnevne cijene za poslužitelje raznih konfiguracija, anti-DDoS i Windows licence su već uključene u cijenu.
Izvor: www.habr.com