Dozvolite mi da ispričam tehničku priču.
Prije mnogo godina razvijao sam aplikaciju s ugrađenim funkcijama za saradnju. Bio je to eksperimentalni stog prilagođen korisniku koji je iskoristio puni potencijal ranih React-a i CouchDB-a. Sinhronizira podatke u realnom vremenu putem JSON-a . Korišćen je interno u kompaniji, ali je bila jasna njegova široka primena i potencijal u drugim oblastima.
Pokušavajući ovu tehnologiju prodati potencijalnim klijentima, naišli smo na neočekivanu prepreku. U demo videu, naša tehnologija je izgledala i radila odlično, nema problema. Video je pokazao kako tačno radi i ništa nije imitirao. Osmislili smo i kodirali realističan scenario za korištenje programa.
U stvari, ovo je postalo problem. Naš demo je radio upravo onako kako su svi ostali simulirali svoje aplikacije. Konkretno, informacije su se trenutno prenijele od A do B, čak i ako su to bile velike medijske datoteke. Nakon prijave, svaki korisnik je vidio nove unose. Koristeći aplikaciju, različiti korisnici su mogli jasno raditi zajedno na istim projektima, čak i ako je internetska veza prekinuta negdje u selu. Ovo se implicitno podrazumijeva u bilo kojem video snimku proizvoda izrezanom u After Effects.
Iako su svi znali čemu služi dugme Osvježi, niko nije shvatio da su web aplikacije koje su tražili da ih napravimo obično podložne njihovim ograničenjima. I da će, ako više ne budu potrebni, korisničko iskustvo biti potpuno drugačije. Uglavnom su primijetili da mogu “ćaskati” ostavljajući bilješke ljudima s kojima razgovaraju, pa su se pitali po čemu se to razlikuje od, na primjer, Slack-a. Phew!
Dizajn svakodnevnih sinhronizacija
Ako imate iskustva u razvoju softvera, mora da je uznemirujuće setiti se da većina ljudi ne može samo da pogleda sliku interfejsa i shvati šta će ono raditi kada bude u interakciji sa njim. Da ne spominjem šta se dešava unutar samog programa. Znati to moći desiti se u velikoj mjeri rezultat saznanja šta se ne može dogoditi, a šta ne bi trebalo. Ovo zahteva ne samo šta softver radi, već i kako su njegovi pojedinačni dijelovi koordinirani i međusobno komuniciraju.
Klasičan primjer ovoga je korisnik koji bulji u a spinner.gif, pitajući se kada će radovi konačno biti završeni. Programer bi shvatio da je proces vjerovatno zapeo i da gif nikada neće nestati sa ekrana. Ova animacija simulira izvršenje posla, ali nije povezana s njegovim stanjem. U takvim slučajevima, neki tehničari vole da prevrću očima, zapanjeni razmjerom zbunjenosti korisnika. Međutim, primijetite koliko njih pokazuje na rotirajući sat i kaže da on zapravo miruje?
Ovo je suština vrijednosti u realnom vremenu. Danas se baze podataka u realnom vremenu još uvijek vrlo malo koriste i mnogi ih gledaju sa sumnjom. Većina ovih baza podataka u velikoj meri naginje NoSQL stilu, zbog čega obično koriste rešenja zasnovana na Mongo, koja je najbolje zaboraviti. Međutim, za mene to znači da se udobno radim sa CouchDB-om, kao i da naučim da dizajniram strukture koje više od običnog birokrata može da ispuni podacima. Mislim da bolje koristim svoje vrijeme.
Ali prava tema ovog posta je ono što danas koristim. Ne po izboru, već zbog indiferentno i slijepo primijenjene korporativne politike. Stoga ću dati potpuno pošteno i nepristrasno poređenje dva usko povezana Google proizvoda baze podataka u realnom vremenu.
Obojica imaju riječ Vatra u svom imenu. Jedne stvari se rado sećam. Druga stvar za mene je drugačija vrsta vatre. Ne žurim da kažem njihova imena, jer kada to učinim, naići ćemo na prvi veliki problem: imena.
Prvi se zove Firebase baza podataka u realnom vremenu, i drugo - Firebase Cloud Firestore. Oba su proizvodi iz Firebase apartman Google. Njihovi API-ji se pozivaju respektivno firebase.database(…) и firebase.firestore(…).
Ovo se desilo zato što Baza podataka u realnom vremenu - to je samo original Firebase prije nego što ga je Google kupio 2014. Tada je Google odlučio kreirati kao paralelni proizvod kopiraj Firebase je baziran na kompaniji za velike podatke, a nazvao ga je Firestore sa oblakom. Nadam se da se još niste zbunili. Ako ste i dalje zbunjeni, ne brinite, ja sam lično prepisao ovaj dio članka deset puta.
Zato što treba da naznačite Firebase u Firebase pitanju, 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. Hamingov razmak između ovih imena je toliko mali da zbunjuje čak i iskusne inženjere čiji prsti ukucavaju jedno ime dok im glava razmišlja o drugom. Ovo su dobronamerni planovi koji nesrećno propadaju; ispunili su proročanstvo da će baza podataka biti u plamenu. I uopšte se ne šalim. Osoba koja je smislila ovu šemu imenovanja izazvala je krv, znoj i suze.
Pirova pobeda
Čovjek bi pomislio da je Firestore zamena Firebase, njegov potomak sljedeće generacije, ali to bi bilo pogrešno. Ne garantuje se da će Firestore biti prikladna zamjena za Firebase. Izgleda da je neko iz njega izrezao sve zanimljivo, a većinu ostalog zbunio na razne načine.
Međutim, brz pogled na ova 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 samo pažljivim uporednim proučavanjem obimne dokumentacije. Ili kada pokušavate prenijeti kod koji savršeno radi na Firebase-u tako da radi s Firestoreom. Čak i tada saznate da se sučelje baze podataka upali čim pokušate prevući i ispustiti mišem u realnom vremenu. Ponavljam, ne šalim se.
Firebase klijent je ljubazan u smislu da baferuje promene i automatski ponovo pokušava ažuriranja koja daju prioritet poslednjoj operaciji pisanja. Međutim, Firestore ima ograničenje od 1 operacije pisanja po dokumentu po korisniku u sekundi, a to ograničenje primjenjuje server. Kada radite s njim, na vama je da pronađete način da ga zaobiđete i implementirate ograničavač brzine ažuriranja, čak i kada samo pokušavate da napravite svoju aplikaciju. Odnosno, Firestore je baza podataka u realnom vremenu bez klijenta u realnom vremenu, koji se maskira kao takav koristeći API.
Ovdje počinjemo vidjeti prve znakove razloga postojanja Firestorea. Možda griješim, ali sumnjam da je neko visoko u Googleovom menadžmentu pogledao Firebase nakon kupovine 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? br. 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 bilo kojom dovoljno motiviranom korisničkom bazom. Znaš da jeste. Na poslu, na primjer, imamo više od hiljadu i po 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? br. Nizovi će sadržavati samo objekte ili brojeve fiksne dužine, kako je Bog zamislio."
Dakle, ako ste se nadali da stavite GeoJSON u svoj Firestore, otkrit ć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 komandne linije ili administrativnog panela? br. Moći ćete samo izvoziti i uvoziti podatke u Google Cloud Storage. Tako se to sada zove, mislim. A kada kažem „vi“, obraćam se samo onima koji imaju akreditive vlasnika projekta. Svi ostali mogu otići i kreirati karte."
Kao što vidite, FireBase model podataka je lako opisati. Sadrži jedan ogroman JSON dokument koji povezuje JSON ključeve sa URL putanjama. Ako pišete sa HTTP PUT в / FireBase je sljedeći:
{
"hello": "world"
}
The GET /hello Će se vratiti "world". U osnovi radi tačno onako kako biste očekivali. Kolekcija FireBase objekata /my-collection/:id ekvivalent 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 sudara, za koji sistem ima standardno rješenje.
Drugim riječima, baza podataka je 100% JSON(*) kompatibilna i odlično radi sa HTTP-om, kao što je CouchDB. Ali u osnovi ga koristite preko API-ja u realnom vremenu koji apstrahuje websockete, autorizaciju i pretplate. Administrativni panel ima obe mogućnosti, omogućavajući i uređivanje u realnom vremenu i JSON uvoz/izvoz. Ako učinite isto u svom kodu, iznenadit ćete se koliko će specijalizovanog koda biti potrošeno kada shvatite da zakrpa i diff JSON rješava 90% rutinskih zadataka rukovanja postojanim stanjem.
Model podataka Firestore sličan je JSON-u, ali se razlikuje na neke kritične načine. Već sam spomenuo nedostatak nizova unutar nizova. Model za podkolekcije je da budu prvoklasni koncepti, odvojeni od JSON dokumenta koji ih sadrži. Budući da za ovo ne postoji gotova serijalizacija, potrebna je specijalizirana putanja koda za dohvat i pisanje podataka. Da biste obrađivali svoje kolekcije, morate napisati vlastite skripte i alate. Administrativni panel vam omogućava da napravite male izmjene samo jedno po jedno polje i nema mogućnosti uvoza/izvoza.
Uzeli su NoSQL bazu podataka u realnom vremenu i pretvorili je u sporu ne-SQL bazu podataka sa automatskim spajanjem i zasebnom kolonom koja nije JSON. Nešto kao GraftQL.
Hot Java
Ako je Firestore trebao biti pouzdaniji i skalabilniji, onda je ironija u tome što će prosječni programer završiti s manje pouzdanim rješenjem od odabira FireBasea iz kutije. Vrsta softvera koja je potrebna Grumpy Database Administratoru zahtijeva nivo truda i kalibar talenta koji je jednostavno nerealan za nišu u kojoj bi proizvod trebao biti dobar. Ovo je slično tome kako HTML5 Canvas uopće nije zamjena za Flash ako nema razvojnih alata i playera. Štaviše, Firestore je zarobljen u želji za čistoćom podataka i sterilnom validacijom koja jednostavno nije u skladu s načinom na koji prosječni poslovni korisnik voli da radi: za njega je sve opciono, jer je do samog kraja sve nacrt.
Glavni nedostatak FireBase-a je taj što je klijent kreiran 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 koristi prednosti nepromjenjivosti koju daje korisnik. Osim toga, ne koristi ponovo podatke u snimcima koje prosljeđuje korisniku, što diff čini mnogo težim. Za velike dokumente, njegov promjenjivi mehanizam transakcije zasnovan na dif-u jednostavno je neadekvatan. Ljudi, već imamo WeakMap u JavaScriptu. To je udobno.
Ako podacima date željeni oblik i ne učinite stabla previše voluminoznim, onda se ovaj problem može zaobići. Ali znatiželjan sam da li bi FireBase bio mnogo zanimljiviji kada bi programeri objavili zaista dobar klijentski API koji koristi nepromjenjivost u kombinaciji s nekim 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. Ova jukstapozicija dvije izuzetno slične, ali neuporedive baze podataka prilično je rijetka. Kao da je neko pomislio: "Firebase je samo funkcija koju možemo oponašati u Google Cloud-u", ali još nije otkrio koncept identificiranja zahtjeva iz stvarnog svijeta ili kreiranja korisnih rješenja koja ispunjavaju sve te zahtjeve. „Neka programeri razmisle o tome. Samo učinite korisničko sučelje lijepim... Možete li dodati još vatre?”
Razumijem nekoliko stvari o strukturama podataka. Definitivno vidim koncept "sve u jednom velikom JSON stablu" kao pokušaj da se apstrahuje bilo kakav osjećaj strukture velikih razmjera iz baze podataka. Očekivati da će se softver jednostavno nositi sa bilo kojim fraktalom sumnjive strukture podataka jednostavno je suludo. Ne moram ni da zamišljam koliko loše stvari mogu biti, uradio sam rigorozne revizije koda i Video sam stvari o kojima vi ljudi niste ni sanjali. Ali znam i kako izgledaju dobre strukture, и . Mogu zamisliti svijet u kojem bi Firestore izgledao logično i da bi ljudi koji su ga stvorili mislili da su uradili dobar posao. Ali mi ne živimo u ovom svijetu.
FireBase-ova podrška za upite je loša po bilo kojem standardu i praktički ne postoji. Definitivno treba poboljšati ili barem revidirati. Ali Firestore nije mnogo 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 haotičnim podacima, potrebna vam je pretraga cijelog teksta, filteri za više opsega i prilagođeni korisnički definirani redoslijed. Nakon detaljnijeg pregleda, funkcije običnog SQL-a su same po sebi previše ograničene. Osim toga, jedini SQL upiti koje ljudi mogu pokrenuti u proizvodnji su brzi upiti. Trebat će vam prilagođeno rješenje za indeksiranje sa pametnim strukturama podataka. Za sve ostalo, trebalo bi barem postojati inkrementalno reduciranje mape ili nešto slično.
Ako tražite informacije o ovome u Google dokumentima, nadamo se da ćete biti usmjereni na nešto poput BigTable-a i BigQueryja. Međutim, sva ova rješenja prati toliko gust korporativni prodajni žargon da ćete se brzo vratiti i početi tražiti nešto drugo.
Posljednja stvar koju želite s bazom podataka u realnom vremenu je nešto što su napravili i za ljude na platnoj skali menadžmenta.
(*) Ovo je šala, ne postoji takva stvar .
O pravima reklame
Tražim za otklanjanje grešaka u projektima, server za razvoj i hosting? Vi ste definitivno naš klijent 🙂 Dnevne cijene za servere različitih konfiguracija, anti-DDoS i Windows licence su već uključene u cijenu.
izvor: www.habr.com