Database hii inawaka moto...

Hebu nieleze hadithi ya kiufundi.

Miaka mingi iliyopita, nilikuwa nikitengeneza programu iliyo na vipengele vya ushirikiano vilivyojengwa ndani yake. Ilikuwa ni rundo la majaribio linalofaa mtumiaji ambalo lilichukua fursa ya uwezo kamili wa React mapema na CouchDB. Ilisawazisha data kwa wakati halisi kupitia JSON OT. Ilitumika ndani ya kampuni, lakini utumiaji wake mpana na uwezo katika maeneo mengine ulikuwa wazi.

Tulipokuwa tukijaribu kuuza teknolojia hii kwa wateja watarajiwa, tulikumbana na kikwazo kisichotarajiwa. Katika video ya onyesho, teknolojia yetu ilionekana na ilifanya kazi vizuri, hakuna matatizo hapo. Video hiyo ilionyesha jinsi inavyofanya kazi na haikuiga chochote. Tulikuja na kuweka msimbo hali halisi ya kutumia programu.


Kwa kweli, hii ikawa shida. Onyesho letu lilifanya kazi kama vile kila mtu mwingine aliiga programu zao. Hasa, habari ilihamishwa papo hapo kutoka A hadi B, hata ikiwa ni faili kubwa za midia. Baada ya kuingia, kila mtumiaji aliona maingizo mapya. Kwa kutumia programu, watumiaji mbalimbali wanaweza kufanya kazi pamoja kwa uwazi kwenye miradi ile ile, hata kama muunganisho wa Mtandao ulikatizwa mahali fulani kijijini. Hii inaonyeshwa kwa uwazi katika video yoyote iliyokatwa katika After Effects.

Ingawa kila mtu alijua kitufe cha Kuonyesha upya kilikuwa cha nini, hakuna mtu aliyeelewa kwa hakika kwamba programu za wavuti ambazo walituomba tuunde kwa kawaida zilikuwa chini ya vikwazo vyao wenyewe. Na kwamba ikiwa hazihitajiki tena, uzoefu wa mtumiaji utakuwa tofauti kabisa. Waligundua zaidi kuwa wangeweza "kuzungumza" kwa kuacha maelezo kwa watu waliokuwa wakizungumza nao, kwa hivyo walishangaa jinsi hii ilikuwa tofauti na, kwa mfano, Slack. Phew!

Muundo wa usawazishaji wa kila siku

Ikiwa una uzoefu katika uundaji wa programu, lazima iwe ya kusisimua kukumbuka kuwa watu wengi hawawezi tu kuangalia picha ya kiolesura na kuelewa itafanya nini wakati wa kuingiliana nayo. Bila kutaja kile kinachotokea ndani ya programu yenyewe. Maarifa hayo Unaweza kutokea kwa kiasi kikubwa ni matokeo ya kujua nini hakiwezi kutokea na nini haipaswi kutokea. Hii inahitaji mfano wa kiakili sio tu kile programu hufanya, lakini pia jinsi sehemu zake za kibinafsi zinavyoratibiwa na kuwasiliana na kila mmoja.

Mfano mzuri wa hii ni mtumiaji anayeangalia a spinner.gif, wakishangaa ni lini kazi hiyo itakamilika hatimaye. Msanidi programu angegundua kuwa mchakato huo labda ulikwama na kwamba gif haitatoweka kwenye skrini. Uhuishaji huu unaiga utekelezaji wa kazi, lakini hauhusiani na hali yake. Katika hali kama hizi, techi zingine hupenda kurudisha macho yao, wakishangaa kwa kiwango cha kuchanganyikiwa kwa watumiaji. Hata hivyo, ona ni wangapi kati yao wanaoelekezea saa inayozunguka na kusema kwamba kwa kweli imesimama?

Hiki ndicho kiini cha thamani ya wakati halisi. Siku hizi, hifadhidata za wakati halisi bado hazitumiki sana na watu wengi huzitazama kwa mashaka. Nyingi za hifadhidata hizi hutegemea sana mtindo wa NoSQL, ndiyo maana kwa kawaida hutumia suluhu zenye msingi wa Mongo, ambazo husahaulika vyema. Walakini, kwangu hii inamaanisha kupata starehe kufanya kazi na CouchDB, na pia kujifunza kuunda miundo ambayo zaidi ya urasimu fulani inaweza kujaza data. Nadhani ninatumia wakati wangu vizuri zaidi.

Lakini mada halisi ya chapisho hili ndio ninayotumia leo. Sio kwa hiari, lakini kwa sababu ya sera za ushirika zilizotumika bila kujali na kwa upofu. Kwa hivyo nitatoa ulinganisho wa Haki Kabisa na Usiopendelea wa bidhaa mbili za hifadhidata za wakati halisi zinazohusiana kwa karibu.

Wote wawili wana neno Moto katika majina yao. Jambo moja nakumbuka sana. Jambo la pili kwangu ni aina tofauti ya moto. Sina haraka ya kusema majina yao, kwa sababu mara nitakapofanya, tutaingia kwenye shida kubwa ya kwanza: majina.

Ya kwanza inaitwa Hifadhidata ya Muda Halisi ya Firebase, na pili - Firebase Cloud Firestore. Wote wawili ni bidhaa kutoka Sehemu ya Firebase Google. API zao zinaitwa kwa mtiririko huo firebase.database(…) и firebase.firestore(…).

Hii ilitokea kwa sababu Hifadhidata ya Wakati Halisi - ni asili tu Moto kabla ya kununuliwa na Google mnamo 2014. Kisha Google ikaamua kuunda kama bidhaa sambamba nakala Firebase kulingana na kampuni kubwa ya data, na ikaiita Firestore yenye wingu. Natumaini bado hujachanganyikiwa. Ikiwa bado umechanganyikiwa, usijali, mimi mwenyewe niliandika tena sehemu hii ya makala mara kumi.

Kwa sababu unahitaji kuonyesha Moto katika swali la Firebase, na Firestore katika swali kuhusu Firebase, angalau ili kukufanya uelewe miaka michache iliyopita kwenye Stack Overflow.

Ikiwa kungekuwa na tuzo kwa uzoefu mbaya zaidi wa kutaja programu, hakika huyu angekuwa mmoja wa wagombea. Umbali wa Hamming kati ya majina haya ni mdogo sana hivi kwamba unachanganya hata wahandisi wazoefu ambao vidole vyao vinaandika jina moja huku vichwa vyao vikifikiria lingine. Hii ni mipango yenye nia njema ambayo inashindwa vibaya; walitimiza unabii kwamba hifadhidata itawaka moto. Na sitanii hata kidogo. Aliyekuja na mpango huu wa kutaja majina alisababisha damu, jasho na machozi.

Ushindi wa Pyrrhic

Mtu anaweza kufikiri kwamba Firestore ni uingizwaji Firebase, kizazi chake kijacho, lakini hiyo itakuwa ya kupotosha. Firestore haijahakikishiwa kuwa mbadala unaofaa wa Firebase. Inaonekana mtu alikata kila kitu cha kupendeza kutoka kwayo, na kuwachanganya wengine kwa njia tofauti.

Walakini, mtazamo wa haraka wa bidhaa hizo mbili unaweza kukuchanganya: zinaonekana kufanya jambo lile lile, kupitia API zile zile na hata katika kikao sawa cha hifadhidata. Tofauti ni hila na zinafunuliwa tu kwa uchunguzi wa makini wa kulinganisha wa nyaraka za kina. Au unapojaribu kuweka msimbo unaofanya kazi kikamilifu kwenye Firebase ili ifanye kazi na Firestore. Hata hivyo utagundua kuwa kiolesura cha hifadhidata huwaka mara tu unapojaribu kuburuta na kuacha na kipanya kwa wakati halisi. Narudia, sifanyi mzaha.

Kiteja cha Firebase ni adabu kwa maana kwamba huhifadhi mabadiliko na hujaribu tena kiotomatiki masasisho ambayo yanaipa kipaumbele utendakazi wa mwisho wa uandishi. Hata hivyo, Firestore ina kikomo cha operesheni 1 ya kuandika kwa kila hati kwa kila mtumiaji kwa sekunde, na kikomo hiki kinatekelezwa na seva. Unapofanya kazi nayo, ni juu yako kutafuta njia ya kuizunguka na kutekeleza kikomo cha kusasisha, hata unapojaribu tu kuunda programu yako. Hiyo ni, Firestore ni hifadhidata ya wakati halisi bila mteja wa wakati halisi, ambayo hujifanya kuwa mtu anayetumia API.

Hapa tunaanza kuona dalili za kwanza za raison d'être ya Firestore. Huenda nimekosea, lakini ninashuku kuwa mtu fulani aliye juu katika usimamizi wa Google aliangalia Firebase baada ya kununua na kusema, “Hapana, Mungu wangu, hapana. Hili halikubaliki. Sio chini ya uongozi wangu tu."

Alitokea katika vyumba vyake na akasema:

“Hati moja kubwa ya JSON? Hapana. Utagawanya data katika hati tofauti, ambayo kila moja haitakuwa zaidi ya megabyte 1 kwa saizi.

Inaonekana kwamba kizuizi kama hicho hakitadumu kwa mkutano wa kwanza na msingi wowote wa watumiaji wenye motisha ya kutosha. Unajua ni. Kazini, kwa mfano, tuna maonyesho zaidi ya elfu moja na nusu, na hii ni ya Kawaida kabisa.

Kwa kikomo hiki, utalazimika kukubali ukweli kwamba "hati" moja katika hifadhidata haitafanana na kitu chochote ambacho mtumiaji anaweza kuiita hati.

"Safu za safu ambazo zinaweza kuwa na vitu vingine kwa kujirudia? Hapana. Mkusanyiko utakuwa na vitu au nambari za urefu usiobadilika, kama Mungu alivyokusudia."

Kwa hivyo ikiwa ulitarajia kuweka GeoJSON kwenye Firestore yako, utagundua kuwa hii haiwezekani. Hakuna kitu kisicho na mwelekeo mmoja kinachokubalika. Natumai unapenda Base64 na/au JSON ndani ya JSON.

"JSON kuingiza na kuuza nje kupitia HTTP, zana za mstari wa amri au paneli ya msimamizi? Hapana. Utaweza tu kuhamisha na kuleta data kwenye Hifadhi ya Wingu la Google. Hiyo ndiyo inaitwa sasa, nadhani. Na ninaposema "wewe," ninazungumza tu na wale walio na vitambulisho vya Wamiliki wa Mradi. Kila mtu mwingine anaweza kwenda kutengeneza tikiti."

Kama unavyoona, modeli ya data ya FireBase ni rahisi kuelezea. Ina hati moja kubwa ya JSON inayohusisha funguo za JSON na njia za URL. Ikiwa unaandika na HTTP PUT в / FireBase ni kama ifuatavyo:

{
  "hello": "world"
}

Hiyo GET /hello itarudi "world". Kimsingi inafanya kazi kama vile unavyotarajia. Mkusanyiko wa vitu vya FireBase /my-collection/:id sawa na kamusi ya JSON {"my-collection": {...}} kwenye mzizi, yaliyomo ambayo yanapatikana ndani /my-collection:

{
  "id1": {...object},
  "id2": {...object},
  "id3": {...object},
  // ...
}

Hii inafanya kazi vizuri ikiwa kila kiingilio kina kitambulisho kisicho na mgongano, ambacho mfumo una suluhisho la kawaida.

Kwa maneno mengine, hifadhidata inaendana 100% JSON(*) na inafanya kazi vizuri na HTTP, kama vile CouchDB. Lakini kimsingi unaitumia kupitia API ya wakati halisi ambayo huchota soketi za wavuti, uidhinishaji, na usajili. Paneli ya msimamizi ina uwezo wote wawili, kuruhusu uhariri wa wakati halisi na uletaji/usafirishaji wa JSON. Ukifanya vivyo hivyo katika nambari yako ya kuthibitisha, utashangaa ni kiasi gani cha nambari maalum kitapotezwa ukigundua kuwa kiraka na tofauti JSON hutatua 90% ya kazi za kawaida za kushughulikia hali inayoendelea.

Mtindo wa data wa Firestore ni sawa na JSON, lakini hutofautiana katika baadhi ya njia muhimu. Tayari nilitaja ukosefu wa safu ndani ya safu. Mfano wa mikusanyo midogo ni kwa wao kuwa dhana za daraja la kwanza, tofauti na hati ya JSON iliyo nazo. Kwa kuwa hakuna utayarishaji tayari kwa hili, njia maalum ya msimbo inahitajika ili kurejesha na kuandika data. Ili kuchakata mikusanyiko yako mwenyewe, unahitaji kuandika hati na zana zako mwenyewe. Paneli ya msimamizi hukuruhusu tu kufanya mabadiliko madogo sehemu moja kwa wakati mmoja, na haina uwezo wa kuagiza/kusafirisha nje.

Walichukua hifadhidata ya wakati halisi ya NoSQL na kuigeuza kuwa SQL isiyo ya polepole iliyo na ujumuishaji kiotomatiki na safu tofauti isiyo ya JSON. Kitu kama GraftQL.

Moto Java

Ikiwa Firestore ilipaswa kuwa ya kutegemewa zaidi na yenye kuenea, basi kinaya ni kwamba msanidi wa wastani ataishia na suluhisho lisilotegemewa zaidi kuliko kuchagua FireBase nje ya boksi. Aina ya programu ambayo Msimamizi wa Hifadhidata ya Grumpy anahitaji inahitaji kiwango cha juhudi na kiwango cha talanta ambacho sio kweli kwa niche ambayo bidhaa inapaswa kuwa nzuri. Hii ni sawa na jinsi HTML5 Canvas si mbadala wa Flash hata kidogo ikiwa hakuna zana za ukuzaji na kichezaji. Zaidi ya hayo, Firestore imejaa tamaa ya usafi wa data na uthibitishaji tasa ambao hauambatani na jinsi mtumiaji wastani wa biashara. anapenda kufanya kazi: kwake kila kitu ni hiari, kwa sababu hadi mwisho kila kitu ni rasimu.

Ubaya kuu wa FireBase ni kwamba mteja aliundwa miaka kadhaa kabla ya wakati wake, kabla ya watengenezaji wengi wa wavuti kujua juu ya kutoweza kubadilika. Kwa sababu hii, FireBase inachukulia kuwa utabadilisha data na kwa hivyo haichukui fursa ya kutoweza kubadilika iliyotolewa na mtumiaji. Zaidi ya hayo, haitumii tena data katika vijipicha ambavyo hupitisha kwa mtumiaji, ambayo hufanya tofauti kuwa ngumu zaidi. Kwa hati kubwa, utaratibu wake wa muamala unaoweza kubadilika kulingana na tofauti hautoshi. Jamani, tayari tunayo WeakMap katika JavaScript. Ni vizuri.

Ikiwa unapeana data sura inayotaka na usifanye miti kuwa mnene sana, basi shida hii inaweza kuzungushwa. Lakini ninatamani kujua ikiwa FireBase ingependeza zaidi ikiwa watengenezaji watatoa API nzuri ya mteja ambayo ilitumia kutoweza kubadilika pamoja na ushauri mzito wa vitendo juu ya muundo wa hifadhidata. Badala yake, walionekana kujaribu kurekebisha kile ambacho hakijavunjwa, na hiyo ilifanya iwe mbaya zaidi.

Sijui mantiki yote nyuma ya uundaji wa Firestore. Kubashiri kuhusu nia zinazotokea ndani ya kisanduku cheusi pia ni sehemu ya furaha. Muunganisho huu wa hifadhidata mbili zinazofanana sana lakini zisizoweza kulinganishwa ni nadra sana. Ni kama mtu alifikiria: "Firebase ni utendaji tu ambao tunaweza kuiga katika Google Cloud", lakini bado haijagundua dhana ya kutambua mahitaji ya ulimwengu halisi au kuunda masuluhisho muhimu ambayo yanakidhi mahitaji hayo yote. "Wacha watengenezaji wafikirie juu yake. Ifanye tu UI kuwa nzuri... Je, unaweza kuongeza moto zaidi?”

Ninaelewa mambo kadhaa kuhusu miundo ya data. Kwa kweli naona wazo la "kila kitu katika mti mmoja mkubwa wa JSON" kama jaribio la kufikiria hisia zozote za muundo wa kiwango kikubwa kutoka kwa hifadhidata. Kutarajia programu kukabiliana tu na muundo wowote wa data mbaya ni wazimu. Sihitaji hata kufikiria jinsi mambo yanaweza kuwa mabaya, nimefanya ukaguzi mkali wa kificho na Niliona mambo ambayo ninyi watu hamkuwahi kuyaota. Lakini pia najua muundo mzuri unaonekanaje, jinsi ya kuzitumia и kwa nini hili lifanyike. Ninaweza kufikiria ulimwengu ambapo Firestore ingeonekana kuwa yenye mantiki na watu walioiunda wangefikiri walifanya kazi nzuri. Lakini hatuishi katika ulimwengu huu.

Usaidizi wa hoja wa FireBase ni duni kwa kiwango chochote na kwa kweli haupo. Kwa hakika inahitaji uboreshaji au angalau marekebisho. Lakini Firestore sio bora zaidi kwa sababu ni mdogo kwa faharisi sawa za mwelekeo mmoja zinazopatikana katika SQL wazi. Iwapo unahitaji maswali ambayo watu huendesha kwenye data yenye fujo, unahitaji utafutaji wa maandishi kamili, vichujio vya masafa mbalimbali na uagizaji maalum uliobainishwa na mtumiaji. Baada ya ukaguzi wa karibu, kazi za SQL wazi ni mdogo sana peke yao. Zaidi ya hayo, hoja pekee za SQL ambazo watu wanaweza kukimbia katika uzalishaji ni maswali ya haraka. Utahitaji suluhisho maalum la kuorodhesha na miundo ya data inayofikiria. Kwa kila kitu kingine, kunapaswa angalau kuwe na upunguzaji wa ramani unaoongezeka au kitu sawa.

Ukitafuta Hati za Google kwa maelezo kuhusu hili, tunatumai kuwa utaelekezwa upande wa kitu kama BigTable na BigQuery. Walakini, suluhisho hizi zote zinaambatana na jargon mnene sana ya mauzo ya kampuni hivi kwamba utarudi nyuma na kuanza kutafuta kitu kingine.

Kitu cha mwisho unachotaka na hifadhidata ya wakati halisi ni kitu kilichotengenezwa na kwa watu kwenye mizani ya malipo ya usimamizi.

(*) Huu ni mzaha, hakuna kitu kama 100% ya JSON inayotumika.

Haki za Matangazo

Tafuta VDS kwa miradi ya utatuzi, seva ya ukuzaji na mwenyeji? Hakika wewe ni mteja wetu 🙂 Bei za kila siku za seva za usanidi mbalimbali, leseni za anti-DDoS na Windows tayari zimejumuishwa kwenye bei.

Chanzo: mapenzi.com