Lasu min rakonti teknikan historion.
Antaŭ multaj jaroj, mi disvolvis aplikaĵon kun kunlaboraj funkcioj enkonstruitaj en ĝi. Ĝi estis uzant-amika eksperimenta stako, kiu utiligis la plenan potencialon de fruaj React kaj CouchDB. Ĝi sinkronigis datumojn en reala tempo per JSON . Ĝi estis uzita interne ene de la firmao, sed ĝia larĝa aplikebleco kaj potencialo en aliaj lokoj estis klaraj.
Provante vendi ĉi tiun teknologion al eblaj klientoj, ni renkontis neatenditan malhelpon. En la demo-video, nia teknologio aspektis kaj funkciis bonege, sen problemoj tie. La video montris ĝuste kiel ĝi funkcias kaj imitis nenion. Ni elpensis kaj kodis realisman scenaron por uzi la programon.
Fakte, ĉi tio fariĝis la problemo. Nia demo funkciis ĝuste kiel ĉiuj aliaj simulis siajn aplikojn. Specife, informoj estis tuj translokigitaj de A al B, eĉ se ĝi estis grandaj amaskomunikilaj dosieroj. Post ensaluto, ĉiu uzanto vidis novajn enskribojn. Uzante la aplikaĵon, malsamaj uzantoj povus kunlabori klare pri la samaj projektoj, eĉ se la interreta konekto estis interrompita ie en la vilaĝo. Ĉi tio estas implicite implicita en ajna produkto video tranĉita en After Effects.
Kvankam ĉiuj sciis, por kio estas la Refreŝiga butono, neniu vere komprenis, ke la TTT-aplikoj, kiujn ili petis de ni konstrui, kutime estas submetitaj al siaj propraj limigoj. Kaj ke se ili ne plu bezonas, la sperto de uzanto estos tute alia. Ili plejparte rimarkis, ke ili povas "babili" lasante notojn por homoj, kun kiuj ili parolis, do ili scivolis kiel tio diferencas de, ekzemple, Slack. Huf!
Dezajno de ĉiutagaj sinkronigoj
Se vi havas sperton pri programaro, devas esti nervoze memori, ke plej multaj homoj ne povas nur rigardi bildon de interfaco kaj kompreni, kion ĝi faros interagante kun ĝi. Sen mencii kio okazas ene de la programo mem. Sciu tion povas okazi estas plejparte la rezulto de scii kio ne povas okazi kaj kio ne devus okazi. Ĉi tio postulas ne nur kion la programaro faras, sed ankaŭ kiel ĝiaj individuaj partoj estas kunordigitaj kaj komunikas inter si.
Klasika ekzemplo de tio estas uzanto rigardanta a ŝpinilo.gif, scivolante kiam la laboro finfine estos finita. La programisto estus rimarkinta, ke la procezo verŝajne estis blokita kaj ke la gif neniam malaperos de la ekrano. Ĉi tiu animacio simulas la ekzekuton de laboro, sed ne rilatas al ĝia stato. En tiaj kazoj, iuj teknikistoj ŝatas ruli la okulojn, mirigitaj pri la amplekso de uzantkonfuzo. Tamen, rimarku, kiom da ili montras al la turnanta horloĝo kaj diru, ke ĝi efektive estas senmova?
Ĉi tio estas la esenco de realtempa valoro. Nuntempe, realtempaj datumbazoj estas ankoraŭ tre malmulte uzataj kaj multaj homoj rigardas ilin kun suspekto. Plej multaj el ĉi tiuj datumbazoj multe klinas sin al la stilo NoSQL, tial ili kutime uzas solvojn bazitajn en Mongo, kiuj estas plej bone forgesitaj. Tamen, por mi ĉi tio signifas komforti labori kun CouchDB, same kiel lerni desegni strukturojn, kiujn pli ol nur iu burokrato povas plenigi per datumoj. Mi pensas, ke mi pli bone uzas mian tempon.
Sed la vera temo de ĉi tiu afiŝo estas tio, kion mi uzas hodiaŭ. Ne laŭvole, sed pro indiferente kaj blinde aplikataj kompaniaj politikoj. Do mi provizos Tute Justan kaj Senantaŭjuĝan komparon de du proksime rilataj Guglaj realtempaj datumbazaj produktoj.
Ambaŭ havas la vorton Fajro en siaj nomoj. Unu aferon mi memoras ame. La dua afero por mi estas malsama speco de fajro. Mi ne rapidas diri iliajn nomojn, ĉar post kiam mi faros, ni renkontos la unuan grandan problemon: nomojn.
La unua nomiĝas Firebase Real-Time Database, kaj dua - Firebase Cloud Firestore. Ambaŭ estas produktoj de Firebase-serio Guglo. Iliaj API-oj estas nomitaj respektive firebase.database(…) и firebase.firestore(…).
Ĉi tio okazis ĉar Realtempa datumbazo - ĝi estas nur la originalo Firebase antaŭ ĝia aĉeto de Google en 2014. Tiam Google decidis krei kiel paralela produkto kopii Firebase bazita sur granda datuma kompanio, kaj nomis ĝin Firestore kun nubo. Mi esperas, ke vi ankoraŭ ne estas konfuzita. Se vi ankoraŭ estas konfuzita, ne zorgu, mi mem dekfoje reverkis ĉi tiun parton de la artikolo.
Ĉar vi devas indiki Firebase en la demando de Firebase, kaj Fajrofarejo en demando pri Firebase, almenaŭ por komprenigi vin antaŭ kelkaj jaroj pri Stack Overflow.
Se estus premio por la plej malbona programara nomsperto, ĉi tiu certe estus unu el la defiantoj. La Hamming-distanco inter ĉi tiuj nomoj estas tiel malgranda, ke ĝi konfuzas eĉ spertajn inĝenierojn, kies fingroj tajpas unu nomon dum iliaj kapoj pensas pri alia. Ĉi tiuj estas bonintencaj planoj, kiuj mizere malsukcesas; ili plenumis la profetaĵon, ke la datumbazo ekbrulos. Kaj mi tute ne ŝercas. La persono kiu elpensis ĉi tiun nomskemon kaŭzis sangon, ŝviton kaj larmojn.
Pirra venko
Oni pensus, ke Firestore estas anstataŭaĵo Firebase, ĝia venontgeneracia posteulo, sed tio estus misgvida. Firestore ne estas garantiita esti taŭga anstataŭaĵo por Firebase. Ŝajnas, ke iu eltranĉis ĉion interesan el ĝi, kaj konfuzis la plej grandan parton de la ceteraj diversmaniere.
Tamen, rapida rigardo al la du produktoj povas konfuzi vin: ili ŝajnas fari la saman aferon, esence per la samaj API-oj kaj eĉ en la sama datumbaza sesio. La diferencoj estas subtilaj kaj estas malkaŝitaj nur per zorgema kompara studo de ampleksa dokumentado. Aŭ kiam vi provas porti kodon, kiu funkcias perfekte en Firebase, por ke ĝi funkciu kun Firestore. Eĉ tiam vi ekscias, ke la datumbaza interfaco lumiĝas tuj kiam vi provas treni kaj faligi per la muso en reala tempo. Mi ripetas, mi ne ŝercas.
La Firebase-kliento estas ĝentila en la senco, ke ĝi bufras ŝanĝojn kaj aŭtomate provas ĝisdatigojn, kiuj donas prioritaton al la lasta skriba operacio. Tamen, Firestore havas limon de 1 skriboperacio per dokumento per uzanto je sekundo, kaj ĉi tiu limo estas devigita de la servilo. Laborante kun ĝi, dependas de vi trovi manieron ĉirkaŭ ĝi kaj efektivigi ĝisdatigan indicon-limigilon, eĉ kiam vi nur provas konstrui vian aplikaĵon. Tio estas, Firestore estas realtempa datumbazo sen realtempa kliento, kiu maskas kiel unu uzanta API.
Ĉi tie ni komencas vidi la unuajn signojn de la ekzistokialo de Firestore. Mi eble eraras, sed mi suspektas, ke iu altnivela en la administrado de Guglo rigardis Firebase post la aĉeto kaj simple diris: "Ne, ho mia Dio, ne. Ĉi tio estas neakceptebla. Nur ne sub mia gvidado."
Li aperis el siaj ĉambroj kaj deklaris:
"Unu granda JSON-dokumento? Ne. Vi dividos la datumojn en apartajn dokumentojn, ĉiu el kiuj havos ne pli ol 1 megabajto.
Ŝajnas, ke tia limigo ne postvivos la unuan renkonton kun iu sufiĉe motivita uzantbazo. Vi scias, ke ĝi estas. Ĉe la laboro, ekzemple, ni havas pli ol unu kaj duonon mil prezentojn, kaj ĉi tio estas Tute Normala.
Kun ĉi tiu limigo, vi estos devigita akcepti la fakton, ke unu "dokumento" en la datumbazo ne similos al iu ajn objekto, kiun uzanto povus nomi dokumento.
"Tabeloj de tabeloj kiuj povas rekursie enhavi aliajn elementojn? Ne. Tabeloj enhavos nur fikslongajn objektojn aŭ nombrojn, kiel Dio intencis."
Do se vi esperus meti GeoJSON en vian Firestore, vi trovos, ke tio ne eblas. Nenio neunudimensia estas akceptebla. Mi esperas, ke vi ŝatas Base64 kaj/aŭ JSON ene de JSON.
"JSON-importo kaj eksporto per HTTP, komandliniaj iloj aŭ administra panelo? Ne. Vi nur povos eksporti kaj importi datumojn al Google Cloud Storage. Tiel ĝi nomiĝas nun, mi pensas. Kaj kiam mi diras "vi", mi alparolas nur tiujn, kiuj havas akreditaĵojn pri Projektposedanto. Ĉiuj aliaj povas iri kaj krei biletojn."
Kiel vi povas vidi, la datummodelo de FireBase estas facile priskribi. Ĝi enhavas unu grandegan JSON-dokumenton, kiu asocias JSON-ŝlosilojn kun URL-vojoj. Se vi skribas kun HTTP PUT в / FireBase estas la sekva:
{
"hello": "world"
}
La GET /hello revenos "world". Esence ĝi funkcias ĝuste kiel vi atendus. Kolekto de FireBase-objektoj /my-collection/:id ekvivalenta al JSON-vortaro {"my-collection": {...}} en la radiko, kies enhavo estas disponebla en /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Ĉi tio funkcias bone se ĉiu enmetaĵo havas senkolizion identigilon, por kiu la sistemo havas norman solvon.
Alivorte, la datumbazo estas 100% kongrua kun JSON (*) kaj funkcias bonege kun HTTP, kiel CouchDB. Sed esence vi uzas ĝin per realtempa API, kiu abstraktas retejojn, rajtigojn kaj abonojn. La administra panelo havas ambaŭ kapablojn, permesante ambaŭ realtempan redaktadon kaj JSON-importadon/eksporton. Se vi faras la samon en via kodo, vi surprizos kiom da speciala kodo malŝparos kiam vi rimarkas, ke flikaĵo kaj diferenco JSON solvas 90% de la rutinaj taskoj pri traktado de konstanta stato.
La datummodelo de Firestore estas simila al JSON, sed malsamas en kelkaj kritikaj manieroj. Mi jam menciis la mankon de tabeloj ene de tabeloj. La modelo por subkolektoj estas ke ili estu unuaklasaj konceptoj, apartaj de la JSON-dokumento kiu enhavas ilin. Ĉar ne ekzistas preta seriigo por tio, speciala kodvojo estas postulata por preni kaj skribi datumojn. Por prilabori viajn proprajn kolektojn, vi devas skribi viajn proprajn skriptojn kaj ilojn. La administra panelo nur permesas fari malgrandajn ŝanĝojn unu kampon samtempe, kaj ne havas importajn/eksportajn kapablojn.
Ili prenis realtempan NoSQL-datumbazon kaj transformis ĝin en malrapidan ne-SQL kun aŭtomata aliĝo kaj aparta ne-JSON-kolumno. Io kiel GraftQL.
Varma Java
Se Firestore devis esti pli fidinda kaj skalebla, tiam la ironio estas, ke la averaĝa programisto finos kun malpli fidinda solvo ol elekti FireBase el la skatolo. La speco de programaro, kiun bezonas la Grumpy Database Administrator, postulas nivelon de penado kaj kalibro de talento, kiu estas simple nerealisma por la niĉo, pri kiu la produkto laŭsupoze estas bona. Ĉi tio similas al kiel HTML5 Canvas tute ne anstataŭas Flash se ne ekzistas evoluiloj kaj ludanto. Plie, Firestore estas enŝlimigita en deziro al datumpureco kaj sterila validumado, kiu simple ne kongruas kun kiel la averaĝa komerca uzanto. amas labori: por li ĉio estas laŭvola, ĉar ĝis la fino ĉio estas malneto.
La ĉefa malavantaĝo de FireBase estas, ke la kliento estis kreita plurajn jarojn antaŭ sia tempo, antaŭ ol la plej multaj retejo-programistoj sciis pri neŝanĝebleco. Pro ĉi tio, FireBase supozas, ke vi ŝanĝos la datumojn kaj tial ne utiligas neŝanĝeblecon provizitan de uzanto. Aldone, ĝi ne reuzas la datumojn en la momentfotoj kiujn ĝi transdonas al la uzanto, kio faras diferencon multe pli malfacila. Por grandaj dokumentoj, ĝia ŝanĝebla dif-bazita transakcia mekanismo estas simple neadekvata. Knaboj, ni jam havas WeakMap en JavaScript. Estas komforta.
Se vi donas al la datumoj la deziratan formon kaj ne faras la arbojn tro grandajn, tiam ĉi tiu problemo povas esti evitita. Sed mi scivolas, ĉu FireBase estus multe pli interesa se la programistoj publikigus vere bonan klientan API, kiu uzis neŝanĝeblecon kombinitan kun iuj seriozaj praktikaj konsiloj pri datumbaza dezajno. Anstataŭe, ili ŝajnis provi ripari tion, kio ne estis rompita, kaj tio plimalbonigis ĝin.
Mi ne konas la tutan logikon malantaŭ la kreado de Firestore. Konjekti pri la motivoj kiuj ŝprucas ene de la nigra skatolo ankaŭ estas parto de la amuzo. Ĉi tiu apudmeto de du ekstreme similaj sed nekompareblaj datumbazoj estas sufiĉe malofta. Kvazaŭ iu pensus: "Firebase estas nur funkcio, kiun ni povas imiti en Google Cloud", sed ankoraŭ ne malkovris la koncepton de identigado de real-mondaj postuloj aŭ kreado de utilaj solvoj kiuj renkontas ĉiujn tiujn postulojn. "Lasu la programistojn pensi pri ĝi. Nur beligu la UI... Ĉu vi povas aldoni pli da fajro?"
Mi komprenas kelkajn aferojn pri datumstrukturoj. Mi certe vidas la koncepton "ĉio en unu granda JSON-arbo" kiel provo abstrakti ajnan senton de grandskala strukturo de la datumbazo. Atendi programaron simple trakti ajnan dubindan datumstrukturan fraktalon estas simple freneza. Mi eĉ ne devas imagi, kiel malbonaj aferoj povus esti, mi faris rigorajn kodajn reviziojn kaj Mi vidis aferojn, pri kiuj vi neniam revis. Sed mi ankaŭ scias, kiel aspektas bonaj strukturoj, и . Mi povas imagi mondon kie Firestore ŝajnus logika kaj la homoj kiuj kreis ĝin pensus ke ili faris bonan laboron. Sed ni ne vivas en ĉi tiu mondo.
La demandsubteno de FireBase estas malbona laŭ iu normo kaj estas preskaŭ neekzistanta. Ĝi certe bezonas plibonigon aŭ almenaŭ revizion. Sed Firestore ne estas multe pli bona ĉar ĝi estas limigita al la samaj unudimensiaj indeksoj trovitaj en simpla SQL. Se vi bezonas demandojn, kiujn homoj funkcias per ĥaosaj datumoj, vi bezonas plentekstan serĉon, mult-intervalajn filtrilojn kaj kutiman uzant-difinitan mendon. Post pli proksima inspektado, la funkcioj de simpla SQL estas tro limigitaj per si mem. Aldone, la nuraj SQL-demandoj kiujn homoj povas ruli en produktado estas rapidaj demandoj. Vi bezonos kutiman indeksan solvon kun pripensemaj datumstrukturoj. Por ĉio alia, devus almenaŭ esti pliiga mapo-redukto aŭ io simila.
Se vi serĉas informojn pri ĉi tio en Google Docs, vi espereble estos direktita al io kiel BigTable kaj BigQuery. Tamen, ĉiuj ĉi tiuj solvoj estas akompanitaj de tiom da densa kompania venda ĵargono, ke vi rapide returniĝos kaj komencos serĉi ion alian.
La lasta afero, kiun vi volas kun realtempa datumbazo, estas io farita de kaj por homoj en administraj salajroskaloj.
(*) Ĉi tio estas ŝerco, ne ekzistas tia .
Pri la Rajtoj de Reklamado
Serĉas por sencimigaj projektoj, servilo por disvolviĝo kaj gastigado? Vi certe estas nia kliento 🙂 Ĉiutaga prezo por serviloj de diversaj agordoj, kontraŭ-DDoS kaj Vindozaj permesiloj jam estas inkluzivitaj en la prezo.
fonto: www.habr.com