Utzidazu istorio tekniko bat kontatzen.
Duela urte asko, aplikazio bat garatzen ari nintzen kolaborazio-eginbideak barne hartuta. React eta CouchDB goiztiarraren potentzial osoa aprobetxatzen zuen pila esperimental erabilerraza zen. Datuak denbora errealean sinkronizatu zituen JSON bidez . Enpresaren barnean erabiltzen zen, baina bere erabilgarritasun eta potentzial zabala beste arlo batzuetan argi zegoen.
Teknologia hau bezero potentzialei saltzen saiatzen ari ginela, ustekabeko oztopo bat topatu dugu. Demo bideoan, gure teknologiak itxura ona zuen eta funtzionatu zuen, ez dago arazorik. Bideoak nola funtzionatzen duen erakusten zuen eta ez zuen ezer imitatzen. Programa erabiltzeko eszenatoki errealista bat asmatu eta kodetu genuen.
Izan ere, hori arazo bihurtu zen. Gure demoak beste guztiek beren aplikazioak simulatzen zituzten moduan funtzionatu zuen. Zehazki, informazioa berehala transferitzen zen A-tik B-ra, nahiz eta multimedia fitxategi handiak izan. Saioa hasi ondoren, erabiltzaile bakoitzak sarrera berriak ikusi zituen. Aplikazioa erabiliz, erabiltzaile ezberdinek argi eta garbi lan egin dezakete proiektu berdinetan, nahiz eta Interneterako konexioa eten bazen herriko lekuren batean. Hau inplizituki inplizitu da After Effects-en moztutako edozein produktu-bideotan.
Nahiz eta denek bazekiten Freskatu botoia zertarako zen, inork ez zuen benetan ulertzen eraikitzeko eskatu zizkiguten web aplikazioak normalean beren mugen menpe zeudenik. Eta gehiago behar ez badira, erabiltzailearen esperientzia guztiz ezberdina izango da. Batez ere ohartu ziren hitz egiten ari ziren pertsonei oharrak utziz "txateatu" zezaketen, beraz, hau Slack-ekin alderatuta nola desberdina zen galdetu zuten. Uf!
Eguneroko sinkronizazioen diseinua
Software garapenean esperientzia baduzu, nerbioak izan behar dira gogoratzea jende gehienek ezin dutela interfaze baten argazki bat ikusi eta harekin elkarreraginean zer egingo duen ulertu. Zer esanik ez programaren barruan gertatzen dena. Jakin hori ahal gertatuko da, neurri handi batean, gertatu ezin dena eta gertatu behar ez dena jakitearen ondorioa. Horrek eskatzen du ez bakarrik softwareak zer egiten duen, baita bere zati indibidualak nola koordinatzen diren eta elkarren artean komunikatzen diren ere.
Honen adibide klasiko bat bati begira dagoen erabiltzailea da spinner.gif, lanak azkenean noiz amaituko diren galdezka. Garatzailea konturatu zen ziurrenik prozesua itsatsita zegoela eta gif-a ez zela inoiz pantailatik desagertuko. Animazio honek lan baten exekuzioa simulatzen du, baina ez dago bere egoerarekin lotuta. Halakoetan, teknikari batzuek begiak altxatzea gustatzen zaie, erabiltzaileen nahasmenaren neurriarekin harrituta. Hala ere, ohartu haietako zenbatek biraka egiten duen erlojuari seinalatu eta benetan geldirik dagoela esaten dute?
Hau da denbora errealeko balioaren funtsa. Egun, denbora errealeko datu-baseak oraindik oso gutxi erabiltzen dira eta jende askok susmoz ikusten ditu. Datu-base horietako gehienek NoSQL estilora jotzen dute, horregatik Mongo-n oinarritutako soluzioak erabiltzen dituzte, hobekien ahazten direnak. Hala ere, niretzat horrek esan nahi du CouchDB-rekin lanean eroso egotea, baita burokrata batzuek datuekin bete ditzaketen egiturak diseinatzen ikastea ere. Nire denbora hobeto erabiltzen ari naizela uste dut.
Baina mezu honen benetako gaia gaur erabiltzen ari naizena da. Ez aukeragatik, axolagabe eta itsu-itsuan aplikatutako politika korporatiboengatik baizik. Beraz, Google-ren denbora errealeko datu-baseko produktuen guztiz bidezko eta alboragabeko konparaketa bat emango dut.
Biek Su hitza dute izenetan. Gauza bat maitasunez gogoratzen dudana. Niretzat bigarren gauza beste su mota bat da. Ez dut presarik haien izenak esateko, behin eginda lehen arazo handiarekin topo egingo baitugu: izenak.
Lehenengoari deitzen zaio Firebase denbora errealeko datu-basea, eta bigarrena - Firebase Cloud Firestore. Biak bertako produktuak dira Firebase suitea Google. Haien APIak deitzen dira hurrenez hurren firebase.database(β¦) ΠΈ firebase.firestore(β¦).
Hau gertatu delako Denbora errealeko datu-basea - originala besterik ez da Firebase 2014an Google-k erosi aurretik. Orduan Google-k produktu paralelo gisa sortzea erabaki zuen kopia bat Firebase big data enpresan oinarrituta, eta Firestore deitu zion hodei batekin. Espero dut oraindik nahastuta ez egotea. Oraindik nahastuta bazaude, ez kezkatu, nik neuk hamar aldiz berridatzi dut artikuluko zati hau.
Adierazi behar duzulako Firebase Firebase galderan, eta Firestore Firebaseri buruzko galdera batean, gutxienez duela urte batzuk Stack Overflow-en uler dezazun.
Software izendatzeko esperientziarik txarrenaren saria balego, zalantzarik gabe hau izango litzateke lehiakideetako bat. Izen horien arteko Hamming distantzia hain da txikia, non nahasten baititu hatzak izen bat idazten duten ingeniari esperientziadunek buruak beste batean pentsatzen duten bitartean. Zoritxarrez huts egiten duten asmo oneko planak dira; datu-basea sutan egongo zelako profezia bete zuten. Eta ez naiz batere txantxetan ari. Izendapen eskema hau asmatu zuenak odola, izerdia eta malkoak eragin zituen.
Garaipen pirrikoa
Batek uste luke Firestore dela ordezko Firebase, bere hurrengo belaunaldiko ondorengoa, baina hori engainagarria litzateke. Firestore ez dago ziurtatzen Firebaseren ordezko egokia denik. Badirudi norbaitek interesgarri guztia moztu zuela, eta gainerako gehienak hainbat modutan nahastu zituela.
Hala ere, bi produktuei begirada azkar batek nahastu egin zaitu: badirudi gauza bera egiten dutela, funtsean API berdinen bidez eta baita datu-baseko saio berean ere. Desberdintasunak sotilak dira eta dokumentazio zabalaren azterketa konparatibo zainduak baino ez dira agerian uzten. Edo Firebasen ezin hobeto funtzionatzen duen kodea porturatzen saiatzen ari zarenean, Firestore-rekin funtziona dezan. Orduan ere jakingo duzu datu-basearen interfazea argitzen dela sagua denbora errealean arrastatu eta jaregiten saiatu bezain laster. Berriro diot, ez naiz txantxetan ari.
Firebase bezeroa adeitsua da aldaketak bufferatzen dituelako eta azken idazketa-eragiketari lehentasuna ematen dioten eguneraketak automatikoki berriro saiatzen direlako. Hala ere, Firestore-k 1 idazketa-eragiketa du dokumentu bakoitzeko erabiltzaile bakoitzeko segundoko, eta muga hori zerbitzariak ezartzen du. Berarekin lan egiten duzunean, zure esku dago horri aurre egiteko modua aurkitzea eta eguneratze-tasa mugatzaile bat ezartzea, nahiz eta zure aplikazioa eraikitzen saiatzen ari zarenean. Hau da, Firestore denbora errealeko datu-base bat da, denbora errealeko bezerorik gabekoa, API bat erabiltzen duena.
Hemen Firestoreren izateko arrazoiaren lehen zantzuak ikusten hasiko gara. Baliteke oker nago, baina susmoa dut Google-ren zuzendaritzan goi-mailako norbaitek Firebaseri begiratu zion erosketa egin ondoren eta besterik gabe esan zuen: "Ez, ene Jainkoa, ez. Hau onartezina da. Ez nire gidaritzapean".
Bere ganbaratik agertu eta esan zuen:
"JSON dokumentu handi bat? Ez. Datuak dokumentu bereizietan banatuko dituzu, eta horietako bakoitzak megabyte 1 baino gehiago izango du".
Badirudi muga hori ez dela bizirik iraungo nahikoa motibatuta dagoen erabiltzaile-base batekin lehen topaketatik. Badakizu hori dela. Lanean, esaterako, mila eta erdi aurkezpen baino gehiago ditugu, eta hori Guztiz Normala da.
Muga honekin, datu-baseko "dokumentu" batek erabiltzaile batek dokumentu bati dei diezaiokeen objekturen antza ez izatea onartzera behartuta egongo zara.
"Errekurtsiboki beste elementu batzuk eduki ditzaketen matrizeak? Ez. Arrayek luzera finkoko objektuak edo zenbakiak izango dituzte soilik, Jainkoak nahi zuen bezala".
Beraz, GeoJSON zure Firestore-n sartzea espero bazenu, hori ez dela posible ikusiko duzu. Dimentsio bakarrekoa ez den ezer ez da onargarria. Espero dut Base64 eta/edo JSON gustatzea JSON barruan.
"JSON inportatu eta esportatu HTTP bidez, komando lerroko tresnen edo administrazio panelaren bidez? Ez. Datuak Google Cloud Storage-ra soilik esportatu eta inportatu ahal izango dituzu. Hala deitzen zaio orain, nik uste. Eta "zuk" esaten dudanean, Proiektuaren jabearen egiaztagiriak dituztenei bakarrik zuzentzen naiz. Beste guztiak joan daitezke sarrerak sortzeraΒ».
Ikus dezakezunez, FireBase datu-eredua erraza da deskribatzen. JSON gakoak URL bideekin lotzen dituen JSON dokumentu handi bat dauka. -rekin idazten baduzu HTTP PUT Π² / FireBase hau da:
{
"hello": "world"
}
du GET /hello itzuliko da "world". Funtsean, espero zenukeen bezala funtzionatzen du. FireBase objektuen bilduma /my-collection/:id JSON hiztegi baten baliokidea {"my-collection": {...}} erroan, zeinaren edukiak eskuragarri daude /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Honek ondo funtzionatzen du txertatze bakoitzak talkarik gabeko ID bat badu, sistemak irtenbide estandar bat badu.
Beste era batera esanda, datu-basea % 100 JSON(*) bateragarria da eta HTTPrekin oso ondo funtzionatzen du, CouchDB-ekin adibidez. Baina, funtsean, websocketak, baimenak eta harpidetzak abstraitzen dituen denbora errealeko API baten bidez erabiltzen duzu. Admin panelak bi gaitasunak ditu, denbora errealean editatzeko eta JSON inportatu/esportatzeko aukera ematen du. Zure kodean gauza bera egiten baduzu, harritu egingo zara zenbat kode espezializatu alferrik galduko den konturatzen zarenean adabaki eta diferentzia JSON-ek egoera iraunkorra kudeatzeko ohiko zereginen % 90 konpontzen duela.
Firestore datu-eredua JSONaren antzekoa da, baina modu kritiko batzuetan desberdina da. Dagoeneko aipatu dut matrizeen barruan array falta. Azpi-bildumen eredua lehen mailako kontzeptuak izatea da, horiek dituen JSON dokumentutik bereizita. Horretarako prest egindako serierik ez dagoenez, kode-bide espezializatu bat behar da datuak berreskuratzeko eta idazteko. Zure bildumak prozesatzeko, zure gidoiak eta tresnak idatzi behar dituzu. Admin panelak aldaketa txikiak eremu batean bakarrik egiteko aukera ematen du, eta ez du inportazio/esportazio gaitasunik.
Denbora errealeko NoSQL datu-base bat hartu zuten eta SQL ez den motel bihurtu zuten, batu automatikoarekin eta JSON ez den zutabe bereizi batekin. GraftQL bezalako zerbait.
Java beroa
Firestore fidagarriagoa eta eskalagarriagoa izan behar bazen, ironia da batez besteko garatzaileak FireBase kaxatik kanpo hautatzea baino irtenbide fidagarriagoa izango duela. Grumpy Database Administrator-ek behar duen software motak esfortzu eta talentu maila bat eskatzen du, produktuak ona izan behar duen nitxorako errealista besterik ez dena. Honen antzekoa da HTML5 Canvas ez den Flash-en ordezkoa, garapen-tresnarik eta erreproduzitzailerik ez badago. Gainera, Firestore datuen garbitasun eta baliozkotze antzuaren nahian murgilduta dago, negozioaren batez besteko erabiltzaileen moduarekin bat egiten ez dena. lan egitea gustatzen zaio: berarentzat dena hautazkoa da, azkenera arte dena zirriborroa baita.
FireBase-ren desabantaila nagusia bezeroa bere garaia baino hainbat urte lehenago sortu zela da, web garatzaile gehienek aldaezintasunaz jakin baino lehen. Horregatik, FireBase-k datuak aldatuko dituzula suposatzen du eta, beraz, ez du aprobetxatzen erabiltzaileek emandako aldaezintasuna. Gainera, ez ditu erabiltzaileari pasatzen dizkion argazkietan datuak berrerabiltzen, eta horrek askoz zailago egiten du desberdintasuna. Dokumentu handietarako, bere desberdinetan oinarritutako transakzio-mekanismo aldakorra besterik ez da nahikoa. Mutilak, dagoeneko badugu WeakMap JavaScript-en. Erosoa da.
Datuei nahi den forma ematen badiezu eta zuhaitzak bolumen handiegiak egiten ez badituzu, arazo hau saihestu daiteke. Baina jakin-mina dut FireBase askoz interesgarriagoa izango litzatekeen garatzaileek datu-baseen diseinuari buruzko aholku praktiko serio batzuekin konbinatuta aldaezintasuna erabiltzen duen bezero API oso ona kaleratuko balute. Horren ordez, apurtuta ez zegoena konpontzen saiatzen zirela zirudien, eta horrek okerrera egin zuen.
Ez dakit Firestore sortzearen atzean dagoen logika guztia. Kutxa beltzaren barruan sortzen diren motiboei buruz espekulatzea ere dibertsioaren parte da. Bi datu-base oso antzekoak baina konparaezinak elkarren ondoan jartzea nahiko arraroa da. Norbaitek pentsatu zuen bezala da: "Firebase Google Cloud-en emula dezakegun funtzio bat besterik ez da", baina oraindik ez du aurkitu mundu errealeko eskakizunak identifikatzeko edo baldintza horiek guztiak betetzen dituzten irtenbide erabilgarriak sortzeko kontzeptua. Β«Utzi garatzaileek horretaz pentsatzen. Egin ezazu UI ederra... Su gehiago gehi dezakezu?"
Datu-egiturei buruzko gauza pare bat ulertzen ditut. Zalantzarik gabe, "dena JSON zuhaitz handi batean" kontzeptua datu-basetik eskala handiko egituraren zentzua abstraitzeko saiakera gisa ikusten dut. Softwareak edozein datu-egitura fractal zalantzazko bati aurre egitea besterik ez izatea eroa da. Gauzak zein txarrak izan daitezkeen imajinatu beharrik ere ez dut, kodeen auditoria zorrotzak egin ditut eta Zuek inoiz amestu ez zituzten gauzak ikusi nituen. Baina badakit nolakoak diren egitura onak ere, ΠΈ . Imajina dezaket mundu bat non Firestore logikoa irudituko litzatekeen eta sortu duen jendeak lan ona egin duela pentsatuko lukeen. Baina ez gara mundu honetan bizi.
FireBase-ren kontsulta-laguntza eskasa da edozein estandarren arabera eta ia ez dago. Zalantzarik gabe, hobekuntza edo gutxienez berrikuspena behar du. Baina Firestore ez da askoz hobea SQL arruntean aurkitzen diren dimentsio bakarreko indizeetara mugatuta dagoelako. Jendeak datu kaotikoetan exekutatzen dituen kontsultak behar badituzu, testu osoko bilaketak, sorta anitzeko iragazkiak eta erabiltzaileak definitutako ordena pertsonalizatuak behar dituzu. Hurbiletik begiratuta, SQL arruntaren funtzioak mugatuegiak dira. Gainera, jendeak ekoizpenean exekutatu ditzakeen SQL kontsulta bakarrak kontsulta azkarrak dira. Datu-egitura adimendunekin indexatzeko irtenbide pertsonalizatu bat beharko duzu. Gainerako guztiarentzat, gutxienez mapa-murrizketa inkrementala edo antzeko zerbait egon beharko litzateke.
Honi buruzko informazioa Google Docs-en bilatzen baduzu, espero dugu BigTable eta BigQuery bezalako zerbaiten norabidean adieraziko zarela. Hala ere, irtenbide horiek guztiak salmenten hizkera korporatibo trinkoarekin batera doaz, non azkar itzuli eta beste zerbaiten bila hasiko zara.
Denbora errealeko datu-base batekin nahi duzun azken gauza zuzendaritzako soldata-eskaletan dauden pertsonek egindakoa da.
(*) Hau txantxa da, ez dago horrelakorik .
Publizitatearen Eskubideei buruz
Bilatzen arazketa proiektuetarako, garapenerako eta hostingerako zerbitzari bat? Zalantzarik gabe, gure bezeroa zara π Hainbat konfiguraziotako zerbitzarien eguneroko prezioak, DDoS aurkako eta Windows lizentziak prezioan sartuta daude dagoeneko.
Iturria: www.habr.com