Gadewch imi adrodd stori dechnegol.
Flynyddoedd lawer yn ôl, roeddwn i'n datblygu cymhwysiad gyda nodweddion cydweithredu wedi'u hymgorffori ynddo. Roedd yn stac arbrofol hawdd ei ddefnyddio a fanteisiodd ar botensial llawn React a CouchDB cynnar. Roedd yn cysoni data mewn amser real trwy JSON . Fe'i defnyddiwyd yn fewnol o fewn y cwmni, ond roedd ei chymhwysedd eang a'i botensial mewn meysydd eraill yn glir.
Wrth geisio gwerthu'r dechnoleg hon i ddarpar gleientiaid, daethom ar draws rhwystr annisgwyl. Yn y fideo demo, roedd ein technoleg yn edrych ac yn gweithio'n wych, dim problemau yno. Dangosodd y fideo yn union sut mae'n gweithio ac nid oedd yn dynwared unrhyw beth. Fe wnaethom lunio a chodio senario realistig ar gyfer defnyddio'r rhaglen.
Mewn gwirionedd, daeth hyn yn broblem. Gweithiodd ein demo yn union y ffordd yr oedd pawb arall yn efelychu eu cymwysiadau. Yn benodol, trosglwyddwyd gwybodaeth yn syth o A i B, hyd yn oed os oedd yn ffeiliau cyfryngau mawr. Ar ôl mewngofnodi, gwelodd pob defnyddiwr gofnodion newydd. Gan ddefnyddio'r rhaglen, gallai gwahanol ddefnyddwyr gydweithio'n glir ar yr un prosiectau, hyd yn oed pe bai'r cysylltiad Rhyngrwyd yn cael ei dorri yn rhywle yn y pentref. Mae hyn yn ymhlyg mewn unrhyw doriad fideo cynnyrch yn After Effects.
Er bod pawb yn gwybod beth oedd pwrpas y botwm Refresh, nid oedd unrhyw un yn deall mewn gwirionedd bod y cymwysiadau gwe y gofynnwyd i ni eu hadeiladu fel arfer yn amodol ar eu cyfyngiadau eu hunain. Ac os nad oes eu hangen mwyach, bydd profiad y defnyddiwr yn hollol wahanol. Roedden nhw’n sylwi ar y cyfan eu bod nhw’n gallu “sgwrsio” trwy adael nodiadau i bobl roedden nhw’n siarad â nhw, felly roedden nhw’n meddwl tybed sut oedd hyn yn wahanol i, er enghraifft, Slack. Phew!
Dyluniad cysoniadau bob dydd
Os oes gennych brofiad o ddatblygu meddalwedd, mae'n rhaid ei bod yn nerfus cofio na all y rhan fwyaf o bobl edrych ar lun o ryngwyneb yn unig a deall yr hyn y bydd yn ei wneud wrth ryngweithio ag ef. Heb sôn am yr hyn sy'n digwydd y tu mewn i'r rhaglen ei hun. Gwybod hynny Gall digwydd yn bennaf o ganlyniad i wybod beth na all ddigwydd a beth na ddylai ddigwydd. Mae hyn yn gofyn nid yn unig yr hyn y mae'r meddalwedd yn ei wneud, ond hefyd sut mae ei rannau unigol yn cael eu cydlynu a chyfathrebu â'i gilydd.
Enghraifft glasurol o hyn yw defnyddiwr yn syllu ar a troellwr.gif, yn meddwl tybed pryd y bydd y gwaith yn cael ei gwblhau o'r diwedd. Byddai'r datblygwr wedi sylweddoli bod y broses fwy na thebyg yn sownd ac na fyddai'r gif byth yn diflannu o'r sgrin. Mae'r animeiddiad hwn yn efelychu cyflawni swydd, ond nid yw'n gysylltiedig â'i chyflwr. Mewn achosion o'r fath, mae rhai techies yn hoffi rholio eu llygaid, rhyfeddu at faint o ddryswch defnyddwyr. Fodd bynnag, sylwch faint ohonynt sy'n pwyntio at y cloc cylchdroi ac yn dweud ei fod yn llonydd mewn gwirionedd?
Dyma hanfod gwerth amser real. Y dyddiau hyn, ychydig iawn o ddefnydd a wneir o gronfeydd data amser real o hyd ac mae llawer o bobl yn eu hystyried yn amheus. Mae'r rhan fwyaf o'r cronfeydd data hyn yn pwyso'n drwm ar arddull NoSQL, a dyna pam eu bod fel arfer yn defnyddio datrysiadau seiliedig ar Mongo, sy'n cael eu hanghofio orau. Fodd bynnag, i mi mae hyn yn golygu dod yn gyfforddus yn gweithio gyda CouchDB, yn ogystal â dysgu i ddylunio strwythurau y gall mwy na dim ond rhai biwrocratiaid eu llenwi â data. Rwy'n meddwl fy mod yn defnyddio fy amser yn well.
Ond pwnc go iawn y post hwn yw'r hyn rydw i'n ei ddefnyddio heddiw. Nid trwy ddewis, ond oherwydd polisïau corfforaethol a weithredir yn ddifater ac yn ddall. Felly byddaf yn darparu cymhariaeth Hollol Deg a Diduedd o ddau gynnyrch cronfa ddata amser real Google sydd â chysylltiad agos.
Mae gan y ddau y gair Tân yn eu henwau. Un peth dwi'n cofio'n annwyl. Yr ail beth i mi yw math gwahanol o dân. Nid wyf mewn unrhyw frys i ddweud eu henwau, oherwydd unwaith y gwnaf hynny, byddwn yn rhedeg i mewn i'r broblem fawr gyntaf: enwau.
Gelwir yr un cyntaf Cronfa Ddata Amser Real Firebase, ac yn ail - Storfa Dân Cwmwl Firebase. Mae'r ddau ohonyn nhw'n gynhyrchion o Swît Firebase Google. Gelwir eu APIs yn y drefn honno firebase.database(…) и firebase.firestore(…).
Digwyddodd hyn oherwydd Cronfa Ddata Amser Real - dim ond y gwreiddiol ydyw Firebase cyn ei brynu gan Google yn 2014. Yna penderfynodd Google greu fel cynnyrch cyfochrog copi Firebase yn seiliedig ar gwmni data mawr, a'i alw'n Firestore with a cloud. Gobeithio nad ydych wedi drysu eto. Os ydych chi'n dal wedi drysu, peidiwch â phoeni, fe wnes i fy hun ailysgrifennu'r rhan hon o'r erthygl ddeg gwaith.
Oherwydd mae angen i chi nodi Firebase yn y cwestiwn Firebase, a Storfa Dân mewn cwestiwn am Firebase, o leiaf i wneud i chi ddeall ychydig flynyddoedd yn ôl ar Stack Overflow.
Pe bai gwobr am y profiad enwi meddalwedd gwaethaf, byddai hwn yn bendant yn un o'r cystadleuwyr. Mae pellter Hamming rhwng yr enwau hyn mor fach fel ei fod yn drysu hyd yn oed peirianwyr profiadol y mae eu bysedd yn teipio un enw tra bod eu pennau'n meddwl am un arall. Mae'r rhain yn gynlluniau â bwriadau da sy'n methu'n druenus; cyflawnasant y broffwydoliaeth y byddai'r gronfa ddata ar dân. A dydw i ddim yn twyllo o gwbl. Achosodd y person a luniodd y cynllun enwi hwn waed, chwys a dagrau.
Buddugoliaeth Pyrrhic
Byddai rhywun yn meddwl bod Firestore yn amnewid Firebase, ei ddisgynnydd cenhedlaeth nesaf, ond byddai hynny'n gamarweiniol. Nid yw Firestore yn sicr o fod yn lle addas i Firebase. Mae'n edrych fel bod rhywun wedi torri allan popeth diddorol ohono, ac wedi drysu'r rhan fwyaf o'r gweddill mewn gwahanol ffyrdd.
Fodd bynnag, gall cipolwg cyflym ar y ddau gynnyrch eich drysu: mae'n ymddangos eu bod yn gwneud yr un peth, trwy'r un APIs yn y bôn a hyd yn oed yn yr un sesiwn cronfa ddata. Mae'r gwahaniaethau'n gynnil a dim ond trwy astudiaeth gymharol ofalus o ddogfennaeth helaeth y datgelir y rhain. Neu pan fyddwch chi'n ceisio trosglwyddo cod sy'n gweithio'n berffaith ar Firebase fel ei fod yn gweithio gyda Firestore. Hyd yn oed wedyn byddwch yn darganfod bod rhyngwyneb y gronfa ddata yn goleuo cyn gynted ag y byddwch yn ceisio llusgo a gollwng gyda'r llygoden mewn amser real. Rwy'n ailadrodd, nid cellwair ydw i.
Mae cleient Firebase yn gwrtais yn yr ystyr ei fod yn clustogi newidiadau ac yn ailgynnig diweddariadau yn awtomatig sy'n rhoi blaenoriaeth i'r gweithrediad ysgrifennu diwethaf. Fodd bynnag, mae gan Firestore gyfyngiad o 1 gweithrediad ysgrifennu fesul dogfen fesul defnyddiwr yr eiliad, a chaiff y terfyn hwn ei orfodi gan y gweinydd. Wrth weithio gydag ef, chi sydd i ddod o hyd i ffordd o'i gwmpas a gweithredu cyfyngiad cyfradd diweddaru, hyd yn oed pan fyddwch chi'n ceisio adeiladu'ch cais yn unig. Hynny yw, mae Firestore yn gronfa ddata amser real heb gleient amser real, sy'n ffugio fel un gan ddefnyddio API.
Yma rydym yn dechrau gweld arwyddion cyntaf raison d'être Firestore. Efallai fy mod yn anghywir, ond rwy'n amau bod rhywun uchel i fyny yn rheolaeth Google wedi edrych ar Firebase ar ôl y pryniant a dweud yn syml, “Na, o fy Nuw, na. Mae hyn yn annerbyniol. Dim ond nid o dan fy arweinyddiaeth."
Ymddangosodd o'i siambrau a datgan:
“Un ddogfen fawr JSON? Nac ydw. Byddwch yn rhannu’r data yn ddogfennau ar wahân, a bydd pob un ohonynt yn ddim mwy nag 1 megabeit o ran maint.”
Mae'n ymddangos na fydd cyfyngiad o'r fath yn goroesi'r cyfarfyddiad cyntaf ag unrhyw sylfaen defnyddwyr â chymhelliant digonol. Rydych chi'n gwybod ei fod. Yn y gwaith, er enghraifft, mae gennym fwy na mil a hanner o gyflwyniadau, ac mae hyn yn Hollol Normal.
Gyda'r cyfyngiad hwn, fe'ch gorfodir i dderbyn y ffaith na fydd un "dogfen" yn y gronfa ddata yn debyg i unrhyw wrthrych y gallai defnyddiwr ei alw'n ddogfen.
“Araeau o araeau a all gynnwys elfennau eraill yn rheolaidd? Nac ydw. Bydd araeau yn cynnwys gwrthrychau neu rifau hyd sefydlog yn unig, fel y bwriadodd Duw.”
Felly os oeddech chi'n gobeithio rhoi GeoJSON yn eich Storfa Dân, fe welwch nad yw hyn yn bosibl. Nid oes dim an-un-dimensiwn yn dderbyniol. Gobeithio eich bod chi'n hoffi Base64 a / neu JSON o fewn JSON.
“Mewnforio ac allforio JSON trwy HTTP, offer llinell orchymyn neu banel gweinyddol? Nac ydw. Byddwch ond yn gallu allforio a mewnforio data i Google Cloud Storage. Dyna beth mae'n cael ei alw nawr, dwi'n meddwl. A phan ddywedaf “chi,” nid wyf ond yn annerch y rhai sydd â chymwysterau Perchennog Prosiect. Gall pawb arall fynd i greu tocynnau."
Fel y gwelwch, mae model data FireBase yn hawdd i'w ddisgrifio. Mae'n cynnwys un ddogfen JSON enfawr sy'n cysylltu allweddi JSON â llwybrau URL. Os byddwch yn ysgrifennu gyda HTTP PUT в / Mae FireBase fel a ganlyn:
{
"hello": "world"
}
Y GET /hello bydd yn dychwelyd "world". Yn y bôn mae'n gweithio'n union fel y byddech chi'n ei ddisgwyl. Casgliad o wrthrychau FireBase /my-collection/:id cyfateb i eiriadur JSON {"my-collection": {...}} yn y gwraidd, y mae ei gynnwys ar gael yn /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Mae hyn yn gweithio'n iawn os oes gan bob mewnosodiad ID di-wrthdrawiad, y mae gan y system ateb safonol ar ei gyfer.
Mewn geiriau eraill, mae'r gronfa ddata yn gydnaws 100% JSON(*) ac yn gweithio'n wych gyda HTTP, fel CouchDB. Ond yn y bôn rydych chi'n ei ddefnyddio trwy API amser real sy'n crynhoi socedi gwe, awdurdodiad a thanysgrifiadau. Mae gan y panel gweinyddol y ddau allu, sy'n caniatáu golygu amser real a mewnforio / allforio JSON. Os gwnewch yr un peth yn eich cod, byddwch chi'n synnu faint o god arbenigol fydd yn cael ei wastraffu pan sylweddolwch fod patch a diff JSON yn datrys 90% o'r tasgau arferol o drin cyflwr parhaus.
Mae model data Firestore yn debyg i JSON, ond mae'n wahanol mewn rhai ffyrdd hanfodol. Soniais eisoes am y diffyg araeau o fewn araeau. Y model ar gyfer is-gasgliadau yw iddynt fod yn gysyniadau o’r radd flaenaf, ar wahân i’r ddogfen JSON sy’n eu cynnwys. Gan nad oes cyfresoli parod ar gyfer hyn, mae angen llwybr cod arbenigol i adalw ac ysgrifennu data. I brosesu eich casgliadau eich hun, mae angen i chi ysgrifennu eich sgriptiau a'ch offer eich hun. Dim ond un maes ar y tro y mae'r panel gweinyddol yn caniatáu ichi wneud newidiadau bach, ac nid oes ganddo alluoedd mewnforio / allforio.
Fe wnaethant gymryd cronfa ddata NoSQL amser real a'i droi'n un araf nad yw'n SQL gyda auto-join a cholofn nad yw'n JSON ar wahân. Rhywbeth fel GraftQL.
Java poeth
Pe bai Firestore i fod i fod yn fwy dibynadwy a graddadwy, yna'r eironi yw y bydd gan y datblygwr cyffredin ateb llai dibynadwy na dewis FireBase allan o'r bocs. Mae'r math o feddalwedd sydd ei angen ar Weinyddwr Cronfa Ddata Grumpy yn gofyn am lefel o ymdrech a chalibr o dalent sy'n syml afrealistig ar gyfer y gilfach y mae'r cynnyrch i fod i fod yn dda ynddo. Mae hyn yn debyg i sut nad yw HTML5 Canvas yn cymryd lle Flash o gwbl os nad oes offer datblygu a chwaraewr. Ar ben hynny, mae Firestore yn cael ei guddio gan awydd am burdeb data a dilysiad di-haint nad yw'n cyd-fynd â sut mae'r defnyddiwr busnes cyffredin wrth ei fodd yn gweithio: iddo ef mae popeth yn ddewisol, oherwydd hyd y diwedd mae popeth yn ddrafft.
Prif anfantais FireBase yw bod y cleient wedi'i greu sawl blwyddyn cyn ei amser, cyn i'r rhan fwyaf o ddatblygwyr gwe wybod am ansymudedd. Oherwydd hyn, mae FireBase yn tybio y byddwch yn newid y data ac felly nid yw'n manteisio ar ansymudedd a ddarperir gan ddefnyddwyr. Yn ogystal, nid yw'n ailddefnyddio'r data yn y cipluniau y mae'n eu trosglwyddo i'r defnyddiwr, sy'n gwneud diff yn llawer anoddach. Ar gyfer dogfennau mawr, yn syml iawn, mae ei fecanwaith trafodion sy'n seiliedig ar wahaniaethau cyfnewidiol yn annigonol. Guys, mae gennym ni eisoes WeakMap yn JavaScript. Mae'n gyfforddus.
Os rhowch y siâp a ddymunir i'r data a pheidiwch â gwneud y coed yn rhy swmpus, yna gellir osgoi'r broblem hon. Ond rwy'n chwilfrydig a fyddai FireBase yn llawer mwy diddorol pe bai'r datblygwyr yn rhyddhau API cleient da iawn a ddefnyddiodd ansymudedd ynghyd â rhywfaint o gyngor ymarferol difrifol ar ddylunio cronfa ddata. Yn lle hynny, roedd yn ymddangos eu bod yn ceisio trwsio'r hyn nad oedd wedi'i dorri, a gwnaeth hynny'n waeth.
Nid wyf yn gwybod yr holl resymeg y tu ôl i greu Firestore. Mae dyfalu am y cymhellion sy'n codi y tu mewn i'r blwch du hefyd yn rhan o'r hwyl. Mae'r cyfosodiad hwn o ddwy gronfa ddata hynod debyg ond anghymharol yn eithaf prin. Fel petai rhywun yn meddwl: "Dim ond swyddogaeth y gallwn ei hefelychu yn Google Cloud yw Firebase", ond nid yw eto wedi darganfod y cysyniad o nodi gofynion y byd go iawn neu greu atebion defnyddiol sy'n bodloni'r holl ofynion hynny. “Gadewch i'r datblygwyr feddwl am y peth. Gwnewch yr UI yn hardd ... Allwch chi ychwanegu mwy o dân?"
Rwy'n deall cwpl o bethau am strwythurau data. Rwy'n bendant yn gweld y cysyniad "popeth mewn un goeden JSON fawr" fel ymgais i dynnu unrhyw synnwyr o strwythur ar raddfa fawr o'r gronfa ddata. Mae disgwyl meddalwedd i ymdopi'n syml ag unrhyw strwythur data amheus yn wallgof. Nid oes rhaid i mi hyd yn oed ddychmygu pa mor ddrwg y gallai pethau fod, rwyf wedi gwneud archwiliadau cod trylwyr a Gwelais bethau na freuddwydiasoch chi bobl amdanynt. Ond dwi hefyd yn gwybod sut olwg sydd ar strwythurau da, и . Gallaf ddychmygu byd lle byddai Firestore yn ymddangos yn rhesymegol a'r bobl a'i creodd yn meddwl eu bod wedi gwneud gwaith da. Ond nid yn y byd hwn yr ydym yn byw.
Mae cefnogaeth ymholiad FireBase yn wael o unrhyw safon ac nid yw bron yn bodoli. Yn bendant mae angen ei wella neu o leiaf ei adolygu. Ond nid yw Firestore yn llawer gwell oherwydd ei fod yn gyfyngedig i'r un mynegeion un dimensiwn a geir yn SQL plaen. Os oes angen ymholiadau arnoch y mae pobl yn eu rhedeg ar ddata anhrefnus, mae angen chwiliad testun llawn, hidlwyr aml-ystod, ac archebu wedi'i ddiffinio gan ddefnyddiwr wedi'i deilwra. O'u harchwilio'n agosach, mae swyddogaethau SQL plaen yn rhy gyfyngedig ar eu pen eu hunain. Yn ogystal, yr unig ymholiadau SQL y gall pobl eu rhedeg wrth gynhyrchu yw ymholiadau cyflym. Bydd angen datrysiad mynegeio wedi'i deilwra arnoch chi gyda strwythurau data craff. Ar gyfer popeth arall, o leiaf dylid lleihau mapiau fesul cam neu rywbeth tebyg.
Os chwiliwch Google Docs am wybodaeth am hyn, gobeithio y cewch eich cyfeirio at rywbeth fel BigTable a BigQuery. Fodd bynnag, mae cymaint o jargon gwerthiant corfforaethol dwys yn cyd-fynd â'r holl atebion hyn y byddwch yn troi'n ôl yn gyflym ac yn dechrau chwilio am rywbeth arall.
Y peth olaf yr ydych ei eisiau gyda chronfa ddata amser real yw rhywbeth a wneir gan ac ar gyfer pobl ar raddfeydd cyflog rheolwyr.
(*) Dyma jôc, nid oes y fath beth a .
Ar Hawliau Hysbysebu
Edrych am ar gyfer prosiectau dadfygio, gweinydd ar gyfer datblygu a chynnal? Chi yw ein cleient yn bendant 🙂 Mae prisiau dyddiol ar gyfer gweinyddwyr o wahanol ffurfweddiadau, trwyddedau gwrth-DDoS a Windows eisoes wedi'u cynnwys yn y pris.
Ffynhonnell: hab.com